Is software development done? Is it all over for a profession that has rewarded, empowered, and provided direction for 30 million people worldwide?
The answer is clearly no: developers are needed as much as ever. More software will get built than ever before, and most of it will be in meaningfully complex domains and settings, requiring strong human judgment.
But it is changing at an incredible pace.
The Unreliable Compiler
Many have analogized LLMs with compilers. Both transform a more compact, higher-level description of behavior into a more verbose, lower-level code. But there is a crucial difference: compilers are now incredibly reliable, so much so that “it was a compiler bug” gets you approximately the same reaction as “a cosmic ray inverted a bit in RAM”. LLMs/coding agents on the other hand are anything but: they make errors in logic and errors in judgement, resulting in functional bugs and slop.
But they’re fast, and there are effectively infinitely many of them.
The developer’s key role, then, is to figure out how to put all these unreliable compilers to work. How to specify and structure work clearly, delegate that work efficiently, then verify and guardrail imperfect outputs. In other words, developers have all just become first-time managers.
Mistakes Managers Make
First-time managers make two classic mistakes: under-delegation and over-delegation. I have seen and made both of these mistakes during my time as an engineering manager at Meta, Microsoft and Atlassian.
Under-delegation results in micro-management. This is incredibly common; the manager can’t let go, and insists on babysitting everything and everyone. This limits scale: you can’t take on more projects if you’re providing dense supervision over everything. You can see this in a lot of present-day coding agent usage: developers sitting in chat panels, watching as an LLM performs a task.
Over-delegation is also a road to pain and suffering. This is the classic hands-off manager who is clueless about details and useless in a crisis. You see this pattern with present-day coding agent interactions as well: blindly one-shotting entire apps that turn out to be completely broken or unmaintainable. Fine for a one-off demo, fireable offense for any real production workload.
The solution to both problems is to define a clear protocol with explicit hand-offs and well-defined points when you as the manager can weigh in: sparse, but effective supervision that scales up.
Lifting the Barbell
A simple model for development is plan → code → verify. It applies at multiple scales, and it’s not entirely waterfall and linear, but the model holds.
In this model, it’s clear where human attention and judgment should be concentrated: at the endpoints. Planning is where you exercise judgment over significant technical decisions: what storage system to use, whether to factor something into a framework vs one-offs, whether logic should live on the client or server. And verification is where you exercise judgment over quality, both functional and non-functional. Just as with managers, a key duty here is to hold a high quality bar.
This is the transformation that is upon us as developers: learning to switch from spending most of our time and energy on coding, to spending most of it at the endpoints. Our role remains critical, but has become barbell-shaped.
We’re building Tonkotsu around this barbell. We give you powerful tools for planning and verification while orchestrating the middle so you don’t have to babysit. The profession isn’t ending. It’s scaling up.