What is the difference between /boost and a normal coding assistant?

A normal assistant answers in a single turn with one agent, which suits feature work and codebase navigation. /boost runs three phases instead: an orchestrator decomposes the problem, specialised agents execute in isolated scopes, then independent verification rounds run the tests and regression checks before delivery. It was designed specifically for hard bugs such as race conditions and intricate refactors, and per Google's documentation it is available on paid plans.

Do tools like this mean I no longer need a development company?

No. An agent implements what you described. It cannot discover that the description itself was wrong or incomplete. Defining requirements, understanding your business rules, billing cycles and permissions, integrating with existing systems and deciding between conflicting needs all remain human work. Google's own documentation states that protected commands or edits outside trusted scopes require explicit user approval.

How do I know my software vendor works at this level of quality?

Ask three specific questions. Who reviews the code other than whoever wrote it? Is there a test suite that runs automatically before every deployment, and can I see its results? Is there a staging environment separate from production? If the answers are vague, the problem is not the tooling in use, it is the process itself.

Is my code or data at risk if my team uses coding agents?

The risk depends on configuration, not on the tool. Check three things before adopting: where code is stored and who can access it under the provider's terms, what file and command permissions the agent is granted, and whether production secrets and keys are separated from the development environment. Writing a policy on those points before adoption is far easier than fixing it afterwards.

Google Ships /boost in Antigravity: Agent Teams That Write and Verify Code

Google has added a new command to its Antigravity development environment called /boost. Invoking it starts a multi-agent reasoning pipeline instead of a single coding assistant: an orchestrator reads the problem and breaks it into tasks, dispatches them to specialised agents working in isolated scopes, then puts the result through independent verification rounds that actually run the tests before anything reaches you. The headline is not that AI writes code faster. It is that coding tools have started building verification into the tool itself.

What Google actually announced

According to the official Antigravity documentation, /boost is designed for hard software engineering specifically: concurrency bugs and race conditions, algorithmic optimisation, subtle regressions that appear and vanish, and intricate refactoring across multiple files. These are exactly the problems a conventional single-turn assistant fails at, because solving them requires experimentation and backtracking rather than direct generation.

The command runs in three clear phases:

Planning: a primary orchestrator receives your prompt, inspects the workspace context, formulates an execution strategy, and decomposes the challenge into discrete, verifiable subtasks.
Distributed execution: the orchestrator dispatches those subtasks to specialised agents. Implementation workstreams write code and unit tests. Investigation workstreams perform root-cause debugging and trace call graphs without modifying any file. Local verification agents run build targets and test suites to validate hypotheses before reporting back.
Verification before delivery: the orchestrator aggregates findings and runs regression checks against full test suites and edge cases. If an assertion fails, the error diagnostics feed into the next iteration for automated correction, and you only get a summary of verified changes once everything passes.

All of it runs inside ephemeral, isolated worktrees, meaning the agents are not experimenting on your working copy of the project.

Three modes, not one

Google documents three distinct execution modes, and the difference between them is the practically useful part:

Default agent: interactive coding, codebase navigation and general refactoring. Task horizon of seconds to minutes, a single-agent loop, single-pass verification. Available on all plans.
/boost: deep reasoning and stubborn bugs. Task horizon of seconds to hours, a three-phase hierarchy, multi-round independent verification. Available on paid plans.
/teamwork-preview: agent teams working for days on large migrations or whole subsystem builds, with named roles such as Explorer, Worker, Critic and Auditor, plus verification gates that deliberately try to break the code before a milestone is approved.

Notice the gradient: the bigger the task, the more the investment goes into review rather than speed. That is a signal worth paying attention to for anyone running a software project.

Why this matters to a business owner, not just a developer

For the past two years the conversation about AI in programming has been a conversation about speed: how many lines get generated per minute. The problem is that speed is not the bottleneck in real projects. Trust is. Does this code actually work in the cases nobody tried?

What the architecture of /boost implicitly says is that the industry reached the same conclusion. Code that arrives faster is worth nothing if it costs two weeks of debugging after delivery. So the tool is built around three rules that apply to any technical team, with or without AI:

The author does not get to grade their own work: the party that verifies is separate from the party that implemented. That has been the principle behind code review for decades. It is now enforced inside the tool.
Evidence means execution, not assertion: tests are actually run and their real output is checked, rather than accepting a claim that they passed.
Isolation protects the original: experimentation happens in a separate copy, so failed attempts never leak into the project.

If you are buying software development, those are precisely the three questions to ask your vendor: who reviews it, what is the evidence the tests passed, and where does experimentation happen?

What does not change

It is easy to read news like this as an announcement that engineers are no longer needed. The documentation says the opposite quite plainly: agents inherit the file access rules and command permission policies configured for your workspace, and any protected command or edit outside trusted scopes raises an authorisation prompt to the user. There is a responsible human at the end of the chain.

And permissions are the smaller half of it. An agent solves the problem you described. It cannot know that the description itself was wrong. It does not know that your billing cycle closes on the 25th and not the 30th, that this field must never be visible to a sales rep, or that when your customer says "order" they mean something different from what you mean. Defining requirements, understanding the domain and owning the decision remain entirely human work.

How we read this at Origami

We treat multi-agent tooling the way we treat any productivity tool: it accelerates execution, it does not transfer accountability. A project here still passes through written specifications, human review, a test suite and a staging environment before production, whether a person wrote the code or an agent generated it. A tool that runs its own tests is a welcome addition to that chain, but it is a link in it, not a replacement for it.

The practical takeaway for a business owner: expect delivery timelines to compress on complex work specifically, but do not accept a handover with no tests, no documentation and no human owner. Tools that review themselves raise the ceiling on achievable quality. They do not remove your need for someone who guarantees that what was built is what you asked for.

Google Ships /boost in Antigravity: Agent Teams That Write and Verify Code