The foundations of our society are shifting.
That was a key insight from Max Buckley’s presentation at AI Engineer Singapore, and it’s been on my mind ever since.
For years, software development revolved around limited resources. Writing code was costly, skilled engineers were hard to find, and shipping features required significant time. These constraints dictated how teams operated. We chose priorities carefully because every feature came with substantial trade-offs.
Now AI has shattered that old model.
With coding agents growing more powerful, the price of building software is plummeting. Tasks that once took weeks can now be mocked up in days — or even hours. Max, currently Head of Knowledge Research at Exa following 12.5 years at Google, described this as a shift in strategic thinking: it’s not simply about deciding your own actions, but about anticipating how others are acting and competing in the same space.
And there’s no sitting this out. Whether or not we feel prepared, the core ways we work are transforming.
However, cheaper development doesn’t automatically lead to superior software.
No level of AI can rescue us from solving the wrong problem. In fact, it might amplify the issue. When creating becomes effortless, it’s far too easy to produce things that look impressive technically but serve no real purpose: extra dashboards, unnecessary workflows, redundant internal tools, and applications that function perfectly yet have no reason to exist.
This is exactly why I believe engineering discernment is becoming more essential than ever.
One example from Max really resonated with me. In the traditional software world, teams had to whittle 30 concepts down to just three before writing a single line. With today’s coding agents, that decision-making process evolves. You can build more, test more, compare more, and abandon what falls short with less personal investment.
The price of experimenting drops, making trial and error far more appealing.
That sounds freeing, yet it introduces a new constraint.
If anyone can bring an idea to life quickly, attention becomes the real scarcity. So I want to genuinely thank everyone who’s made it this far. Your time matters, and I hope this piece has earned it.
I recently took part in the first-ever AI Engineer conference in Singapore, running from 15 to 17 May 2026. It gathered speakers from organisations including Google DeepMind, Vercel, OpenAI, Exa, NanoClaw, and more. This article covers three standout points from three different speakers.
AI isn’t eliminating the need for engineering rigour. It’s simply pushing that rigour to a different stage of the process.
The nature of technical knowledge itself is evolving.
Models display uneven intelligence: they can excel at certain tasks while struggling with seemingly similar ones that appear straightforward to humans.
Models often hold the right answers but won’t reveal them unless you frame the right question.
So the real question now isn’t whether we can build something, but whether it ought to exist at all.
Jimmy Lai, Director of Next.js at Vercel, echoed a similar message from a different perspective. His view was that AI has made producing things inexpensive, but taking responsibility for them far costlier.
When building gets simpler, the volume of things we produce naturally increases. But every prototype that makes it past experimentation becomes something that requires ongoing support, troubleshooting, documentation, security, and explanation. The cost of an initial build may shrink, but the cost of maintaining and owning the system remains fully intact.
Jimmy made three forecasts that particularly struck me.
First, we’re now building for agents. AI agents are emerging as a new category of software user. A neglected README isn’t merely a frustration for human developers — it’s a ticking time bomb for misinterpretation.
Second, we’re now alongside agents. Ironically, even though it’s becoming easier to ship things you don’t fully grasp, the truth is that fundamentals haven’t gone away — they’ve become more crucial than ever. Someone who masters both agent-assisted development and core engineering principles becomes nearly unstoppable.
Third, we must get better at what to walk away from. The ability to build something is not a reason to. The simplicity of generating new things turns into an upkeep headache.
This isn’t about shipping less. It means being far more deliberate about what we allow to persist. The edge belongs to teams that clearly understand what sets their product apart, what truly merits their focus, and what they should consciously leave unbuilt.
In a world where software is easy to produce, concentration becomes a competitive advantage in engineering.
Finally, my third major takeaway came from a session on design.
Phil Hedayatnia from Airfoil delivered a talk on how to build design agents that genuinely possess refined judgment amid an ocean of generic AI mediocrity. I’m not a designer, so I tend to think about design in terms of rules — what to include and what to avoid. His presentation shifted my thinking entirely.
Design isn’t about dictating actions — that’s simply drilling outcomes.
Strong design is rooted in understanding how people think, how they behave, and why certain layouts, visuals, and narratives click with them. Phil linked it to the principles of human psychology.
It’s less about examining what people create and more about investing time into grasping why they built it that way and the reasoning that shaped it.
Put simply, taste isn’t a rulebook. It’s context-sensitive judgment.
Phil shared the story behind the Shinkansen bullet train and the kingfisher’s beak. The train faced an issue: exiting tunnels produced a loud “tunnel boom” from compressed air. Engineers tackled the noise by reshaping the train’s nose to mirror a kingfisher’s beak. A kingfisher dives from air into water with minimal disturbance because its elongated, narrow, gradually tapered beak eases pressure transitions. The engineers applied the same concept to the train, using a longer, more tapered front end to compress air progressively.
What made this example compelling to me was that it wasn’t about mimicking nature — it was about grasping the principle behind why something works, then applying it in a completely different setting.
And as AI makes generating outputs effortlessly easy, the truly valuable skill isn’t recognising what a good output looks like on the surface. It’s understanding the reasoning underneath it.
Bringing it all together
Across numerous sessions, common threads kept appearing — crafting personal AI assistants, experimenting with new tools, and learning to collaborate more effectively with agents. But beneath it all, a single recurring idea emerged: code is getting cheaper to write, but sound judgment and refined taste are not.
Here’s a summary of my three core takeaways:
- Building is no longer the primary bottleneck. AI enables you to explore more approaches and reduces the penalty of being wrong. But this makes engineering judgment far more important. We need to determine what deserves to exist.
- Easy creation generates a maintenance challenge. Be deliberate about what you choose not to take on.
- In a landscape flooded with output, build products with stronger taste. Grasp the reasoning behind why something succeeds.
AI has transformed how we build software, but it hasn’t relieved us of the responsibility of owning what we create.
That’s all from me. I hope you found this worthwhile. The full talks are available on the AI Engineer YouTube channel. All conference photos were provided by the organisers, 65labs. See you in the next post!
