Software Engineering to Outcome Engineering
A fundamental shift is underway in the domain of software engineering. I’ve observed it firsthand across teams, organizations, and the wider industry.
The discipline used to mean building things by hand. You gathered requirements, designed the solution, wrote the code, tested it, and shipped it yourself.
That is no longer the default.
A SemiAnalysis report found that 4% of all public GitHub commits are now authored by Claude Code. That number doubled in a single month. At the current trajectory, it could cross 20% by the end of 2026. One in five commits, written by AI.
Inside Anthropic, the numbers are even more striking. Boris Cherny, the head of Claude Code, said he hasn't written any code himself in over two months. Company wide, 70% to 90% of code is AI generated. Claude Code itself? About 90% of its own code is written by Claude Code.
We are in the middle of a real shift, not just in tooling but in what the job actually is.
The value is moving up the stack toward architecture, solution design, and system thinking. The role is evolving from software engineering into something closer to outcome engineering: define what you want, set the constraints, direct agents, and review what comes back.
What the Industry Leaders Are Saying
The people building these tools and running these companies are saying it out loud.
Andrej Karpathy
Karpathy's arc over the past year tells the whole story in fast forward.
In February 2025, he coined the term "vibe coding" to describe building software by prompting AI and accepting whatever comes back. It was casual, fun, and mostly for throwaway projects.
By October 2025, he was skeptical. He called AI coding tools "overhyped slop" and said the industry was "trying to pretend like this is amazing, and it's not."
Two months later, in December, he wrote: "I've never felt this much behind as a programmer."
Then on the one year anniversary of vibe coding, February 2026, he introduced a new term: agentic engineering. This is the version where developers are not just prompting. They are overseeing AI agents that plan, write, test, and iterate on code with minimal direct input. The evolution from casual prompting to professional orchestration, in under 12 months.
Dario Amodei
The CEO of Anthropic said it plainly at Davos 2026:
"I have engineers at Anthropic who say: I don't write any code anymore. I let the model write the code, I just edit it."
He went further, predicting that the industry is "maybe only 6 to 12 months away" from AI handling most or all of what software engineers do end to end.
Sam Altman
Altman framed the change in numbers. In a Q&A with developers in San Francisco, he noted that in 2024, developers spent 80% of their time writing code and 20% on architecture and design. By 2026, that ratio has flipped: 30% writing, 70% architecture.
His point was blunt. The developer who writes 10x more code is not the valuable one anymore. The one who understands why the code should exist and how it fits into a larger system is.
Satya Nadella
Nadella's framing is the broadest of the group. At Davos 2026, he compared this moment to the 1980s, when computing created an entirely new class of knowledge work. His point: the PC did not just automate typists. It turned billions of people into computer users and created entirely new categories of work. He believes AI will do the same.
He describes AI as a "complete inversion" of how information flows through a business. Traditional hierarchies exist to filter data upward through layers of management. AI flattens that. When anyone can query an agent for a full briefing, the rationale for many of those layers changes.
On the engineering side, he pointed to a concrete example. At LinkedIn, Microsoft merged four separate roles (design, program management, product management, and front end engineering) into one: "full stack builders." He called it the biggest structural change to software teams he has seen in a career that started at Microsoft in the 1990s.
His summary of where this is heading: "All of us are going to be managers of infinite minds."
What Changed in Practice
The day to day work of building software looks different now.
The old loop:
- Get requirements
- Write the code
- Test it
- Deploy it
The new loop:
- Define the outcome
- Set constraints and context
- Direct agents to build it
- Review, adjust, and iterate
Engineers still need deep technical knowledge. You need to understand what good code looks like in order to recognize good output from an agent. But the hands on the keyboard are increasingly the agent's, not yours.
Karpathy described it well: LLMs behave like eager but sloppy junior developers. Fast, capable, and occasionally careless. The engineer's role shifts to oversight, direction, and quality control.
The biggest difference between vibe coding and real agentic engineering comes down to one thing: testing. With a strong test suite, agents can iterate in a loop until tests pass. That gives you high confidence in the result. Without tests, the agent declares the task done and you have no way to know if the code actually works.
This is why the shift is not "engineers are being replaced." It is "the nature of engineering is changing." Knowing how to architect systems, write clear specs, and build reliable test suites matters more than ever. Writing boilerplate matters less.
The Consensus: "I Should Have Tried It Earlier"
When I talk to engineers about these tools, the most common reaction is not resistance. It is regret.
"I should have tried this sooner."
I hear some version of that almost every time. Not from people who are behind. From experienced engineers who waited because they assumed the tools were not ready yet, or that adopting them would be a distraction.
One story that stuck with me: my wife is a UX Designer, not a software engineer. She was stuck on a bug for 4 days using ChatGPT to help her debug it. Back and forth, prompt after prompt, no resolution. Then she tried Claude Code. One prompt. Solved.
That moment captures something bigger than a product comparison. The barrier to using these tools has collapsed. This is no longer something only engineers with deep context can benefit from. Designers, product managers, analysts, founders, anyone who can clearly describe what they want can now get meaningful work done with AI.
The skill that matters most is no longer memorizing syntax or frameworks. It is the ability to clearly articulate what you want to achieve. That is a skill anyone can build.
This Is as Bad as It Gets
Here is the part that is easy to miss when you are caught up in what these tools cannot do yet.
What we have today is the worst these tools will ever be.
Every month they get better. Every update expands what a single person can accomplish. The frustrations you hit today, the hallucinations, the context limits, the occasional broken output, those are all shrinking. The trajectory is steep and consistent.
Software engineering is being disrupted first because it is the domain closest to the tools themselves. Code is structured, testable, and iterable. It is the ideal playground for AI agents to prove themselves.
But it will not stop at software.
The same pattern will reach the wider world of knowledge work. Legal analysis. Financial modeling. Operations. Marketing. Healthcare administration. Any domain where the work involves processing information, applying rules, and producing structured output is on the same path. Software engineering is simply one of the earliest domains where this shift is already happening.
The people who start now, even while the tools are imperfect, will build compounding advantages. They will develop intuition for how to direct agents effectively. They will learn what makes a good prompt versus a vague one. They will understand the architecture of human plus AI workflows before their peers even begin.
The disruption of software engineering is not the end of the story. It is the opening chapter. Knowledge work as a whole is next.
Enjoyed this post?
If this brought you value, consider buying me a coffee. It helps me keep writing.