The 2010s were a golden age for the archetype of the Silicon Valley code ninja – someone who learned fast, executed with efficiency, and sometimes broke things along the way. They built products, companies, empires.
While I’ve certainly worked with many people who outpaced my coding productivity and project execution, I do suspect a non-trivial portion of my own career progression can be attributed to wielding (at least some) of these behaviours.
In 2026 I suspect that this archetype as a competitive differentiator is dead.
Moving fast has been commodified – Anthropic PBC sells a subscription for it that costs around $20/month.
I’m being a little facetious, but some aspects of this are uncontroversial:
It was very tempting when authoring this to outright claim that software as a field is dead – but I’ll leave the apocalyptic vagueposting to Twitter, where it belongs.
The natural follow-up for many is “I’ll just specialize deeper.” This isn’t the escape hatch it appears to be. The same capabilities that commodified fast generalist output are rapidly eroding the value of deep domain knowledge. An agent can ingest a complex codebase and develop working familiarity with its idioms in minutes. The engineer who spent years building expertise in a particular system or framework finds that the knowledge gap between them and a well-prompted newcomer has narrowed dramatically.
This isn’t to say that domain expertise is worthless – context that lives outside the codebase, in the heads of users and operators, remains hard to extract. But the portion of specialist value that was simply “I know how this code works” is shrinking fast.
Some of the most deliberate, slow-but-correct engineers I know are becoming some of the most productive. The new reality is a perfect fit for their skillset, where much of the tactics are becoming less relevant than the strategy.
The engineers whose value was defined by output velocity are the most directly substitutable by agents. An organization paying for fast code production can now get it far cheaper and at greater scale from a machine. But not every organization operates this way. For companies where the cost of being wrong is high – infrastructure, finance, health, safety-critical systems – the ability to make sound technical decisions under uncertainty has always been the real bottleneck. Generation was never their constraint; judgment was.
These are the environments where the methodical engineer thrives. With generation costs approaching zero, the organizations that value correctness and quality will find that their most important engineers are the ones who were never optimizing for speed in the first place.
So where ought human software engineering to direct its efforts moving forward?
The popular answer is verification. If generation is cheap, surely the human role is to check the output – to be the quality gate. This will remain relevant for longer than the ability to be generative, but I’m skeptical it’s a durable moat for two reasons:
This brings us back to the organizational question. The value of human engineering will increasingly depend on the stakes of the environment you choose to work in. At a company where a bad deploy means a degraded user experience for a few hours, the case for human oversight is thin and getting thinner. At a company where a bad deploy means regulatory consequences, financial loss, or physical harm, the calculus is entirely different.
My recommendation to anyone considering entering the field: choose roles and companies with limited tolerance for slop. Your competitive edge is being accountable for ensuring a high verification bar in environments where the organizational stakes demand it. The methodical engineer’s market is narrowing, but deepening – and that’s a trade worth making.
I have no better suggestion at this time.
← home