Own the architecture before you prompt

¶Why architecture is the leverage point now

When typing was the bottleneck, architecture competed with shipping for your time. When a model types for you, the bottleneck moves: the constraint is no longer "can I write it" but "do I know exactly what should be written, and can I tell when it is wrong." Both are architecture. The skill the market now pays for is deciding the shape of the system — and a model amplifies that decision, for better or worse, faster than ever.

¶The five lines you write before any prompt

Architecture for a single feature is not a diagram tool. It is five answers you can write in a comment block:

• Boundary — what is in this change and what is explicitly NOT.
• Data — the shape that flows in and the shape that flows out.
• Contracts — the function/endpoint signatures other code depends on.
• State — what persists, where, and who is allowed to change it.
• Failure — the two or three ways this realistically breaks.

Feature: "Save draft" on the post editor.
- Boundary: client autosave + one API route. NOT versioning, NOT collaboration.
- Data: { postId, body, updatedAt } in → { ok, savedAt } out.
- Contract: POST /api/posts/:id/draft  (auth required, owner only).
- State: one row per post in post_draft; last-write-wins.
- Failure: offline (queue + retry), not-owner (403), body too large (413).