Jonathan Coulton wrote Code Monkey in 2006. If you haven't heard it, it's a tragicomic song about a programmer who spends his days translating other people's half-formed ideas into working software, largely invisible, largely undervalued. It was funny because it was true.
I've been writing software since the late nineties. Long enough to have been that code monkey. Long enough to recognise the pattern when I see it again.
Everyone is talking about AI replacing programmers. I think they're asking the wrong question.
Every generation of tooling in our industry has done the same thing: taken the most mechanical layer of the programmer's work and automated it away. Not the job. The mechanical layer.
When assembly language replaced machine code, nobody stopped needing programmers. They stopped needing programmers who could hold binary instruction sets in their heads. The work moved up.
When C replaced assembly, the register allocation, the manual memory addressing — that went away. What remained was harder and more interesting. The work moved up again.
Java, Python, every managed language that followed — memory management, the tedious plumbing of resource allocation, gone. Each time, the prophecy came: programmers will no longer be needed. Each time, we needed more of them, not fewer, because the reduced friction meant software ate more of the world.
AI is the next step on that ladder. Possibly a bigger step than any before it. But it is the same kind of step.
Here is what I believe, and have believed for a while now: the programmer's role does not change. What changes is the job.
Programmers sit between the world of human intention — messy, contradictory, politically charged, half-articulated — and the world of executable logic, which is precise, unambiguous, and merciless. Part of what that has always required is translating: taking what people mean and rendering it in a form a computer can execute. But translating is an activity, not the whole of the role. Programmers have always done much more. They ask the question nobody else thought to ask: but what should it do when that happens?
That requires understanding humans well enough to know what they mean when they contradict themselves, what they want when they don't know how to say it, what they'll need next year that they haven't thought of yet. AI can assist parts of that process. But the responsibility, the judgement, the negotiation, the trust — those remain human. They are not a technical problem.
There is another side to this that I hope changes too. I have been in organisations where ideas were discarded before they ever reached a programmer. The business people thought something would take three to six months, so they never asked. What they didn't know — couldn't know — was that a small change in the requirement would have made it a week's work. The idea died in a meeting no programmer was in.
The role needs to be present at the moment of articulation, not handed a finished document afterwards. Good programmers are good problem solvers. That capability doesn't stop at the edge of the codebase.
Marty Cagan argues for something similar in Inspired and Empowered — continuous discovery rather than handed-down specs. I'd push it one step further. Great products emerge when four perspectives are present from the beginning: the PM carrying the business interest, the UX designer carrying the user's interest, marketing carrying what the market wants, and the programmer carrying knowledge of what is actually possible — and what isn't. You can make a good product with two or three of these in the room. To make a great product, you need all four. Not consulted. Not informed afterwards. Present.
That judgement — technical possibility meeting business intent in real time — is one of the most valuable things a programmer can offer. It has nothing to do with writing code.
What changes is where you focus. Every previous abstraction leap produced dramatic productivity gains, but those gains didn't translate uniformly into one outcome. I think we'll see the same four responses this time. Some organisations will deliver the same software with fewer programmers — this is what I hear most often today, and it will happen. Others will keep headcount and ship the same scope faster. Some will use the freed capacity to take on complexity that was previously out of reach. And some will see new business opportunities that simply weren't viable before, and hire more people to pursue them.
All four will happen. Which one happens to you depends less on the technology than on how your organisation chooses to respond to it. That's a leadership question, not a technical one.
The code monkey is not the problem. Many programmers I know think of the broader conversations — the domain discussions, the stakeholder meetings, the product decisions — as distractions from the real work. I understand that. There is satisfaction in craft, in the clean rendering of a well-understood requirement into working code. But organisations that reduce their programmers to that activity alone are leaving most of the value on the table. The programmer who only writes code is being underused, whether they know it or not.
AI absorbs the mechanical end of the translating. What remains is the part that was always more important. That is not a threat to the programmer. It is, if anything, an overdue correction.
And the translating doesn't disappear. It moves up the ladder, as it always has.
What I think is coming is a new abstraction layer — one that will need its own language, its own tooling, its own discipline. Not prompts. Not natural language thrown at a chat interface. Something with enough structure to version control, reason about, and verify. Something closer to a specification language than a prompt. Something capable of capturing intent precisely enough that software can be derived from it rather than manually assembled.
The programmer working at that level is still translating — between human intent and a formal specification. The AI handles the step below. The craft moves up, as it always has, and finds a larger and more interesting surface to work on.
They still write. Still think. Still talk to the business, the designer, the stakeholder. Still find the contradictions in the spec before they become bugs in production. Still make the judgement calls.
They just don't spend their afternoons writing boilerplate.
Jonathan Coulton's code monkey deserves better than that anyway.
Johan Aludden has been building software since the late nineties. He is currently thinking about what comes next.