Better AI Coding Still Needs Good Code

AI coding has moved on quickly.

The current model releases are not just better at filling in a function or producing a plausible component. They are getting better at working across files, using tools, running checks, holding a plan, and staying with a task for longer.

OpenAI's GPT-5.5 release talks about stronger coding, debugging, using tools, and long-running work in Codex. The earlier GPT-5.4 notes put coding alongside broader professional work and computer use. Anthropic's Sonnet 4.6 release focuses on better coding consistency, instruction following, and computer use. Google's Gemini 2.5 Pro update made a similar point for web apps and code editing.

So yes, the coding model got better.

That does not mean the codebase stopped mattering.

If anything, it matters more, because better AI can now move faster through a system. Speed is useful when the system has clear shape. It is less useful when the system is a drawer full of old assumptions with a test suite from happier times.

AI coding now works across whole tasks

The old mental model for AI coding was autocomplete with confidence.

That is no longer enough.

The more interesting shift is that coding models can now behave more like working agents. They can inspect a project, make a plan, edit several files, run tests, read the failure, adjust the fix, and explain what changed.

That is a real improvement.

It changes which tasks are worth handing to AI. Small bugs, repetitive refactors, test additions, interface cleanup, content migrations, dependency upgrades, and awkward little "change this everywhere, but not quite everywhere" jobs can move much faster.

It also changes who can prototype. A non-developer can now get further with a small internal tool than they could a year ago. A developer can get through the first pass of a dull change without giving the whole afternoon to it. A team can explore two or three approaches before committing to one.

Useful. Very useful.

But the happy path is not the hard part.

The codebase sets the ceiling

AI coding works best when the project gives it a good map.

That means clear names, predictable patterns, useful tests, small modules, current documentation, and a visible way to check whether the change worked.

If the project has those things, AI can move surprisingly well. It can follow the local style. It can spot repeated patterns. It can make a small change and update the right nearby tests. It can explain the risk in a way that gives a human reviewer somewhere sensible to start.

If the project does not have those things, the model has to infer too much.

It may still produce code. It may even produce code that looks tidy. But tidy is not the same as correct.

A codebase with hidden business rules, stale comments, weak tests, and several competing ways to do the same job will confuse a model in the same way it confuses a new developer. The difference is that the model may keep going with more confidence and fewer raised eyebrows.

That is where risk enters.

A quote form shows the difference

Imagine a website has a quote form.

The business wants to add a new rule: if the visitor selects a same-week deadline, the form should ask one extra question and route the enquiry differently.

In a healthy codebase, the model can find the form, the validation, the email or queue logic, the tests, and maybe the admin view where the enquiry appears. It can add the field, update the route, adjust the tests, and run the suite.

The human reviewer still needs to check the judgement. Is the question worded properly? Does the route match how the team works? Does this create extra noise for the person handling enquiries? But the implementation work may be much faster.

In a weaker codebase, the form might have three partial copies, validation might live in the view, the email might be assembled in a controller, and the "urgent" rule might already exist as a half-remembered condition somewhere else. There may be no test for the quote flow because the original developer planned to add one after launch, which is software's version of "I'll put that away properly later".

The model can still try.

It just has less truth to work with.

That is why "we use AI to code faster" is not a complete delivery plan. The real question is whether the project is shaped so faster coding produces safer changes.

Tests become more important, not less

When AI writes or edits code, tests stop being a nice extra and become part of the steering system.

They tell the model what must remain true. They tell the reviewer what was checked. They catch the dull regressions nobody wants to spot by hand at 5.40pm.

The best AI-assisted development still has a loop:

• understand the change
• make the smallest sensible edit
• run the relevant checks
• inspect the diff
• review the behaviour
• decide what still needs a person

That loop is not glamorous. It is how the work stays attached to reality.

We built Fuse, our own code review companion, because faster code without sharper review just moves the bottleneck. The risk does not disappear. It changes address.

That is a Stuntrocket sentence because our own AI tools have spent enough time in real worktrees to remind us that a green test is helpful, but it is not a character reference.

AI can still produce convincing mistakes

AI coding tools are genuinely useful.

They are also uneven.

They can follow the visible pattern too closely and miss the business reason behind it. They can duplicate logic instead of finding the right shared place. They can claim a check passed when the wrong check ran. They can tidy code that should have been left alone. They can make a large change feel smaller than it is because the diff arrived neatly.

That does not make them useless.

It means the work needs a reviewer who understands the system, not just someone who can approve a tidy patch.

For small, isolated tasks, AI can be excellent. For messy product decisions, unclear requirements, fragile old code, payment logic, permissions, security-sensitive work, or anything that changes customer data, it needs tighter boundaries.

Check the codebase before buying faster delivery

If you are hiring a team that uses AI in delivery, do not ask whether they use AI.

At this point, that question is too broad to be useful.

Ask how they control it.

The useful questions are:

• What parts of the work can AI do, and what parts stay with a person?
• How do you stop AI changing more than the task requires?
• What tests or checks prove the change worked?
• How is the code reviewed before it ships?
• What happens when the model gets stuck or makes the wrong assumption?

Good answers will be practical. They will talk about tests, small diffs, review, project conventions, source material, and a way to undo a bad change.

Weak answers will sound like the model is a magic developer that never gets tired and does not need supervision.

It is not.

It is a powerful tool inside a delivery process. The delivery process still matters.

Good code lets AI work safely

The real advantage of better coding models is not that they remove engineering judgement.

It is that they can give good developers more useful reach.

They can help explore options faster. They can clear boring edits. They can draft the first implementation. They can find patterns across a codebase. They can help maintain internal tools that used to sit in the "useful but never urgent" pile.

That is a meaningful shift for small teams.

But the work still needs architecture, taste, restraint, tests, review, and an understanding of what the software is actually meant to do for the business.

Better models raise the floor.

The codebase still sets the ceiling.