What AI-assisted engineering taught us about team design 

As organizations experiment with AI-assisted software development, one of the most immediate expectations is that the biggest gain will come from making individual engineers faster. 

That is already happening, but it is exposing a broader constraint: AI can produce implementation faster than engineering teams can safely understand, review and absorb it. 

We have seen a model generate in roughly 15 minutes an amount of code that could take a developer a couple of days to meaningfully understand, validate and become comfortable owning. 

The apparent productivity gain can be enormous. The real gain may not be. Much of it can be consumed downstream by review. 

Atlassian’s State of Developer Experience Report 2025, published July 9, 2025, and based on 3,500 developers and managers across six countries, found a similar disconnect: even as developers reported saving more time through AI, 50% said they were losing at least 10 hours each week to organizational inefficiencies. 

That points to a larger lesson. Generating more code is not necessarily the highest-leverage place to improve.  

We deliberately reduced how much code AI was allowed to produce 

One effective response is not to give AI more autonomy but to constrain it. 

Instead of prompting a model with a broad requirement and asking it to implement the whole thing, engineering teams can reduce both the context and the size of the task. Engineers can ask AI to work on only a few functions or another narrowly bounded unit at a time. 

A simple operating rule can be applied: AI-generated code should remain understandable to the engineer using it, reviewable by a peer and approved before entering production systems. 

The benefit is not simply that AI produces smaller amounts of code. It is that engineers can implement individual pieces faster while keeping each change small enough to understand, review and validate. That allows implementation speed to increase without creating an unmanageable review burden.  

There is still a limit. Peer review, architectural decisions and verification continue to operate largely at human speed. Once AI-generated output exceeds that capacity, the bottleneck has not disappeared. It has simply moved from implementation to review.  

That distinction matters because much of the discussion about AI productivity focuses on how much faster developers can generate software. In practice, the more important question is how much reliable software the engineering system can absorb and ship.   

We moved from optimizing prompts to engineering the harness 

Instead of treating AI mainly as a coding assistant that an engineer continuously prompts and supervises, engineering organizations are focusing more attention on the system surrounding the model, what we call the AI harness. 

The harness determines what context the model receives, which tools it can access, how larger tasks are broken into smaller steps, which constraints it must follow, how its output is evaluated and what happens when it fails. 

With the earlier approach, the developer remains the control system. The engineer decides what to ask, inspects each relatively small result and decides what happens next. 

With a harness, some of those controls become software. 

The engineering effort begins shifting toward defining the rails on which the model operates: giving it the right context, exposing the right tools, constraining its actions and building mechanisms that determine whether the resulting work is acceptable. 

This can be more significant than simply improving prompts because it creates the possibility of increasing AI’s useful scope without increasing human supervision at the same rate. 

Evals become part of the engineering system 

That shift creates a new requirement around how performance and reliability are measured. 

If AI is going to execute larger portions of a workflow, subjective review cannot be the only way to decide whether the system is improving. 

Evals therefore become a necessary part of the engineering system. 

The questions become more systematic: Did the agent accomplish the intended task? Did it violate an architectural constraint? Did a change break an existing behavior? Under which contexts does the workflow fail? When should a human be brought back into the loop? 

The objective is not maximum autonomy but measurable reliability. 

This distinction becomes more important as the underlying models improve. Better models increase what organizations can potentially delegate, but they also increase the leverage of the engineering system surrounding them. 

DORA’s State of AI-assisted Software Development 2025, released in September 2025 from research involving nearly 5,000 technology professionals, describes AI primarily as an amplifier of the organization around it: strong systems can convert AI capability into greater throughput, while weaknesses in the underlying system can also be magnified. 

The team needs different skills, not simply fewer people 

These developments are changing how engineering team design should be considered. 

Large engineering teams have partly been a consequence of the expense of implementation. If a roadmap required substantially more software, organizations generally needed more people producing it.
AI is weakening that relationship, but the logical conclusion is not simply to replace a 20-person engineering team with five people performing the same roles.
The smaller team has to be constructed differently. 

It needs engineers who can understand architecture and product intent, but also people who can design context, build agent workflows, expose tools safely, create evals, analyze failures and improve the harness around the model.

Those capabilities are not identical to the skills traditionally associated with being a senior software engineer.

As AI makes implementation capacity less scarce, the scarce parts of engineering increasingly become judgment, system design, evaluation and accountability. 

The goal is not simply to employ fewer developers or generate more code with AI. It is to design an engineering system in which increasingly capable models can take on more implementation work without allowing quality, understanding or accountability to deteriorate. 

The teams that adapt to that shift will be designed around the parts of engineering AI does not make abundant and around the systems required to direct what it does.  

Prashanth Tondapu is founder and CEO at Innostax, a custom software development and IT staff augmentation company,