Code is getting cheap. Engineering isn't.

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 argues the tools don't work. Brett argues the opposite. He was skeptical of Copilot and the early models, came round to agentic coding in 2025, and watched himself ship more software than he could have written by hand — he describes 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 that were 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 manufacturing 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.

Let me be direct: the important parts are almost certainly correct. Compressed, his argument is 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. Our industry has good answers to none of it.

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.

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 turns 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? How do we stop an agent inventing three abstraction layers for a CSV import, and keep the result understandable to whoever is on call? And how do we do all this without turning our best engineers into exhausted reviewers of ten thousand generated lines a day?

Read that list again, because it is Brett's list. He has 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 that we need better engineering around it.

One more economic point.

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 process never worth automating is now worth automating on a Thursday afternoon.

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.

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.

In practice 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 keep AI-generated complexity out of a codebase you'll own for a decade; how to modernise what you already have rather than blindly regenerating it; and how to get from "our developers have Copilot licences" to AI-native workflows. 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.