AI-Native Software Development with Google Antigravity
Cursor puts a model in your editor; Antigravity (Google's agent-first development platform) flips the frame — you manage agents that do the work while you supervise from a mission-control view. This chapter covers the agent-first paradigm, why verifiable artifacts matter, and how supervising agents differs from editing code.
Learning objectives
- Explain the 'agent-first' IDE model Antigravity represents.
- Contrast it with Cursor's editor-first model.
- Reason about when an autonomous agent IDE helps vs hurts.
- Evaluate an emerging tool for team adoption.
code/ad3-antigravity/ in the course, with a README on how to run it. Read here, run there — no need to copy-paste.1 · Editor-first vs agent-first essential
Cursor puts a model in your editor; Google Antigravity pushes further — the agent is the primary interface, and the editor is one tool it uses. You describe outcomes; the agent plans, writes across files, runs, and verifies. It's the far end of the autonomy spectrum.
This picture lays out AI coding tools on a single line — an autonomy spectrum — from "the tool suggests, you type" on the left to "the agent does the work, you supervise" on the right. It's the one-sentence summary of the whole chapter: Antigravity sits at the far right.
- Read it left to right as "how much does the tool do on its own?". Each box is a step further along that line, and the arrows show the direction of increasing autonomy.
- Autocomplete (Copilot) — the least autonomous: it finishes the line you're already typing. You are still writing every decision.
- Inline edit (Cursor Cmd-K) — you select code and ask for a change in place. The tool edits, but only where you point it.
- Editor + agent (Cursor agent) — an agent can now work across several files for you, but the editor is still the main thing you look at.
- Agent-first IDE (Antigravity) — the far right: the agent is the main interface. You describe an outcome; it plans, writes across files, runs, and checks, while you supervise.
In short: The further right a tool sits, the more you shift from writing lines to specifying and reviewing. That's why the chapter says verification becomes your real job.
2 · What 'agent-first' means in practice essential
You give a goal ("add OAuth login"); the agent decomposes it into tasks, works through them, runs the app, reads errors, and iterates — surfacing a plan and artifacts for you to steer. Your job shifts from writing lines to specifying, reviewing, and correcting.
3 · Intermediate — where autonomy pays off (and doesn't) intermediate
agent_fit.pydef agent_fit(well_specified, has_tests, reversible, high_novelty):
if not reversible:
return "NO — irreversible; keep a human in the loop"
if high_novelty and not well_specified:
return "NO — novel + vague; you must design it first"
if well_specified and has_tests:
return "GREAT — clear goal + tests to verify against"
return "MAYBE — specify it better or add tests first"
print(agent_fit(True, True, True, False)) # scaffolding CRUD -> great
print(agent_fit(False, False, True, True)) # novel + vague -> no
print(agent_fit(True, False, False, False)) # touches prod data -> no
GREAT — clear goal + tests to verify against
NO — novel + vague; you must design it first
NO — irreversible; keep a human in the loopThis tiny function is a decision helper: given four yes/no facts about a task, it tells you whether handing that task to an autonomous agent is a GREAT, MAYBE, or NO idea. It turns the fuzzy question "is this a good fit for an agent?" into a checklist you can actually run.
def agent_fit(well_specified, has_tests, reversible, high_novelty):takes fourTrue/Falseinputs — is the goal clearly specified, are there tests to check the result, can the work be undone, and is it something brand-new/unusual.- The checks run top to bottom and the first match wins (each
returnexits immediately).if not reversible:is checked first — if the work can't be undone, it's alwaysNO, no matter what else is true. Safety gate comes first. - Next,
if high_novelty and not well_specified:— something new and vaguely described is aNO: you have to design it yourself before an agent can help. if well_specified and has_tests:is the sweet spot — a clear goal plus tests to verify against returnsGREAT. If none of the above matched, the finalreturnis the fallbackMAYBE: fix the spec or add tests first.
What the output means: The three print lines feed in three example tasks. You get GREAT (clear + tested), then NO (novel + vague), then NO (irreversible — note the last call is caught by the very first check even though its goal is well specified).
Try this: Change the last call to agent_fit(True, True, True, False) and it flips to GREAT. Flipping one fact changes the verdict — that's the point: agent-fit is about the conditions around a task, not how hard the coding is.
4 · Advanced — verification is the bottleneck advanced
The more the agent does autonomously, the more your verification load grows. Tests, types, and a reviewable plan are what make autonomy safe — without them you're trusting a black box. The agent-first model only scales if verification scales with it (the eval discipline from Ch 5).
5 · Professional — evaluating an emerging tool professional
Antigravity is new and fast-moving. Evaluate it like any emerging tool: run a time-boxed pilot on a real (non-critical) task, measure vs your current flow, check data/privacy terms, and don't bet the team on it until it's proven. Enthusiasm isn't an adoption decision.
6 · Tech-lead — betting on the autonomy curve tech-lead
A lead reads the trajectory: tools are climbing the autonomy spectrum, and the durable skill is specification + verification, not any one IDE. Invest the team in tests, clear specs, and review culture — those pay off regardless of which agent-first tool wins. Adopt tools; don't marry them.
Exercise AD3.1 — Classify your backlog by agent-fit
Context: Classifying your real backlog by agent-fit is how the ‘where autonomy pays’ idea becomes actionable — and it surfaces that some tasks are one better spec or test away from being a great fit.
Your task: Take five real tasks, run each through agent_fit.py, and sort them into GREAT, needs-work, and human-only.
Requirements:
- Run five real tasks through
agent_fit.py - Classify which are GREAT for an autonomous agent, which need better specs/tests first, and which must stay human-driven
- Write one sentence on what would move a MAYBE to GREAT
- Respect the hard gate: irreversible work stays human-driven regardless of how well specified it is
💡 Hint: The reversible check runs first for a reason — if work can't be undone, no amount of spec quality makes it agent-safe.
🪜 Practice ladder beginner → industry
Six graded exercises, easy to real-world. Try each before opening its solution.
Context: The editor-first vs agent-first distinction is about where human attention sits: helping you type, or directing an agent that types. Getting this framing right sets up everything else in the lesson.
Your task: In one paragraph each, contrast editor-first and agent-first tools and name who is ‘driving’ in each.
Requirements:
- Editor-first: the human drives, typing/editing with AI assisting at the cursor; unit of work is a keystroke/edit
- Agent-first: the agent drives, planning and executing multi-step work while the human supervises; unit of work is a task/goal
- Name who drives in each
- Frame the shift as a change in where human attention sits, not just a faster autocomplete
💡 Hint: Ask what the unit of work is — a keystroke or a whole task — and who reviews versus who authors.
Show solution
Editor-first (e.g. a traditional AI editor): the human drives, typing and editing, with AI assisting at the cursor. The unit of work is a keystroke or an edit; the AI accelerates a human who is continuously in the loop.
Agent-first (Antigravity's model): the agent drives, planning and executing multi-step work across files while the human supervises. The unit of work is a task or goal; the human sets direction and verifies outcomes rather than authoring each edit.
The shift is from ‘AI helps me type’ to ‘I direct and review an agent that types’ — a change in where human attention sits, not just a faster autocomplete.
Context: Autonomy pays off exactly when a task is well-specified and verifiable in bulk, and costs you when each edit needs in-the-moment judgment. The deciding factor is verifiability, not task size.
Your task: Give two tasks where agent-first clearly pays off and two where editor-first is still better, with the deciding factor.
Requirements:
- Two agent-first wins: well-specified, bulk-verifiable work (e.g. migrate a pattern across many files, scaffold from a spec)
- Two editor-first wins: delicate single-function changes or exploratory work where the design is still forming
- State the deciding factor: autonomy pays when the task is well-specified and verifiable in bulk (tests/spec)
- Note that supervising an agent is slower than just doing it when each edit needs human judgment
💡 Hint: The line isn't how big the task is — it's whether the many edits can be checked cheaply and in bulk.
Show solution
| Agent-first pays off | Editor-first still better |
|---|---|
| Migrating a pattern across 40 files | Delicate change to one hot, subtle function |
| Scaffolding a new service from a spec | Exploratory work where you're still deciding the design |
Deciding factor: autonomy pays when the task is well-specified and verifiable in bulk (tests, a clear spec) so the agent's many edits can be checked cheaply. Editor-first wins when each edit needs human judgment in the moment or the goal itself is still forming — there, supervising an agent is slower than just doing it.
Context: In agent-first development, generation is nearly free and verification is the constraint. As generation speed rises, total throughput is capped entirely by how fast you can verify.
Your task: Explain why verification, not generation, is the bottleneck in agent-first development, using the throughput argument.
Requirements:
- Make the throughput argument: an agent generates a 30-file change in minutes; a human verifies it in hours
- Conclude that as generation → infinite, throughput is capped by verification speed
- Note that unreviewed agent output is a liability, not progress
- State the leverage move: invest in cheap verification (tests, types, small diffs, agents that self-verify)
- Summarize: generation got cheap, judgment did not — optimize the expensive step
💡 Hint: Follow the queue: if you verify slower than the agent generates, work piles up unreviewed — so the bottleneck is verification.
Show solution
An agent can generate a 30-file change in minutes; a human reads and validates it in hours. As generation speed → infinite, total throughput is capped entirely by how fast you can verify — classic bottleneck.
- If you verify slower than the agent generates, work piles up unreviewed — and unreviewed agent output is a liability, not progress.
- So the leverage move is investing in cheap verification: strong test suites, type checks, small reviewable diffs, and agents that self-verify against tests before handing off.
- The skill that scales in an agent-first world is designing systems that are fast to verify, not fast to write.
Generation got cheap; judgment did not. Optimize the expensive step.
Context: Since verification is the bottleneck, the highest-leverage practices are the ones that convert human-judgment cost into machine-checkable cost. Ranking them by leverage tells you what to build first.
Your task: List four concrete practices that lower the cost of verifying a large agent-generated change, ranked by leverage.
Requirements:
- Rank automated tests the agent must pass first as highest leverage (shifts verification to a green/red signal)
- Include forcing small, scoped, reviewable diffs over one giant dump
- Include types + linters + static analysis to catch error classes mechanically
- Include an agent-produced rationale and a plan you approved up front
- Explain that each practice converts human-judgment cost into machine-checkable cost, raising the throughput ceiling
💡 Hint: Rank by how much human judgment each one removes — a test suite the agent must pass beats reading a diff every time.
Show solution
- Automated tests the agent must pass first — highest leverage: shifts most verification from human eyes to a green/red signal. Have the agent run them and iterate before you look.
- Small, scoped diffs — force the agent to split a big task into reviewable commits; a 200-line focused diff is verifiable, a 3000-line dump is not.
- Types + linters + static analysis — catch whole classes of error mechanically so human review focuses on logic and intent.
- Agent-produced rationale & a plan you approved up front — reviewing against a plan you already agreed to is far faster than reverse-engineering intent from the diff.
Each practice converts human-judgment cost into machine-checkable cost, raising the throughput ceiling.
Context: Betting a team's workflow on a new, fast-changing agent-first tool needs a rubric, not demo wow-factor — and the rubric should center on the bottleneck: does the tool make verification cheaper?
Your task: Write the evaluation rubric you'd use before betting a team's workflow on an emerging agent-first tool.
Requirements:
- Center the rubric on verification support (does it run tests, show scoped diffs, explain its plan?)
- Include control & interruptibility (can you stop/steer/roll back mid-task?)
- Include context handling, security/data (what leaves the network), and maturity/lock-in risk
- Include an escape hatch (fall back to editor-first when autonomy fails)
- State the method: pilot on a real non-critical project and measure verification time and rework rate, not demo wow-factor
💡 Hint: Weight the dimensions by the bottleneck — bet only where the tool makes verification cheaper.
Show solution
| Dimension | Question |
|---|---|
| Verification support | Does it run tests, show scoped diffs, explain its plan? (the bottleneck) |
| Control & interruptibility | Can you stop, steer, or roll back a running agent mid-task? |
| Context handling | How does it pick which files/knowledge to use? Can you correct it? |
| Security/data | What leaves your network? Secret handling? Repo scoping? |
| Maturity risk | How fast is it changing? Lock-in? What breaks if they pivot? |
| Escape hatch | Can you fall back to editor-first when autonomy fails? |
Method: pilot on a real, non-critical project; measure verification time and rework rate, not demo wow-factor. Bet only where the tool makes verification cheaper, since that's the constraint.
Context: How much to invest now in agent-first workflows vs wait is a real strategic bet. The hedged position invests in the durable skill — verification — which pays off regardless of which tool wins.
Your task: As a tech lead, frame the bet on investing now vs waiting on agent-first workflows: upside, risk, and the hedged position you'd actually take.
Requirements:
- Frame the bet: autonomy is on a steep curve; investing early builds compounding verification-first muscle, waiting risks falling behind
- Lay out both positions (bet big now vs wait) with upside and risk for each
- Give the hedged position: invest in durable skills (tests, cheap verification, small diffs, evals) that pay off regardless of tool
- Adopt the emerging tool only in low-risk pockets, not for critical workflows
- State the lesson: bet on the trend by strengthening verification (what every agent-first tool depends on), not by marrying today's vendor
💡 Hint: Invest in the constraint (verification), which survives tool churn, rather than in a specific immature vendor.
Show solution
The bet: autonomy is on a steep curve — agents handle bigger tasks each quarter. Investing early builds the muscle (verification-first practices, evals, review discipline) that compounds; waiting risks a slower team when the curve steepens.
| Position | Upside | Risk |
|---|---|---|
| Bet big now | First-mover velocity; skills compound | Immature tools, rework, churn as tools change |
| Wait | Let tools mature, avoid churn | Fall behind; miss the compounding of practice |
Hedged position (what I'd take): invest in the durable skills now — strong tests, cheap verification, small diffs, evals — because those pay off regardless of which tool wins. Adopt the emerging tool in low-risk pockets to build familiarity, but don't rebuild critical workflows around an immature agent. This way the investment is in the constraint (verification), which survives tool churn, rather than in a specific vendor that may not.
Lesson: bet on the trend by strengthening the thing every agent-first tool depends on — your ability to verify — not by marrying today's specific tool.
✓ Checkpoint — you can move on when you can…
- Explain agent-first vs editor-first.
- Judge which tasks fit autonomous agents.
- Explain why verification is the bottleneck.
- Evaluate emerging tools; invest in the transferable skill.
Knowledge check check yourself
Antigravity is described as "agent-first" rather than "editor-first." What concretely changes about the developer's job in that model?
Show answer
In the agent_fit helper, the reversible check runs first and returns NO even when the goal is well specified. Why is irreversibility the first gate?