Every successful vibe-coded project eventually meets a line. On one side sit personal tools and prototypes, where a bug costs an evening; on the other sit other people's data, money, and logins, where a bug costs trust. Recognizing that line before crossing it is what separates a deliberate handoff from a public incident.

This final lesson closes the arc the course opened with the spectrum. It looks at what graduating actually means, the signals that a project has outgrown casual building, why handing a prototype to engineers is a promotion rather than a failure, and what the practice beyond the line, now called agentic engineering, looks like.

The lesson ends where the course began, with the builder. Tools and labels churn every year; what holds its value is the set of abilities built across the course: scoping, describing, verifying, and judging.

What is graduating?

Graduating means recognizing that a project has crossed from the low-stakes end of the spectrum into territory that demands engineering accountability, and then responding deliberately. The boundary existed from day one: Andrej Karpathy scoped vibe coding to "throwaway weekend projects" in the founding post itself [1].

A deliberate response takes one of three forms:

  • Handing the project off to engineers
  • Rebuilding it properly with engineering discipline
  • Leveling up the builder's own practice to match the new stakes

Simon Willison named the far shore in October 2025, proposing "vibe engineering" for professionals who accelerate their work with LLMs while staying "proudly and confidently accountable for the software they produce" [2]. By February 2026 he conceded the industry had settled on a different label for the same territory: agentic engineering [3]. The names keep churning, but the spectrum underneath them has stayed stable.

Floor and ceiling revisited

Floor and ceiling revisited

At Sequoia's Ascent conference in 2026, Karpathy gave the two ends of the spectrum their sharpest framing yet: "Vibe coding is about raising the floor for everyone in terms of what they can do in software. Everyone can vibe code anything, and that is amazing. Agentic engineering is about preserving the quality bar of professional software" [4]. His compression of the idea runs even shorter: vibe coding raises the floor, and agentic engineering extrapolates the ceiling.

The floor is where this course has lived: anyone can now build working software by describing it. The ceiling is where accountability lives: tests, review, security, and promises kept to strangers. Neither replaces the other; a raised floor creates more projects that eventually deserve the ceiling's treatment.

Seen through this frame, graduation isn't a wall between two worlds. It's movement along the same dial the course introduced at the start, turned to match the stakes.

Accountability, not tools

Willison drew the defining line in March 2025. Work that's reviewed, tested, and explainable "is not vibe coding, it's software development. The usage of an LLM to support that activity is immaterial" [5]. Graduating is a change in the promises a builder makes about the software, not a change in tools.

The conversational loop stays the same on both sides of the line. What professionals add is practice layered on top of it [6]. Willison's list includes:

  • Automated testing and QA planning
  • Written plans and documentation before building
  • Version control and careful code review

Willison raises the gatekeeping worry himself and answers it: "in this case a bit of gatekeeping is exactly what we need!" The gate guards accountability, not identity; the floor stays open to everyone.

Signs it's time

Projects rarely announce that they've outgrown vibe coding; they show it. The clearest signs include:

  • Other people's data, money, or logins are now involved
  • Every change breaks something else
  • Asking for random changes until an error disappears has become the entire workflow

The first sign is the course's one-question heuristic reaching its conclusion, and it maps directly onto Karpathy's founding scope of "throwaway weekend projects" [7]. The third deserves care: the random-changes move appears in the founding description itself, and it's a legitimate technique at low stakes. It becomes a warning only when it stops being occasional.

There's evidence the pattern doesn't scale. GitClear's research across hundreds of millions of changed lines found copy-pasted code rising, refactoring collapsing, and a growing share of new code revised within 2 weeks of being written [8].

Pro Tip! One question compresses every sign into a single check: who gets hurt if this breaks tonight?

Graduating as a crisis

When the signs are missed, graduation still happens, just on the incident's schedule. In March 2025 a founder known as leojr94 launched a SaaS built in Cursor, watched attackers exploit it within days, and shut it down to rebuild on a managed platform, posting that unsecured code should never have reached production [9].

Even the coiner of the term hit the same wall, if more gently. Karpathy's MenuGen work log ends with the graduation smell in his own words: building it "the correct way" would need databases and work queues, and his verdict was that "vibe coding full web apps today is kind of messy and not a good idea for anything of actual importance" [10].

Security research explains why the deadline arrives fast. The Cloud Security Alliance found AI-assisted developers committing code 3 to 4 times faster while introducing security findings at roughly 10 times the rate [11]. The point of learning the signs is to graduate by choice, before an incident makes the choice.

The prototype as living spec

When a project graduates into a team, the prototype's job changes rather than ends. Lenny's Newsletter documents that quick prototypes built in tools like v0, Bolt, Replit, or Lovable are now standard in product teams, and that engineers "may start with the latest prototype from a tool to get a headstart on their code" [12]. The prototype travels as a communication artifact, not as the codebase.

That reframe dissolves the sunk-cost sting. Months of conversation produced something better than code: a working demonstration of exactly what the product should do, precise in a way no written document matches. A prototype people can click through is the best requirements document a builder will ever produce; it makes the idea undeniable and the requirements concrete.

Pro Tip! In documented team workflows, product managers attach the working prototype to the product requirements document and designers raise its fidelity before engineers start.

"An engineer will clean it up"

The expectation that a professional will simply tidy up the code is how many non-engineers picture the handoff: a cleanup pass over working software. Unreviewed AI-built codebases usually need more than tidying. GitClear's repository research shows duplication rising while refactoring collapses, and CodeRabbit's analysis found markedly more major issues in AI-co-authored code; the Cloud Security Alliance adds a layer of security debt on top, with findings introduced at roughly 10 times the usual rate [13]. Together these often make rebuilding cheaper than repairing.

The realistic expectation is that engineers keep the behavior and replace the implementation. The documented team norm treats the prototype as a specification to rebuild from, not a codebase to inherit [14]. There's a hopeful nuance here: the stronger the builder's scoping and verification habits were, the more of the work survives the handoff, because it survives as requirements.

One person, both modes

Simon Willison runs both ends of the spectrum at once, which makes him the cleanest proof that graduation is per-project, not per-person. His site tools.simonwillison.net hosts more than 80 experiments he describes as pure vibe coding: "I outsource a simple, low-stakes task to an LLM and accept the result if it appears to work" [15].

His libraries get the opposite treatment. sqlite-utils and Datasette are software other people depend on, so every change is reviewed and tested, even when an AI agent writes most of the code; a 2026 release of sqlite-utils was mostly agent-written and still shipped under his full engineering process [16].

The mode belongs to the project's stakes, not to the builder's skill level. The same person, with the same tools, dials discipline up or down depending on who would be hurt if the software failed.

What stays with the builder

The frontier past this course now has a name and an emerging canon. Willison launched his open guide Agentic Engineering Patterns in February 2026, built on one observation: the cost of producing initial working code has dropped to almost nothing, which reorganizes professional work around review, specifications, and verification [17]. Karpathy called late 2025 an inflection point and admitted, "I have never felt more behind as a programmer" [18]. When the field's founders feel the floor and ceiling moving, no one finishing this course is behind; the whole field is running to keep up.

What stays durable, on every point of the spectrum:

  • Scoping what's worth building
  • Describing it clearly enough that a machine can build it
  • Verifying that what came back actually works
  • Judging when the stakes have changed, and changing the promises to match

Karpathy expects agents to absorb the implementation details while humans keep "taste, engineering, design, and whether the system makes sense." Ethan Mollick describes the same shift as redistribution: expertise moved "to knowing enough about systems to guide, troubleshoot, and evaluate" [19]. The labels will keep changing, and the tools will churn every year. The builder who can scope, describe, verify, and judge stays valuable no matter what the frontier gets called next.