Code is Cheap. Engineering Judgment is Now a Scarce Resource

basic society is changing.
That was one of the ideas from Max Buckley's talk at AI Engineer Singapore, and it has stuck with me ever since.
For decades, software engineering has been structured by scarcity. Code was expensive to write, developers were scarce and features took time. This mindset has shaped the way teams work. We prioritized carefully because all aspects had significant opportunity costs.
But AI has broken that assumption.
As encoding agents become more powerful, the cost of implementation drops dramatically. What used to take weeks can now be represented in days or hours. Max, Head of Information Research at Exa after spending 12.5 years at Google, put it this way changing game theory: it's not just asking what to do, but what to do when everyone behaves this way and tries to win.
And you can't opt out of these changes. Whether we are ready or not, the fundamental ways of working are changing.
But cheaper implementation does not mean better software.
No amount of AI can save us from building the wrong thing. In fact, AI may make that problem worse. The simpler the architecture, the easier it is to create things that are technically impressive but not essential: More dashboards, more workflows, more internal tools, more apps that work but don't deserve to exist.
That's why I think engineering judgment is so valuable.
One of Max's examples stayed with me. In the old software economy, teams had to whittle 30 ideas down to 3 before building anything. With coders today, the decision process is changing. You can create more, test more, measure more, and discard what doesn't work with less emotional attachment.
The cost of trying is low and testing becomes more attractive.
That sounds liberating but it also creates a new bottleneck.
If anyone can model an idea, attention is now a scarce resource. That also means I have to thank each and every person reading this. Your attention is not free, and I hope I made this piece worth your time.
I recently attended the first AI Engineer conference in Singapore, held from 15 to 17 May 2026. It included speakers from companies such as Google DeepMind, Vercel, OpenAI, Exa, NanoClaw, and others. This article will explain 3 points of 3 speakers that stood out to me.
AI does not eliminate the need for an engineering discipline. It moves that behavior to another part of the system.
Technical knowledge changes with the situation.
The models have it strong intelligence: They can be extremely good at some tasks, but surprisingly bad at nearby tasks that seem equally easy to humans.
Models often know the answers to complex questions but will not reveal them unless you know what to ask.
So the question is no longer whether we can build something. It is that there should be.
Jimmy Lai, Director of Next.js at Vercel, shared the same sentiment in another way. His point was that AI has made creation cheaper, but ownership more expensive.
As construction becomes easier, the number of things we can do increases. But every heavy prototype becomes something that someone has to maintain, modify, document, protect, and explain. The cost of writing the first version may fall, but the cost of owning the system never goes away.
Jimmy made three predictions that impressed me.
First, we are here now structure of agents. Agents are becoming a new breed of software users. The old README is no longer just annoying. It's a vision waiting to happen.
Second, we are here now building with agents. Ironically, although it is now easier to be able to build something that you do not understand well, the truth is that the basics have not changed and are more important than ever. If you're good at building agents while also being strong in the basics, you're unstoppable.
Third, we must learn what not to be the owner. Just because you can build something doesn't mean you should. The freedom of creation has become a burden of maintenance.
This does not mean that we should post less. It means that we should be many on purpose about what allows us to survive. The advantage goes to teams who know what makes their product unique, what deserves their attention, and what not to build on purpose.
In a world where software is cheap to create, focus it becomes an engineering property.
Finally, my last key takeaway came from the design discourse.
Phil Hedayatnia from Airfoil gave a talk on how to create tasteful design agents in a sea of common AI slop. I'm not a designer, so I tend to think about design in terms of what good design should or shouldn't contain. His speech reframed that for me.
Design does not try to teach a person about what to do and what not to do. That is training by results.
Good design is about understanding how people think, how they act, and why certain flows, visuals, and narratives resonate with them. Phil was referring to the human mind.
It's less about looking at what people are doing, but spending more time trying to understand why they do so and the thought process behind it.
In other words, taste is not a checklist. Contextual judgment is used.
Phil gave the example of the Shinkansen bullet train and the kingfisher bill. The train had a problem: when it exited the tunnel, it created a huge “tunnel boom” caused by compressed air. The engineers reduced the noise by modeling the nose of the train after the bill of kingfisher. The kingfisher can jump from air to water with very little splash because its long, thin, pointed leg reduces rapid pressure changes. Engineers use the same principle on a train, using a long and pointed nose to gradually compress the air.
What I liked about this example was that it wasn't just copying nature. It was about understanding why something worked, and then applying that principle to a different situation.
And as AI makes it easier to produce output, the key skill isn't just knowing what a good product looks like. It is to understand the why behind it.
Wrapping up
Throughout the many talks, there were many recurring themes, such as building personal assistants, trying new tools, and learning how to work effectively with ambassadors. But underneath it all, the same idea keeps coming up: Code is getting cheaper, but judgment and taste aren't.
3 key takeaways:
- Implementation is no longer the main barrier. AI allows you to try more ideas and reduce the cost of mistakes. But that makes engineering judgment very critical. We have to decide what is worth having.
- Cheap creation creates a burden of care. Decide what is not yours.
- In a multi-product world, create products that taste better. Understand the context behind why something works.
AI has changed the way we build software, but it hasn't taken away the responsibility and ownership behind it.
That comes from me. I hope this was worth your time. The full lectures are on AI Engineer Youtube here. See you in the next article!




