A Personal Moment of Disruption
Last week, I downloaded Google’s new development environment: Antigravity.
After decades in software engineering, I’ve learned to be skeptical. I’ve seen countless hypes come and go — new languages, new frameworks, new paradigms, new tools. Some changed the industry, many quietly disappeared. So after reading Antigravity’s glossy marketing material, my expectations were… restrained.
The last real rupture happened about three years ago.
With the launch of ChatGPT, AI stopped being experimental and became practical. Since then, it has been part of my daily workflow: writing software, drafting texts and emails, planning trips, even cooking. ChatGPT set a new baseline. Others followed — Claude, Gemini, Perplexity, DeepSeek, GitHub Copilot. Productivity gains were massive, especially in software development.
Still, it was assistance.
My first real encounter with Antigravity came through a concrete project. For my kids, I built the Pixel Image Creator as a simple standalone app using ChatGPT, and now I want to turn it into a web application and evolve it further.
Within the first conversations with Antigravity’s Agent Manager, it became clear that this plays by different rules.
Antigravity doesn’t ask for the next function to implement. It proposes an overall approach. It sketches concepts, makes assumptions explicit, invites feedback — even asynchronously, while agents are already working in the background.
What followed felt less like programming and more like collaborating with a highly competent engineering team. Structure emerged. Tests were generated and executed. Code was corrected and retested. Documentation appeared. Deployment instructions were written. The technology stack was explained. Git repositories received commits, branches, and tags.
That was the moment it stopped feeling like a productivity boost. This wasn’t code generation anymore.
It was software development being delegated.
And that realization was as fascinating as it was deeply unsettling.
What is Antigravity (without the marketing)?
At first glance, Antigravity looks familiar. You get a regular VS Code–based editor. Files, folders, terminals — everything you’d expect. If that were all, it would be unremarkable.
The difference sits next to it: the Agent Manager.
This is not a chat window bolted onto an IDE. It is a control layer for autonomous agents that operate across the entire codebase and its surrounding ecosystem.
The workflow is simple, but the implications are not.
You describe intent in the Agent Manager: what you want to build, change, or understand. The agent responds by proposing a plan — architecture, steps, assumptions, risks. You can accept it, reject parts of it, refine it, or let it evolve over multiple iterations. Feedback can be synchronous or asynchronous; agents continue working while you think.
Once execution starts, the agent doesn’t stay confined to a file. It:
- navigates the repository
- generates and modifies code across layers
- runs tests and fixes failures
- updates documentation
- explains design decisions
- interacts with version control
- and much more
Meanwhile, the VS Code window remains fully usable. You can inspect changes in real time, open diffs, run commands manually, or step in at any point. Nothing is hidden — but very little is micromanaged.
The crucial shift is this: You are no longer instructing how to write code line by line. You are steering what should exist and why.
Antigravity doesn’t replace the development environment. It wraps it with an agent-based reasoning layer that treats software development as a coherent, end-to-end process.
That distinction is what makes it fundamentally different — and why it doesn’t feel like just another tool.
From Prompt to Production: A Full blown Web Application
The first working version of the web application was up and running in about 15 minutes.
Before anything starts, Antigravity asks how the agents should operate. I chose the restricted mode. In this mode, agents must explicitly ask for permission before executing local commands. It slows things down slightly, but the trade-off is transparency: you see what is about to happen, which commands will run, and why. At no point does the system feel like a black box.
For every task, the agent begins by outlining a clear execution plan. Steps are spelled out. Assumptions are stated. Alternatives are often suggested. You can comment on individual steps, reorder them, or replace the plan entirely before anything happens.
This interaction feels far less like chatting with a bot and far more like discussing a solution with a software architect or technical project lead. The Agent Manager is highly communicative, continuously explaining its reasoning and next moves. While agents work in the background, you can follow the progress in real time, influence decisions, or step in whenever necessary.
Once the webapp was finished, I applied some incremental improvements:
- making the application available in desktop mode
- integrating a native file save dialog in the desktop version
- defining deterministic logic for generated PDF filenames
- receiving deployment support and platform recommendations
- generating project documentation in Markdown
- generating a dynamic sized grids in the pdf layout
- added dithering in the image generation
- added another color palette based on physical available pixels
None of this required context switching, ticket writing, or setup overhead. Each step followed naturally from the previous one, guided by short discussions rather than long specifications.
The Uneasy Part: What Happens to the Software Engineer?
Tools like Antigravity push software engineering toward something that, until recently, felt unrealistic: expertise on demand.
Capabilities that once required years of training — architecture design, testing strategies, deployment workflows — are suddenly accessible to a much broader audience. Not perfectly, not without supervision, but good enough to build real products. Software development becomes less exclusive, more approachable, more widely distributed.
That shift inevitably changes the role of the software engineer.
If implementation becomes cheap and fast, value moves elsewhere: problem framing, system thinking, quality judgment, responsibility. Engineers are less defined by how well they write code and more by how well they decide what should be built, how it should behave, and when it is good enough.
At the same time, product development accelerates dramatically. Ideas turn into running systems in hours instead of weeks. Iteration cycles collapse. This is a massive creativity boost — fewer barriers, less friction, more experimentation. But speed also amplifies mistakes. Bad ideas can scale just as fast as good ones.
Education will not be immune to this shift. Universities can no longer treat software engineering primarily as an exercise in manual implementation. Students will still need fundamentals, but they will also need something that has been harder to teach: orientation knowledge. Understanding trade-offs, evaluating generated solutions, recognizing when systems are fragile, unethical, or simply wrong.
Beyond the profession itself, there are uncomfortable societal questions. If fewer people are needed to build software, what happens to those displaced? Productivity gains are rarely distributed evenly. The risk is not just technological unemployment, but a further widening of the gap between those who can leverage these systems effectively and those who cannot.
This is not just a tooling change. It is a structural shift — the emergence of a new class of tools that feel less like development utilities and more like a technical project manager of a software company, translating intent into execution by coordinating architects and engineers in the background and turning high-level wishes into running systems.
Software engineering is not disappearing — but it is being redefined. And whether that leads to empowerment or erosion depends less on the tools themselves than on how consciously we choose to use, teach, and regulate them.