Coding is dead. Long live the coders

In 1959, a committee in Washington shipped a programming language called COBOL. The skeptics were so confident it would fail that one member commissioned a literal tombstone as a joke. The bet behind COBOL, championed by Grace Hopper, was that programmers should write in something close to English, not in the machine code and assembly that defined real engineering skill at the time. Sixty years later, more than 200 billion lines of COBOL still ran the financial systems of the world. The assembly programmers who had treated their craft as the job slowly disappeared. The programmers who treated their craft as a layer they could climb above defined every decade that followed.

That is the pattern. Eighteen months ago, "prompt engineer" was a job title. Today it is a paragraph in your README. The companies that cut their engineering ranks to AI-proof the P&L are now scrambling to rebuild a different capability. The constraint was never code production. The constraint was always judgment about what to build, for whom, in what sequence, and whether the output mattered.

We have moved through three layers of human-to-AI interface in rapid succession. Each one re-prices a different part of the engineering org.

1. Prompts and prompt engineering came first. The wave was about phrasing. People who could coax good output from a model felt like wizards. Six months later, everyone could do it well enough that the wizardry stopped paying a premium.
2. Agents and agentic workflows came next. The wave was about delegation. You stopped asking a model to write code and started asking it to plan, execute, recover from errors, and chain multiple steps. This is where the gap between people who could orchestrate and people who could only type got wide.
3. Skills are now arriving, and most engineering leaders are still underestimating them. A skill is a documented, testable, reusable unit of know-how that an AI can pick up, apply, and self-verify. It is the difference between an intern who improvises every task and a senior practitioner who runs a repeatable playbook. Claude Code became powerful the moment skills became first-class, because skills turn ad-hoc prompting into infrastructure. You can compose them. You can chain them. You can hand one to a teammate and expect a similar result.

Skills are not a coding pattern. They are a management pattern, and that is the part most engineering leaders are missing.

The Situational Leadership parallel

If you have managed people, you already know how to train AI. Ken Blanchard's Situational Leadership maps almost one-to-one onto how you build, deploy, and trust an AI capability inside a real workflow. I cover this in detail in Level Up, but the short version is four states.

1. S1, Directing. You tell a junior team member exactly how to do something. Step by step. Inputs, outputs, edge cases. Writing a skill is the same exercise. You are codifying tacit knowledge into a procedure another agent can follow. If you cannot write the skill, you do not yet understand the work well enough to delegate it, to a human or to an AI.
2. S2, Coaching. You let the team member try the work and you stay close. You review, you correct, you tighten. With AI, this is the iteration loop on the skill itself. You watch the agent execute, you see where it drifts, you sharpen the instructions, the examples, and the guardrails. The skill gets better because you are coaching it the way you would coach a new hire in their first ninety days.
3. S3, Supporting. You let the person run the work and you ask them to flag you when they hit a wall. The AI equivalent is verification. A well-designed skill tests its own output and escalates when the result fails the gate. As the leader, you are no longer monitoring every run. You are responding to escalations the agent itself raises. Most teams stop investing here too early, and this is where the leverage gets exponential.
4. S4, Delegating. You hand the work over. The agent runs the skill, verifies the output, escalates exceptions, and you spend your time on the next problem. You did not get here by writing better prompts. You got here by training the system the way you train people, and the system became trustworthy because the training was rigorous.

In Syntropy I made the argument that the hard skills get commoditized fast, and the human superpowers, situational leadership, judgment, the ability to teach, the ability to know what good looks like, become more valuable the more AI capability you stack on top of them. The leader who can coach an agent through S1 to S4 is doing the same job as the leader who can coach a person through S1 to S4. It is the same muscle. The 4 C's I describe in Syntropy, Create, Curate, Connect, and Consequence, are what the human does at every stage of that loop. AI cannot originate a skill it has never been taught. It cannot decide which of two outputs is better when both pass the syntactic test. It cannot tell you that the work is technically correct and strategically wrong. Those are human jobs, and they get more valuable, not less, as AI compounds.

The new coder

Here is the part most companies are getting wrong. They equated "coder" with "person who types code," looked at the productivity gains from AI-assisted coding, and concluded they needed fewer of them. The actual story is more interesting.

The new coder is not a typist. The new coder is a subject matter expert who wires together agents, skills, and verification loops into working systems, often from a terminal, often using tools like Claude Code. The browser is increasingly overhead. The IDE is increasingly overhead. A capable operator working close to the metal, composing skills and agents, will out-ship a team of traditional engineers on the work that actually matters, which is net-new applications that solve problems nobody else has solved yet.

What makes a new coder powerful is not language fluency. It is the same set of questions I have been pushing on for fifteen years in T2D3.

1. What is it for. The new coder starts from a problem worth solving, not from a ticket. They can describe the outcome in language a customer would recognize.
2. Who is it for. They have a clear picture of the user, the buyer, and the economic buyer, and they know which one they are optimizing for in this release.
3. What is the sequence. They understand that order of operations matters more than feature count. Shipping the right thing in the wrong sequence is just expensive noise.
4. How does it create value. They can connect the work back to ARR, retention, expansion, or cost. If they cannot, they kill the work.
5. Signal versus noise. They are ruthless about producing signal. A skill that generates more output is worthless if the output is noise. A skill that produces one clean answer is gold.

The coding itself, the wiring, becomes the easier part. The hard part is the subject matter expertise, the framing, the original question. AI cannot ask the question that has not been asked. It can only answer the ones it is pointed at. The new coder is the person doing the pointing, and the pointing comes from depth, not syntax.

A lesson from the painters

When Daguerre announced his photographic process in 1839, portrait painters lost commissions almost overnight. A daguerreotype could capture a face in minutes that took a skilled painter weeks. The painters who tried to compete on realism lost. The painters who asked a different question, what can a camera not do, invented Impressionism, then Cubism, then modern art. Monet, Degas, and the painters who followed did not survive by getting better at the thing the machine had automated. They survived by reframing what painting was for.

The opposing view here deserves a fair hearing. The reasonable case for cutting engineering deeply is that a smaller, AI-augmented team genuinely can ship more in the short term, and that the marginal coder who only translates spec into syntax is, in fact, replaceable. That part is correct. The error is in assuming the replaceable part of the role is the whole role. It is not. The painters who survived photography did not have better hands. They had different eyes.

This is also why the ATM analogy matters as a data point rather than a story. James Bessen at Boston University documented that ATM deployment grew from about 60,000 in 1985 to over 350,000 by 2002, and total bank teller employment grew over the same period from roughly 485,000 to 527,000. The cost of operating a branch fell, banks opened 43% more branches, and the role shifted from cash dispensing to relationship banking and cross-selling. The work that the machine could do got automated. The work that required judgment got more valuable and more abundant. The same compositional logic applies in software now. Per-unit production cost is collapsing, demand for net-new applications is expanding, and the part that requires judgment is the new bottleneck.

Why this is not a bigger team, it is a different one

The companies cutting engineering on the assumption that AI replaces coders are about to learn an expensive lesson. The coders they kept, the ones who could only translate spec into syntax, are exactly the people AI is best at replacing. The coders they let go, the ones with domain depth who also happened to write code, are exactly the people they now cannot replace at any price.

I have seen this pattern in the operating model of every team I have worked with in the last two years. The high-leverage operator in the new model is the person who can do four things at once.

1. They can write a skill, which means they can articulate a procedure clearly enough that another mind, human or otherwise, can execute it.
2. They can coach a skill, which means they can sit with the output, see where it drifts, and tighten the instructions until the drift stops.
3. They can verify a skill, which means they can design the gates that tell them when the output is wrong, and they can resist the urge to ship anything that has not passed those gates.
4. They can delegate to a skill, which means they can let the system run, watch the escalations, and spend their time on the work that only a human can do.

The first two are basic engineering hygiene. The third is where most teams underinvest. The fourth is where the compounding happens. Companies that build all four into the operating cadence will run circles around companies that just bought more licenses and called it transformation.

The discipline of shipping

In Finish Line Fridays I argue that most OKR systems measure activity and output when they should measure outcomes. The same pathology shows up in AI adoption. Teams report on prompts written, agents deployed, and skills shipped, all of which are activity and output, none of which are outcomes. The outcome question is whether the work is producing signal that the market validates.

The 72-hour rule from Syntropy applies here as well. Syntropy has a half-life. The insight that came out of Monday's session loses value by Thursday if nobody ships it. With AI in the loop, the cost of shipping has collapsed and the cost of delay has not. Teams that do not move within 72 hours of insight are systematically converting their own signal into noise. Procter & Gamble cut a new product line from 18 months to 6 by pairing AI trend analysis with human consumer-insight teams. Speed without syntropy is just faster entropy, but speed in the service of a clear "what's it for" and "who's it for" is how compound advantages get built.

The sum of the parts grows when the human in the middle gets better. It does not grow when the human in the middle gets removed. That is the bet worth making, and it is the bet that separates the companies that will define the next decade from the ones that will spend it explaining what happened to their engineering org.

Discussion items

1. Where in your current org is coding still defined as typing, versus defined as wiring agents and skills against a real subject matter problem?
2. Which of your most valuable people are quietly building skills and agentic workflows on their own time, without you knowing about it?
3. What is your S3 strategy for AI? Do your agents verify their own output and escalate failures, or are humans still doing manual QA on every run?
4. If you mapped your engineering org to S1 through S4 in their use of AI tools, what does the distribution look like? How many people are still stuck at S1?
5. How quickly does insight travel from creation to shipped work in your team? Is the 72-hour window the rule or the exception?

Questions to ask

1. What skills should we be writing down and shipping as reusable units across the company, not just inside engineering?
2. Who on the team has the subject matter depth to be a new coder, and what is blocking them from operating that way today?
3. Where are we still paying for the old coding when we could be investing in the new coding?
4. How do we promote, compensate, and protect people whose value is increasingly invisible inside traditional engineering metrics?
5. What would change in our hiring loop if we screened for situational leadership skill at the AI interface, not just at the people interface?
6. Which of our current OKRs measure activity or output rather than outcomes the market validates, and which one are we willing to rewrite this week?