Gergely Orosz made an observation that deserves wider circulation: software engineers carefully prompting, validating before committing, thinking through the architecture, and closing the loop on AI output are not vibe coding. They are doing professional software engineering with AI tools. Calling that “vibe coding” because they are using an AI agent is the same category error as calling a surgeon who uses robotic tools someone who is “vibing the operation.”
The label has consequences. When engineering leadership believes that AI-assisted development is inherently informal, they either over-restrict it — limiting AI use to the point where teams cannot capture the real productivity gains — or they under-govern it, treating the label as permission to skip the discipline that distinguishes professional engineering from casual prototyping.
flowchart TD
A{Does AI-generated code<br/>have an architecture owner?}
A -->|No| B[Architecture gap]
A -->|Yes| C{Is there a validation<br/>gate before commit?}
B --> Z[Technical debt at AI speed]
C -->|No| D[Production risk]
C -->|Yes| E{Is the codebase<br/>footprint defined?}
D --> Z
E -->|No| F[Consistency breaks down<br/>across sessions]
E -->|Yes| G[Enterprise AI coding<br/>done right]
F --> Z
class Z bad
class G good
class B warn
class D warn
classDef good fill:#163a26,stroke:#44cc77,color:#d7ffe6;
classDef bad fill:#3a1620,stroke:#ff5555,color:#ffd9d9;
classDef warn fill:#3a2e16,stroke:#ffaa33,color:#ffe9c7;
classDef accent fill:#15233b,stroke:#4488ff,color:#dce9ff;
What the Label Was Actually Invented For
The term “vibe coding” was coined to describe a specific mode of development: generating code by prompting an AI without deeply understanding what the AI produces, accepting the output, and moving forward. The vibe is real — there is something qualitatively different about building something that runs before you fully understand every line of it. For prototyping, for personal projects, for exploring what is possible, that mode has genuine value.
What it was never meant to describe is a senior engineer who understands the system architecture, defines the prompt constraints to match it, reviews the output against the requirements, runs the validation suite, and commits only what passes. That is not vibe coding. That is engineering with better tooling.
The confusion matters because it collapses a meaningful distinction. The failure mode of unconstrained vibe coding — inconsistent architecture, unreviewed output, no accountability for what gets committed — is real and worth naming. But it is not what professional engineering organizations do when they adopt AI tools.
What Enterprise AI Coding Actually Requires
The same accountability that governed professional software engineering before AI tools arrived still governs it after. What has changed is the interface, not the requirements.
An architecture owner is still required. Someone must be accountable for the structural decisions of the codebase — the module boundaries, the data model, the integration patterns — regardless of whether the implementation was written manually or generated by an AI agent. AI can implement within an architecture. It cannot own the architecture.
A validation gate is still required. Code that has not been reviewed against the requirements, tested against the defined behavior, and verified in the integration environment does not go to production. The fact that AI generated the code does not change the bar. If anything, it raises it — AI-generated code can pass a surface-level review while containing subtle structural problems that only surface under load or at integration points.
A defined code footprint is still required. Every session of AI-assisted development must operate within a consistent architectural foundation. Without it, ten sessions produce ten different structural decisions, and the codebase accumulates inconsistencies that compound into maintenance problems.
The Carvana Lesson
I led a small data team at Carvana in 2016 and 2017. Five developers processing millions of vehicle records every day using an event-driven architecture. What that team demonstrated was that excellence in engineering does not dilute under pressure — it compounds. The relentless pursuit of accuracy and architectural consistency in a small team produces outsized results. The discipline was the differentiator, not the headcount.
The same principle applies to enterprise AI coding. A team that brings disciplined architectural thinking to AI-assisted development will compound its advantages. A team that uses AI as an excuse to skip the discipline will compound its debt. The AI accelerates whichever direction the team is already pointed.
Orosz’s Second Point Is Also Right
Gergely Orosz also noted that rebuilding established SaaS tools with AI-coded software is not a viable strategy for any company with an actual business to run. Rebuilding ticketing, observability, or feature-flag tooling in-house is a fun exercise. But then the company owns the oncall rotation, the maintenance burden, the upgrade cycle, and the reliability responsibility for tooling that was never their core competency.
This is the enterprise vibe coding trap in its sharpest form. The speed of AI-assisted development makes it feel feasible to build anything in-house. The maintenance burden that follows is independent of how quickly you built it. What used to be a month of development that discouraged the rebuild conversation is now a day — but the ten years of maintenance cost hasn’t changed.
Enterprise engineering judgment means knowing which things to build and which things to buy, regardless of how quickly AI can generate the alternative. That judgment is the discipline that makes enterprise AI coding valuable rather than just fast.
