AI makes software cheaper. Systems thinking becomes more valuable.
Models make code cheap to write. They don’t make systems cheap to own, and that gap is where the valuable work moves.
Writing code is getting cheap fast. A function that took an afternoon now takes a prompt and a review. A prototype that took a week can exist by lunch.
It’s tempting to conclude that software itself is getting cheap. I don’t think it is. What’s getting cheap is one part of it: turning a clear intention into working lines. The expensive parts were always elsewhere.
Code was never the bottleneck
Most of the cost of software sits after the first commit. Keeping it running, changing it without breaking something three layers away, explaining it to the next person, deciding what not to build. None of that got cheaper this year.
Cheap code actually adds pressure there. When producing a feature costs little, you get more features, more integrations and more surface area. Every one of them has to be owned, and ownership is what gets expensive.
What becomes valuable
If output is cheap, judgement is what’s scarce. In practice that looks like:
- Knowing where the boundaries are. Which parts of a system should know about each other, and which never should. A model will happily wire everything to everything.
- Choosing what to leave out. The fastest code to maintain is the code that was never written.
- Seeing second-order effects. A change to how money moves, or how data is stored, echoes through places nobody is looking at.
- Writing things down. Models work better with clear constraints, and so do teams. Good specs used to be a courtesy. Now they multiply everyone’s output.
None of these are new skills. They just used to be hidden behind the effort of typing, and now they aren’t.
Different work, not less of it
The work I do has shifted. I spend less time producing code and more time deciding what the code should be, reviewing what was produced, and designing the system it lands in. The job looks more like editing than writing.
That makes the reviewer the bottleneck, which is uncomfortable. A model can produce a thousand plausible lines in a minute, and plausible isn’t the same as correct. So I lean on tests, types and small, reversible steps: the unglamorous tools that make fast change safe.
Open questions
- If juniors learn by writing the code a model now writes, where does the next generation of systems thinkers come from?
- How much review is enough when the volume of changes keeps growing?
- Which of today’s “best practices” were really workarounds for expensive code, and can quietly go?