The first surprise in Antigravity was seeing a chat request turn into a change in the open file. The conversation stayed on the right, the code stayed on the left, and a diff showed which lines had changed.
Until then, AI help on personal projects mostly meant pasting code into ChatGPT, reading a suggestion, and carrying it back into the project. Copilot Chat was already familiar at work too. There was still a step between receiving an answer and making a change in the files.
Tools such as Antigravity and Gemini CLI connect the model to the project, so the conversation can lead to an edit, a command, or a result to inspect. What changes when the model can work with the code it is discussing? That is the part worth a closer look.
The chat-and-paste routine
In the ChatGPT workflow, the project lived outside the conversation. The developer chose the context, meaning the code and information to bring into the chat, and carried the suggestion back into the files. Asking the question, applying the answer, and checking the result were separate bits of work.
That selection matters. A function might look perfectly sensible on its own while the mistake sits in the code calling it. Pasting only the function leaves part of the problem out. The conversation can help reason through the supplied excerpt, but someone still has to decide which parts of the project to share.
That gets harder when the language is unfamiliar. Describing what an extension should do is easier than knowing which snippet carries the problem. Choosing the context can already require some of the understanding the chat is being asked to help with.
The developer still carries the useful code into the chat, applies the proposed edit, and returns the result of trying it. Better answers help, but this coordination remains part of every change.
Autocomplete inside the editor
AI autocomplete already brings some of that help into the editor. A function signature (the name, inputs, and beginning of a function) or a comment describing the behaviour gives it a starting point. The editor can suggest an implementation, sometimes a whole function, to accept or adjust.
Cursor belongs in that story, alongside tools such as GitHub Copilot. Copilot has been suggesting lines and entire functions since 2021; Cursor’s early autocomplete work brings that experience into its own editor. The help sits where the code lives.
A function that adds up a list of prices is a simple example. A comment can describe the behaviour, and autocomplete can suggest the body. The function still needs a place in the project and a shape to work within. The assistance happens where the code is being written.
An agent lets the request start further out: “Make the total return zero when the list is empty.” The request describes a behaviour. The tool can look for the relevant code and make the change there.
What Antigravity brings to the project
The Google subscription provided access to two tools: the Antigravity app and Gemini CLI. Both have free access too; Google’s paid AI plans provide higher Antigravity usage limits and higher Gemini CLI limits. The important capability is working with the project itself.
The Antigravity editor is a fork of VS Code’s open-source codebase, with the familiar file and folder structure, tabs, and code editor. Its Editor view includes an agent in the side panel. The editor view puts the chat on the right and the code on the left. The actual files stay visible while the agent works on them.
Gemini CLI brings an agent into the terminal. CLI means command-line interface: you interact through text in a terminal instead of a graphical editor. It can read and modify files and run commands, so a conversation there can also lead to work in the project.
An agent, here, is a model connected to tools that let it take actions. It can inspect a file, use what it finds to decide on a change, edit the code, and inspect the result of a command. Antigravity’s agents can work across the editor, terminal, and browser. That connection is what makes the conversation useful in a different way.
The wow moment: watching the diff
Watching the diff appear was the moment this difference clicked for me. The conversation sat on the right; the changed code appeared on the left. A diff is the view of the change: which lines are removed and which are added.
The interaction still looked like chat. The response was an edit in the file beside the conversation, ready to inspect. The answer had reached the project without a code block being carried across. That was the wow moment.
Here’s a small illustration using the total function. An empty list makes this version
of JavaScript’s
reduce
throw. Giving it an initial value of zero fixes that case. The request describes the
outcome; the edit supplies the detail.
An empty total has a clear desired result even when the JavaScript syntax is unfamiliar. Asking for that behaviour produces a specific edit to examine. The explanation can then connect the result to the line of code that implements it.
The useful detail is the added zero.
Return zero when the list is empty. Keep adding prices otherwise.
function total(prices) {
return prices.reduce(
(sum, p) => sum + p
(sum, p) => sum + p, 0
);}total([])Before: TypeErrorAfter: 0
total([12, 8])Before: 20After: 20
The small zero is the useful detail in the picture. It is easy to miss in a paragraph and easy to locate in a diff. The agent supplies an implementation; the visible change lets the developer ask whether it actually matches the request. Running the empty-list case turns that proposal into a result that can be checked.
Why this changes the workflow
The improvement goes beyond saving a copy and paste. The agent can inspect related files, find where a function is used, and apply edits in the project. With the tools and permissions available, it can also run a check and use the output to work out what to try next. More of the context and feedback can stay inside the same process.
Plain language becomes a useful starting point. “Make the total return zero for an empty list” gives the agent a behaviour to work toward, while leaving room to find the implementation. A request still needs a meaningful goal; vague instructions leave more for the agent to guess.
Autocomplete is useful when a function is already being written. The agent opens up a larger piece of work: finding the relevant code, changing it, and checking what happened. That shifts more attention toward the intended behaviour and the change that actually appears.
The familiar editor made the change easy to underestimate at first. There were still files, tabs, visible code, and a chat. What changed was the work between sending the message and reading the edit: the agent could carry the request into the project.
Working from an idea
An empty-list fix is small enough to read and understand. It also shows why the starting point matters. A request can describe the desired result before specifying the function, file, and exact line that need changing.
The same conversation can follow the change further: find the other places that use the function, add a check for the empty list, or explain the edit with the relevant code still open. Those requests connect the implementation to the behaviour it needs to support.
C++ and SQL make up most of my day-to-day work. Chrome extensions are an outside-work experiment in much less familiar JavaScript and TypeScript. That is where starting with a description helps: the intended behaviour can be clear while the language needed to express it is still being learned. The edit makes that unfamiliar syntax something concrete to inspect and ask about.
A lot of the old routine was moving information around: selecting code, copying a reply, and reporting the result. Keeping the files, changes, and explanations together leaves more room to follow the problem itself.
Making the request clear
The request takes on some of the role a function signature plays in autocomplete: it gives the tool an intended behaviour and a starting point. Plain language still has to say something useful.
“Fix the total” leaves a lot open. “Return zero when the list is empty, and keep adding the prices the same way otherwise” names a behaviour and a boundary. Those give the edit a result to aim for while leaving the exact implementation to the agent.
An initial request can leave implementation details for the agent to work out. As the diff makes those choices visible, the request can be refined. A follow-up can ask why a particular approach was chosen, keeping the explanation connected to the change.
The edit is also something to learn from. In this example, the extra zero raises a useful question: what does the function do when there is nothing to add? The answer connects the explanation to a visible change in the file.
Backend experience helps with reasoning about the result. Where the frontend language is unfamiliar, following the change requires slower reading, a clear explanation, and a check in Chrome. Producing an edit and understanding its effect are both part of the work.
A different place to start
The shift is in how close the conversation gets to the work. ChatGPT and Copilot Chat made asking for help familiar. Antigravity and Gemini CLI connect that conversation to the files, tools, and feedback of the project. A request can become a change that is visible and ready to inspect.
For a backend developer with frontend ideas, these tools offer a useful starting point: describe the behaviour, inspect the implementation, and learn from the change. A small, clear request, a readable diff, and a check in Chrome keep that process concrete.