Everyone Can Be a Software Engineer Now. Become Something Rarer.
Code authorship is becoming abundant. Outcome specification, precise enough that an agent executes without filling in gaps, is what’s scarce now. Most senior technical careers haven’t started the tran
Earlier this year, Naval Ravikant made an optimistic statement: “Thanks to AI, everybody can be a software engineer.” He meant it as a prediction about access and democratization, the collapse of the barrier between an idea and its execution. He’s right on the access side. He’s incomplete on the value side, and the value side is where the careers live.
If everybody can be a software engineer, software engineering is no longer the scarce skill. The thing that was the gate, the ability to translate intent into working software, is becoming abundant. When something scarce becomes abundant, the value doesn’t disappear. It moves. The question for any senior career built on the old gate is where the value moves to, and whether you’re already standing where it lands.
The role on the other side of that move now has a name. The frontier labs are calling it the Forward Deployed Engineer, paying $10K a day to deploy agents inside customer organizations. OpenAI launched a $4 billion deployment company and acquired Tomoro to staff it with 150 FDEs. Anthropic raised $1.5 billion with Blackstone and Goldman Sachs for the same play. Aaron Levie at Box calls it the fastest-growing role at companies like OpenAI and Anthropic. The Weekend Dispatch covered the external version two weeks ago: a $5.5 billion bet that the right answer for AI deployment is consultants sitting inside your company at $10K a day.
The external bet is real. It is also incomplete. External FDEs can customize the deployment, but they cannot make your team trust the system, improve your data hygiene, or capture the institutional context that determines whether the agent is solving the right problem. That work is internal. It lives with the senior person who knows what good looks like in the organization. Call it the Outcome Engineer: the person inside your company who specifies what the software should do precisely enough that the agent builds it correctly, reliably, repeatably, without continuous interpretation and correction. Becoming one is the move Naval didn’t name.
I had to become an Outcome Engineer before I knew the role existed. When I first started working seriously with coding agents, nearly every interaction was probabilistic. I would describe what I wanted, the model would interpret my intent, and something would come back: usually impressive-looking, often close to what I had in mind, but shaped by the model’s best guess about the gaps between what I said and what I meant. The output varied from session to session on the same problem. The same prompt delivered different results depending on how much context the model had, which model I was using, and what I’d said in the first ten messages of the conversation. I thought this was the nature of the tool. It is not. It was the nature of where I was in the process.
This is what practitioners now call vibe coding. You’re expressing intent and hoping the model’s interpretation of that intent is close enough to be useful. Sometimes it is. Over time, though, you notice something: the results are uneven in ways you can’t fully explain, you’re re-explaining your preferences in every session, and the impressive-looking output sometimes collapses under examination. You’ve built something that works until it doesn’t, and you can’t always tell in advance which one you got.
The transition out of that layer doesn’t happen at once. It happens as you accumulate the infrastructure that makes outcomes repeatable: briefing documents that give the model your context before you’ve typed a word, rules that encode the preferences you’d otherwise re-explain, skills that specify the exact procedure for tasks you run more than once, commands that invoke those procedures without ambiguity. None of this is about complexity. The setups I run now are simpler than the elaborate “multi-agent” architectures I built a year ago and subsequently dismantled. What they are is precise. The model doesn’t interpret; it follows. When I specify the outcome I want, I get that outcome, or I get a failure I can diagnose and correct. That’s context engineering: building the layer beneath the model that makes its behavior deterministic rather than probabilistic.
The test I use is simple. Can I hand this to a different model with similar capabilities tomorrow and get the same result? If yes, I’ve engineered the outcome. If the result depends on this specific model, this specific session, or this specific phrasing, I’m still vibe coding with better vocabulary.
The Distance Between Layers
The career structure that felt like advancement is now the source of exposure. Software development as a profession has historically organized itself into layers of abstraction. You start writing code. As you grow more senior, you move toward reviewing code, designing systems, and managing the people who write the code. Each layer felt like an advancement: more responsibility, more distance from the implementation details. Seniority looked like an abstraction. That pattern wasn’t wrong for most of the last thirty years. It described how technical careers actually worked.
The problem is that the layers between you and value creation are now a different kind of exposure than they used to be. Each layer of seniority added distance from the output. Writing code puts you one step away. Code review added another. Managing a team that did the reviewing added a third. Each layer felt like safety, and each is now the thing that can be removed without the output stopping, because the output keeps coming regardless of who’s in the middle.
Block is the public case. In March 2025, Jack Dorsey cut about 1,000 workers and explicitly demoted 200 managers out of their leadership roles. In February 2026, Block announced cuts of roughly 4,000 jobs, about 40 percent of the workforce, with the stated goal of flattening the org, building smaller and more focused teams, and mandating AI fluency in performance evaluations. Dorsey predicted most companies will make similar cuts within a year. The layers are being compressed, not from the top but from the bottom, and the people who understand this earliest have the most time to reposition.
The dynamic isn’t specific to developers. The same compression is happening at the consulting layer, where the partner whose value lies in translating client needs into project scopes is being asked to produce what the agent could have produced on its own. The product management layer is feeling it, where the PM whose value was aligning stakeholders around a roadmap is being asked whether the alignment work would survive an agent that surfaces the same options. Every layer in which the job description involves translating intent into something an agent could produce is exposed. The layer matters less than the gap between you and the outcome. If the gap is greater than zero, someone will ask whether it could be removed.
The repositioning isn’t about writing more code faster. Developers who respond to this moment by accelerating code production are running toward the disruption rather than away from it. The repositioning is about moving toward outcome specification: becoming the person who defines what the software should do, at a level of precision that an agent can execute against without filling in gaps you didn’t intend. That’s a recognition that the scarcest cognitive skill in a world where code-writing is abundant isn’t the ability to produce code. It’s the ability to specify outcomes precisely enough that the right code gets produced without continuous interpretation and correction.
The timeline on this is shorter than most developers are accounting for. The ones who are repositioning now, who are learning to work at the outcome layer, are building a durable skill while the layer below them is still in transition. The ones who wait for the transition to complete before deciding what to do about it are making a calculation that has historically not worked out well.
The Same Destination From Two Directions
The CC4NC reader, who has never written a line of production code, and the developer, who has spent twenty years doing exactly that, are converging on the same skill set from opposite directions.
The non-coder is arriving at outcome engineering because they’ve discovered that expressing vague intent to a coding agent produces vague results. The better they get at specifying what they want in plain language, with constraints and explicit success criteria, before the session starts, the better the output gets. They’re learning that precision in the brief is the leverage. They’re becoming Outcome Engineers without ever touching a syntax error.
The developer is arriving at the same place from the other direction. They know precisely what they want at the code level, but they’re learning that articulating that precisely enough for an agent to execute reliably, without babysitting the session, without fixing the agent’s interpretation of their intent, requires a different kind of specification than they’re used to writing. Something more like a contract with the agent: here is the outcome, here are the constraints, here is what “done” means, here is how to tell if you got it wrong before it reaches me. The specification is the work. The code is the artifact produced once the specification is sufficiently well-defined.
Aaron Levie has been describing the role for months. “You need humans to go implement this stuff inside the organization. Those are the engineers of the future, if you’re not just building software that is an application.” That description maps directly to the Outcome Engineer. Levie is hiring for it externally at the frontier labs and internally at Box. Every senior technical person reading this is being hired for some version of it, whether the title catches up or not.
An Outcome Engineer is someone who can specify the target precisely enough that the gap between specification and output is not filled by the model’s best guess. It’s the same role arriving from two very different backgrounds, and the path from either direction runs through the same set of skills.
What This Asks of You
The transition Naval was pointing at is real on the access side and incomplete on the value side. The completed version is this: you were hired for the code you could write. You’re hired now for the outcomes you can specify well enough that an agent can produce them without filling in the gaps. The senior people who make this transition early are the ones to whom the next wave of FDE-style work falls. The ones who don’t are the ones whose layer keeps getting compressed.
The objection worth handling is that AI will eventually do outcome engineering too. The model will read the user’s mind, infer intent without specification, and fill in the gaps with judgment rather than guesses. That may come, in some narrow domains, on some timescale. It hasn’t come yet, and what is clear from current practice is that the human context, the institutional knowledge, the read on what success actually looks like for this customer, in this market, this quarter, is the part that doesn’t outsource cleanly to a model trained on the average of the internet. For now, outcome engineering is a human role that an agent executes against.
The exercise to run this week: pick one recurring task you currently do in agent sessions. Write the outcome specification, what you want, what constraints apply, what “done” means, how to tell if it went wrong, precisely enough that a fresh session with a different model would produce the same result. Then run it against a different model. The gap between what you specified and what came back is the work that remains.
Daniel Williams advises clients about AI tools, strategy, and human resilience at dewilliams.co.
Claude Code for Non-Coders publishes on Tuesdays and Thursdays. If you found this useful, share it with someone who’s still writing code instead of specifying outcomes.