From Chat Window to Software Factory: Antigravity Is Changing How Development Is Organized, Not Just the Models

"If you've already used Antigravity, raise your hand."

That was how the Antigravity deep dive opened. The speaker, a senior developer relations engineer who has been at Google for about six years, ran several rounds of hand-raising: Who has used Gemini? Who relies mainly on IDE autocomplete? Who treats the chat panel beside the editor as their main workspace? And who works entirely from the command line? The distribution itself pointed to the problem he wanted to discuss. Most people still think of AI-assisted programming as "a smarter conversation partner."

His argument goes a step further. Staring at a single chat thread is like a craftsman chained to one workbench. The number of projects you can push forward at once is limited by how fast you type, how fast you review, and the cost of switching context. If you want more output, chatting harder won't help. You have to change how the work is organized: from a single bench to a parallel assembly line. That is what he calls a "software factory."

The models got stronger, and so did the harness around them

He dates the turning point to last December. Since then, model releases have arrived in waves: Gemini 3 Flash first, then Gemini 3.1 Pro, then the whole Flash line, including Gemini 3.8 Flash. Now there are Gemini 4, Argon, and Carbon. Each release came with a more capable agent framework.

The Antigravity team works closely with the model teams and research. In his words, some of the decisions they make at the "harness" layer directly affect the models, and changes in the models reshape the harness in turn. Recent benchmarks show that running any Gemini model inside Antigravity produces better results. His recommendation is blunt: if you tried Gemini outside Antigravity before, try again with the latest version.

That shift has also changed the shape of the development interface. Early models were already quite good at writing code, but complex systems usually required strict supervision, broad guardrails, and careful context scoping to keep the model from writing to unintended files or directories. As models and harnesses matured together, interaction moved from line-by-line autocomplete to IDE chat, and then to dedicated desktop and CLI agent environments. The show of hands reflected that split: some people are fine with autocomplete, some live in the side panel, and some have already handed everything to the terminal.

When Antigravity launched late last year, one of the team's goals was to build an agent-first development environment from scratch. The engineer had previously supported Project IDX (later reorganized into Firebase Studio) and worked on Gemini CLI; more recently, many of Jules's capabilities were folded into Antigravity. The recurring question was how each product could feed the others and drive continuous improvement. At this year's Google I/O, they split the capabilities into four entry points: the main app, the CLI, the IDE extension, and the Python SDK. Whether you organize tasks visually in the app or launch them from a terminal, the same harness sits underneath, and the results should match.

The software factory is not a new metaphor. Japan tried it more than half a century ago

The term "software factory" became a reality in Japan decades before modern AI. In 1969, Hitachi opened the world's first software factory in Yokohama; in 1977, Toshiba opened one in Tokyo. As an MIT professor documented, Japanese engineering leaders turned software development from an isolated craft into a repeatable discipline, built on reusable components and strict quality control.

That history explains why "opening more chat windows" is not the same as scaling. A craftsman's bench can produce excellent work, but output is tied to one person. The assembly line changed how work is divided, handed off, and inspected. Antigravity is trying to bring those three things into agent-driven development.

Step one: replace synchronous chat with structured delegation

Two features in Antigravity represent this step: /boost and /teamwork-preview.

/boost coordinates a group of subagents on a linear assembly line. You specify the task and the scope each "station" should work within, and it verifies the result before returning it. The engineer often pairs Boost with Carbon and Argon for long-running tasks where he wants to keep context compression to a minimum.

/teamwork-preview, by contrast, defines a full team of specialized roles that can advise, criticize, and improve one another's work. The team can adjust dynamically at runtime. You can launch 50 or more subagents, which consumes a lot of tokens, but they can run unattended for hours, sometimes days. Many people on his team already use it for overnight sessions: start the process before leaving, and review the results the next morning.

The I/O demo showed what that scale can do. With Teamwork Preview and the Flash models, they built an operating system from scratch, compiling C++ into an OS and even getting it to run Doom. They also used the same approach to optimize C++ performance across several libraries. At an event with Argonne National Laboratory, they discussed helping companies migrate Fortran, COBOL, or legacy C++ codebases to modern Rust, solving memory-performance problems and letting scientific computing run efficiently on modern hardware.

The longer a task runs, the less practical it is for a person to watch it. Antigravity's Remote Control lets you connect to your workstation from any browser and, more importantly, sends notifications to your phone or even your watch. A model may now take an hour and a half to three hours to return a result. You only need to show up when an approval prompt needs a decision, or when you notice the work heading in the wrong direction. As he put it, you intervene only when the "council" needs you to make the call.

Step two: remove manual invocation too

Moving from chat to delegation is like putting an assembly line into the factory. But a line still needs someone to deliver raw material and press start. The next step is to eliminate the manual call entirely.

Antigravity supports scheduled tasks and automations that run on a cron schedule. Setup has become simpler: a single @automation command configures it for you. The natural candidates are the things you repeat every day: triaging overnight error reports, analyzing benchmarks, auditing dependencies, or creating proactive agents that start working before you open your laptop.

Beyond schedules, .agents/hooks.json provides declarative JSON hooks. A background sidecar can listen for lifecycle events and automatically validate code or trigger a line. The moment an event fires, the factory floor can start moving. If you haven't used a sidecar, think of it as a webhook-like mechanism for summoning Antigravity when it is needed.

Jidoka: a line that stops itself when it should

A real software factory also needs a system that takes raw material in at one end and delivers finished work at the other. The Toyota Production System's "Jidoka" is often translated as "automation with a human touch." Its origin was an automatic loom built in 1924.

Before that, every loom needed an operator watching continuously, because a single broken thread could turn a large run of cloth into defects. Unsupervised AI carries a similar risk: a large amount of context and tokens can be wasted on irrelevant information or a wrong direction. What made that loom different was that it stopped itself when a thread broke. One operator could then oversee 40 looms.

Toyota later generalized the idea into four steps: detect the abnormality immediately; pull the cord to stop the line so defects do not flow downstream; fix the immediate problem; then add mistake-proofing so the same error does not recur.

Antigravity tries to build the same principle into the development process. Every line you create is backed by a .gemini/brain folder: chat history, step-by-step operation documents, and independent Git worktrees all leave complete JSON traces, and everything is persisted automatically. That disk-based state lets you pause, switch, and resume a workflow without losing progress. When quota runs out, you need to change models, or you want to fix something that went wrong, you can stop cleanly.

The mechanism already has data behind it inside Alphabet. According to the engineer, more than 100,000 monthly active users work with Gemini 4 Argon in the company's internal Antigravity environment; agent-written code is up 35%, while post-submit rollbacks are down 30%. Because verification sits directly in the production flow, overall speed went up and the defect rate went down. These are internal figures, not an independent audit, but they make one point: the value of a line is not only that it is faster, but that every step can be verified and rolled back.

Five steps to building a line

He breaks building a software factory in Antigravity into five steps. The core components are custom subagents, Skills, and plugins.

First, define the work primitives. They live in .agents/agents. Markdown files and custom subagents let you define behavior completely: which MCP servers and tools a subagent can access, the policy for its execution environment, and even which model it uses. This also lets you keep a large number of subagents that load context only when they are actually invoked. At runtime, these primitives execute concurrently in separate Git worktrees, with dynamic model selection, scoped sandboxes, and real-time state tracking.

Second, codify the process as a standard operating procedure with Skills. They live in .agents/skills. A line specifies which workers are called directly, in what order, and when and how work is handed off between separate worktrees. It also defines what research and definition material is needed before moving on, and which outputs should be reviewed and summarized.

Third, add read-only inspectors. Read-only custom subagents audit everything happening in the system, which is useful for security checks, accessibility monitoring, and policy enforcement. He also likes them for another case: when a subagent gets stuck or looks about to drift into the wrong context, these inspectors can take charge. Several Google teams already ship these capabilities in plugins, including the Flutter team's accessibility checks, Firebase rules checks, and Google Play's pre-submission review.

Fourth, package it as a portable plugin. Combine the main factory agent, subagents, skills, and inspectors into one Antigravity plugin, and your whole team can version it and run it anywhere. They also announced an expansion of the plugin marketplace.

Fifth, connect automation triggers. Have the main agent start automatically when raw material arrives: a new GitHub issue, a daily scheduled job, a webhook, or a watched folder on a NAS. The CI pipeline can then run and deliver verified pull requests and dry-run artifacts at the end.

While a line is running, inspectors pause production when they find a problem, stop the damage immediately, and feed the improvement back into the agents, skills, and workflows so the next run is smarter. When a real architectural trade-off is needed, you can step in through remote control on your phone. That matters more and more, because these systems are becoming capable of self-repair and continuous improvement.

Start where the risk is lowest

If you don't know where to begin, his advice is to pick one repeatable, verifiable, low-risk task and turn that into a line first.

His own example was deleting old code. He built a system that checks iOS, Android, and web APIs and removes outdated polyfills or unused APIs. With a background in web development, he knows the value of that kind of cleanup: it keeps the codebase current, while people can keep the chat agents on the new technology that genuinely needs exploration.

That is the central shift of the whole session: stop managing every turn of a conversation, and start designing a line, stepping in only where judgment is required. The point of a software factory was never to remove people. It is to make every step verifiable, stoppable, and resumable, so that scaling means changing how production works rather than making copies of the same workbench.