Prompt engineering optimizes one string. Context engineering optimizes everything the model sees at inference time — and for any system running longer than a single turn, that's the discipline that actually determines cost, latency, and reliability.

A large context window feels like it removes the constraint entirely. It doesn't — it just changes where the cost shows up, from truncation bugs to degraded attention and higher latency.

Closing out this series' month of daily posts with an honest look at what actually held up under real use, and what needed revision from the early, more idealized picture."

If specs are accurate and current — the whole premise of this series — they're a better source for user-facing and internal documentation than reverse-engineering it from code or comments after the fact.

A database migration is one of the few changes in a codebase that's genuinely hard to fully reverse once applied to production data. That irreversibility deserves its own spec discipline.

An API's contract outlives its first implementation by a wide margin, and changing it later means coordinating with every consumer. That asymmetry is the argument for specifying it before writing code.

Infrastructure changes have a higher blast radius than application code changes if something goes wrong, which makes them a strong candidate for spec-driven discipline — and a distinct set of things a spec needs to cover.

Retrofitting specs onto a vibe-coded prototype that's outgrown its origins — without a big-bang rewrite. A practical playbook for the transition, closing out this series.

Three real categories of spec-driven development going wrong, each illustrating a failure mode this series has discussed in the abstract — concrete enough to recognize when it's happening to you.

Pairing directly with an agent, spec open in a second pane, changes the interaction pattern from most agentic coding sessions — fewer big autonomous leaps, more of a genuine back-and-forth.