I love vibe coding. I do it almost every day. I use AI for 90 percent of my “real” coding.

Vibe coding is bullshit.

Exploration and enterprise delivery are different activities. Exploration allows me to test an idea, change direction, and discard the work. Enterprise delivery requires commitments about time, budget, and behavior. It also requires software that can survive changing requirements and changing teams.

The trouble begins when we treat exploration as a delivery method.

Exploration Creates Obligations

In college, a programming partner routinely started writing code without planning. His approach worked for him. I preferred to establish what I was building and how I intended to build it.

As the consequences became more expensive, my plans became more deliberate.

Following Juval Löwy’s The Method, I consider how requirements will change and create structures in the design to accommodate those changes. That work begins while requirements are still being defined.

System design, detailed design, and implementation establish a solution. Changes from the business require us to revisit those decisions.

The purpose is to accommodate change without requiring modifications throughout the system.

Vibe coding makes that thinking easy to skip. Each new feature becomes another implementation task, with the expectation that AI will resolve the resulting complexity.

But a feature generated in ten minutes can create years of obligations. Someone has to review, test, operate, secure, and change it. Someone has to understand why it exists, what depends on it, and which assumptions a change would violate.

Whether that work falls to a person or an agent, the obligation remains.

My last major consulting project involved migrating a 35-plus-year-old accounting system off a mainframe. The business needed to update its accounting models and reduce its dependence on an ever-shrinking pool of COBOL developers. The organization invested over $50 million in the project.

The quality of the existing code could not resolve the staffing problem. If the available team cannot understand and safely change a system, the business has a maintenance problem.

Generating code faster than we can understand it increases that maintenance burden.

Define the Work Before Generating It

In The Method, responsibility is explicit. Architecture, business requirements, delivery planning, and testing each have an accountable owner.

Generating code does not discharge any of those responsibilities.

I have been working on a governance pattern for agent-driven development built around that premise. Before a developer agent starts, it receives:

  • The approved design: system boundaries, responsibilities, and relevant detailed design.
  • A bounded requirement: the behavior to implement and the scope of the assignment.
  • Acceptance criteria: the evidence required to consider the work complete.
  • Coding standards: the rules the implementation must satisfy.
  • A communication model: how to ask questions, report problems, and propose changes.

The agent can make implementation decisions within that scope. Changes to approved service boundaries or responsibilities require architectural review and approval.

In one instance, before I had explicitly defined this governance pattern, agents expanded my system design from seven components to more than 50 without architectural approval. That left an implementation whose component boundaries had not been reviewed against the intended design.

I have encountered the same behavior with human developers. Repeatedly. Agents accelerated the deviation.

Developers need a process for challenging a design. Discovering a problem during implementation is useful, but replacing the design without review bypasses architectural accountability. Proposed changes must reach the responsible owner before implementation proceeds on a revised basis.

Without that control, an approved design has little practical authority.

Make Acceptance Explicit

A working screen and a successful happy-path demonstration provide limited evidence of readiness.

Does the implementation handle invalid input? Enforce permissions? Recover from partial failure? Can we diagnose a problem? Can the next developer change a business rule without breaking unrelated behavior?

Acceptance has to address those questions through defined checks and accountable review.

Deterministic checks establish specific facts. The code compiles or it does not. A test passes or fails. Automated standards checks report violations. These checks provide evidence within their defined coverage.

Compilation and test results are verifiable outcomes.

Architectural review checks the implementation against the design. Did the agent preserve the approved boundaries? Did it introduce dependencies or services outside its assignment? Does the implementation assign responsibilities according to the design?

Business acceptance checks the result against the requirement. Does the behavior satisfy the business need, including the relevant failure cases and constraints?

In the governance pattern I am developing, review agents check the work against its requirements and standards. Failed work returns for correction. Proposed changes to the design return for architectural review. The Product Owner remains responsible for validating the business outcome.

The developer agent cannot declare an assignment complete solely because its implementation appears to work.

A more capable model does not eliminate these responsibilities. Another skill file helps only if the process checks whether its instructions were followed.

Discipline requires enforcement.

I will continue using vibe coding to explore ideas and assess their potential. Some exploratory code will pass review and become part of a production system. Other code will be discarded after it has served its purpose.

Durable software requires that decision to be deliberate. Define the work. Bound the agent’s authority. Verify the implementation. Assign responsibility for accepting the result.

Code generation must remain accountable to the design.