Clients ask us one question more often than almost any other: if we let AI write our code, will our code quality get worse?

It is a fair question. The people who ask it expect to maintain that code for years.

The short answer: with AI, quality does not come for free. But you can manage it, and the same automation that writes the code can check it.

The Worry Is Rational

The popular version is “AI generates spaghetti code”. The serious version has three parts:

  • Speed: a model writes plausible code faster than anyone can read it.
  • Review: review was already the bottleneck, and now there is far more to review.
  • Erosion: quality does not drop on a specific day; it degrades one reasonable-looking change at a time.

All three are true. What I disagree with is the usual conclusion: that erosion is the cost of speed, and the only defence is to keep AI out.

It Is Still Engineering

I have written before, in AI won’t fix your architecture, that building software with AI is still engineering, just as building it without AI is. This question is a good test of that.

Look closely at the fear of bad code and it is usually a fear of one way of working: no structure, prompt and hope, vibe coding. Code gets accepted because it looks right, and nothing checks whether it is. That fear is justified. Code written that way does degrade.

Approach it the way an experienced team approaches any system, and the question has a practical answer.

So the useful question is not whether AI writes good code. It is what you build around the agent.

Four Questions a Good Harness Answers

Claude Code and Codex come with a harness off the shelf. The part that decides your code quality has to fit your code, so you build it on top: the workflow, rules and checks an AI coding agent works inside. It has to answer four questions:

  1. Is the code written correctly?
  2. Does the code do what it should?
  3. Can the code and its architecture evolve over time?
  4. Does the path from idea to use protect quality?

None of these is new. Keeping quality in a system built with AI is not fundamentally different from keeping it when people write every line: the same questions, answered with the same kinds of tools.

What AI changes is the cost of acting on the answers. Refactoring is no longer a project you have to schedule. You can write some code, use it to understand the domain better, and improve it soon after. The quality of such a system depends on its feedback loops, and AI lets you automate them.

So I think the claim that AI-generated code is inherently worse is backwards. Set up this way, keeping quality high is easier than with hand-written code, not harder.

1. Is the Code Written Correctly?

This is the job of the compiler and the tools around it: static analysis, linters, formatters. None of them depends on anyone remembering to run them. Run them automatically while the agent works and send the results straight back to it: that is the shortest feedback loop you can have. It does not answer the bigger questions, but it removes many small problems: constructs that lead to undefined behaviour and patterns known to be bad practice. Passing static analysis doesn’t make code good; failing it means you are asking for trouble.

This loop is fast and takes almost nobody’s time. If static analysis flags a piece of code, the agent can usually fix it straight away, without supervision.

2. Does the Code Do What It Should?

The simplest way to check is to test it. Tests are code, so AI can write them too, and much of that work can be automated. But choosing good test cases, and writing code that can be tested in the first place, takes engineering judgement. The system has to be designed so that it makes the agent’s job easier, not harder.

So this area needs more human involvement than the first, at least at the start. A person goes through the test cases with the agent: which behaviours matter, where more tests are needed and where fewer, and which level each part belongs at, from unit to end-to-end.

3. Can the Code and Its Architecture Evolve Over Time?

Here again you need someone who can design the architecture, and good architecture comes from understanding the domain well. Agents can help with the preparation: when a feature is defined, a technical analysis compares what the feature should do with what is in the code today and lists the options, A, B, C, sometimes D. But a person has to review that analysis carefully and choose. No agent knows which domain we are trying to model in code.

This is where most of the design work happens. Someone decides how the system should work and gives it a structure that works today, stays readable for the people and agents who open the code later, and is easy to extend, because most code eventually gets extended.

That needs someone who understands what is being built: the product and the business domain. These are also the decisions that are most expensive to reverse, which is why this is the last place to take the person out. Leave it all to an agent and it will almost certainly fail.

That does not leave the models out. Current ones such as Opus 5.5 and GPT-6 Sol are very good at the review side of architecture. Given the whole codebase, they can compare what the code does with what the architecture says it should do, point out where the two have drifted apart, and keep the architecture documentation up to date: the module map, the decision records, the boundaries between parts of the system. That changes where the architect spends their time. Instead of piecing the structure together from files, they work from an accurate description of it and make decisions at that level. The decisions are still theirs.

No harness will decide what your product should be. If someone promises you one that does, they are giving you an answer without thinking.

Automating the first two areas frees time for the third. The person building the software gets much more time for the part where an agent can help but cannot do the work.

4. Does the Path From Idea to Use Protect Quality?

This question is not about the code but about the path it takes: from noticing that something needs doing, through defining it, planning the implementation and building it with its tests, to checking that it works as intended, deploying it and, finally, someone using it.

How that path is set up, which steps are automated and, above all, where you put deliberate human checkpoints, has a big effect on the quality of the result. In a well-structured workflow with clear rules and a lot of automation, the natural checkpoints to start with are:

  • defining what we want to do;
  • deciding how to implement it in the code;
  • turning that into a concrete plan;
  • defining how we will test it;
  • going through or reviewing the test cases;
  • validating the result.

At each of these, a person applies engineering judgement and checks the agent’s work. Everything in between can be automated, so the person can give each checkpoint more attention than they could if they were writing everything themselves.

This is a starting point, not a permanent setup. The checkpoints do two jobs early on: they make the team comfortable with what the agent is doing, and they show where it goes wrong. That second job is what lets you remove checkpoints later. Once you know which kinds of work the agent handles reliably, you can decide by risk. A change that could do serious damage, or would be hard to reverse, keeps a person in the loop. A low-risk change that is easy to undo can go through on its own. Some teams already sort their work this way. Keeping a person on every change is not the goal; it is how you learn which changes need one.

So, Will It?

It can. AI can make your code quality worse. It can also take it to a level of consistency that a team writing every line by hand rarely reaches. Which of the two you get does not depend on the model. The four questions say what good quality means. Whether you get it depends on three decisions about the system you build around the agent:

  • Where the automated feedback loops go. A feedback loop here means a check whose result goes straight back to the agent: the static-analysis report, the failing test, the compiler error. The agent reads it and fixes the problem itself, so the system corrects most mistakes before it takes up anyone’s time.
  • Where the person goes. At which points someone sees the work early enough to step in when it is going wrong.
  • How precisely the path is defined. A single step called “check quality” gets done differently every time. Spell it out as fixed steps, such as write the tests, make them pass, review the result, and each one happens on every change. How the agent gets through a step is still up to it.

This is how we work today. The harness we implement for clients is one we built ourselves, so its steps are shaped to each client’s system. An agent cannot close a task until every step the process defines is done, and control stays with a person at the points the process names. Inside each step, the agent still works with its full capability.

Get those three decisions right, and track how the four areas above change from where they stand today. Then you know which way your code is going instead of guessing.

When someone last told you your code quality was fine, which of the four were they actually looking at?