Sovereign Code: What's Left of Software Engineering in 2027

For most of my career, I could tell you what an engineer did with their day: pick up a ticket, think about it, write code, get it reviewed, ship it.

The day itself kept changing. Waterfall became agile. Monoliths became services. A deploy went from a Friday afternoon ceremony to a pipeline that runs on every commit, and the tooling around every step got better, cheaper, and less ceremonial with each generation. The software development lifecycle has been evolving and maturing for as long as I have been in it, and it is a far better lifecycle than the one I started with.

What did not change was the loop. Somebody had to understand the problem. Somebody had to write the code. Somebody had to read it before it shipped. The proportions shifted with seniority and the tools got sharper, but the loop held.

It is breaking now, and 2026 is the year it broke. The models arrived able to do, at speed, most of what I had done by hand in 2025, and they got better continuously through the year, not in jumps that made the news but in the quiet, compounding way that matters. Each month the thing that had been slightly too hard became routine. Each month the harness I built to compensate for a weakness got absorbed into the model and stopped being my problem.

The industry adapted faster than it understood what it was adapting to. We were too busy shipping to ask what the shape of the job was becoming.

We Are All Orchestrators Now

Through 2026 we became orchestrators. We stopped writing most of the code and started writing the conditions under which code gets written.

The first effect was throughput, and it was enormous. The second was a quality dip, because speed without new guardrails just produces more defects faster. Then quality came back up, and in places went past where it had been, because we built the machinery to catch what the agents could not see: review tooling, quality gates, tests that gate a merge instead of decorating a pipeline.

Where we landed is this. Outside genuinely tricky problems, AI does most of the work, provided the harness carries your judgment: your business rules, your conventions, the quirks of your codebase. The harness is the job now. It encodes what you know so the agents inherit it without needing you in the room.

The engineer's day became a loop. Understand the problem. Execute with agents. Review. QA that it solved the actual problem. Ship. Then do it again.

A lot of engineers are comfortable right now. They look at that loop and think: fine, this is the equilibrium. The models do the typing, I do the thinking and the checking, it plays to my strengths, and it is stable.

It is not stable. It is a snapshot of a transition that is still running. 2026 was the year we found out the AI could do the job. 2027 is the year it does.

The Review Loop Is Already Hollow

The pull request that lands in a mature harness does not get read by a person. An agent runs the diff and comments. A second agent reviews the same pull request from a different angle and comments again. Then the agents approve, and the merge goes through.

Human input at review time is close to zero. Not zero. Close. Reading a diff line by line and forming an independent opinion about whether it should exist is mostly over where the harness is mature. We kept the ceremony and dropped the substance, and almost nobody noticed, because the outcome was fine.

I know because it happened to me first. In Sandstorm, once the review agents were catching more than I was, my review stopped being a check and became a formality. I was signing off on the machine's judgment with my name attached.

The only genuinely human gate left is manual QA against the real product. Somebody opens the thing, clicks around, tries the flow the ticket described, and decides whether it does what a person would want. That gate survives because it is the one place where the artifact under test is reality instead of a description of reality. Everywhere else, we check representations against representations.

One gate. And a gate is a place work passes through, not a place work stops.

The Ticket Becomes the Interface

The next step is obvious, and someone is already building it. Product teams stop talking to engineers and start talking to the agents. They file tickets. The ticket shape is enforced by the system (acceptance criteria, affected surface, constraints, definition of done), because a malformed ticket is a malformed input, and the harness rejects it the way a compiler rejects a type error. The work gets picked up, executed, reviewed, and shepherded automatically into an environment where a human does manual QA against the running product. Then it ships.

Read that path again and find the engineer.

They are not in the specification, because the product team writes it. They are not in the implementation, because the agents do that. They are not in the review, because the review agents do that. They are not in the merge, because the pipeline does that. They are not even in the QA, because the person clicking through it is checking the product, not the code.

There is no seat at that table labeled "engineer." There is a seat labeled "the person who built and maintains the orchestration," and there are a handful of those, and they are not doing the work the twenty engineers used to do.

The Sovereign Codebase

There is a phrase I keep coming back to: the sovereign codebase. Code that nobody reads. That second phrase is not mine, and other people have been saying it out loud all year, which is part of why the first one stuck.

Not code nobody can read. Code nobody does read, because reading it stopped being how correctness gets established. The system validates itself. Tests, benchmarks, QA, architecture agents, runtime telemetry: the code is checked constantly and by many means, and none of those means is a human being holding the file in their head.

The business does not care whether an engineer understands the code. It never did, really, but for decades understanding was the cheapest proxy for the properties the business wanted, so we convinced ourselves the proxy was the requirement. The business cares that the code is scalable, that it is secure, that it does not regress, and that it solves the business problem. That is the list. Understanding is not on the list.

I am not sneering at craft. I have spent twenty-five years caring about how code is shaped and I still care. But craft satisfaction is not a business requirement, and pretending otherwise has a cost: you argue for things the business has no reason to fund, in language it has no reason to accept, and then you are surprised when the argument loses.

The uncomfortable part is not that the business does not value your understanding. It is that the business is right not to. Understanding was never the product. It was a means, and means get replaced.

What Still Needs a Human

When engineers push back on this, the objections are always the same list. Performance. Regressions. Architecture. Judgment. Taste.

Performance is a number. It goes in a benchmark suite that gates every merge. If a change makes the hot path slower than the threshold, the change does not land. No human opinion required. And the human opinion was usually "this looks fine" until production disagreed.

Regressions are tests plus real QA. The suite catches the ones you thought to encode. QA catches the ones you did not, because a person uses the product the way a person uses it, and no set of assertions has ever fully modeled that. Together they cover the ground code review used to cover badly.

Architecture is where engineers feel most irreplaceable, so it deserves the longest answer. Architecture agents can review and revise the plan against the system's actual needs (load, coupling, cost, failure modes, the direction the business is moving), which is what turns the architecture from a fixed artifact into one that tracks the system, revised the way a good principal engineer would revise it with unlimited attention and no ego about last quarter's diagram.

Which leaves judgment and taste, and I will concede both are real and hard to specify. But notice the count. I started with five things that supposedly require a human, and three turned into properties you can measure and gate. The two that survived are the two that live at the edges of the pipeline: deciding what is worth building, and deciding whether what came back is any good. That is not a defense of the middle of engineering. It is a map of what is left after it.

So the codebase stops being a static artifact a team carries around. It becomes dynamic, managed by agents, continuously re-derived and validated, with a small number of principal engineers running the orchestration system itself and answering for its outputs. Everyone else in the pipeline is doing work the pipeline now does.

We Are Whalers at the Time of Electricity

I have been using a line that keeps landing: we are whalers at the time of electricity.

A historian would correct me, and the correction makes the analogy sharper. The American whaling fleet peaked in 1846 and was in steep decline by the late 1850s. What finished it was cheap kerosene and the Civil War, not electricity. Edison's electric light did not arrive until 1882. We are not whalers watching a new technology get switched on. We are whalers in 1859: the substitute is on the market, the skill is intact, and most of the fleet has not noticed yet.

Here is the part that holds. The whaling trade did not decline because whalers got worse at whaling. They were extraordinary at it. Hundreds of years of accumulated skill, ships built for the work, crews who took on real danger, a whole culture of prestige built around doing the hardest thing on the water. None of it saved them.

What ended the trade was that demand for what they produced went away. Something else did the job, cheaper and safer and easier to scale, and the market did not care how good the whalers had become. Skill and danger and prestige were not protection. They were the price of doing the work in the first place.

The dates are not the point. The shape is. A body of hard-won expertise can be real and obsolete at the same time, and the people holding it are usually the last to accept the second part, because the first part is true and feels like an argument.

The Value Moves to the Ends

If the middle is absorbed, where does the value go? I see three places, and I want to be honest about the size of the door.

Product. Knowing which problem is worth solving. Not writing the spec for a problem someone handed you: choosing the problem, understanding the customer, having a feel for what will matter in eighteen months, and the nerve to say no to the rest.

QA. Judging whether the thing actually works in the real world. Not "does it match the ticket." Does it work for a person with a real need, in a real session, with data messier than the test fixture. This gets more valuable as the middle hollows out, because it is the last place where reality touches the artifact.

Research. Pushing boundaries, generating ideas the models have not generated. It is the smallest door of the three in headcount, and the one with the highest variance.

Three places. That is a narrowing, not a rescue. There is no version of this where the same number of people do the same kind of work under a new job title. I would rather say that plainly than hand out a comfortable story.

Narrowing the Search Space Is the Job

The reason those three survive is structural, and it starts with how a machine decides what to work on.

Imagine a system capable of doing its own research. Not a chatbot. A swarm of agents that reads, proposes, tests, and iterates. The kind of thing that already grinds at open problems in mathematics by crawling a search space, trying combinations, checking results, and reporting the ones that hold.

In September 2026, OpenAI announced that roughly ten thousand coordinating agents had produced a machine-checked proof about the Navier–Stokes equations. The run took eighty-eight hours and passed 2.7 million messages between agents. It is a genuine result, and mathematicians have spent the weeks since arguing about what exactly it established, because the formal statement proved weaker than the paper's. Both halves of that matter: the swarm can do the work, and the work still has to be adjudicated.

And it is still resource-constrained in the way everything is: compute, energy, attention, time.

A system like that has to choose where to spend itself. It will allocate to the regions of the search space with the highest expected value, quantified by its own priors, which are, by construction, the priors it inherited from the data it was trained on. It will be excellent at finding the best answer inside the regions it already thinks are promising. It has no particular reason to look somewhere its priors assign a low value, even when that somewhere is where the answer is.

Human experience and intuition can point at those regions. Not because a human out-reasons the swarm, and not because the human's guess beats the swarm's search. Because the human can say "look there" for a reason the system has no encoding for: a decade of watching a market behave a certain way, a customer who said something strange six months ago, a hunch built out of failures that never made it into any dataset. The system cannot generate that from its own priors, because the thing you are pointing at is precisely what its priors say to skip.

This is the same relationship product has to the business. The product person does not solve the engineering problem. They narrow the search space so the engineering effort lands somewhere worth landing. Which problem, for which user, at which moment. That is the contribution. Not the solution. The selection.

So my bet is this. For the short to mid term, the bottleneck is knowing where to look. Beyond 2027, all bets are off. I have a view on the direction and none on the timeline, and I would rather say that than pretend the curve is legible.

Stop Optimizing for the Middle

Move toward the ends of the pipeline. Get close to problem definition: spend time with people who have the problem, learn to tell a real problem from a well-formatted one, get good at deciding what not to build. Get close to verification against reality. Be the person who uses the thing and can tell, without a spec, whether it works. Get close to research direction. Develop a point of view about where the interesting territory is, and the taste to defend it.

And stop optimizing for being the middle. Stop getting faster at the part that is being absorbed. Stop measuring your value in tickets closed, diffs reviewed, lines written. Those numbers are going to zero for reasons that have nothing to do with how good you are, and the people who spent 2026 getting excellent at the middle are going to find out that being excellent at the middle never protected anyone.

The direction has been consistent for two years and the pace has been consistent for one. I wrote in May that the scaffolding would be absorbed, and less than a year later it is dissolving into the models that were supposed to need it. The work moved in 2026. In 2027 the middle goes with it, and the engineers who end up fine are the ones who decided early that they would not be the middle.