Beyond the Model: What AI-Amplified Engineering Actually Requires
AI is getting incredibly adept at coding. We're already seeing teams ship more code, more features, and more pull requests. The models will only keep improving, and the scope of work given to agents will only keep increasing. This shows us an interesting problem: the rest of our engineering ecosystem wasn't exactly designed for this kind of throughput.
To be fair, even before AI, human-led code review was not a guarantee of correctness. Humans will always miss things. We skim over large pull requests, misunderstand or misinterpret requirements, overlook downstream effects, and sometimes approve a PR because the tests pass and the code looks good.
Now we're increasing the amount of code produced without increasing our capacity to review it. We could always put more humans into the review process, but ultimately that defeats the purpose of what we're trying to accomplish with AI in the first place. So I think we should be thinking toward a goal that might make some engineers uncomfortable:
We need to feel comfortable allowing AI agents to approve and merge pull requests.
And not because AI becomes so freaking good that we blindly trust whatever it produces. I actually think that's exactly the wrong idea.
We should be building engineering systems where we don't have to trust their output.
Engineering Confidence Instead of Trust
Trust has always played a much larger role in software engineering than we like to admit. We trust that an engineer understood the requirements. We trust that the reviewer understood the change. We trust that somebody remembered some random edge case. We couple that trust with tests, static code analysis, deployment controls, monitoring, and other safeguards, but human judgment has always remained a major part of the process.
AI-amplified engineering forces us to reconsider all of that.
If we truly want agents to take on increasingly autonomous work, we need to move the confidence out of people's heads and into the system itself. I see three major points here: giving agents enough context to understand what correct means, deterministically verifying as much of that correctness as possible, and designing runtime systems that can safely identify and contain what we couldn't prove beforehand.
You may think, none of this particularly new. Isn't this what we've always talked about building towards in engineering anyway? What's changing is how important this becomes when implementation itself gets dramatically cheaper and faster.
The Code Doesn't Tell the Whole Story
One of the clearest things I've learned while driving for AI-amplified engineering is that giving an agent access to a repository is simply not enough.
This is particularly obvious in bespoke and legacy systems that make up the reality of countless organizations. These systems have accumulated years, sometimes decades, of business decisions, some of those might be reflected in documentation or tests. Others are buried in old tickets, architecture docs, or conversations. So many likely exist only in the heads of people who have been around long enough to remember them.
Consider an odd if/then/else buried in a service that's been running for ten years. Is it unnecessary complexity that should be cleaned up? Or is it accounting for an edge case created after a production incident eight years ago? The source code can tell an agent what it is actually doing. But even an extremely capable model can't reliably determine the intent, or why it exists, if that information isn't available to it.
The code can tell an agent what a system does. It doesn't necessarily tell it what the system is supposed to do.
This isn't a problem we're going to solve waiting for models to get better. If intended behavior exists only in someone's head, the model has nothing to reason from. It can infer, and it may infer very well, but inference is still inference. That's particularly important in critical systems. A model that gets something right almost every time may be incredibly useful, but “almost every time” just isn't good enough when a single incorrect, autonomously generated change could create a major security incident, financial event, safety issue, or loss of public trust.
The answer is to design around the uncertainty of the model.
Engineering Context Is Infrastructure
This changes the role of engineering documentation.
Architecture decision records, API contracts, business intent, engineering standards, and domain knowledge have historically been created for human consumption. In an AI-amplified engineering organization, all of those things now have a new consumer: machines.
Take an OpenAPI spec as a simple example. We might define a property as an integer. But let's say the actual business rule says the value must always be positive and must never be greater than 10. Certain values could have specific meanings under different business conditions. Some of those constraints could be formally expressed in the spec, but not everything fits neatly into JSON Schema or other contract mechanisms. To work around that, the remaining context might end up in a separate doc, tribal knowledge, or most likely, nowhere at all.
AI actually gives us another cool option. We can place natural language expectations alongside formal contracts, explaining what a field means, why a constraint exists, the behavioral intent, and what must never happen. An agent can then use that information while implementing a change and again when validating whether its implementation satisfies the intended behavior.
Documentation is no longer just something an engineer may or may not read before making a change. It now becomes an active input into all generation and verification.
Engineering context is infrastructure.
And that means we need to start treating it with the same seriousness we apply to other infrastructure: ownership, discoverability, consistency, maintenance, and validation.
More Context Isn't the Answer
There seems to be this temptation that once we recognize agents need organizational context to just give them everything. Connect every repository, wiki, architecture document, ticket, API spec, meeting transcript, and knowledge base. If lack of context is the problem, surely providing all of the available context is the solution.
Except we're learning that this creates a different problem.
Models and agentic systems are increasingly being designed to operate effectively with more narrow context. Large amounts of irrelevant, stale, or conflicting information can make an agent less effective rather than more effective. Huge contexts also have real costs in latency, token spend, and complexity. We need to find the right balance.
More context isn't the goal. Better context is.
The problem is discovery. An agent working on an API shouldn't need every architectural decision the company has ever made in its working context. It needs to understand the responsibility of the system it's changing, what is affected by that change, identify the business rules and architectural constraints that apply, and know where to retrieve deeper context when it encounters something it doesn't understand.
That's actually not at all different from how a human engineer works. Engineers don't hold every piece of organizational knowledge in their heads. They understand the landscape, know which sources to engage, recognize when they're missing information, and know where to go find it. Building that capability for agents is an architecture problem. We need to think not only about what engineering knowledge exists, but where it lives, how systems and decisions relate to each other, which information is authoritative, how agents discover it, and how we keep it current.
Engineering context is infrastructure. Context management is architecture.
The specifics on what we use to accomplish that are still changing rapidly, and I'd bet they'll keep changing for quite some time. But the need itself is becoming increasingly clear.
Verification Has to Scale Too
Giving an agent a better definition of correct doesn't prove that what it produced is correct. This is where deterministic, human approved verification becomes extremely important.
I've heard folks ask, “How can we use AI to test the code AI generates?” To be fair, there are absolutely useful applications for that. But one probabilistic system asking another probabilistic system whether something looks correct can't be the foundation on which we build autonomous delivery. We need deterministic controls whose expectations come from humans and the business: contract tests, integration tests, invariants, static analysis, security policies, architectural constraints, and other mechanisms that produce predictable outcomes.
As AI increases the rate at which changes are introduced, verification has to become more and more automated and increasingly independent of whoever (or whatever) authored the change.
Verification Doesn't Stop at Merge
There will always be things we can't prove before deploying software. So our production engineering practices are most definitely part of the AI-amplified engineering story too. Canary deployments, progressive delivery, feature flags, observability, anomaly detection, monitoring, blast-radius controls, and automated rollback are no longer separate concerns. They're now foundational layers of verification and protection.
The engineering system should absolutely be capable of answering some fundamental questions: What is this change supposed to accomplish? What constraints must it never violate? How do we establish that it behaves correctly before deployment? How will we know if it's behaving incorrectly afterward? And what happens automatically when it isn't?
The better our systems become at answering those questions on their own, the less confidence needs to come from the identity of the person (or agent) that wrote the code. Again, this is not a new concept introduced by AI. And this is where I think the conversation starts becoming much more interesting than simply “developers write code faster with AI.”
Designing for Autonomous Delivery
I don't think most organizations should let agents autonomously approve and deploy arbitrary production changes today without seriously considering everything I've discussed here. There are likely too many gaps in context, verification, and operational safety. But I do think we should intentionally design toward the conditions where we can. Regardless of AI, we should be doing that anyway!
AI is exposing weaknesses that likely already existed in our engineering systems. Undocumented business intent was always a risk. Tribal knowledge was always a risk. Incomplete or incorrect testing was always a risk. Fragile deployments were always a risk. Human reviewers have always been capable of missing defects. AI dramatically increasing implementation throughput is making those weaknesses much harder to tolerate.
There are still plenty of unanswered questions, like how we provide agents with the right context without overwhelming them. Models are changing, agent architectures are changing, and the mechanisms we use to expose engineering knowledge to them are changing very quickly.
The good news is, we don't need to wait for those questions to be fully answered before acting.
We can document intent that currently exists only in people's heads. We can enrich contracts with the business intent surrounding them. We can build stronger deterministic verification. We can make architecture decisions and engineering standards discoverable. We can improve our deployment safety, observability, and automated recovery. And we can start treating all of those things as part of the infrastructure required for AI-amplified engineering rather than prerequisites for adopting a coding assistant.
The organizations that get the most leverage from AI will absolutely not be the ones with access to the best models. Everyone will eventually have access to amazing models.
The differentiation will come from the engineering surrounding them.
The goal isn't to make AI trustworthy enough to ship software autonomously. It's to build an engineering system that doesn't require us to trust it.
