I’ve been in tech for seventeen years, and I keep watching the same cycle repeat itself — just with a different tool wearing the costume.
Back in 2008, when WordPress and Drupal were taking off, the line everywhere was the same: websites will build themselves, developers won’t be needed. What actually happened was different. Sites got built fast and cheap, and then the real work started — fixing speed problems, patching security holes, untangling SEO disasters that came from templates nobody fully understood. For the next decade, an enormous amount of developer time went into cleaning up what the “no-code” promise said would clean up after itself.
Now AI is having its own version of that moment. But notice what the obsession actually is this time. Nobody’s talking about page speed anymore — that conversation quietly disappeared. The new question is how fast can we build it? AI can produce a working website in minutes, a full application in hours, and everyone is rightly amazed by that speed.
The pattern repeating itself
Here’s what I think is coming next, because I’ve watched this exact shape before: the client comes back. “The site you built with AI — can we make it faster? Can we improve it? Something feels off.” And that’s the moment the real dependency reveals itself.
When you build with AI, your biggest risk isn’t the technology. It’s the quality of what the developer asked for. A vague prompt from someone who doesn’t fully understand the problem produces a vague result — confidently packaged, difficult to debug, and expensive to unwind. You end up back at square one: fixing what the tool promised would fix itself.
“The tools change every decade — CMS, AI, whatever comes next. But the cycle stays exactly the same. The goal matters more than the tool.”
Why this matters for how we work
This is part of why, when we scope an AI-assisted build at Yugantix, we treat the prompting and architecture decisions as the actual engineering work — not a shortcut around it. The model can write code quickly. It can’t tell you whether that code reflects how your business actually operates, whether the data model will hold up under real usage, or whether the person driving it understood the problem well enough to ask the right question in the first place. That judgment doesn’t come from the tool. It comes from experience with what breaks, and why.
The takeaway
Every decade hands developers a new tool that promises to make the old skills unnecessary. Every decade, the teams that actually deliver working software are the ones who understood that the tool changed, but the underlying discipline — knowing what you’re actually trying to build, and asking the right questions before touching the keyboard — didn’t. AI is no exception. It’s just running the same cycle faster than before.
