Codex, Claude Code and Antigravity: what AI coding agents mean for non-technical teams

What is an AI coding agent, in plain words?

A chat assistant answers questions. A coding agent does work on files: it reads a project, writes or changes code, runs it, sees what breaks, and tries again, asking for approval along the way. You describe what you want ("a page that calculates our seat costs"); it builds it.

The important part for a manager: it acts with the access of the person using it. If that person can't read the code, they're still the one approving it.

Codex, Claude Code and Antigravity: how are they different?

From each vendor's own pages, checked 1–2 November 2026. Plans and limits change often.

Developers compare them in detail; one widely upvoted thread sums up the experienced view: Claude Code gets more done per session but needs a skilled driver, while Codex is slower and its code needs less clean-up. The line that matters for everyone else: both give poor results if the person directing them doesn't know what good software looks like.

What could a non-technical team get built?

Realistic, low-risk examples:

• Small internal calculators and pages. We asked Claude Code for a page that shows what AI seats would cost for a given team size. It was working in minutes; a 10-seat test came out right ($200 a month at $20 per seat). A person still types in and dates the prices, and owns keeping them current. That and six other jobs we tested.
• Data clean-up and weekly reports from exports you already have.
• Bulk updates to documents or files, with a review step.
• Prototypes to show a developer what you want, rather than the finished product.

The clearest real story we found is from a product manager with 20 years' experience who has never written production code. A vague request produced junk. A field-by-field spec, a plan reviewed before building, and precise descriptions of what was broken produced something they'd pay for. Their estimate: the build itself is about 20% of the time; the rest is specifying and checking.

Worth knowing: when asked whether non-technical teams can build internal tools, ChatGPT, Gemini and Perplexity all said yes, then mostly pointed to no-code builders (Lovable, Replit, v0, Power Apps) rather than to these three agents. In forums, too, non-technical operators mostly talk about those builders, while developers argue about Codex and Claude Code.

What can go wrong?

• It does the wrong thing confidently. In one of the most-upvoted posts on the subject, someone asked an agent to back up files and it deleted them instead. Approval prompts and backups matter.
• Code nobody understands. If no one on the team can read it, no one can fix it when it breaks.
• Real data in a "quick" app. A common worry in no-code forums: an app built in an afternoon starts holding customer data, and "hiding a button is not a locked backend".
• Access. The agent works with your permissions. Keep it in a project folder, never your whole computer or production systems.
• Quotas and preview-stage tools. One user reports a morning of Antigravity used up a quota that took nearly four days to refresh.

The assistants' own advice converges on one rule, and we agree: a technical person reviews anything before it goes live, especially anything customer-facing or touching payments.

What's already in the plans you pay for?

• ChatGPT: Codex is part of ChatGPT plans; ChatGPT Business lists "all ChatGPT, ChatGPT Work, and Codex features". OpenAI says plan usage will be shared across ChatGPT and Codex from December 2026.
• Claude: Claude Code is included in every paid plan (Pro $20/month; Team from $20 per seat on annual billing).
• Google: Antigravity is free for individuals; organisations go through Google's enterprise options.

So the question is rarely "should we buy a coding agent?" It's "should anyone on the team use the one we already have, and with what rules?"

When not to use one

• Anything customer-facing, or that stores customer data, without a developer's review.
• Anything that moves money or changes records in your main systems.
• When nobody on the team will own the result after it's built.
• When a spreadsheet, an existing tool's setting or a simple automation would do the job.

A simple policy for a small team

1. One named person may use a coding agent, on a project folder only.
2. Write a short spec before building: inputs, outputs, what "done" looks like.
3. Approval prompts on; backups before any bulk change.
4. Internal, low-risk tools only, unless a developer reviews it.
5. Every tool built gets an owner and a one-paragraph note on what it does.

Common questions