I use four coding agents: Google Antigravity, Claude Code, Cursor and Devin. The question I get most about them is which one is best.

I don't think that is the useful question. After more than 30 years of building for the web, I now build with AI coding agents that I direct, review and test. Mentor Intelligence was built that way. What makes it work is not the tool. It is the spec each agent works from and the review each change goes through.

Still, the tools suit different kinds of work, and splitting it well saves time. Here is how I divide it.

Four ways of working, not four brands

The lines between these products have blurred. Google describes Antigravity as an agentic development platform whose agents plan, execute and verify tasks across the editor, terminal and browser. Anthropic describes Claude Code as an agentic coding tool that reads your codebase, edits files and runs commands. Cursor calls itself a coding agent, with its own editor and cloud agents. Devin describes itself as your team's autonomous software engineer.

So I don't split the work by brand. I split it by how involved I need to be:

  • A workhorse agent for long runs through a whole spec while I am away.
  • A terminal agent for work I am steering as it happens.
  • An in-editor assistant for work where my hands are on the code.
  • An asynchronous cloud agent for well-scoped tasks I can hand off and review later.

Each tool can fill more than one of those roles. The roles are what matter.

The workhorse: a long spec, run overnight

This is Antigravity. If I just need to grind through a spec for an entire day, or the evening, I use Antigravity to get everything from the spec doc built out, and I leave it running all night.

It is my workhorse. Then I move the work into Claude Code, Cursor or Devin to refine it, review it and finish it.

That only works because the spec is complete before the run starts. A long unattended run multiplies whatever the spec leaves unclear. And an overnight build is a first pass, not a release.

The terminal agent: work I'm steering

This is mostly Claude Code. It gets work that spans the repository and needs commands run: a feature that touches several files, a refactor, a failing test traced back to its cause.

I give it a task from the spec, read its plan before it starts and stay close while it works. The test of a good terminal task is simple: I want to see each step, and I would interrupt if it went the wrong way.

The in-editor assistant: work I'm doing

This is mostly Cursor. When I am reading code and making precise changes myself, I want help inside the file in front of me: a component adjusted while I look at it, an unfamiliar module explained, a diff read line by line.

Here the assistant speeds me up. It does not take over. That makes it the right place for detailed interface work and for review, where the judgment has to be mine.

The asynchronous agent: work I can hand off

This is mostly Devin. Some tasks are clear enough to hand over and check later: a bug with a reliable reproduction, tests for a module that has none, a dependency update, a small feature with acceptance criteria already written.

Devin's own documentation offers a good rule of thumb: "if you can do it in three hours, Devin can most likely do it." It also recommends explicit completion criteria and tasks that are easy to verify. The work comes back as a pull request, so it has to be something a person can review in one sitting.

What I don't hand off: vague tasks, anything that needs product judgment halfway through, and changes to permissions or data isolation, which I want to watch being written.

The same rules for all four

Whichever agent writes a change, it works under the same written constitution: no production data, preview before production, public claims need evidence. I wrote about the rules my coding agents work under separately.

An AGENTS.md file in the repository can be read by Claude Code, Cursor, Devin and Antigravity, so one file can carry the same rules to all four.

But written rules are guidance, not enforcement. So the rules that matter most are also built into how the project is set up:

  • No agent touches real records. Agents work against seed data, in environments with their own databases, separate from live.
  • Every change takes the same path. The same tests, preview, security review, release checklist and rollback point, whichever agent wrote it. An overnight run gets no shortcut.
  • No agent approves its own work. A person does.

The tool matters less than the spec and the review

Every agent is better with a clear spec. Flows, a data model and acceptance criteria leave fewer gaps to fill with guesses, which is why the spec comes before the code. A vague task makes all four tools guess, each in its own way.

Review is the other half. When agents write code this fast, and one can work through the night, review becomes the bottleneck. The review has to be as careful for the agent I trust most as for the one I trust least, because the failure that gets through is the one nobody expected.

I also pick the model for each task, from Anthropic, OpenAI and Google. That choice changes often. The spec, the rules and the review do not.

If you are starting with one

You do not need four tools. A sensible order:

  1. Write the spec and the rules down in the repository.
  2. Set up previews and automated tests, so every change is checked the same way.
  3. Pick one agent and use it for the work you are steering.
  4. Add an asynchronous agent when you notice well-scoped tasks waiting that you could hand off and review later.
  5. Add a long-running workhorse for whole specs, once your review can keep up with what it produces.

If your team uses coding agents and everyone has their own way of working with them, email me. Setting up one set of rules, one pipeline and one review process that every agent follows is one of the most useful things I do with existing teams.