A follow-up to the article "Code Only What You Need". That article was written before the AI era, but the original argument still stands. This update looks at what AI-assisted development changes about it, and just as importantly, what it doesn't.

The original argument, restated

The core claim of the original article was simple: unrequested functionality is never free. It costs time in writing, testing, documenting, QA clarification, and worst of all, in the rework and technical debt that shows up months later when a genuine new use case collides with the "bonus" behaviour nobody asked for.

In the article we identified the root cause of this behaviour as psychological rather than technical: enthusiasm, a 'hero' engineer, and short-term thinking summed up by the all too common phrase "I'm in the code now, it'll only take ten minutes."

What impact has AI had on this argument?

What AI changes: The time constraint has gone

It's worth recalling that one of the main deterrents in the original article was the time taken (aka effort). If a developer were to go sufficiently off-piste then there are safeguards in place to detect the misdirection — the standup, for example, would (should) highlight that unspecified work was being undertaken. The time safeguard meant that it shouldn't be possible for an engineer to go too far from what was required; this friction created by the time cost would prevent a lot of the larger "wouldn't it be neat if…"s.

However, AI-assisted development removes the time constraint almost entirely. The 'ten-minute' feature is now a ten-second prompt. The psychological drivers highlighted in the original article — enthusiasm, heroics, short-termism — still remain, but they are now amplified given the absence of the time safeguard. This exacerbates the problem, increasing the frequency and scale of the problem without changing its nature:

• More surface area, same mechanism — A single prompt can now plausibly generate the sorting, filtering, pagination, and "alternative retrieval methods" we used as classic examples of over-engineering — all at once, all before anyone has had a chance to question whether they're needed. The problem is actually worse than before, as this functionality may be added by the AI helper without the engineer specifically asking for it.
• Scope creep — Scope creep often relies on a second pair of eyes (PR review) and QA analysis to catch it. But reviewers now face a higher volume of plausible-looking code, often written faster than it can be meaningfully read. Whilst the PR checkpoint still exists, whether it still functions is a different question.

Neither of these are new failure modes. They are known pre-AI failure modes, but now served at higher velocity, now that the friction time provided has been greatly reduced.

Surely AI means we lose the sunk-cost argument?

The classic sunk-cost trap actually weakens under AI-assisted development. The basis of sunk cost is that it relies on real invested effort people were reluctant to write off, but when code creation only takes moments, this argument disappears. However, it's not all good news — a different bias now fills this gap: a reluctance to discard something that seems to have cost nothing. Functionality that 'just appears' may feel like a gift; there's no visible investment to weigh against removing it, and no decision ever really gets made to keep it either. Where the old argument was "it cost too much to abandon," the new one is "it cost nothing, so why say no?", and functionality that nobody had to justify building is, if anything, less likely to get scrutinised than functionality someone spent a week on. The safeguard for this functionality could potentially bypass the quality gate because it's unexpected.

What current teams are doing about it

It's early days in this AI coding adventure, but so far a few approaches stand out:

• Moving the human decision earlier. Instead of reviewing a finished diff and inferring intent from it, some teams now require a short, explicit scope and a few concrete acceptance criteria to be agreed before code is generated — restoring, by policy, the checkpoint the article assumed review would provide implicitly.
• Constraining scale rather than trying to out-review it. Some teams cap how large or broad an AI-assisted change is allowed to be before it must be broken down, on the reasoning that smaller, well-scoped changes are the only kind humans can meaningfully review at the speed AI can produce them.
• Introducing AI into the quality process. Validating coding standards and doing reviews of code before a human is introduced can help reduce the noise so the human can focus on the functionality.

What is worth noting is that the first two of these approaches are also considered best practice in a pre-AI world.

There's open acknowledgement that review capacity is not scaling at the same rate as generation, and that "review happened" is increasingly a formality rather than a guarantee of a thorough review. As a result, we're back to relying on discipline to enforce these quality gates.

What does not change

With all the excitement of these new advances, it's worth focussing on what is at risk of being forgotten in the rush to adopt new tooling.

The cost model is identical. Time spent writing untested, undocumented, unrequested functionality is still time spent. AI changes who or what performs the writing; it does not change the fact that testing, documentation, QA clarification, support, and future rework still consume real hours, from real people, later. Cheap generation does not mean cheap ownership.

Acceptance criteria are still the primary defence. As with pre-AI engineering, the stance of not settling for vague ACs, challenging them until the intent is clear, and not implementing beyond what they specify is not just still valid, it is more pertinent than before. When generation is cheap and fast, the acceptance criteria are the only thing left that reliably constrains scope before the fact rather than after.

The sunk-cost fallacy is still a fallacy. "It already exists" was never a good reason to keep something, and it still isn't, even if the time spent creating it is significantly reduced.

The cost of detection still rises the later it happens. Pre-deployment discovery is still cheap. Post-release discovery still means deprecation, dependency management, and client impact. AI hasn't changed this — it has just made it easier to get further along that curve before anyone notices.

Organisational discipline, not tooling. Clear ACs, developers doggedly sticking to building what's specified, stand-ups surfacing scope in progress, PR review as a second pair of eyes, QA analysis and bug discovery — is still the right list. AI tooling can assist at each of these checkpoints, but it cannot substitute for a team that has agreed to actually hold the line. A checklist run by a bot is not a decision, it's an input to one.

The root cause is still human, not technical. Enthusiasm, heroics, and short-term thinking were never solved by better tooling in the first place — they were managed by team norms and review discipline. That remains true. AI has changed the blast radius of an ungoverned impulse; it has not changed the impulse, and it has not changed what/who governs it.

Summing up

The summary and claims of the original article still hold firm: delivering the minimum is still the fastest way to validate a decision, and unnecessary functionality still costs more than it appears to save. AI-assisted development undeniably adds speed, which removes one of the constraints of scope creep, but increases the temptation. This means the discipline to call out scope, tight acceptance criteria, real PR scrutiny, and a willingness to say "we don't need this yet" remain best practice. The tools may have changed. The judgment they were always meant to support has not, and cannot be automated away.