Antigravity's Edge: A Flow That Keeps Correctness Without Sacrificing AI Speed

Andrej Karpathy once described vibe coding with a phrase that went viral: “forget the code exists”. The idea is simple — let AI write, you just accept, run, and if an error appears, paste it back to AI until it works. This is attractive at first because it feels fast. But anyone who has cleaned up a vibe-coded codebase knows that speed carries a bill that comes later — bugs with unclear origins, inconsistent architecture, and developers who no longer have a mental model of the system they “built” themselves. This article discusses one specific work pattern in Antigravity that I’ve been using recently — implementation plan, strict review, execution, then a walkthrough that gets reviewed again — and why this pattern, when done properly, isn’t vibe coding, even though it still fully leverages AI speed.

What Is Vibe Coding, and Why It’s a Problem

The definition of vibe coding is often misunderstood as “writing code using AI”. That’s wrong. The real boundary isn’t in the tool used, but in whether the developer still holds control and understanding over what’s being built.

The real characteristics of vibe coding:

• Accept-all without reading. AI-generated diffs are accepted directly because “they’re usually right”, not because they were evaluated.
• Vague correctness criteria. Code is considered “done” if it seems to work when tried once, not because the developer understands why it’s correct.
• Lost ownership. When a bug appears next week, the developer can’t explain the design decisions taken, because those decisions were never actually made by them — just passively approved.
• Unmaintained mental model. The developer loses the complete picture of how system parts relate to each other, because they never actually thought through the implementation.

The problem isn’t speed itself. AI is indeed much faster at writing boilerplate, migrations, or implementations with clear patterns. The problem is when that speed is bought by sacrificing correctness — and the price of that correctness is only felt later, when the system is already complex and the developer has lost the trail.

This is what work flows like the one Antigravity offers try to answer: how to keep full AI speed, but not lose the correctness and mental model that fall victim in vibe coding.

Five Checkpoints in the Antigravity Flow

This flow has five points, each an opportunity for a human to make a decision — not just watch AI work.

1. Implementation Plan

Before a single line of code is executed, the agent composes an implementation plan document. This document contains the approach to be taken, the files to be touched, the step order, and the assumptions used. It’s a representation of AI’s “intent” before that intent turns into code that must be read line by line.

The key point here isn’t just “there’s a plan document”. It’s about moving the decision point to a phase that’s far cheaper to correct. Correcting one paragraph in a misdirected plan is far cheaper — in time and cognitively — than correcting an implementation that has spread across ten files.

Imagine a simple scenario: the task is adding caching to one slow endpoint. Without a plan, the agent could directly choose any approach it thinks makes sense — an in-memory cache that won’t survive across server instances, or caching at the wrong layer making invalidation complicated later. The developer only realizes the choice was wrong after reading the finished code, if they read it at all.

With an implementation plan, the approach is written explicitly before the code: “will use Redis with a 5-minute TTL, manual invalidation triggered from the related update endpoint, keys using a hash of the query parameters”. The developer can immediately see whether this approach fits the existing infrastructure, whether a 5-minute TTL makes sense for this use case, and whether that invalidation strategy will cause stale data in certain scenarios — all evaluated before a single line of code is written.

2. Strict Review of the Plan

This is the first crucial checkpoint. The developer reads the plan not to check “does this sound reasonable”, but to match it against architecture principles and experience they already hold. Is this approach consistent with existing patterns in the codebase? Are there trade-offs AI didn’t mention but actually matter? Is the scope right, or is AI quietly expanding changes into areas not requested?

Review at this point is the purest form of keeping control — the developer is still the architectural decision maker, AI only proposes. If the plan is wrong, the developer requests revision before execution begins, not after.

Continuing the caching example above: if the developer has a principle that all user-session-related data must not be cached for more than one minute for consistency reasons, but the AI-proposed plan sets a 5-minute TTL, this is the moment to push back. The developer doesn’t need to rewrite the plan themselves — just state the constraint, and ask the agent to revise the plan before continuing. This is far cheaper than discovering a data consistency problem after the feature is live and users start reporting unsynced data.

Effective review at this point usually asks a few fixed questions: Is this approach consistent with architectural decisions already made elsewhere in the system? Are there new dependencies introduced, and are they proportional to the problem being solved? Does this plan assume something about data or infrastructure that isn’t actually true? These questions are what make the review a genuine evaluation, not just reading then nodding.

3. Execution

After the plan is approved, the agent starts writing code per the validated plan. At this point, AI speed is truly used to the max — because the direction is clear and validated, the agent can move fast without the developer needing to watch every keystroke.

This is the part often misunderstood as “the same as vibe coding because AI still writes all the code”. The difference lies in what happens before and after this phase — execution isn’t a decision point, it’s just the implementation of decisions already made at previous checkpoints.

The analogy is like a mature engineering team: a senior engineer approves a junior’s design doc, then the junior writes the code themselves without the senior watching every typed line. That trust is valid precisely because the direction was agreed first, not because the senior doesn’t care about implementation details. AI execution in this flow plays a similar role — fast because the direction is clear, not fast because no one is watching at all.

4. Walkthrough

After execution completes, Antigravity provides a walkthrough — a summary of what was done, which files changed, and how those changes fulfill the agreed plan. This walkthrough is a representation of results, just as the plan is a representation of intent.

Its function bridges the gap between “what was planned” and “what actually happened”. Without a walkthrough, the developer must re-read the entire diff from scratch to know what changed — the walkthrough provides a map so the subsequent review can be focused and efficient.

Continuing the caching example: a good walkthrough will mention that the Redis implementation is done in a certain file, the TTL was adjusted to the agreed number after the revision, and there’s a note that one edge case was found during execution — for example concurrent requests that could cause a cache stampede when TTLs expire simultaneously. A good agent will report findings like this explicitly, not hide them because “it’s outside the initial plan scope”. A walkthrough honest about deviations from the plan actually adds trust to the process, not reduces it.

5. Reviewing the Walkthrough

The second checkpoint, just as important as the first. The developer matches the walkthrough against the approved plan — did execution truly follow the plan, or are there deviations that need questioning? Are the AI’s claims (“tests pass”, “handled edge case X”) actually verified, not just believed?

At this point, the developer returns to the role of verifier, not passive receiver. If something seems off, the developer can request another revision — this cycle can repeat until the result truly meets the standard.

For the cache stampede case mentioned above, the walkthrough review is the moment the developer decides whether that edge case is important enough to handle now, or can be noted as deliberate technical debt for a future feature. What matters is that this is a conscious decision made with complete information — not an unknown risk that only surfaces when production is already receiving real traffic. Verification also doesn’t always mean re-reading the entire diff line by line; for low-risk changes with familiar patterns, it’s enough to make sure the walkthrough claims are consistent with the files mentioned. For changes touching critical areas — authentication, payments, or sensitive data — verification must be deeper, including running tests manually, not just trusting a report that “tests pass”.

Flow Diagram

What’s important to understand about this flow is that it isn’t a one-way straight line. At both review checkpoints, there’s a revision path that returns the process to an earlier stage.

flowchart TD
    A[Developer gives a task] --> B[Agent composes an Implementation Plan]
    B --> C{Strict Review by Developer}
    C -- Plan rejected / revision --> B
    C -- Plan approved --> D[Agent executes the code]
    D --> E[Agent composes a Walkthrough]
    E --> F{Walkthrough Review by Developer}
    F -- Doesn't match the plan / deviations --> D
    F -- Matches and verified --> G[Code accepted]

These two decision gates — not one — are what structurally distinguish this flow from the vibe coding loop, which is usually just: prompt, accept, run, repeat if error.

Why This Isn’t Vibe Coding

The core argument isn’t about “using a more sophisticated tool”, but about where the human decision points sit in the work cycle. Here’s the explicit contrast:

The most fundamental difference is in the first row of this table: where the decision points sit. Vibe coding places the only evaluation point at the end — if there’s time, if remembered, if available. This flow places two mandatory evaluation points, both occurring before the code is considered done, one at the intent level (plan) and one at the result level (walkthrough).

This also answers the criticism often leveled at agentic approaches in general — that developers become “passive supervisors” of AI. With two genuinely evaluated checkpoints, the developer remains the party determining the project’s direction. AI handles the implementation throughput, but the intelligence — in the sense of decisions about what’s right and what isn’t — stays in human hands.

This is actually the same principle underlying spec-driven development: specifications and intent come from humans, AI executes per those specifications, not replacing them. The difference is that in spec-driven development the specification is usually written once at the start and relatively static during implementation. The plan-review-execute-walkthrough flow brings the same principle but makes it repeat at a more granular level — every task, however small, has its own specification-and-verification cycle. This matters because high-level specifications at the start of a project are rarely detailed enough to capture all the small decisions that emerge during actual implementation — the per-task plan is what fills that gap.

The ownership aspect also deserves deeper discussion. In vibe coding, when a bug is found, the question “why is this code like this?” often has no clear answer from the developer — the answer is just “AI wrote it that way”. This isn’t just a psychological issue about who to blame, but a practical problem: if the developer can’t explain a design decision, they also can’t predict the consequences of that decision in other parts of the system. With a flow that has two explicit checkpoints, the developer has a traceable decision trail — which plan was approved, what reasoning underpinned it, and what deviations emerged during execution. This trail isn’t just administrative documentation; it’s evidence that the decision was truly made, not passively approved.

Speed That Stays Preserved

A fair criticism arises: with two review layers, doesn’t this become slow, just like heavy manual code review?

The answer lies in what is reviewed, not how much is reviewed. Reviewing an implementation plan is far lighter than reviewing thousands of lines of diff — a plan is usually a few paragraphs and a step list, not complete code. Reading and evaluating intent is much faster than reading and evaluating finished results.

Reviewing the walkthrough is also more efficient than reading a raw diff from scratch, because the walkthrough already provides a map — the developer knows which files are most important to check deeper, and which can be trusted because the patterns are familiar and low risk.

What’s sacrificed isn’t implementation speed — that remains fully delegated to AI. What’s “sacrificed” is just a few extra minutes at two crucial points, traded for certainty that the direction and results are correct. Compared to the cost of hours of debugging when an architectural error is only discovered after the next feature is built on top of it, this is a clearly favorable trade.

Where This Flow Can Still Fail

This flow’s structure has the right shape — two explicit review checkpoints. But the right shape doesn’t automatically guarantee the right substance. This flow can silently revert to vibe coding if the reviews at both checkpoints become superficial — looking like evaluation, but not actually being one.

Some concrete forms of this superficial review:

• Skimming, not reading. Eyes pass over the plan or walkthrough text, but it isn’t truly processed against the question “does this match the principles I hold?” What happens is more like seeking visual reassurance that “the document exists”, rather than actively evaluating its content.
• Approval by fatigue. After several AI plans look reasonable, the developer starts approving faster and pushing back less often. Reviews that were once critical gradually become formalities — a checklist ticked, not a decision truly made.
• No explicit criteria. If the developer doesn’t know exactly what makes a plan “correct” — the architecture principles or trade-offs they hold — then the review becomes just a check of “does this sound reasonable”, not “does this meet my standards”. A confidently written but misdirected plan easily slips through such a review.
• Walkthrough trusted raw. If AI reports “implemented, tests pass, edge case handled”, but the developer doesn’t actually verify those claims — doesn’t read the diff, doesn’t run the tests themselves — then this second checkpoint is effectively empty. This is the same as blind trust in AI output, just wrapped in an extra step that feels safe but isn’t.

The critical point: this two-checkpoint process has an anti-vibe-coding shape, but if the reviews become ritual rather than genuine evaluation, the substance is still vibe coding — just with extra steps giving the illusion of control. The discipline to truly evaluate, not just go through the motions, is the part that no tool, however sophisticated, can replace.

How to Prevent It

Several practical habits help keep these reviews genuine rather than mere formalities:

• Write review criteria explicitly, not implicitly. If the developer holds a list of architecture principles — for example “all database access must go through the repository layer, no raw queries in controllers” — these criteria should actually be written down, not just vaguely remembered in the head. Explicit criteria are easier to turn into a real checklist when reading a plan, compared to criteria that are just a feeling of “seems off”.
• Treat plans that “look neat” with the same suspicion as messy ones. It’s precisely the confidently written, neatly structured plans that slip most easily past superficial review, because they already look convincing visually. Writing neatness doesn’t correlate with approach correctness.
• Verify some walkthrough claims randomly, not all — but also not none. For low-risk tasks, checking a small portion of the reported claims — whether the mentioned files actually changed as described — is enough to detect inaccurate walkthrough patterns before they become a blindly trusted habit.
• Notice when fatigue starts to appear. If the developer feels they’re approving plans faster than usual without a clear reason, that’s a signal to pause for a moment, not a sign that the AI is becoming more trustworthy.

Summary

• Vibe coding isn’t about “using AI”, but about the loss of human control and understanding over the code being built.
• The Antigravity flow — plan, review, execution, walkthrough, walkthrough review — places two mandatory decision points before the code is considered done.
• Reviewing the plan corrects wrong direction at the cheapest point, before code is written.
• Reviewing the walkthrough verifies results, not accepting them raw.
• AI speed remains fully delegated for execution — what changes is only where the developer places their attention.
• This two-checkpoint shape can fail if the reviews become superficial — skimming without evaluation, approval by fatigue, or walkthroughs trusted without verification.
• What distinguishes this flow from vibe coding isn’t the tool, but the human discipline to truly evaluate at every available checkpoint.