Hari Sonnenahalli is a thought leader and seasoned Enterprise Architect at NTT Data Business Solutions (NDBS).gettyA few months ago, I watched a product manager demo something that would have taken a development team weeks to build just one year earlier. She'd described what she wanted in plain English to an AI coding assistant, and within an afternoon, she had a working prototype. No ticket in a backlog, no sprint planning, no architect in the room. Everyone in that meeting was impressed. I was too. I was also quietly making a mental list of every question nobody had asked.​That's the moment vibe coding stopped being a novelty to me and started being a responsibility.​The Vibe Shift​Vibe coding, for anyone who hasn't encountered the term yet, describes building software by describing intent to an AI tool rather than writing every line yourself. You prompt, the model generates, you iterate based on how it feels and whether it works and you move on. It's fast, it's intuitive and it has genuinely opened software creation to people who never trained as engineers. A marketing lead can spin up an internal tool. A finance analyst can automate a reporting workflow. That democratization is real, and I don't think architects should be dismissive of it.​The pros are hard to argue with. Speed is the obvious one; prototypes that once took sprints now take hours. There's also a creativity dividend: When the friction of syntax disappears, people experiment more freely, and some of those experiments turn into genuinely good ideas that would never have survived a formal intake process. And there's a morale benefit too. Teams feel unblocked. Nobody enjoys waiting three weeks for a small utility that could theoretically be built in a day.​But here's what that demo didn't show, and what most vibe coding conversations skip past. Nobody had asked what data that prototype touched, whether it duplicated a capability three other teams already had, how it would authenticate against existing systems or what would happen when someone else needed to maintain it. The tool answered "can we build this," which is a much smaller question than "should we build it this way, here, connected to everything else."​The Knowledge Gap​That gap is where I've seen good ideas quietly turn into liabilities. A prompt-generated integration doesn't know your company has a data governance policy. It doesn't know two other departments already solved this problem differently, and now you have three versions of the truth. It doesn't know your security team has a standard for how credentials get stored. It just knows what you asked for, and it gives you that, confidently, without flagging what it doesn't know. Multiply that across a dozen teams all vibe coding their own solutions in parallel, and you get an organization full of clever, disconnected fragments instead of a system. That's technical debt with a head start.​This is precisely the gap enterprise architecture frameworks like TOGAF were built to close, and it's why I think the conversation about vibe coding is incomplete without it.​TOGAF's Method​TOGAF's Architecture Development Method starts before anyone writes a line of anything, with a preliminary phase that establishes principles: what standards apply here, what's out of bounds, what "good" looks like for this organization specifically. Applied to vibe coding, that doesn't mean slowing every prompt down with committee approval. It means the AI assistant, and the person prompting it, are working inside guardrails that were decided once, deliberately, instead of being improvised project by project. A data principle that says customer information lives in one system of record, stated up front, prevents a dozen well-meaning shadow databases later.​The framework's separation of business, data, application and technology architecture is useful here too, not as bureaucracy but as a checklist that a fast-moving prompt session naturally skips. Does this tool align with how the business actually operates, or does it optimize a single person's afternoon at the expense of the next team's integration headache? Does it reuse the data model that already exists, or quietly create a new one? TOGAF doesn't ask these questions to be slow. It asks them because someone eventually has to, and it's far cheaper to ask before deployment than after three other systems have started depending on the answer.​A Memory Question​There's also the matter of the Architecture Repository, the running record of what's already been built, decided and standardized. Vibe coding tools generate output brilliantly, but they have no memory of your organization's prior decisions unless you give them one. Feeding an AI assistant your architecture principles and existing patterns as context turns a talented but forgetful collaborator into one that actually knows your house rules. That single practice, treating your architecture repository as context for your AI tools rather than a document nobody opens, has been the difference I've seen between vibe coding that scales and vibe coding that has to be quietly rebuilt six months later.​None of this means every quick prototype needs a governance board. TOGAF's own approach scales oversight to risk: A personal reporting script and a customer-facing workflow don't deserve the same scrutiny. The judgment call, of matching the level of architectural rigor to what's actually at stake, is exactly the skill vibe coding needs paired with it, not replaced by it.​The honest takeaway for executives watching this trend isn't to slow down the teams who've found a faster way to build. It's to make sure someone has done the architecture thinking before the prompting starts, not after the fragments pile up. Speed and structure aren't opposites here. Vibe coding gives you velocity. Architecture gives that velocity somewhere useful to go.​Forbes Technology Council is an invitation-only community for world-class CIOs, CTOs and technology executives. Do I qualify?