An Operating Model for AI-Native Engineering

Originally published on LinkedIn, August 2026.

Most organizations are adopting AI by giving engineers better tools. That produces a real gain, and a modest one. The larger opportunity requires changing the operating model, because when generation gets cheap the constraint moves somewhere else. It moves to deciding what is correct, verifying that it is, and holding the architecture together while code arrives faster than any one person can hold in their head.

I spent the last four months finding that out directly. I designed, built, and shipped a production SaaS platform end to end as a solo operator, from first commit to public launch, using agentic AI tooling as the engineering capacity. Payments, bank data aggregation, encrypted credential handling, LLM-powered product features, a real QA environment and release process. Before that I spent twenty-five years running engineering organizations, most recently as VP of Software Engineering for a platform processing more than $2.5 billion in annual financial aid.

The four months taught me more about where leverage actually sits in an engineering organization than any strategy work I have done on the subject. What follows is what I would do with that.

What actually changes

Throughput stops being the constraint. Within about two weeks of working this way, writing code was no longer the thing standing between an idea and a shipped feature. Judgment was. Deciding what to build, deciding whether what came back was right, deciding whether it belonged where it had been put.

The ratio between production cost and verification cost inverts. Producing a change became nearly free. Confirming a change was correct cost the same as it always had. When one side of that equation collapses and the other does not, everything downstream of it has to be redesigned.

Architectural entropy accelerates. I finished with ninety six modules and a running list of functions living in the wrong files. Nothing was broken. Everything was slower to change than it should have been. Coherence degrades quietly when code arrives faster than the mental model of the system updates, and no tool warns you it is happening.

The operating model

Team shape: smaller and more senior

If judgment is the scarce resource, staff for judgment. Smaller teams with higher average seniority will outperform larger teams with a wider spread, because the work that remains is disproportionately the work that requires experience.

The uncomfortable consequence is that this squeezes the junior pipeline. The traditional path into engineering judgment ran through ticket volume: you built pattern recognition by writing a lot of code, badly, over years, until instinct formed. That path assumed ticket volume was expensive enough to be scarce. It no longer is.

My answer would be to put junior engineers where judgment is actually built now, which is verification, not production. Paired on reviewing what an agent produced and finding what is wrong with it. Present in architectural review. Responsible for reproducing and characterizing failures rather than for closing tickets. That is slower to show up in a delivery metric, and it is the only way you have senior engineers in five years, because the muscle that used to form by writing bad code now has to form by catching it.

Forward deployed engineering and rapid prototyping

When generation is nearly free, the expensive part is knowing what to build. The fastest way to find out is to put engineers in front of customers, onsite and on calls, with the ability to prototype in the conversation rather than after it.

I did a version of this without the label. Our engineers went onsite and joined client calls directly rather than receiving requirements secondhand, and the difference in what came back was large. Watching a financial aid office actually work through a packaging cycle surfaces things no requirements document does, particularly the workarounds people have quietly built because the software did not do what they needed.

Agentic tooling makes this materially more valuable than it was three years ago. A rough working prototype used to cost a sprint, which meant you prototyped only when the stakes justified it. It now costs an afternoon, which changes the calculus entirely. More of what currently gets specified for weeks should be built roughly, shown, and thrown away.

Two things keep this from becoming a shadow engineering organization. Prototypes are explicitly disposable unless they earn promotion, with a defined path for turning a validated one into owned and maintained product. And the learning routes back into the platform teams, so wins compound instead of staying local to one account.

Fund verification ahead of capacity

I spent a meaningful share of those four months building things that shipped nothing. A separate pre-production environment. An end-to-end suite that grew to roughly 1,500 tests. A CI gate that actually blocked. And a practice I would carry into any organization: a negative control on every check, meaning I verified the test failed when it should before trusting it to tell me anything. As one person, on a deadline, that felt indulgent. It was the highest-return work I did.

The same discipline has to hold one layer deeper. An agent fixing a bug should never be able to weaken the test that caught it. If the fix and the test proving the fix come out of the same untrusted pass, you have built a check that can quietly rubber-stamp itself. This is not a hypothetical. It is the most natural failure mode there is, because a test that gets in the way of the fix is exactly the kind of thing an agent will helpfully loosen unless something stops it.

Agents produce plausible code quickly. Plausible and correct are different properties, and the only thing standing between them is your test harness. An organization that adds generation capacity without adding verification capacity does not get faster. It gets faster at producing work nobody has checked.

Concretely: a real pre-production environment that mirrors production closely enough to be trusted, an end-to-end suite that gates deployment rather than reporting after the fact, a definition of done that is the full build passing rather than a partial check, and a hard rule that the process fixing a defect is never the same process with authority to loosen the check that found it.

Redefine code review

The old question was is this good code. That question is mostly answered now. Generated code is usually clean, idiomatic, and readable. The new questions are harder and less pleasant to ask.

Is this the right thing to have built? Does it fail correctly? Does it belong where it was put? Does the test prove what it claims to prove?

I would rewrite the review standard around those four, and I would put failure paths first. Generated code is optimistic by default. It handles the path you described and gets vague about the ones you did not. My worst bug in four months was a save function that swallowed its own errors. Everything reported success. Nothing persisted. It reviewed beautifully.

Underneath the review standard, one more distinction matters, and most organizations blur it. Some rules should live as guidance an agent is likely to follow. Others need to be mechanically impossible to violate. Telling an agent not to touch a test file while it fixes a bug is a suggestion. Making that edit fail at the tool level is a guarantee. I would sort every rule I care about into one of those two buckets on purpose, rather than discovering which bucket it was in after an incident. The gap between telling an agent what not to do and making it structurally unable to do it is where the worst outcomes live.

Make architectural ownership someone’s actual job

Not necessarily a title, but a named accountability with protected time. When code arrives faster than judgment, someone has to own the map, and it cannot be a thing senior engineers do in the margins between features.

I would run a recurring architectural review whose only purpose is catching drift, with the authority to require relocation of code that is in the wrong place even when it works. That last clause matters. The reason drift accumulates is that every individual instance of it is defensible. Nothing is broken. The cost is entirely in the future, which means nobody is incentivized to pay it in the present unless someone owns doing so.

Keep a record the next step can read

The other habit worth naming directly: every stage of the work should end with something committed and readable that the next stage, or the next reviewer, or you in six months, can act on without reconstructing it from memory or a chat thread. I did a version of this without planning to. What I built told me what it was for, what it decided, and why, before I moved to the next piece.

The value is not documentation for its own sake. It is that the artifact is how the next step knows what to do, and it is how anyone, including a future version of you, can recover the reasoning behind a decision without finding the person who made it. This is also the real defense against the drift problem above. Drift accumulates fastest exactly where nobody wrote down what should have lived where.

Measure the right things

I would stop reporting velocity. It measured something real when writing code was the constraint. It measures noise now.

What I would instrument instead:

Escaped defect rate. How much of what we shipped was wrong in a way we did not catch.

Rework share. What fraction of changes required a second pass. This is the honest proxy for whether we are building the right things.

Time from commit to verified in production. Not to deployed. To verified. The gap between those two is where the new risk lives.

Architectural drift. This one is genuinely hard to measure and I would rather approximate it than skip it. Coupling between modules that should not know about each other, and the rate at which changes require touching files nobody expected, are both instrumentable and both directionally useful.

Resource ratios, reviewed continuously. The dev-to-QA ratio most organizations run was set when writing code was the expensive part. If production cost has collapsed and verification cost has not, that ratio is now wrong, and it will keep moving as tooling improves. I would treat it as a live number reviewed quarterly rather than a staffing assumption, and watch for the specific signal that it is off: work queuing in front of verification rather than in front of development.

One more, easy to skip. If you adjust the instructions and guardrails that steer the agent itself, treat that change like a code change. Keep a small fixed set of tasks you already know the right answer to, and rerun them whenever you touch those instructions. A rewrite meant to make the agent smarter can quietly make it worse at the ten things you were relying on it to get right, and nothing will tell you unless you check.

Guardrails, kept light

Where agents may act without approval, what requires a human in the loop, what data may never enter an external service, and who is accountable by name for any AI-assisted output that reaches a customer. Not a committee. A person.

I keep this section short deliberately. It is the part every organization writes first and it is the least differentiated thing on the list. Governance that only prohibits gets routed around. Governance that makes the approved path fast is the version that holds.

What breaks

The failure modes are specific, and I hit most of them.

Plausible and wrong. Output that is confident, well-structured, and incorrect in a way that survives casual review. This is the central risk and everything above is downstream of it.

Confidence borrowed from a gate that does not prove what you think. I had a contract check passing while the real build was broken, and a red build reached production. The check had given me confidence I had not earned. The lesson generalizes: audit what your green checkmark actually proves, because a partial gate is worse than no gate at all. No gate makes you careful. A partial gate makes you comfortable.

Silent failure. Errors swallowed rather than surfaced, because the generated path handled the case that was described and not the case that occurs.

Drift that costs nothing today. Architectural decay whose entire cost is deferred, which means it will not surface in any metric you are currently watching.

And the organizational version of all of it: a team that has gotten measurably faster at producing work that nobody has verified, reporting improved velocity right up until the escaped defect rate catches up with them.

The first ninety days

If I inherited an engineering organization tomorrow and were asked to make it AI-native, this is the sequence I would run.

Audit what the gates prove. Before changing anything else, establish what the existing checks actually verify. Most organizations do not know, and the answer is usually less than assumed.

Fund verification before capacity. Whatever the AI adoption budget is, spend the first portion on the harness. It is the least visible and highest-return work available.

Adapt the SDLC to agent work. Rewrite the review standard around failure paths, placement, and whether the test proves what it claims. Sort every rule into advisory or enforced, and stop assuming a written instruction is a guarantee. Then adjust the mechanics around it: how agent-generated changes are attributed and audited, whether they enter the same review path as human work, and what ready for review means when the diff is a hundred files.

Stand up AI-assisted security scanning across every repo. Agents generate auth logic, input handling, and dependency choices at a volume no manual review process was built to absorb. When I ran a full security pass on my own platform before launch it surfaced an unauthenticated enumeration weakness, over-broad database grants, and both XSS and SSRF exposure. All of it was in code that reviewed cleanly. Continuous automated scanning is the only version of this that scales.

Name architectural ownership. One person, protected time, real authority to require relocation.

Change what gets reported. The new metrics above, plus a regression check on the agent’s own instructions whenever they change. Stop reporting velocity in the same meeting where you are asking people to slow down and verify.

None of that requires a new tool. All of it requires deciding that the constraint has moved and organizing around where it went.

I built this solo, by hand, one habit at a time, because I had no team to delegate any of it to. The next version of this, and the part I have not built yet, is making the loop close itself: a system that notices when something in production drifts out of band and writes up what it found well enough for a person to act on it in minutes instead of hours. I did not need that at my scale. Any organization running this for real eventually will.