People has responded in different ways to a recent tweet by Pieter Levels where he explains he replaced all his paid SaaS with machine learning-powered custom builds and the internet went wild. But Levels was talking about code, not necessarily software.
Those are not the same thing. The gap between them is where most of us actually work.
What happened
In a June 2025 post, Levels shared that he had thrown out all paid software from his life and instead replaced it with custom AI-generated tools, making the case that if AI could build it for you in minutes, why pay for it?
Herbie Bradley disagreed. Creating software that is trustworthy — the type that manages edge cases, scales up, and doesn’t compromise your data in the middle of the night — is still a very difficult thing to do. The discussion raged across X and suddenly every engineer was talking about it.
Code is cheap now. Software never was.
Here’s the distinction that no one is explaining clearly enough.
Code is what you have in your editor. And AI is so good at writing it for you. You can describe your way to a first draft of the program faster than ever before. This is the real part.
Software is everything around that code:
→ Error handling that doesn’t silently eat failures
→ Auth that actually works when tokens expire
→ Migrations that don’t nuke production data
→ Monitoring that wakes you up before users notice
→ The boring, unglamorous connective tissue that makes a product trustworthy
AI commoditized the first, but the second barely got a glance. And mistaking one for the other is what causes you to produce a lot of fragile prototypes and name it engineering.
The prototype trap 🪤
I understand the attractiveness of it. Creating a fast tool that solves your specific issue seems like having a superpower.
However, it is essential to keep in mind that any tool you create will require maintenance. For example, that AI-generated script taking over your project management SaaS was a good idea, but eventually, it will stop working. Guess what? You will be the one dealing with support.
Levels can make that tradeoff. He’s a solo operator who ships fast and tolerates breakage. It’s a rational choice for his situation. But most of us are not in that situation. Most of us work on a team where reliability is not optional, and “it works on my machine” stopped being cute a long time ago.
This is actually good news for your career
If you’re a developer reading all the “coding is dead” opinions and feeling anxious, just relax.
The hard parts of your job — designing systems that hold up under real usage, making architectural decisions you won’t regret in six months, debugging problems that span multiple services — none of that got easier. AI can generate code for you based on a description of desired functionality but defining that desired functionality is just the same as it ever was. Writing tests is still as hard and manual as it’s always been.
Your worth did not depend on how quickly you could write a function. It was in knowing which function to write, where to put it, and what happens when it fails. That skill just got more valuable, not less. The amount of code available increased but the need for good decisions remained constant. 🎯 🎯
The real divide ahead
I think we’re heading toward a split in the industry. On one side: people who generate lots of code quickly and ship things that mostly work. The second will be those who develop software that truly functions as intended on a large scale and meets users’ needs.
Both are valid. However, they are different jobs with different pay scales and different failure modes. Understanding which one you are doing and which one the situation demands is crucial.
AI didn’t turn trivial software engineering into a solved problem, it just made the parts we thought were trivial go by faster and more reliably.
I have a question for you: when do you know if AI-generated code is “good enough,” versus software that requires human engineering judgment? Where is the boundary in your work?
