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.

What this looks like in production

We are starting to see evidence of this approach working at meaningful scale.

GitHub recently used AI agents to rewrite the runtime behind Copilot from TypeScript into more than 800,000 lines of production Rust.

The interesting part is not how much code the agents generated.

GitHub found that the agents spent roughly 10 times more effort exploring the codebase than modifying it. They searched existing code, investigated behaviour, ran commands and used other agents to research questions in parallel before making changes.

Failures discovered during the project were turned into new evals, while automated tests provided a stable definition of whether the new implementation behaved correctly.

That is a useful example of what AI-enabled software engineering is becoming.

The value did not come simply from giving a developer a better model. It came from combining capable agents with good context, decomposition, automated testing, evals and experienced engineering judgement.

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 automatically run Copilot code review on pull requests, including those produced by a coding agent. Teams can also choose to re-run that review as new commits arrive.

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 → separate review step → automated tests and evals → human approval

That separate review step is not a substitute for accountable human approval. It is a way to make review more consistent and direct human attention towards the decisions that need judgment. It should also be designed with its own criteria, context and permissions, rather than simply asking the same agent to mark its own work.

More generated code does not mean teams should accept larger pull requests. Small, focused changes, re-review after material updates and measures such as review turnaround, escaped defects and merged changes give teams a way to learn whether AI is improving delivery or simply increasing output.

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.

Agent orchestration is becoming a delivery capability

The next constraint is not only what one agent can do. It is how a team assigns, supervises and integrates work across many agents without creating a new coordination bottleneck.

Long-running work increasingly needs a delivery control plane: well-shaped tasks, a clear source of truth for priorities, isolated workspaces, automated checks, progress visibility and a defined path to human review. The goal is not to keep people busy supervising agent sessions. It is to let agents pull bounded, well-specified work through a delivery system engineers can trust. This is the pattern behind recent moves towards harnesses that manage context, tools and parallel subagents over longer tasks.

This makes the quality of the backlog, architecture decisions and integration practices more important, not less. A vague task or a weak feedback loop scales poorly when several agents can act on it at once.

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. Crucially, it treats a reduction in false positives as valuable only while recall remains inside a defined safety threshold.

Measure the outcome, not the model

As models become cheaper and more interchangeable, benchmark scores and token prices become less useful measures on their own.

A better metric is the cost of successfully completing a task.

Did the implementation meet the requirement? Did the tests pass? Did independent review find problems? How much human intervention was required? How long did the task take? What did the complete task cost?

A model that is cheaper per token may be more expensive if it needs several attempts, produces more defects or requires significantly more human review.

Likewise, a model with a higher benchmark score may not be the best choice for a particular engineering environment.

This is where evals become particularly useful. They allow teams to compare models and agent configurations against representative work using measures that actually matter: quality, reliability, latency, human intervention and total cost per successful outcome.

Models are changing quickly enough that teams should preserve the ability to evaluate and substitute them where practical. That does not require complex multi-model routing in every system. It does require comparing models using representative tasks and outcome-level measures, rather than relying only on generic benchmarks.

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.

That environment also needs to assume that some of the content an agent reads is untrusted. Prompt injection is not solved by a policy or a single filter. Limit network and data egress, use least-privilege credentials, require confirmation for consequential actions and keep an auditable record of tool use. The controls should constrain the impact of a compromised agent, not depend on it recognising every malicious instruction.

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 five capabilities I would be investing in now: agent harness engineering, agent orchestration, 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.