AI has made it astonishingly easy to get from an idea to something that looks like software.
You can describe a feature, generate a component, wire together an API and have something convincing on screen before you’ve really had time to understand what you built.
That is genuinely exciting. It is also where the interesting engineering starts.
A working demo is not the same as a production system
Production software has users, data, failure modes, security boundaries, accessibility requirements, monitoring, maintenance and people who will need to understand it six months from now.
AI can help us move through some of that work faster. It doesn’t make those concerns disappear.
If anything, speed can make judgement more important. When producing code is cheap, it becomes very easy to produce more code than the problem needs. A convincing implementation can arrive before we’ve asked basic questions about ownership, failure, data quality or what happens when the generated assumption is wrong.
The engineer’s job is shifting
I’m increasingly interested in the idea that our value moves away from simply producing code and towards understanding systems: how data moves, where trust boundaries sit, what happens when something fails and whether the thing we are building solves the right problem.
That doesn’t make fundamentals less important. It makes them easier to accidentally skip.
I think that changes what strong engineering looks like. Reading and writing code still matter, but so does being able to trace a flow through a system, understand where data comes from, recognise the boundaries between services and explain why an approach is safe to ship. Those are the things that let you use AI as acceleration rather than outsourcing your understanding.
Use the acceleration, keep the judgement
I use AI in my own engineering work. I like the speed it gives me for exploring unfamiliar code, testing an idea and getting another perspective on a problem.
But I still need to understand what is going into production. I need to be able to explain the decisions, spot when an answer is plausible but wrong, and recognise the things the generated solution never thought to ask about.
For me, the useful question isn’t whether engineers should use AI. We already are. It’s what we choose to keep doing ourselves: reasoning about the problem, validating assumptions, reviewing the result, understanding the system and taking responsibility for what eventually reaches a user.
Vibe coding can get us somewhere interesting very quickly. Engineering is what turns that momentum into something people can actually rely on.