Nestor G Pestelos Jr · Writing · Print

When the AI Writes the Code, the Plan Becomes the Work

Published August 11, 2026. Revised September 3, 2026.

TL;DR

When AI collapses the cost of coding, Fred Brooks's essential complexity (deciding what to build) becomes most of the job. The plan is the authored artifact now, not bureaucratic upfront design, but unread code still ships bugs.

The August 11, 2026 version is at ai-writes-code-plan-becomes-work-20260811.

In No Silver Bullet, Fred Brooks argued that writing code was never the hard part of software engineering. The hard part was deciding what to build. Brooks divided the work into "essential complexity" (specifying a coherent system) and "accidental complexity" (expressing that design in machine syntax). He predicted tools would never eliminate the essential part, because intent requires original thought.

For decades, that distinction felt theoretical. Writing code remained the visible bulk of engineering. Developers typed every file, reviewed pull requests line by line, and understood systems by reading implementation. When models began generating full implementations in minutes, Brooks's distinction became operational reality. When accidental complexity approaches zero, essential complexity remains. Deciding what to build is now most of the job.

The inversion

Salvatore Sanfilippo, creator of Redis, stated the shift plainly. If you control the architecture, line-by-line review of generated code is "suboptimal and often pointless." Sanfilippo captures ideas in a design document and lets the model regenerate the implementation. Mark Essien described his routine the same way: hours authoring and validating a plan, followed by twenty minutes of code generation. "The plan is now the coding, not the coding."

The plan becomes the primary authored artifact. It holds the architecture, constraints, acceptance tests, and trade-offs that raw syntax cannot explain. The code becomes compiled output that you regenerate instead of patching by hand. Don Norman's analysis of automation captures this transition: automating mechanical execution elevates the human role to high-level guidance. The scarce skill shifts from producing syntax to specifying intent. Code review stops checking syntax trivia and starts verifying architectural boundaries.

The lesson is not "plan more"

Bureaucratic specification was friction before AI, and it remains friction now. A forty-page requirements binder that nobody executes confuses accidental bureaucracy with essential thought. Elevating the plan does not revive Big Design Up Front. The Agile Manifesto authors correctly prioritized "responding to change" over "following a plan." That warning holds if modern planning reverts to exhaustive upfront documentation.

What relocates upstream is clarity of intent, not administrative ceremony. Authors must define essential decisions: purpose, governing constraints, and correctness criteria. Skip boilerplate that a competent model can derive. In practice, this mirrors Gojko Adzic's *Specification by Example*: an executable specification stays current because tests enforce it. The most effective plan resembles an architecture decision record with test assertions. Bloated plans rot quickly, competing for the attention they were meant to save.

Where the model breaks

Treating this inversion as an absolute creates four failure modes.

First, unread code ships vulnerabilities. In a 2022 NYU study, researchers tested GitHub Copilot across high-risk CWE scenarios, including MITRE's Top 25. Roughly forty percent of generated programs contained exploitable flaws, reproducing insecure training data. Logic inspection does not vanish; it shifts to type systems, compiler invariants, and comprehensive test suites.

Second, plans govern intent, not runtime behavior. Charity Majors's critique of specification worship applies directly. Identical logic behaves unpredictably across hardware limits, network partitions, and traffic spikes. Telemetry and runtime observability reveal actual behavior. Confusing intent with runtime reality leaves production blind.

Third, the map is not the territory. As Thariq observes in A Field Guide to Fable, a plan only represents the intended work. When an autonomous model hits an unstated edge case, it guesses. Across multi-step tasks, guesses compound into behavioral drift. Effective plans are living documents adjusted as execution reveals unmodeled realities.

Fourth, velocity amplifies errors. A flawed plan builds the wrong system in twenty minutes, and downstream tasks inherit the broken foundation. Speed makes bad planning expensive. Keeping plans small ensures mistakes remain cheap to correct.

Upstream intent and the learning gap

These limits do not invalidate the inversion; they define its boundaries. Working upstream requires clear intent and verification gates, not bureaucratic paper trails.

This shift creates a training paradox that Sanfilippo acknowledged. If junior engineers never inspect and debug raw implementation, they cannot develop the intuition to separate essential complexity from accidental detail. Senior judgment historically came from years of reading, repairing, and maintaining fragile code. An industry that only authors plans and regenerates code provides no clear path to train future planners.

What engineers author today is intent: the statement of what must hold true, and the constraints that verify generated output. Engineers who excel will not write the longest documents. They will isolate essential complexity from accidental mechanics, and record only the essential.

Fred Brooks would recognize this paradigm. The hard challenge was always deciding what to build. We finally have machines fast enough that specifying intent comprises most of the engineering work that remains.

Sources

Back to top