For a long time, the expensive part of software development was implementation.
That shaped our process. We invested heavily in requirements, analysis, architecture, design documents, estimation, and planning before anyone started building. When a feature takes weeks or months to implement, that approach makes sense. Changing direction late is expensive.
LLM coding agents change the economics.
Given a clear enough task and a capable agent harness, an agent can inspect a repository, create a plan, implement a vertical slice, add tests, run checks, and document the result far faster than manual implementation.
That does not mean the agent replaces the developer.
It means the bottleneck is moving.
The difficult question is becoming less:
“Can we build this?”
And more:
“How quickly can we find out whether this is worth building?”
Extreme Programming fits this moment
Extreme Programming, or XP, focused on short feedback loops: small releases, automated tests, continuous integration, refactoring, pair programming, and close feedback from users.
Its main idea was not to predict every requirement in advance. It was to make change cheap once reality proved the original assumptions wrong.[1][2]
That idea is even more relevant when an agent can produce a first working version quickly.
Instead of following a long sequence of idea, analysis, design, implementation, and eventual feedback, we can move toward a tighter loop:
[ \text{hypothesis} \rightarrow \text{prototype} \rightarrow \text{feedback} \rightarrow \text{learning} \rightarrow \text{refinement} ]
The agent makes the prototype cheaper. XP gives us the discipline to learn from it without turning it into accidental production software.
“Garbage in, garbage out” still applies
A vague requirement can absolutely produce polished but useless code.
The agent may compile the application, generate tests, and create a convincing UI while still solving the wrong problem. “Garbage in, garbage out” remains true.
But I do not think the answer is always more up-front planning and increasingly detailed specifications.
The better approach is to let the agent challenge the idea before it implements it.
Before coding, ask it to identify assumptions, open questions, unclear decisions, risks, non-goals, and measurable success criteria. Then challenge the resulting plan instead of accepting it because it sounds plausible.
A tool such as Matt Pocock’s can help challenge a proposed plan and surface unanswered questions before implementation starts.[3][4]