With so many organizations launching vibe coding and code-assist platforms, it’s a fair question: if AI can generate an application from a prompt, why spend years learning software design, architecture and coding?
I think there’s still plenty of value. In fact, as these tools get better, understanding the fundamentals may become even more important.
It’s true that AI can already get you surprisingly far—you can have a working prototype from a rough idea in a fraction of the time it used to take. For mockups, experiments and proofs of concept, that’s a game changer. Someone with an engineering background will also get more out of these tools than someone without one—they know how to frame the problem, spot the shortcut that’ll cause trouble later, tell when an answer doesn’t make sense.
The harder question comes when someone asks you to explain what you built. How does the architecture work? Why was it designed this way? What happens when you need to change it six months from now?
If you don’t understand the underlying design, you’re going to have a hard time answering those questions—or maintaining the system when things inevitably change. In an enterprise, software rarely exists on its own; it has to fit with existing systems, processes, data and standards.
I felt this firsthand when building a web-based application in a previous role. In a client demo, I wasn’t just walking through features—I was fielding questions about how the application worked under the hood and why certain decisions were made. Months later, once the system was in production, I was called on to fix the bugs that surfaced under real use—the ones a demo environment never reveals. Understanding the design helped me stand behind the design and actually maintain it afterward.
A prototype can work perfectly when everything goes according to plan. What happens in production when the data is incomplete, a service goes down, a user does something unexpected, two processes collide, or volume spikes tenfold?
Amazon had a six-hour outage this past March that disrupted 6.3 million orders—traced back to AI-generated code that no one had stress-tested against the failure mode that eventually hit it.
In 2025, a formal vulnerability report—a CVE, short for Common Vulnerabilities and Exposures—found that Lovable had been generating database schemas without row-level security. It took 170+ production apps getting exposed before anyone caught it.
When building a prototype to test an idea, I don’t need to know every detail of how the app is wired. But once people start depending on it, someone has to know why it was built this way, where it’ll break, what it costs if it does.
More people will be able to build apps without being engineers, and honestly that’s a good thing—more experimentation, more people getting to make things who couldn’t before. But when the prototypes turn into something real, then you need someone who actually understands what’s in front of them, even if they didn’t write most of it.
If you’re in university: take on personal projects that apply what you’re learning in class, outside of it. Build something real, even small—a scheduling app, a game, a tool for a club you’re in.
If you’re early in your career: don’t just accept what the AI hands you—ask why it made the choices it did, and try rebuilding a piece of it yourself or with help from a senior engineer without the assist. Push to be in the room when things break or when a client asks “why,” not just when the demo goes well.
While code may increasingly be machine generated, the responsibility for the system still belongs to you.