AI Vibe Coding: Faster Doesn’t Mean Better

The missing loop

Alan Cooper’s 1999 book The Inmates Are Running the Asylum argued that technical possibility can outrun the needs of the people who must live with a product. That problem did not disappear. Software teams learn what a system really needs by building, reviewing, failing, and correcting.

---

The core issue

AI-assisted development changes the tempo. It can produce a credible first draft quickly enough that teams may confuse visible completeness with readiness. The problem is not that fast generation is bad. It is that a faster build loop can make the missing feedback loop harder to see.

I encountered this while building the RS AI Learning Lab. Once we had a reusable template, an AI coding agent could generate complete learning modules remarkably quickly. The first drafts looked polished. They had structure, working interactions, and enough consistency that it was tempting to think the hard part had been solved.

The signal that something was missing came during review rather than implementation. Our copywriter and reviewers kept asking the same kinds of questions: Where is the evidence? What real-world example supports this claim? Which constraint or design decision is this module teaching? The generated artifacts were technically complete enough to review, but they were not yet educationally complete.

The recovery was not to slow the AI down. We improved the template, strengthened the review criteria, and added explicit evidence requirements so those questions became part of generation and review instead of being rediscovered in every module. The experience reinforced an old lesson in a new setting: faster generation does not eliminate the need for feedback. It makes the feedback loop itself part of the product.

---

Make correction part of the fast path

If AI speeds up generation, teams need to speed up the ways they check, explain, and recover from what was generated. That does not mean adding ceremony to every small experiment. It means matching controls to a system’s lifespan and consequences. NIST’s current AI-assisted development guidance likewise emphasizes requirements, traceability, testing, and human review rather than treating generated code as self-validating. NIST

Non-functional drivers for AI-accelerated builds

Before generation, decide what kind of thing you are building. Non-functional requirements should steer the design as much as features.

Expected lifespan

• Disposable (≤ 4 weeks): hack fast, use minimal scaffolding and ephemeral storage, and set an explicit end-of-life date.
• Seasonal or campaign (1–12 months): add light telemetry, critical-path tests, a data-migration plan, and documented decommissioning steps.
• Sustained or core (12+ months): add traceability, versioned contracts, SLOs and alerts, upgrade paths, rollbacks, and security review.

Support and SLOs

Define response and repair targets. An SLA is a commitment to a customer; an SLO is an internal, measurable service objective. If someone will page you at 2 a.m., design for operability: health checks, backpressure, circuit breakers, and safe-to-retry behavior. Google SRE

Traceability

Documentation is often the first victim of the schedule. When people spend less time living inside the code, they need better ways to recover why a decision was made and what a component depends on.

• Requirements ledger: who asked for what, why, and when.
• Decision log: key trade-offs with date, context, and alternatives.
• Dependency manifest: libraries, models, prompts, and datasets, each pinned and checksummed where practical.
• Provenance: model and prompt versions stamped into artifacts so runs can be reproduced or understood later.

Observability by default

Use structured logs, metrics, traces, and correlation IDs. Build the first useful dashboard near the first commit, not at the end.

Governance and data hygiene

Set data classification, retention and erasure, PII handling, consent, model-use restrictions, and auditability before the system has too many users to change easily.

Backout and exit strategy

Every system needs a way to step back or shut down safely. A backout plan covers rollback procedures, data migration reversals, and configuration restores. An exit plan covers feature flags, decommissioning, data export, URL tombstones, and user communication.

Testing gates match the NFRs

• Disposable: lint and smoke tests.
• Seasonal: add contract tests and basic load tests.
• Sustained: add property tests, chaos drills, backup-and-restore rehearsal, and failover testing.

Why this matters to AI builds

When code is generated quickly, people may not acquire the tacit knowledge that usually comes from building and debugging more slowly. Traceability and observability do not replace experience, but they preserve enough context for the next person to review, repair, or challenge what was built.

Closing thought

Vibe coding can be useful. Faster still does not mean ready. The goal is not to bring back slow work for its own sake. It is to make sure rapid generation leaves behind the evidence, controls, and recovery paths that let a system improve.