When 60% of the Code Is Already Written by Agents

"At Microsoft, more than 60% of our code is already written by AI agents. We are planning to scale it to 2–20 million agents, all running in a loop."

It is the kind of line that makes half of the timeline roll its eyes and the other half quietly update their roadmap. The eye-rollers have a point — "written by" is doing a lot of work, and 60% of what, exactly, is a fair question. But the roadmap-updaters have a bigger point. Whether the specific number is 40 or 60 or 80, the trajectory is not in dispute anymore. A very large software organisation is planning, on the record, for millions of agents running in a loop against its own code.

The interesting question is not whether the quote is true. It is what has to be true in your stack for a number like that to be safe.

The phrase sounds like marketing until you draw it. A loop is: an agent looks at some state, decides on an action, takes the action, observes the result, updates the state, and does it again. Millions of loops means millions of tiny decisions per minute, each of them potentially touching a file, a database, a bill of materials, or a customer.

Two things scale non-linearly when you go from one loop to twenty million. The first is cost — every wasted token, every re-fetch, every unnecessary reasoning step is now multiplied by a number with seven zeros. The second is blast radius. A bug that would have been a bad afternoon at one loop per developer becomes a company-wide incident when the same bug runs twenty million times before anyone notices.

This is why the interesting layer is not the agent. It is the harness around the agent — the thing that decides which loops are allowed to run, on what, for how long, and with what evidence they succeeded. That harness is exactly what https://bricksnotes.com/context-advantage/book/chapter-27 calls the trusted agent architecture, and it is the reason a company can honestly plan for two to twenty million agents without also planning for two to twenty million lawsuits.

"More than 60% of our code is written by AI agents" is not the same claim as "more than 60% of our engineers have been replaced." It is closer to "more than 60% of the keystrokes that end up in a pull request originated from an agent's suggestion, which a human reviewed, edited, and merged."

That distinction matters, because it tells you where the human work went. It did not disappear. It moved. It moved out of typing and into reviewing, framing, deciding what to build, and — this is the part most teams underinvest in — deciding what the agent is not allowed to touch. The new senior engineer is the one who can hold a clear picture of the system in their head and act as the last honest reviewer before code lands.

The book calls this shift by name in https://bricksnotes.com/context-advantage/book/chapter-8 — the new role of the data and software professional in the agentic era. The tools change every quarter. The role does not.

Two things had to happen before an agent could plausibly write the majority of a company's code.

First, the model had to get good enough at code that its suggestions were, on average, better than the median line a tired engineer types at 4pm. This is the part everyone talks about, and it happened faster than almost anyone predicted.

Second — and this is the part the timeline misses — the surrounding stack had to get good enough to catch the model when it was wrong. Type systems, linters, tests, CI, code review, static analysis, and increasingly, evals against real production traffic. Without that harness, a model that is right 95% of the time is still catastrophic at scale. With the harness, a model that is right 80% of the time is a superpower.

The lesson generalises well beyond code. It is the same lesson https://bricksnotes.com/context-advantage/book/chapter-13 makes about trust: trust is designed into the layer around the model, not begged out of the model itself.

Take the quote at face value for a minute and imagine you were the person responsible for running twenty million agents against your codebase and data. Five things stop being optional the moment you cross the first million.

One: a semantic layer. The agents cannot each hold their own private definition of "customer," "order," or "active." There has to be one canonical set of business meanings that every agent resolves against, or the outputs diverge and the loop turns into noise. This is exactly the argument of https://bricksnotes.com/context-advantage/book/chapter-6.

Two: guardrails and approvals. Not every action an agent proposes should be allowed to execute. The high-blast-radius actions — writing to production, sending emails, touching money — need explicit approval gates. https://bricksnotes.com/context-advantage/book/chapter-12 is the field guide for what those gates look like.

Three: cost as a first-class design constraint. At twenty million loops, a two-cent inefficiency is a four-hundred-thousand-dollar-a-day tax. https://bricksnotes.com/context-advantage/book/chapter-15 walks through where those cents hide and how to find them before finance does.

Four: evaluation on real traffic, not on demos. A golden set of a hundred prompts is worse than useless at this scale — it gives you a false sense of safety. https://bricksnotes.com/context-advantage/book/chapter-18 is the case for eval systems that run continuously against a shadow of production, not against a bookmark from launch week.

Five: a human in the loop, but a scarce one. You cannot review twenty million actions. You can review the ten thousand highest-risk ones, and design the system so those are the ones that surface. https://bricksnotes.com/context-advantage/book/chapter-14 is about how to place that human where they add the most leverage.

We recorded a short companion video for this essay on the BricksNotes YouTube channel — the same argument, in about the time it takes to make a coffee. If you prefer to watch first and read after, the player is embedded at the top of this article.

The video walks through the three-layer picture we keep coming back to: the probabilistic model on top, the deterministic core underneath, and the correctness layer in the middle where trust is actually built. It is a good five-minute primer before diving into the chapters.

The honest read on the Microsoft quote, if you are early or mid-career, is not "the field is closing." It is "the field is re-pricing." The parts that used to be the whole job — typing SQL, wiring pipelines, writing boilerplate — are quietly becoming the cheapest input in the system. The parts that used to be the invisible tax — defining metrics, sitting with stakeholders, saying no on Friday, writing the one-page memo — are becoming the whole product.

If we were mentoring an engineer or analyst this quarter, we would tell them three things. Get comfortable reviewing agent output the way a senior editor reviews a junior writer — fast, opinionated, and unbothered. Learn to write short, decisive prose; every agent-heavy team we know is bottlenecked on the humans who can turn a messy meeting into three clear sentences. And build one small piece of the trusted agent architecture at work — a resolver, a guardrail, an eval — so you have a story to tell that is not about tools.

The reading list we would give them is short. Start with https://bricksnotes.com/context-advantage/book/chapter-1 for the shift itself, then https://bricksnotes.com/context-advantage/book/chapter-4 for the 4 C's lens, then jump to https://bricksnotes.com/context-advantage/book/chapter-27 for the reference architecture. Free chapters get you the framing; the paid ones get you the playbook.

If you are the person deciding budgets, the trap to avoid is treating the Microsoft number as a target rather than as a symptom. Racing to say "our agents write 60% of our code too" is how you buy a very expensive incident. The right response is to ask which loops in your business are safe to hand to an agent, which are not, and what would have to be true — in guardrails, evals, cost budgeting, and human review — to move a loop from the second category to the first.

The teams that will still be running agents in production in 2028 are not the ones with the most agents today. They are the ones who spent this year building the layer underneath.

That layer is what The Context Advantage is a book about. If you have not started yet, the free chapters at https://bricksnotes.com/context-advantage/blog are a good afternoon. The full book, with the trusted agent blueprint, the cost patterns, and the eval playbook, is at https://bricksnotes.com/context-advantage/buy.