The unit of work in AI-assisted development is the decision, not the line of code

Treating AI-assisted development as code generation produces a recognizable failure mode. The engineer writes a vague prompt. "Build the booking module." The agent generates something. The engineer reviews, finds problems, sends a follow-up. The agent fixes some, breaks others. After three or four rounds, the work is done but the engineer cannot explain what they shipped. The codebase grows opaque to the person who built it. I learned this the way most people learn it: by trying the alternative first. Early on, I would write a long prompt describing an entire feature and hand it to the agent in one shot. The output looked impressive at first scan. The problems surfaced later — edge cases unhandled, conventions silently violated, assumptions baked in that conflicted with the rest of the codebase. Each round of fixes introduced new divergences. The work technically shipped, but the system underneath was incoherent. This happens because there were no decisions made before the code was written. The engineer outsourced the decisions to the agent's defaults. The agent made reasonable choices, but reasonable choices accumulated without intent produce a system that works by accident.

The alternative is to encode the decisions explicitly, before code is written. The framework is not new. Computational thinking, taught as one of the four foundational components of computer science alongside pattern recognition, abstraction, and algorithm design, has always advocated for decomposition as the first move on any complex problem. Break the problem into smaller sub-problems. Solve each in isolation. Compose the solutions back together. What changed with AI agents is not the principle. It is who executes the sub-problems. The engineer still decomposes. The agent now implements.

I work through what I call milestone-based prompting. Each milestone is a self-contained brief that encodes a single decision unit. Scope small enough to verify by eye, usually one to four files. Explicit acceptance criteria. Named dependencies on prior milestones. A clear handoff to the next milestone. The structure is the same every time, five interconnected sections: Context loaded once per session through a project brief that establishes architecture decisions, conventions, and the current build state. This sits at the top of the session, anchoring everything that follows. Then for each milestone in sequence: prerequisites that name what must be true before starting, the prompt itself encoding the work to be done, acceptance criteria defining what done looks like, gotchas surfacing what could go wrong, and a pointer to the next milestone. Each section feeds the next. The context grounds the prompt. The prerequisites prevent skipped foundations. The acceptance criteria gate progression. The gotchas are the lessons that compound across milestones. When this works, something interesting happens. The agent, given a bounded scope and clear acceptance criteria, often catches edge cases and implementation details I missed. The decomposition does not just reduce the risk of bad output. It creates a focused surface where the agent's pattern-matching can act as a second pair of eyes on the work I already specified. When it does not work, the response is targeted, not catastrophic. A small follow-up prompt addressing the specific divergence from project goals. Not a restart. Not a new session. The agent corrects against the same context that produced the original output. The cost of an iteration is bounded. Each milestone is a commit. The commit message names the milestone. The git history becomes a narrative of decisions, not a stream of changes.