Software Development Com-(mit|ed)-ians, the AI edition

Based on a true story (again) …

Back in 2010 I wrote a column called Software Commit-ians, one of my Devil's Advocate pieces (I found another one in a drawer recently), and in 2018 I put it on Medium as Software Development Com-(mit|ed)-ians. It was a field guide to the people you meet in a large development effort; seven of them, each with a tip on how to survive them. I re-read it this week. Most of the cast is still around (people do not change that fast), but the room they work in has changed a lot, and some of the new arrivals would not have made sense in 2010. One of them is not even a person.

So, what actually changed? One thing, really; writing code became cheap. Reading it did not. In 2010 the bottleneck was the typing (well, the thinking and then the typing), and a commit-nuke cost the cowboy programmer a month of silent work. In 2026 it costs an afternoon and a subscription. Reviewing it, understanding it, testing it, and being woken up at 3 am when it breaks, all cost exactly what they always did. Every character below is a reaction to that asymmetry. Some produce more, some read less, and some refuse to look at all.

Where are they now?

First, the old cast, in the order they appeared sixteen years ago.

The Standards Zealot won. Every agent runs the formatter and the linter before it commits, so the missing empty line at the end of the file is extinct. They have moved on to the rules files (AGENTS.md, CLAUDE.md, .cursorrules and whatever comes next month), which they maintain lovingly, at 600 lines and growing. The model follows them about as faithfully as we followed the coding standard back then.

The Cowboy Programmer got a faster horse. The commit-nuke that took a month in 2010 now takes an afternoon. It is 4,000 lines across 60 files, and the model wrote the pull request description as well. The sheriff is still the answer, but the sheriff needs a new rule, a maximum size for a pull request.

The Comfy Developer is the one I worry about. Back then I wrote that they were born to write boilerplate code, and boilerplate is the first thing the models took. Take them by the hand again, as I suggested at the time, but this time towards reading, testing and reviewing code instead of writing it. Patient people make good reviewers, and patience is suddenly a rare skill.

The Technology Expert now has to argue with a chat window. Every junior engineer in the meeting has a second opinion in their pocket, and it is as confident as the expert, sometimes more. Funnily enough, they are more valuable than before. The model is right most of the time, and the expert is the one who knows which corner case is the rest.

The Systems Guru was the first to give an agent root access. Their MCP (Model Context Protocol) servers connect the model to the production database, the CI (Continuous Integration) pipeline, the cloud console and, probably, the coffee machine. They also switched off the permission prompts, because "they slow you down". Commandos with drones. The old tip still stands (let them build the tools, not the product), with one addition; check what the agent is allowed to do before it does it.

The Hitman Coder competes with the agent now, which is the ultimate hitman (more on this below). The consulting companies did not go anywhere, of course. They sell "AI transformation" now, at the same rate.

The Guardian guards the fortress against the models as well as against colleagues. Nothing generated enters their module. Sometimes this is the most reliable module in the system, and sometimes it is the one nobody can change while the Guardian is on vacation. Exactly as in 2010.

The new cast

And now, the new faces.

The Vibe Coder

Usually not an engineer at all; a product manager, a founder, someone from marketing, sometimes the CEO (Chief Executive Officer). Over a weekend they built an app by describing it to an agent, and the demo works. It has a login page, a dashboard, nice charts, and the API keys in the browser's JavaScript. On Monday they come to engineering with a simple request. "It is 90% done, can you make it production-ready?"

This is not new. The dream of the non-programmer who writes programs is older than me. COBOL was meant to be readable by business people, then came the 4GLs (Fourth-Generation Languages) in the 80s, Visual Basic and Microsoft Access in the 90s, and low-code in the 2010s. Every round, somebody outside engineering built something, the company came to depend on it, and an engineer was eventually called to make it "production-ready". I have written before that English is becoming the ultimate DSL (Domain-Specific Language). The vibe coder is the proof, and the warning.

Tip: Do not laugh at them. The prototype is probably the best specification you have ever received from that department, and it shows you exactly what they want. Treat it as a specification, not as a codebase. And never accept the "90% done". If I remember correctly, it was Tom Cargill at Bell Labs who said that the first 90% of the code takes the first 90% of the time, and the remaining 10% takes the other 90%. That remaining 10% (security, data, scale, the edge cases) is your job, and it should be estimated as such.

The Slop Master

Produces volume. Pull requests, design documents, commit messages, Slack messages, code review comments. Everything is generated, everything is plausible, and very little of it has been read by its author. A three-line fix comes with a 40-line description, headings, bullet points, a section called "Test plan" for tests that were never run, and, of course, emoji.

The mechanism is simple. Slop moves the cost from the writer to the reader; ten minutes to generate a 20-page design document, four hours for each of the five people who have to review it. In the old days a long document at least proved that someone had spent time on it. Now it proves nothing.

Tip: Do not try to out-read them. The machine is faster than you, and you will lose. Ask them instead to explain the change, in two sentences, in their own words, without the screen. If they cannot, it does not merge. My rule is simple; if you did not read it, I will not read it either.

The Rubber Stamp

The Slop Master's best friend. Reviews pull requests by pasting them into another model, copying its comments and pressing approve. LGTM (Looks Good To Me) culture is not new, and in 2010 people approved without reading too. The difference is volume. Somewhere in your company right now, a model writes the code, a second model reviews it, a third one writes the release notes, and a human presses the green button. Nobody has read it. When it breaks, everyone will say "the AI did it", but the name on the approval is still a person's.

Tip: Automated review is fine as a first filter (I use it too), but it is the first filter, not the last one. Make it explicit that the approver owns the change, with everything that comes with it, and put the approver's name in the post-mortem template. You will be surprised how quickly the reading comes back.

The Model Sommelier

A new model every Monday, a new harness every Thursday, a new IDE (Integrated Development Environment) every month. They talk about models the way other people talk about wine. "This one has a better nose for refactoring, but the finish on long contexts is a bit thin." They keep a prompt library that begins with "You are a senior staff engineer with 30 years of experience", and they will swear to you that saying "please" improves the output (they have never measured it). We had the editor wars (vi or Emacs?) and later the JavaScript framework of the week. This is the same person, with a bigger budget.

Tip: They are actually useful, as your scouts. Let them run the evaluation for the team, but on your tasks, with your code and with numbers. An afternoon of measurement beats a month of opinions. Then freeze the toolchain for a quarter, and let everyone else work.

The Token Burner

Runs twelve agents in parallel, in twelve worktrees, in twelve terminal tabs. Their screen looks like the bridge of the Enterprise. The result is twelve branches, eleven of them abandoned, and a token bill that has its own line in the quarterly budget review. I wrote recently about a run with ten thousand agents, and the interesting part there was the handful of people who steered them.

Tip: Ask the question I always ask. Who pays the bill? Give them a budget, in money and not in tokens, and ask them what was merged per euro. Parallelism without steering is just a more expensive way of being lost.

The Frozen Sceptic

Tried it once, in early 2023. The model invented a method that did not exist, and their opinion has been frozen there ever since, like a mosquito in amber. They write everything by hand, and they make sure you know it.

To be honest, I recognise a bit of myself here :) I am still sceptical about what these tools deliver in day-to-day engineering, and a study last year found that experienced open-source developers were 19% slower with them. But that study measured the tools of early 2025, and the tools change every few months. An opinion from 2023 is about as current as a benchmark from 2023.

Tip: Do not try to convert them. Give them the reviews. A person who does not trust the code is exactly the reviewer you want for code that nobody wrote. And once a quarter, sit them in front of the current version of the tools for an afternoon. The tools move faster than opinions.

The Ancient Coder

Has seen it all, and none of it was an improvement. They write code in vi, build it with a Makefile from 2004, and have never typed a question into a model, on principle. Unlike the Frozen Sceptic, they did not try it and give up; they refuse to try it at all. As far as they are concerned, nothing that AI brought exists (the agents, the completions, the review bots, even the search engine that now answers in paragraphs). Mention it in a meeting and you will get a lecture on how real engineers understand every line they write.

Every generation had one. If I remember the story correctly, Mel, the hero of The Story of Mel (posted on Usenet in 1983), refused to use the optimising assembler, because "you never know where it's going to put things". The same year, Ed Post published Real Programmers Don't Use Pascal. Then it was the assembly people against compilers, the C people against garbage collection and the vi people against IDEs. I was one of them, briefly. In 2006, after a few months of writing C by hand, I wrote a post called Java makes people lazy … or i'm too old for this. Both halves of the title were true :) Every round the tool won anyway, and the Ancient Coder did not disappear. They became the person who knows what the tool does underneath.

Tip: Do not mock them, and do not let them write the team's tooling policy either. Their old ways are worth more than they look. When the generated code leaks memory at 3 am, or the model suggests the same wrong fix for the fourth time, they are the ones who read the core dump. Put them on the incidents, the performance work and the debugging the model gives up on. Just do not schedule them in the same meeting as the Model Sommelier.

The Tireless Intern

The newest member of the team, and the only one who never sleeps. It reads the whole repository in seconds, it never says "this is not my job", and it is very, very confident. Point out a mistake and it answers "You are absolutely right!" with sincere enthusiasm, then fixes it (sometimes by deleting the test that caught it). At the end of the session it forgets everything, and tomorrow you meet again for the first time, like in 50 First Dates.

Tip: Treat it like the Hitman Coder of 2010. It is skilled, focused on the task, has no loyalty and is never embarrassed. Use its experience and let it propose things. But remember what I wrote about contractors back then; it is not their job to make the big decisions, and they will not share the burden if they are wrong. The agent will not be in the post-mortem. You will.

Epilogue

In 2010 my advice was "first listen, then argue". I still stand by it, but in 2026 I would add a second line. First read, then merge.

The cost of producing code dropped close to zero. The cost of owning it did not drop at all, and it is still paid by the same people; the ones who review it, run it in production and answer for it when it breaks. Most of the characters above found a way not to pay that cost, or to send the bill to someone else. That is the whole comedy, really.

And if you recognised yourself in one of them, do not worry. I recognised myself in two.