Nobody Wants Artisanal Code Anymore

The boerie was always made the same way. Now everyone can see how.

For most of my career, the way you got ahead was by sharpening the axe. You knew the route, and you knew, walking in, which i's needed dotting and which t's needed crossing for this customer, this budget, this system. You knew what was safe to skip, and what would bite you in production six months later, because you had been there before. Tens or hundreds of times.

That was the contract. Hit the spec, look right, perform under load, hold up over time, and right-size the effort to what the work called for. The judgement was the product. The output looked like fast delivery; the careful, deliberate work underneath was almost invisible to the buyer.

That invisibility just disappeared.

#The boerie was always made the same way

Quick aside for non-South-African readers: a boerie (boerewors) is a farmer's sausage, and the metaphor I keep coming back to is the butcher's deli. Glass counter at the front, finished string on the tray. Kitchen at the back, where the spice grinding, casing prep, and trimming happen out of sight. Software has always had both halves too.

The split itself is older than most of us. Tom Cargill at Bell Labs, popularised by Jon Bentley in CACM in September 1985: "the first 90% of the code accounts for the first 90% of the development time. The remaining 10% accounts for the other 90%." Forty years on, it still holds: eighty percent of the visible work in twenty percent of the time. The remaining twenty percent is the edges, load behaviour, failure modes, maintainability, and security. That is where the other eighty percent goes.

That ratio is not a flaw. It is where software actually becomes software: the first eighty is shape, and the last twenty is engineering.

And here's the bit that broke: customers used to come to the butcher with nothing in hand. Of course we worked with stakeholders the whole way through. Developers do not work in a vacuum. But because the customer came in at the start and built the kitchen with us, the shape of the work was a conversation we had together. They saw the time split because they were in it. The fact that the spice mixing took half the morning even though the casing went on in twenty minutes was something they had context for.

That part is gone.

#Everyone knows someone

Everyone knows someone now: the accountant who built a CRM in a weekend, the marketer with a working SaaS prototype, the PM who shipped an internal tool without filing a ticket. They got eighty percent of the way there in days. No malice, no contempt, no "they don't get it". They shipped a real, working-ish thing, and good for them.

The data backs the visible part of the story. The original GitHub Copilot study from Peng et al. (2023) measured devs writing a JavaScript HTTP server with AI assistance and found 55.8% faster completion than the control group. That is the headline number people quote.

Then METR ran an experiment in 2025 on something much closer to real work: sixteen experienced open-source developers, in their own repositories, on real issues. The devs expected a 24% speedup with AI, and after the experiment they still believed they had been sped up by 20%. They had been measured 19% slower. METR's follow-up in February 2026 softened the headline to roughly −4% on a wider sample, but the perception gap survived intact.

The DORA 2025 State of AI-assisted Software Development report is the load-bearing one for me. DORA is the closest thing our industry has to an annual physical for software delivery, and this is the first edition where AI is the headline. Ninety percent of devs use it at work. Individual output is up: 21% more tasks completed and 98% more pull requests merged, while team-level delivery throughput is flat. The report's framing is exactly right: AI is an amplifier of an organisation's existing strengths and weaknesses, not an accelerator of delivery in its own right.

The shift is not that developers got worse; we were never slow. What changed is that the gap between "looks done" and "is done" is now visible to the buyer, and they did not know it existed before.

And upfront, nobody wants to pay for "this is going to take 80% more time." It reads as wasteful. The careful work has to fit into a smaller window now: sometimes 60% of the old time, sometimes 40, sometimes 20. The new skill is knowing, for this project, how much we can confidently shave.

#The risk that doesn't show in the demo

Here is what the demo hides.

GitClear's 2024 report and its 2025 follow-up tracked 211 million lines of changed code and projected that "code churn" (lines reverted or rewritten within two weeks) would roughly double versus the 2021 pre-AI baseline. Refactor-class changes fell from around 25% of work to under 10%, and by the 2025 update, code clones had grown four-fold. The eighty percent that "works" sits on patterns that collapse under their own weight.

Then there is Perry et al. (2023) from Stanford, published at CCS, a peer-reviewed top-tier security venue. Users with an AI assistant wrote significantly less secure code across multiple security-relevant tasks, and they were also more likely to believe their code was secure than the unaided control group. The confidence gap is the whole story.

The DORA 2024 report ties it together: a 25% increase in AI adoption was associated with about a 1.5% drop in delivery throughput and a 7.2% drop in delivery stability. Two reports, two years, same direction.

Mass-produced biltong (the good version of jerky 😉) does not taste like what your mate down the road makes, and mass-produced infrastructure security has the same problem. The cost is paid later, by someone else, in production.

#Craft moved

Craft did not die, and it did not even move; it just stopped being hidden. The careful work developers were always doing under cover of the delivery window is now the only work that still needs one. The eighty percent is commodity. The twenty (and the judgement to know which twenty matters for this particular system) is the entire product.

The hard part of selling that work is the same hard part every CISO in the world has lived with for thirty years: nobody wants to pay to reduce a risk they cannot see yet. Security teams do not get budget by listing what could go wrong; they get it by helping organisations want to help themselves. Developers in 2026 are walking into the same conversation. The selling job is not "I am faster than the AI." It is "here is the bet I can confidently take on this delivery: how much of it AI carries, where I still spend deliberate human time, and why the combined approach holds up." The bet itself is the product.

We still need to know the fundamentals deeply. More than ever, really. What we don't have anymore is the luxury of time. We have to talk while we walk. The skill that sells now is moving fast confidently. What that looks like in practice:

• Calibration. Knowing, for this project, how much compression it will tolerate before something breaks.
• Risk management. Knowing where the bug will live in six months, and which accelerated path will put it there.
• Taste. Knowing which "working" prototypes ship as-is and which will eat themselves under load.
• Judgement. Knowing when the bet didn't pay off and starting over.

Andrej Karpathy coined "vibe coding" in February 2025: "you fully give in to the vibes, embrace exponentials, and forget that the code even exists." Worth knowing: he has openly admitted that his real projects are still hand-coded. He picks the bet on every project. So do we.

#Strap in

The expectation gap is not closing. It is getting wider.

We cannot sell artisanal commercially anymore. Maybe on weekend projects, maybe on prestige work, but not on commercial software. The dev who wins the next decade is not the fastest typer or the best prompter. It is the one who can move fast confidently, who knows, on each project, how much of the work to lean on AI for and where to still spend deliberate human time.

That is part of the craft now too: building the tooling around the work. Better rules, better agent files, better prompts, better loops, better ways of checking what came back. It is not a one-time setup. It is the daily work of making the whole system one percent less dumb than it was yesterday.

Things are about to get crazy. Strap in.

EDIT: After writing this, I came across this video on agentic engineering vs. vibe coding, and it puts better names around the distinction I was circling. Vibe coding is the "follow the prompt, trust the shape, ship the thing" version: useful for exploration, prototypes, and low-risk bets. Agentic engineering is what happens when you keep the AI speed, but wrap it in intent, constraints, context, tests, review, and the judgement to know when the agent is wrong.

That is the line I care about. The problem is not using AI to move quickly; the problem is outsourcing the engineering judgement along with the typing.