Vibe Coding on a Time-Boxed Spike

Vibe coding belongs on a time-boxed spike, where the deliverable is knowledge. Both practices use rough code to get a quick answer to a question. Their legitimacy depends on the same boundary, which is that an experiment must not become production software without an explicit change of intent and discipline.

What vibe coding and the spike actually are, and why the debate about vibe coding misses the point

The debate over whether vibe coding is good or bad has stalled because it treats a development method as an identity. Defenders emphasize speed and access, while critics emphasize defects and maintenance. Those positions often describe different kinds of work. The code’s purpose and who must respond when it breaks provide useful grounds for judging it. A learning artifact and a load-bearing wall cannot be judged by the same standard.

Andrej Karpathy coined “vibe coding” in February 2025 to describe casual, low-scrutiny AI-assisted programming, explicitly for throwaway weekend projects. Its defining feature was that users could proceed with code generated by AI without closely examining it. Exploration can succeed by showing that an approach fails, while software that people must maintain has to meet needs beyond the experiment. Agile already has a practice for keeping those purposes separate.

What a spike is and what it was always designed to do

A spike is a time-boxed exploration built to answer a question before implementation begins. Its output is knowledge. The question might concern architecture, a technical approach, a vendor file format, or an API contract. Code provides a way to investigate the uncertainty rather than an obligation to preserve the implementation.

Maintainability is not the acceptance criterion for an artifact destined for deletion, and failure may provide exactly the evidence the team needs. A spike that exposes an unsuitable approach has done useful engineering work. The discipline lies in its bounded purpose and explicit status. AI changes how quickly the investigation proceeds, but not the need to understand how something can be built before committing to build it.

Why vibe coding and the spike are structurally the same practice

Vibe coding in Karpathy’s original sense follows the same structure as a spike. The practitioner prompts, generates, iterates, and discards in pursuit of an answer. Both practices trade code quality for a chance to learn faster. That trade is defensible because the artifact will not become something other people must maintain.

The equivalence depends on a defined endpoint, however. A question answered, a time-box expired, or a decision made ends the exploration. Without that endpoint, prompt-driven iteration becomes an open-ended development process whose obligations remain unspecified. The faster engine makes more code available before anyone has decided what that code is allowed to become.

The corresponding handoff is from discovery to specification. Teams can use vibe coding to discover requirements, then formalize them into version-controlled specifications before production deployment. This preserves the knowledge without treating the exploratory implementation as approved software. It is the familiar spike-to-implementation transition applied to AI tools. Much of the dispute therefore concerns whether people are conducting experiments or operating production systems while using the same name for both.

Two variables that determine whether vibe coding is a spike or a liability

Lifespan and blast radius provide a practical way to classify the work. They describe the artifact. A short-lived prototype, demo, or weekend experiment with no real consequences fits the exploratory model. A short-lived demo that pulls production data or a proof of concept that emails real customers falls into a different group. Its code can remain rough, but its data access and effects require protection.

Long-lived work divides in the same way. Internal tools, personal scripts, and team dashboards may initially appear to have no blast radius, yet their expected lifespan creates a route to dependency. This is the deceptively dangerous quadrant of the model. “Internal” describes an audience, and useful tools tend to become permanent. Once other work depends on them, they no longer fit in the group with no blast radius.

Long-lived production paths involving money, authentication, or user data require gates, tests, and review. Generated code can belong there, but authorship does not substitute for those controls. The practical shortcut is to ask who gets called if the code breaks at 2 AM. If nobody must respond and deletion is acceptable, it remains a spike. If a named person must get the service running again, the work has production obligations.

Why the throwaway contract fails without mechanical enforcement

The weakest part of spike discipline is the promise to throw the code away. Intention alone does not enforce that promise. A repository can contain an experiment or a production dependency without the toolchain distinguishing between them. Consequently, a prototype can acquire users and integrations without any explicit decision to promote it.

The temporary script from 2019 that still runs the nightly report shows how this goes wrong. Continued use need not follow a considered decision that the script is fit for permanent service. It can follow from the absence of a decision point. Each new use makes the code harder to delete, and calling it temporary does nothing to stop that. The artifact becomes indispensable before its obligations become explicit.

This is the mechanism behind the vibe coding hangover. Work that felt fast during exploration becomes a difficult black box as users and dependencies accumulate over subsequent months. Maintenance overhead then competes with the speed that justified the approach. Internal tools are especially at risk because there may be no outside pressure to make a formal move to production. Advice to respect the throwaway contract is therefore incomplete unless something can prevent the artifact from quietly outliving it.

What spike discipline actually requires when vibe coding is the method

The practical response is to enforce the contract at the artifact level. A certificate-like expiry model gives each spike a date after which it stops working unless someone consciously renews it. A more targeted version blocks new integrations or write privileges first, notifies a named owner, and requires a decision to retire or harden the artifact. The useful acceptance test is whether an expired spike can acquire a new real dependency without anyone acknowledging the change.

Expiry should be part of a set time to live for the proof-of-concept. That limit should be time-bound and informed by data, with a decision at expiry to kill, pause, pivot, or formally commit to hardening. The question must also exist before the code. Writing it down gives the team a criterion for learning, while the fixed time-box ends the investigation even if the implementation does not feel finished.

The repository, ticket, and Slack channel should identify the work as “spike — do not ship”. If the result justifies production investment, an explicit gate changes the governing process. For this spike-to-production model, the handoff is a rewrite under spec-driven discipline. The specification retains the discovery while the new implementation takes on production requirements.

Where the speed gains are real and where they reverse

Vibe coding can deliver large gains when the task is to explore an idea and discard the implementation. Less effort goes into code intended to survive, so the team can reach a feasibility decision sooner. That is a genuine productivity gain within the spike boundary. That gain does not show that the same process speeds up complex development work that must last.

Experienced developers can feel faster with AI while taking longer to complete real-world coding work. On complex tasks, generating a plausible change falls short of integrating a correct one. The absence of review and specification leaves work for later. As maintenance accumulates, the initial impression becomes a poor measure of the full cost.

Security makes the distinction sharper still. Vulnerabilities in an isolated experiment that is never deployed have a different consequence from vulnerabilities in software handling real users or data. The short-lived, real-blast-radius quadrant remains an exception to any easy claim that prototypes are harmless. Likewise, more code and faster adoption do not show that quality, security, or trust has improved. The relevant productivity measure must include the defects and technical debt that ungoverned production use can compound.

The non-developer population and what happens when the spike boundary is invisible to them

Governing software creation becomes harder when creators have no prior exposure to spike discipline. A person who can turn an idea into an application may reasonably see a working interface as the completion of the task. The missing distinction is organizational. If the workflow does not show the boundary between an experiment and an operational system, users must somehow infer a boundary the tool has not made visible.

Compressing the distance between idea and artifact from months to hours can bypass the quality controls that previously surrounded software creation. The ability to generate code does not by itself come with a production handoff. The application has the same obligations whatever its creator had in mind. Software handling protected health information has the same regulatory exposure whether a professional team built it through a formal development lifecycle or a non-developer prompted it into existence.

The ACM Technology Policy Council’s April 2026 TechBrief found that vibe coding can accelerate development and widen access while often skipping core practices needed for secure, reliable, maintainable systems. Citizen development needs to be recognized as a distinct deployment pathway in organizational and regulatory implementation guidance. For these users, expiry, ownership, and a formal production transition cannot depend on familiarity with Agile terminology. The controls must express the distinction directly in the workflow.

What agentic engineering inherits from spike discipline and where the boundary moves next

Karpathy reframed vibe coding as the entry-level case at Sequoia Capital’s AI Ascent 2026 fireside chat. He presented agentic engineering as the professional discipline of coordinating fallible agents while preserving correctness, security, and maintainability. This distinguishes throwaway exploration from production work governed by explicit obligations.

The same agents can work in either mode. What changes is the oversight and the intent under which they operate. Between minimally governed prototyping and spec-driven agents with bounded autonomy sits AI-accelerated development with architect-defined intent, test gates, and human accountability. Spike discipline sets the gateway for moving out of exploration. A working experiment supplies evidence for a decision at that gateway.

Augment Cosmos helps coordinate agents through shared context and memory within governed agent workflows. The structural aim is to keep individual generation speed from becoming disconnected from the development lifecycle. Version-controlled specifications turn the requirements found during discovery into a plan for production, and governed workflows give that handoff a place in the work. Neither more agents nor faster generation removes the need for a decision about what the artifact is becoming.

Discovery is engineering work in its own right, with the same standing as implementation. Vibe coding has a lasting place when the task is to answer a bounded question without making something that other work will depend on. Agentic engineering inherits that boundary. Faster spikes make spike discipline more important.