The model is becoming the least interesting part of AI-enabled software development.

For the last couple of years, most conversations about AI in software development have focused on the models and coding tools.

Which model writes the best code? Should developers use GitHub Copilot, Cursor, Claude Code or Codex? How much faster can an engineer build something with an AI coding agent?

These questions still matter. But I think we are starting to focus on the wrong thing.

The more consequential change in AI-enabled software development is happening around the models. We are starting to see the emergence of a new engineering layer made up of agent harnesses, automated code review, evals, permissions, tools and governance.

Increasingly, the question is not which AI model are you using? It will be how well have you engineered the system around it?

Agent harnesses are becoming part of software architecture

An AI coding agent becomes much more useful when it can do more than generate code.

It needs to understand the repository and engineering standards. It needs access to documentation and tools. It needs to run tests, maintain context across longer tasks and potentially interact with other systems.

This surrounding environment is often referred to as the agent harness.

Recent developments from GitHub and OpenAI are pointing strongly in this direction.

Coding agents are moving beyond being assistants inside an IDE towards environments where they can use tools, interact through MCP and execute increasingly complex software development workflows.

For engineering teams, that creates a new set of architecture decisions. What can the agent access? What context does it receive? What can it execute by itself? When does a human need to approve an action? How are credentials and secrets handled? How do you know what the agent actually did?

These are not prompt engineering questions. They are software engineering questions.

AI reviewing AI-generated code will become normal

If coding agents dramatically increase the amount of code being produced, humans reviewing every generated line eventually become the bottleneck.

GitHub, for example, can now automatically run Copilot code review against pull requests generated by Copilot.

So it is not surprising that we are seeing AI code review becoming part of the same workflow. The product is less interesting than the pattern:

Specification → implementation agent → independent review agent → automated tests and evals → human approval

Humans are still involved, but where they spend their time starts to change. Instead of reviewing every implementation detail, experienced engineers can concentrate more on architecture, requirements, security, unusual edge cases and whether the software actually solves the problem it was supposed to solve.

That is a much bigger change than simply generating code faster.

Evals are becoming part of normal software testing

Traditional software testing asks a relatively simple question: given a particular input, did we get the expected output?

AI makes that considerably messier. Change a model, prompt, piece of context or tool and the behaviour of the system can change in ways that are difficult to predict.

This is where AI evals become important. GitHub recently described how it evaluates the LLM component of its secret-scanning capability using representative datasets, offline evaluation, error analysis, regression testing and controlled production rollout.

Over time I expect evals to become a standard part of the software delivery lifecycle, sitting alongside unit tests, integration tests and security testing.

If you cannot reliably determine whether an AI system became better or worse after a change, it is very difficult to operate that system safely in production. “Seems to work” will not survive enterprise scale.

AI governance is becoming an engineering problem

A lot of enterprise AI governance started with policies about which tools employees should use and what information they should put into them. That was necessary, but it is not enough once AI agents start taking actions.

Organisations now need to think about which models agents can use, what data they can access, which MCP servers they can connect to, what tools they can call and which actions require human approval.

A policy saying employees must “use AI responsibly” provides limited protection if an autonomous coding agent has unrestricted access to sensitive data, credentials and production systems. The controls need to exist inside the engineering environment.

Are autonomous AI developers about to replace software teams?

I do not think that is what the evidence is telling us.

Coding agents are getting remarkably capable. But look closely at the best examples and there is usually a lot happening around the agent: good specifications, carefully prepared context, tools, automated tests, evals, permissions and guardrails.

The model might be doing the work, but engineers are designing the environment that allows it to do that work reliably.

That is why I think the next phase of AI-enabled software delivery will be less about finding the best coding assistant and more about redesigning the software delivery system itself.

There are four capabilities I would be investing in now: agent harness engineering, AI-assisted code review, eval-driven development and technical AI governance.

The leading coding model will keep changing. The tools will change with it. Knowing how to build a reliable engineering system around those models is likely to have a much longer shelf life.