Code is getting cheap. Engineering isn't.

Crowds of fun-seekers exploring a city on foot, "

Arjan Franzen

17 August 2026

Two panels: implementation priced at 150 euro an hour, struck through with a downward arrow, beside engineering judgement marked scarce with an upward arrow.

Brett Chalupa has been programming for twenty years. He recently published a video on his channel Brett Codes called I'm done coding with AI — not the video the title suggests.

The lazy version of this genre says the tools don't work. Brett says the opposite. He was skeptical of Copilot, came round to agentic coding in 2025, and watched himself ship more software than he could have written by hand — connecting Linear to Claude Code and getting non-trivial projects built without editing a line. That worked, and anyone arguing with the rest should sit with that first.

His problem started about a year in, and it wasn't productivity. The agents produced more code than he could meaningfully review. He felt detached from codebases nominally his. He was learning less, because he had stopped struggling with implementation — and the struggle was where the learning lived. He cared less about code he hadn't written. More output wasn't becoming more revenue or better products, and when generation is nearly free, little stops a team shipping features nobody asked for. His role had flattened into reviewing someone else's work: "basically just a hamster on a wheel, checking boxes," as he puts it. So he stopped, and went back to writing code by hand.

The important parts of that are almost certainly correct. His argument compresses to a chain of inequalities worth pinning above every engineering manager's desk — more code is not better software, better software is not more customer value, and none of it automatically produces better engineers. Review capacity as the true bottleneck. Ownership decaying when nobody wrote the thing. Cheap generation quietly financing feature bloat. We have written before about how generated code is not automatically good, how constant AI assistance wears people down, and how AI erodes the path from junior to senior.

I just don't arrive at his conclusion. Brett's answer is to stop using AI. Mine is that software engineering itself has to change.

The business model nobody quite wants to say out loud

So here it is: the days of selling your Java knowledge for €150 an hour are ending.

For three decades, implementation knowledge was scarce, and that scarcity was the business model. Companies needed people who knew Java and Spring, relational databases, AWS or GCP, Kubernetes, CI/CD, whichever JavaScript framework was ascendant that year. That knowledge was expensive because it was hard to acquire, and a whole consultancy industry — ours included — sold it by the hour.

Generative AI attacks the scarcity, not the skill. Competent implementation is becoming dramatically cheaper. When one supplier needs four developers for three months and an AI-native team solves the same problem with two experienced engineers in a fraction of that, customers eventually notice. They were never buying Java hours. They were buying a solved problem.

That is not to say senior engineers have become worthless. I wrote in 2023 that "the end of programming" was silly sales nonsense, and I still think so. What I underrated was how much the job itself would move.

Code becomes cheap. Engineering judgement does not. As implementation becomes abundant, value migrates to the questions that were always hard: What should we build, and what should we deliberately not build? Which architecture survives three years, and how does it integrate with the ERP nobody wants to touch? How do we migrate, secure and operate it? How do we recognise generated code that is subtly, plausibly wrong, or stop an agent inventing three abstraction layers for a CSV import — while keeping the result understandable to whoever is on call, and our best engineers out of a review queue ten thousand lines deep?

Read that list again: it is Brett's list. He named the central engineering problems of the AI era more precisely than most vendors selling into it. His conclusion is to stop using AI. Ours is better engineering around it.

Cheaper software usually means more software

One more point about cost.

When something becomes five times cheaper, buyers rarely buy the same quantity and bank the difference. They buy more. Projects that never cleared the business case suddenly clear it. The €500,000 internal application becomes a €75,000 project. The €150,000 integration becomes €25,000. The customer portal that died in three budget rounds is abruptly worth building.

The likely future isn't simply "fewer programmers". It is much cheaper software and far more of it — software that still has to be architected, secured, integrated and operated by people who know what they are doing. Economists call this the elasticity of software demand. Engineers can call it a bigger backlog.

What we're doing about it

This is the transition that pushed ZEN Software toward AI-native software engineering and AI technology consultancy — not a fresh label on the same hours, but because the work is genuinely different.

We help organisations work out where AI actually reduces development cost and where it merely hides it; how a team uses coding agents without drowning in review; what changes in architecture, testing and delivery when much of your code arrives pre-written; how to modernise what you already have rather than blindly regenerating it. Above all: how lower implementation cost becomes something the business can point at.

Almost nobody needs more code. So: don't buy more code — build better software for less.

If you want to understand what AI-native engineering means for your software organisation, development costs or technology strategy, talk to us. Bring a real problem rather than a demo request; it makes for a better conversation.

no image placeholder

Happy Nerds are productive Nerds