Post also inspired by Giorgi Kobaidze
A separate post on Linked crossed my feed recently comparing “vibe coding” to “AI-assisted developing,” using a building metaphor: one structure floating on cracked, shallow footings, the other resting on a full foundation of requirements, architecture, data design, security, and testing. It’s a simple image, but it captures something real about where software development is actually headed and it’s worth unpacking!
The honeymoon phase is ending
For the last couple of years, the dominant AI-coding narrative has been about speed: describe what you want, watch a working prototype appear in minutes. That’s genuinely magical, and it’s not going away. But “looks amazing in the demo” and “survives contact with real users, real data, and real scale” are two very different bars. A lot of vibe-coded projects clear the first one and faceplant on the second — not because the AI wrote bad syntax, but because nobody made the upstream decisions: what’s the data model, who can access what, what happens when this fails, how does this component talk to that one in six months.
I don’t think that’s an AI problem. It’s an engineering problem that AI has made it easier to skip.
Why the future gets more architecture-focused, not less
The instinct might be “AI writes the code now, so architecture matters less.” I think it’s the opposite, for a few reasons:
• AI is a force multiplier on whatever direction you point it. Good architecture + AI assistance = fast, coherent systems. No architecture + AI assistance = fast, incoherent systems. The AI doesn’t know your product’s constraints unless a human has already thought them through.
• The bottleneck is shifting from typing to deciding. When generating a CRUD endpoint takes seconds, the scarce skill isn’t “can you write this code” — it’s “do you know what code should exist.” That’s architecture, system design, and judgment.
• Maintainability becomes the differentiator. Everyone can ship an MVP fast now. The teams that win are the ones whose fast MVP doesn’t collapse the moment it needs a second feature, a second developer, or a second order of magnitude in traffic.
• Review and taste get more valuable, not less. If AI can generate five plausible implementations, someone still has to know which one fits the system’s actual shape.
What this means for developers, especially ones re-entering the field- like myself
From experience, If you’re learning to code or coming back into tech right now, the temptation is to chase “prompt fluency” as the new core skill. I’d argue the opposite: prompt fluency is cheap to pick up later. What’s harder to pick up and what will age well no matter how the tools change is the traditional developer knowledge in that second image: requirements gathering, thoughtful design, data modeling, security thinking, testing discipline. AI assistance rewards people who already know what “good” looks like; it can’t substitute for that judgment yet, and arguably it shouldn’t have to.
The real split isn’t “AI vs. no AI”
It’s structure vs. no structure Vibe coding and AI-assisted developing can use the exact same model, the exact same prompts even — the difference is whether a human put in the architectural thinking before, during, and after the AI’s output. The future of software development probably looks less like “AI replaces engineers” and more like “AI raises the cost of not having engineering discipline.” The floor for shipping something that looks done gets lower. The floor for shipping something that lasts stays exactly where it’s always been, maybe even rises, because expectations rise with capability.
Bottom line
Same tools, more possibilities. But only for the teams doing the unglamorous work underneath. Architecture isn’t being replaced by AI. It’s becoming the thing that decides whether AI-assisted code is an asset or a liability six months from now.