Software Engineering Is Becoming an Oversight Job

The pattern is familiar enough to have a name by now. A technology matures past the point where the people closest to it can stay quiet about it, and suddenly every executive in the industry gives the same speech in the same quarter. That's roughly where we are with AI and software development in 2026.

Brian, who runs the BMad Code channel and leads engineering teams at scale, made a video a year ago predicting that traditional coding was ending. He stood in a 95-degree heatwave with wind chimes clanging behind him and said natural language would become the new programming language, that agents and data were the future, and that software engineers were already behind on grasping what was happening. He's back now with a follow-up, and his basic read has held up well enough that he's no longer the only one saying it.

Dario Amodei of Anthropic said at Davos in January that AI could do most — maybe all — of what a software engineer does within six to twelve months. Anthropic now claims more than 90% of the code in its newest models was written by AI, and the company's word for the shift is "phase transition," not "upgrade." Sam Altman said publicly that we may simply need fewer software engineers, and that the skill worth building now is fluency with the tools, not fluency in the language. Andrej Karpathy, who coined the term "vibe coding" and then abandoned it, has landed on "agentic engineering" as his replacement frame: "You are not writing the code directly 99% of the time. You are orchestrating agents who do and act with oversight from you."

Brian's observation about this convergence is worth taking seriously: you can dismiss any one CEO making this argument. When they all make it in the same breath, in the same year, something real is probably moving underneath.

The numbers add texture to the anecdote. Google has said 75% of its new code is generated by AI and then approved by an engineer. Shift magazine reported that 93% of developers are now using AI tools, though productivity gains remain stubbornly low — a point worth sitting with. A study from METR tracking experienced open-source developers found they took 19% longer on tasks when using AI assistance while believing they were 24% faster. Gartner, in a published press release, projects that 40% of enterprise applications will ship with AI agents built in by 2026, up from under 5% in 2025.

Brian flags the 90%-of-code-is-AI-written headlines as requiring scrutiny, and he's right to. "AI-assisted" and "AI wrote it" are not the same thing, and the gap between those two categories is where a lot of the hype lives. The METR finding on developer productivity is the kind of complication that tends to get lost in the consensus-forming phase of a technology cycle. It doesn't refute the broader direction; it does suggest the transition is messier than the CEO speeches imply.

The most structurally interesting part of Brian's argument is the markdown claim, and it's the one that deserves the most scrutiny. His position: markdown isn't the tool you use to build software. It already is the software. When you build an AI agent, the logic and behavior live in a plain text file — the code wrapped around it is just a harness. His own BMad Method framework is, by his account, essentially 100% markdown. An engineering leader he knows measured his own codebase and found that roughly 10% of what his teams produced in 2025 was "AI-layer" (markdown-driven) output; this year it's 40%, and his projection runs to 80-90% by next year, with 100% markdown by 2028. A plain markdown instruction file standard — agent.md and similar formats — went from essentially nothing to 60,000 repositories in a year and runs in production at companies including OpenAI, Cloudflare, and Sentry.

The three-layer architecture Brian describes — human writes English, that becomes code, the machine runs the code — has a compelling follow-on argument. That middle layer, code as humans write it, exists primarily so humans can read and trust it. The machine never strictly needed it in that form. One of Brian's colleagues pushes this further: the next step is training models to skip the intermediate layer entirely and produce optimized machine code directly from natural language input. Brian himself goes back and forth on whether this actually happens, which is the correct epistemic posture. The honest version of this prediction is: it's a training problem, training problems have been getting solved faster than anyone guesses, and there's no technical miracle required. Whether it's overreaching depends on timelines that nobody has right, including Brian. I find the underlying logic more plausible than it sounds on first pass — the middle layer's primary purpose really is human legibility, and if the humans are out of the loop, legibility stops being load-bearing.

Three things currently stand in the way of the full handoff, and Brian names them plainly. Memory: models still forget instructions across sessions, and no memory architecture has fully solved this. Reliability: agents need to be right almost all the time before you can hand them the whole job, and while Karpathy has said reliability broke through late last year, "broke through" and "production-ready for autonomous deployment" aren't synonyms. Cost: running the best models continuously for an entire engineering team's workload is still expensive enough to constrain how far any organization can push this. Brian expects meaningful progress on all three within six to twelve months. He may be right on the direction and optimistic on the timeline, which is a combination this industry produces reliably.

What's left for the engineer when the typing stops? This is where Brian's argument shifts from observation to prescription, and where the supervision problem becomes the actual job. His framing: right now you drive the AI. You prompt it, you check its work. The destination is an AI that drives and pulls you in only where a human is genuinely needed — to approve a decision, to confirm intent, to catch something the model can't see. The engineering job becomes less about producing code and more about deciding what gets built and whether the output is actually what you wanted.

That's a real skill set. It's also a very different one from what most computer science programs teach and what most engineering hiring processes screen for. The deskilling dynamic Anthropic's own research has flagged — roles shifting from execution to management — suggests the transition isn't costless or automatic. Learning to direct an AI agent well requires knowing enough about the domain to catch its errors, which means the underlying expertise doesn't disappear; it just moves upstream in the process.

The engineers who will navigate this best are probably the ones who have always been most interested in what to build rather than how to build it. The ones who treated the technical craft as the point, rather than as the means to an end, have a harder road ahead. That's not a comfortable observation, but Brian makes it without flinching, and the data available right now is consistent with it.

A year ago, Brian's backyard prediction was a minority position. Today it's the consensus among the people running the companies that build the models. Whether the timeline they're describing is accurate — or whether it's the AI equivalent of every other "this changes everything in 18 months" forecast this industry has produced — is the question that doesn't have a clean answer yet. The direction, though, is about as settled as these things get before they actually arrive.

— Bob Reynolds, Senior Technology Correspondent, Buzzrag