A departmental manager describes the broad strokes of what is needed, a developer literately “vibes” with the AI to generate code, and a working application materializes before lunch.
CIOs are celebrating exuberantly. CFOs are eyeing the reduced development costs. Application development directors are watching their backlog shrink. And everyone is declaring victory.
They shouldn’t be. Not yet.
* * *
Magic or Illusion?
The applications being vibe coded today work. That’s not the problem. The problem is what happens six months, twelve months, or three years from now when the organization needs those thirty departmental applications to talk to each other, or when leadership needs a cross-functional view of operations, or when someone tries to build an AI or analytics capability on top of data that was never governed, or when a regulatory audit requires a consistent, traceable data lineage across systems that were never designed to share a common vocabulary.
That’s when the bill comes due. And it will be enormous.
I’ve spent decades working with enterprises on business systems analysis, logical data modeling, and application architecture. What I’m seeing right now is an acceleration pattern that should alarm any senior technology or business leader: organizations are repeating the exact mistakes of the legacy era, just at ten times the speed.
The Problem That Never Went Away
Enterprise application development has always been fundamentally about two things: 1) understanding the transactional requirements of the business, and 2) defining the data-oriented business rules that support those transactions. A purchase order isn’t just a row in a database. It has a lifecycle, referential dependencies, validation rules, and downstream implications for inventory, finance, fulfillment, and compliance.
Getting the data model right - understanding cardinality, optionality, normalization trade-offs, referential integrity, temporal data handling - isn’t bureaucratic overhead. It’s the necessary engineering.
This was true when we built applications in COBOL. It was true during the client-server era. It was true when we moved to web applications and SOA. And it remains true now that an AI can generate a full-stack application from a conversational prompt.
The underlying reality hasn’t changed: enterprise data has meaning, relationships, and rules that must be explicitly understood and deliberately managed. The tooling has gotten dramatically faster. The intellectual work has not gotten simpler.
When a vibe-coded application generates a database schema from a natural language description, The AI make implicit decisions, within the isolation of the application, about how entities relate to each other, what constraints govern valid data states, how temporal changes are tracked, what referential integrity rules apply, and what domain values are permitted.
These decisions are made whether or not anyone analyzes them. The only question is whether they are made deliberately by someone who understands the business context or inferred by a model optimizing for “looks reasonable.”
The Looming Data Architecture Crisis
Here is the scenario playing out right now at organizations that have embraced vibe coding without maintaining business analysis discipline.
• Marketing builds a customer engagement tracker.
• Sales builds a pipeline management too
• Customer Success builds an onboarding workflow application.
• Operations builds a capacity planning dashboard.
Each application works beautifully in isolation. Each was delivered fast, cheap, and to the delight of its stakeholders. Each also has its own database, each with its own definition of “customer.”
•In Marketing’s system, a customer is an account with at least one campaign interaction.
•In Sales, a customer is a closed-won opportunity.
•In Customer Success, a customer is an entity with an active subscription.
•In Operations, a customer is a resource-consuming unit tied to a service tier.
Now the CEO asks: “How many customers do we have, and what’s our average revenue per customer?”
Nobody can answer this question. Not because the data doesn’t exist, but because four different applications each embedded their own assumptions about what the data means - and nobody identified or reconciled those assumptions before the code was written.
This is not a hypothetical. This is the exact problem that data architecture, enterprise data models, and business systems analysis were invented to solve. And it is the exact problem that organizations spent decades and billions of dollars trying to dig out from under with their legacy systems.
Vibe coding, without business systems analysis rigor, doesn’t prevent this problem. It accelerates it. You can now create the mess faster now, than ever before.
Common (and dangerous) Misconceptions
This is the most common counterargument I hear from technology leaders, and it deserves a serious response because it contains a kernel of truth wrapped in a dangerous assumption.
Yes, API-first architectures and microservices allow bounded contexts to maintain their own data stores. This is a legitimate architectural pattern. A well-designed microservices architecture lets individual services own their data while communicating through well-defined contracts.
But here’s what this argument overlooks:
• Someone still needs to define those contracts.
• Someone still needs to determine the canonical data definitions that govern how “customer” or “order” or “approved” translates across service boundaries.
• Someone still needs to analyze what happens when Service A publishes an event that Service B, C, and D consume - and what the downstream transactional implications are if any of those services interprets the event differently.
API contracts are a form of data modeling. Event schemas are a form of data modeling. Domain-driven design’s bounded contexts require explicit identification of where contexts overlap and how translation occurs at the boundaries. None of this happens automatically. All of it requires the same analysis rigor that has always been necessary - it just produces different artifacts.
The microservices architecture doesn’t eliminate the need for data modeling and business systems analysis. It redistributes where the analysis happens. And if the analysis doesn’t happen at all - if teams just vibe code their services and APIs without coordinating on shared data semantics, your organization ends up with a distributed mess instead of a monolithic mess. A distributed mess is harder to fix.
This sounds pragmatic. It isn’t. Database schemas, once in production with live data, become extraordinarily expensive to change. Every application, report, integration, and downstream process that depends on a particular data structure becomes a migration risk. The refactoring cost grows exponentially with the number of systems and the volume of data involved. Deferring analysis doesn’t reduce cost, it compounds it with interest.
More importantly, by the time you “know more,” you’ve already made irreversible decisions. Data has been entered, business processes have conformed to the schema’s assumptions, and users have built workflows around the application’s behavior. You aren’t refactoring a codebase. You’re refactoring an organization’s operational reality. Ask anyone who has led an ERP migration knows how that goes.
This conflates speed of code generation with speed of system delivery. They are not the same thing. A system is not delivered when the code compiles and the UI renders. A system is delivered when it reliably supports the business transactions it was built to support, integrates with the systems it needs to interoperate with, and can be maintained and evolved over time.
The competitive advantage of fast code generation is real, but only if the resulting systems actually work at enterprise scale. Deploying thirty applications that each encode conflicting business rules doesn’t create competitive advantage. It creates technical debt that will consume your development capacity for years.
The argument also rests on a false choice. Nobody is suggesting a return to eighteen-month waterfall requirements phases. Nobody is proposing that every departmental tool needs a six-month analysis cycle. The question is proportionality: the more an application touches shared data, cross-functional processes, or regulated activities, the more analysis rigor it demands.
AI-assisted development can and should accelerate the analytical work itself - generating candidate data models from requirements conversations, validating business rules against existing schemas, identifying integration conflicts before they reach production. The right approach is to use the speed to do better analysis, not to skip analysis entirely.
This is perhaps the most seductive objection, and it reveals a fundamental misunderstanding of what AI and machine learning can do with data. AI/ML models are powerful tools for finding patterns, making predictions, and automating decisions, but they require clean, consistent, well-governed data as input.
If your training data contains four different definitions of “customer” with no reconciliation, your model doesn’t magically resolve the ambiguity. It learns the ambiguity. It produces outputs that reflect the inconsistencies in the input. Garbage in, garbage out is not a cliché in machine learning - it’s a mathematical certainty.
Organizations that plan to build AI/ML capabilities on top of ungoverned data are building on sand. The data quality and consistency problems that result from skipping business systems analysis will become the single largest obstacle to their AI strategy.
A data lake that ingests data from thirty applications, each with its own implicit data model, doesn’t become a single source of truth. It becomes a single repository of conflicting truths. The data engineering team will spend months writing transformation logic, building reconciliation rules, and creating mapping tables - essentially doing the business systems analysis that should have been done upstream, but now with the added complexity of working backward from production data rather than forward from business requirements.
Someone still needs to reconcile those definitions, build transformation logic, define master data management rules, and maintain them as source systems evolve. That work is business systems analysis by another name. Putting it downstream doesn’t eliminate it. It makes it harder and more expensive because you are now reverse-engineering business rules that should have been explicitly defined upstream.
What Should Enterprise Leaders Do?
None of this is an argument against vibe coding or AI-assisted development. These capabilities are transformative, and organizations that don’t adopt them will fall behind. The argument is that these capabilities must be paired with analytical discipline, not replaced by them. Speed without direction is just expensive chaos.
The good news is that the same AI capabilities driving vibe coding can dramatically accelerate the analytical work that makes enterprise systems successful. Here’s what that looks like in practice.
• First, maintain a canonical data model. Even if individual applications own their own databases, the organization needs an authoritative reference for what core business entities mean, how they relate, and what rules govern them. This doesn’t have to be a monolithic data model. It can be a federated set of domain models with explicit boundary definitions. But it has to exist, and it must be actively governed.
• Second, require transactional requirements analysis before development begins. This doesn’t mean months of documentation. It means deliberately identifying what business transactions the system must support, what data entities are involved, what state transitions are valid, what integrity constraints must hold, and what downstream systems will be affected. An experienced business systems analyst can do this work in weeks, not months - especially with AI assistance.
Best Practice Tip: Data modeling and transaction requirement analysis can, and should, be performed in parallel.
• Third, define integration contracts upfront. Before vibe coding a new departmental application, identify how it will exchange data with existing systems. Define the API contracts, event schemas, and data transformation rules. This is where the microservices argument becomes valid - but only if the contracts are defined deliberately rather than discovered after production incidents.
• Fourth, use AI to accelerate analysis, not skip it. AI-assisted development tools are remarkably good at generating candidate data models, identifying potential constraint violations, and flagging integration conflicts. Use them for this purpose. Let the AI draft the schema - then have a professional business systems analyst review it against the actual business rules before it goes to production.
• Fifth, establish a governance checkpoint for vibe-coded applications. Not every application needs the same level of rigor. A single-user departmental tool with no integration requirements is low risk. An application that creates, modifies, or consumes shared business data is higher risk.
Create a simple triage process: before any vibe-coded application goes to production, someone with business systems analysis expertise evaluates whether it touches shared entities, feeds downstream systems, or encodes business rules that must be consistent with the rest of the enterprise. If it does, the analysis work needs to happens before deployment.
The Bottom Line
The organizations that thrive in the age of AI-assisted “vibe coding” development are not the ones that generate code the fastest. They are the ones that combine the speed of modern tooling with the discipline of proven analysis practices.
The organizations that will struggle - the ones that will spend three years and millions of dollars trying to untangle what they built in a three months - are the ones that mistook the ability to generate applications quickly for the ability to build enterprise systems successfully.
Business systems analysis isn’t a relic of the waterfall era. It’s the intellectual work that determines whether your applications are assets or liabilities. The speed of vibe coding hasn’t made that work less important. It’s made the consequences of skipping it arrive faster and hit harder.
If you’re a CIO celebrating how many applications your teams shipped this quarter, ask yourself one question: can you produce a single, consistent, cross-functional view of your core business entities and associated data-oriented business rules? If the answer is no, and if you don’t have a plan to get there, then you haven’t accelerated your enterprise. You’ve accelerated your technical debt.
No amount of faster code generation makes this problem go away. It just makes it easier to create the mess faster.
Related Posts:
The Secret Sauce to Unlocking Agentic AI
The Uncomfortable Truth About AI Agents
The Secret Sauce of Enterprise-Grade Agentic AI
Agentic AI - Breaking the Myth of the Iron Triangle
Why AI Agents Often Fail to Improve Business Processes
* * *
Subscribe to my blog | Visit our Knowledge Hub
Visit my YouTube Channel | Connect with me on LinkedIn
Check out our business analysis Training Courses and Consulting Services
Contact us at info@inteqgroup.com