Google Antigravity in Practice: From AI-Assisted Coding to Agentic Engineering

From writing code to describing engineering outcomes

Most developers still think of AI programming as "completing the next line" or "explaining this code." In this talk, a Google Developer Expert and enterprise cloud and AI architect offers a clearer frame of reference: collaboration between AI and developers has gone through three stages—code completion, conversational programming, and coding agents—and is now entering a fourth: Agentic Software Engineering.

The key change in this stage is the unit of interaction. In the past you told the AI "how to write it"; now you describe "what engineering outcome you want," and the agent plans, executes, tests, inspects files, and iterates on its own when the goal isn't met. The unit of interaction shifts from "code completion" to "engineering task completion."

This isn't wordplay. Once the unit of work becomes a complete engineering task, the agent must have more capabilities: reasoning and forming plans, browsing the web to retrieve information, executing commands and installing dependencies in a terminal, reading and modifying repository files, running applications, and producing evidence such as plans and test reports. The speaker summarizes this structure with a five-layer capability diagram, with "human approval" prominently marked at the very bottom—the more capable the agent, the more important it is to define the boundaries of human approval.

The dual-loop workflow: humans haven't disappeared, they've moved up

The mental model the speaker recommends is a dual-loop structure. The inner loop is the agent's execution loop: understand intent, form a plan, execute, produce artifacts, verify. The outer loop is controlled by humans: define intent, review plans and outputs, approve, and decide whether to iterate.

Developers don't disappear from the process—they move to a higher level of abstraction. What's saved is syntax-level checking time; what's added is thinking about architecture, constraints, trade-offs, verification methods, and acceptance criteria.

Live demo: one requirement generates a website

The talk demonstrates several progressive examples. The first asks the agent to visit Google News and scrape headlines, using a browser tool (chrome-devtools-mcp) to read the DOM and synthesize the information, with user authorization required to access web pages during execution. The second generates a tech conference info site: a homepage with date and location, a schedule, 8 talks, and 1–2 speakers per talk. The agent first produces an implementation plan, which the user can edit directly; once confirmed, it generates the code and starts the server.

The third case is closer to real development: a single line—"create a productivity app with a pomodoro timer and white noise, in a farm aesthetic style"—and the agent generates files in an independently created project space, starts the app, finds errors and fixes them itself, ultimately delivering a runnable application. In the environment, the demoer can also switch the model driving the agent.

chrome-devtools-mcp is an open-source MCP (Model Context Protocol) server from Google that exposes Chrome DevTools capabilities—debugging, DOM reading, network request capture, performance profiling, console logs—to AI agents. MCP itself is an open protocol for standardizing the invocation interface between large models and external tools and data sources, letting agents discover and call tools on demand without hard-coding every tool integration into the prompt. In this example, the agent reads the structure of the Google News page through this server and then parses and synthesizes the information itself; such browser tools typically also require explicit authorization to limit the agent's access boundaries.

The glass-box principle: artifacts are the engineering boundary

The biggest engineering obstacle for agentic systems is the "black-box problem"—give it a prompt, it spits out thousands of lines of code, then declares "done." That's unacceptable in an engineering process.

The alternative the speaker proposes is the "glass box": make plans, task breakdowns, tests, and documentation all visible, so another engineer can inspect what actually happened. The role of artifacts here isn't deliverable decoration but the engineering boundary between "agent intent" and "actual output," making the execution process reviewable and governable. This is precisely why the speaker explicitly opposes having the agent return code as its only output.

Only with artifacts can a verification loop be established. In the pomodoro case, the agent generates mock dependencies, executes in the terminal, identifies failures from standard output, applies fixes, completes verification, and generates tests—this entire chain is itself reviewable evidence.

Artifacts in the context of agentic engineering broadly refer to the persistable, inspectable intermediate and final results an agent produces during execution—implementation plans, task breakdown lists, modified files, terminal commands and output, test reports, screenshots, or architecture notes. What distinguishes them from ordinary deliverables is that artifacts carry the evidence chain of "why the agent did this, what it did, and what the result was." Because artifacts can be read and reviewed by another engineer, the black-box approach of "dumping all the code at once" is replaced by a reviewable glass-box process, making artifacts the engineering interface connecting human approval and agent autonomy.

Input determines output: specifications are the new core skill

A formula that recurs throughout the talk: better context + clearer intent + stronger constraints = higher-quality agent execution.

Conversely, if the specification itself is vague, the agent will only execute vague input faster. AI hasn't eliminated the need for engineering rigor—it has exposed the cost of lacking it more quickly. The speaker gives a comparison: instead of just saying "build an app," provide the repository structure, architecture docs, relevant interfaces, existing patterns, and constraints, then specify tech stack limits, architectural conventions, security requirements, test coverage targets (e.g., over 90%), and acceptance criteria—and the output quality will differ fundamentally.

This also explains why the specification is deliberately placed between context and implementation—it isn't an optional step but the leverage point that determines execution quality.

A specification here refers to a structured task description aimed at the agent, typically including goals and non-goals, constraints, interfaces and data contracts, acceptance criteria, and verification methods. What distinguishes it from a traditional requirements document is that its audience is the agent: constraints need to be explicit enough to be decidable, and acceptance criteria need to be automatically verifiable (e.g., test pass rate, lint results), otherwise the agent can't tell whether the task is complete. The reason the specification sits between context and implementation is that context provides "environmental facts" and the spec provides "success criteria," and together they determine the upper bound on the quality of the agent's planning and iteration.

Six governance questions: autonomy must have boundaries

An agent that can only generate text has limited destructive power; an agent that can access production systems, repositories, databases, cloud resources, and external services is entirely different. The speaker lists six governance dimensions that must be designed explicitly:

• Trust boundaries: what scopes the agent is allowed to operate in
• Tool permissions: which tools it can invoke
• Data access restrictions: what information it can read
• Verification evidence: what evidence is required to trust the result
• Auditability: what access and operations occurred
• Cost control: whether it might unexpectedly consume large amounts of compute or API resources

The last one has real-world grounding: an API called thousands of times by an agent, rendering it unavailable—this kind of risk isn't hypothetical under unbounded autonomy.

A trust boundary originally refers to the dividing line between regions of different trust levels in a system, where data crossing the boundary requires validation and authorization. In agent scenarios, it's extended to "the scope within which the agent is allowed to act autonomously"—for example, a read-only repository, an isolated sandbox branch, a non-production environment, or a restricted cloud resource quota. Unlike tool permissions and data access control, trust boundaries emphasize the overall design of scope and isolation: the agent can plan and iterate freely within the boundary, while out-of-bounds actions must trigger human approval. The clearer the boundary, the more you can retain autonomy while controlling the blast radius.

Practical advice: start with small boundaries

The path the speaker offers teams that want to adopt agentic engineering immediately is convergence rather than aggression: start by giving the agent a small task with clear boundaries rather than opening up all permissions; provide architecture docs, repository structure, conventions, and constraints; require a plan before execution and review it; define clear acceptance criteria; enforce verification (tests, lint, validation); and keep human checkpoints around security-sensitive, infrastructure-sensitive, or high-impact operations.

This is also where traditional AI coding assistants and agentic development environments diverge: the latter treat multi-step execution as a core capability, push testing from "generating tests" to "executing and iterating," and move the human role from prompting and code review to architecture, supervision, and verification.

The question posed at the end of the talk is worth remembering: don't ask "can AI read and write my code," but ask "which segment of my team's engineering workflow can the agent execute." The answer to that question determines your engineering competitiveness in the agent era.

One-line Summary

AI programming has entered the agentic engineering stage, where the unit of interaction shifts from writing code to delivering reviewable engineering outcomes.

Paragraph Summary

Drawing on a Google Developer Expert's talk, the article traces the four-stage evolution of AI programming—code completion, conversational programming, coding agents, and agentic engineering—and identifies the core shift: the unit of interaction moves from "code completion" to "engineering task completion." Agents must plan, retrieve, execute commands, modify files, run applications, and produce evidence, while humans move up to the outer loop of a dual-loop workflow, responsible for intent, review, and approval. The article emphasizes the glass-box principle—using artifacts such as plans, tests, and documentation as the engineering boundary between intent and output; the quality of specifications as the leverage point for execution quality; and the need to constrain autonomy through six governance dimensions: trust boundaries, tool permissions, data access, verification evidence, auditability, and cost control. The path to adoption starts with small, clearly bounded tasks.