Aug 12, 2026
What happens when implementation gets cheap?
If writing software becomes dramatically cheaper, what becomes more valuable?
For most of my career, writing software took time.
A lot of time.
You had an idea.
You designed it.
You implemented it.
You debugged it.
You tested it.
You shipped it.
The implementation itself was often one of the biggest constraints.
AI is changing that.
The first thing that changes is experimentation
I’ve noticed this in my own projects.
An idea that would previously have needed a weekend can sometimes become a working prototype in an evening — a whole extension idea, from nothing to something I could click through, in less time than it used to take me to settle on a folder structure.
That’s useful.
It means more ideas can be tested.
It also means more bad ideas can be built.
That’s an important distinction.
Cheap implementation doesn’t mean valuable software
If it costs almost nothing to build something, the cost of building it stops being a good reason not to.
But that doesn’t make the thing useful.
We could end up with an enormous amount of software that nobody needs.
The bottleneck moves upstream.
What problem are we solving?
Is it actually a problem?
Who has it?
What is the simplest useful solution?
Engineering judgment becomes more important
This is the part I find interesting.
If implementation gets cheaper, knowing how to implement something is still useful.
But knowing whether it should be implemented becomes even more valuable.
The same is true for architecture.
If an AI can generate three possible architectures in a few minutes, the interesting question isn’t whether it can generate them.
It’s which one you should choose.
And why.
Maybe the job changes
I don’t think software engineers disappear because code generation gets better.
I think the job moves upward: more time thinking about problems, understanding systems, reviewing, making trade-offs, talking to users. Less time typing boilerplate.
That’s not necessarily a bad future.
I’ve spent the last few years mostly managing engineers. Going back to hands-on building — shipping my own small tools, not reviewing someone else’s PR — has given me a chance to feel that shift firsthand instead of just describing it to a team.
I’m still figuring out what it means for the day-to-day of the job. But if there’s one thing I’m fairly sure of already: the parts of the work that got cheaper were never the parts that were hard to teach. Judging whether something’s worth building was always the harder skill. It’s just more visible now that it’s the only thing left to do slowly.
← Back to writing
Comments
Loading comments…