MLA 022 Vibe Coding in 2026: Codex vs Claude Code vs Antigravity vs Grok

Loading...

This episode was generated with Gnothi, a tool I built. Give it a topic and it researches the subject, writes the chapters, and narrates them. If you want more than one episode on this, Gnothi has a whole show on Claude Code, from your first change in the terminal to a repeatable delivery workflow. O C devel dot com slash code. That's O C D E V E L dot com, slash code.

This is the first of three episodes on vibe coding, which by now really means running coding agents on real codebases. This one is the map and the decision: what a coding agent actually is, how the four agents everyone asks about differ in philosophy, why open harnesses like pi and OpenCode exist, and where the open-weight models and the second tier fit. The next episode, Inside a Coding Agent, covers the mechanics: context, instruction files, hooks, skills, and the Model Context Protocol, MCP. The one after that, Agentic Software Engineering, covers how you actually ship with these things without shipping garbage. By the end of this one you should be able to pick a tool and defend the choice.

Let me start with where the phrase came from, because it has drifted a long way from what it originally meant.

In February of twenty twenty-five, Andrej Karpathy posted that there was a new kind of coding he called vibe coding, where you fully give in to the vibes, embrace exponentials, and forget that the code even exists. He said he hit accept all on everything, that he didn't read the diffs anymore, and that when he got an error he pasted it back in without comment. What people forget is the caveat in the same post: he said this was fine for throwaway weekend projects, and that it was mostly amusing. He was describing a mode of play, not a methodology. By November of that year Collins Dictionary had named vibe coding its word of the year, and by then the term meant anything from prototyping a landing page in a chat window to running a fleet of agents on a production monorepo.

Here's the arc, compressed to a minute. Autocomplete came first: a model suggesting the next line inside your editor. Then chat, where you pasted code in and pasted answers out. Then the agent: a model that can read your files, run your tests, edit, run them again, and keep going until it thinks it's done. Vibe coding named the moment when the agent got good enough that not reading the diff became tempting. What has happened since is that the working engineers who stayed with it stopped vibing and started engineering. The tools got serious, the failure modes got documented, and the interesting question moved from can it write code to how do I run these on something that matters. That shift, from vibe coding to agentic engineering, is the through line for all three episodes. This one is about the tools; the next two are about the discipline.

So that's the history. Now, what a coding agent is made of.

Hold one idea for the whole sequence: the model and the harness are two different things. The model is the neural network. It takes text in, produces text out, and it's good or bad at code in the way a person is good or bad at code. The harness is everything wrapped around it: the loop that calls the model, hands it tools, executes what it asks for, feeds the result back, and stops when the job is done. When you say Claude Code or Codex you're naming a harness plus a default model, and the two can be pulled apart. A great model in a bad harness will thrash. A mediocre model in a great harness can get surprisingly far. Most of the arguments you'll hear online about which tool is best are really arguments about one of those two things without noticing which.

Inside the harness there are five parts worth naming. First, the model, which we just covered. Second, the tools: read a file, write a file, run a shell command, search the codebase, fetch a web page, maybe drive a browser. The agent is only as capable as the actions it's allowed to take. Third, the permission model: which of those actions need your approval, which run automatically, and whether the whole thing runs inside a sandbox where the blast radius is bounded. Fourth, the context strategy: the model has a finite window, and a long task on a big repo will blow through it, so the harness has to decide what to keep, what to summarize, what to offload to files, and when to hand a subtask to a fresh agent with a clean window. Fifth, the surface: terminal, editor, desktop app, web page, chat message. Same engine, different chairs to sit in.

A concrete example makes the permission and context parts less abstract. Say you ask an agent to fix a failing test. It reads the test, reads the code under test, proposes an edit, and asks to run the test suite. The permission model decides whether that shell command runs on its own or waits for you; a sensible default is that reads are free, edits to files in the repo are free, and anything that touches the network or leaves the directory asks. Now the test suite prints four thousand lines of output. The context strategy decides whether all four thousand lines go into the window, or the harness truncates them, or it writes them to a file and hands the model the path. Twenty minutes into a session those decisions are the difference between an agent that still knows what it's doing and one that has forgotten the original task. That's why the harness matters as much as the model, and why the next episode is entirely about these knobs.

That framing gives you the questions to ask about any product. Which models can it run, and can I swap them? What tools does it have, and can I add my own? How does it ask permission, and can I run it in a box? What does it do when the context fills up? And where do I sit while it works? The next episode goes deep on the middle three. For today I want to use them to describe the four agents people ask about most, and I want to describe them as philosophies, because the feature lists converge within months and the philosophies don't.

Claude Code first, since it's the one I use most and the one the Gnothi show is built around.

Anthropic's own description is that Claude Code is composable and follows the Unix philosophy: pipe logs into it, run it in continuous integration, chain it with other tools. That sentence tells you the design center. It started as a terminal program, and even though it now has an editor extension, a desktop app, a web version and a mobile version, the documentation is explicit that all of those connect to the same underlying engine, so your instruction files, settings and tool servers work across every surface. The terminal isn't a legacy surface; it's the primary one, and the other surfaces are ways of looking at the same process.

What that philosophy buys you is scriptability. There's a headless mode, a print flag, where you hand it a prompt and it runs once with no interface and returns text, which means you can put it in a shell pipeline or a cron job or a GitHub Action the same way you would any other command-line tool. The team ships official integrations for GitHub Actions and GitLab pipelines, automated pull request review, a Slack integration, a Chrome integration, and a software development kit, the Claude Agent SDK, that lets you build your own agent on the same loop. If you're the kind of programmer who thinks in pipes and composition, this is the tool that thinks the way you do.

On models, as of this recording the defaults depend on your plan tier, with the Opus class as the default on the higher tiers and the Sonnet class on the lower ones, and Anthropic's Fable models above those for long, complex runs. There are one million token context variants, and the harness auto-compacts as the window fills. There's an effort dial that goes from low through high up to a maximum setting for hard problems. I'm deliberately not giving you version numbers, because they'll be wrong in six months; the shape to remember is that there are three or four tiers of model behind one harness and you choose based on how hard the task is and how much you want to spend.

Two mechanics belong here because they're Claude Code's answer to the context problem. Subagents: a lead agent coordinates, assigns subtasks to fresh agents with their own windows, and merges what comes back. And worktrees: each parallel session gets its own working directory and branch, so several agents can work on the same repo at once without stepping on each other. Both of those get a full treatment next episode. The plan shape is that it's included in the Claude subscriptions with rolling usage windows, or billed per token through the API, or run through the big cloud providers. Positioning in one sentence: a terminal-native, composable agent that treats itself as a Unix tool and wants to be embedded in your existing workflows rather than replace them.

The surface story deserves one more sentence because it changes how you work. You can start a session in the terminal, push it to the cloud when you need to close the laptop, pick it up from your phone to answer a question the agent asked, and pull it back down to the desktop app to review the diff side by side with another session. That's the same session the whole way through, not four products pretending to be one, and the reason it works is the composable core: every surface is a client of the same loop.

Now OpenAI Codex, which is the clearest contrast in philosophy.

Codex started as two separate things: an open-source command-line agent, and a cloud product inside ChatGPT where each task ran in its own sandboxed container preloaded with your repo. The question I had going into this was whether those had become one product, and as of this recording the answer is yes. One login across the CLI, the web, the editor extension, and a desktop app for Mac and Windows. And the handoff is explicit: there's a command to push the work you're doing locally into the cloud, where it runs in a configured environment, and then apply the result back to your machine. Cloud tasks can be started from the web, from GitHub or GitLab, from Linear, or from Slack.

The design center is delegation and parallelism. OpenAI's own framing is: run tasks in isolated cloud environments, work in parallel, compare multiple solution attempts. Where Claude Code's mental model is a very capable pair sitting in your terminal, Codex's is a pool of workers in the cloud that you dispatch to and collect from. You can absolutely use the Codex CLI interactively, and it's a good interactive agent. But the product wants you to hand off work and go do something else, and the sandboxing is what makes that safe: the cloud task can't touch anything but the repo and environment you gave it. The CLI is open source under Apache, which matters if you want to read how the loop works or fork it.

On models, the Codex-tuned models are trained specifically for long-running agentic work, and the newest generation's pitch on context is that instead of repeatedly compressing a session into one summary, the model keeps notes across context windows so accumulated detail survives. That's a model-side answer to the same problem Claude Code answers with subagents and compaction, and it's a nice illustration of the model-versus-harness idea: the same limitation attacked from opposite sides. The plan shape is that Codex usage is metered on the same ChatGPT plans as the chat product, with credits, and there's API access at API rates. There's also an Agents API that lets you bring the Codex harness into your own cloud agents with managed orchestration, which is the equivalent of the Claude Agent SDK.

Positioning in one sentence: an asynchronous agent that wants to run many sandboxed tasks in parallel and hand you back pull requests, with a local CLI as one of several entry points rather than the center.

Third, Google Antigravity, and this is one where my priors were wrong.

Antigravity launched in late twenty twenty-five as an agent-first IDE, an integrated development environment built around the agent, and the fair question with any Google product is whether it will still be called that a year later. This one is. And rather than being folded into something else, it absorbed something else: as of this recording, Google has retired the Gemini CLI into an Antigravity CLI, and Antigravity has grown into a platform with an IDE, a desktop app, a CLI and an SDK. So if you learned Gemini CLI, that lineage now lives here.

The philosophy is agent management. Google's language is that you manage higher-level tasks for the agent, not individual tool calls. There's an agent manager surface where you watch several agents work across your editor, your terminal and your browser, and a conventional editor view when you want to drop down and type. The distinguishing idea at launch was that the agent produces artifacts as it works: task lists, implementation plans, screenshots, recordings of it driving a browser, and you review those artifacts rather than reading every diff. The current product pages talk about rich visual feedback and artifact review without restating that exact taxonomy, so treat the itemized list as the original pitch. But the shape holds: verification through things the agent shows you, not just code.

The other thing worth knowing is that Antigravity is multi-vendor on models. The documented model list has several Gemini tiers, and alongside them Anthropic's Claude models and an open-weight OpenAI model. That's unusual for a first-party tool and it's a real argument for it: you get Google's harness and a choice of frontier models under it, at least on the consumer tiers; enterprise plans are Gemini only. The plan shape is a free tier plus paid tiers with usage windows, which is the same shape as everyone else.

Positioning in one sentence: an IDE built around supervising several agents at once, where you review what the agents show you, with a model menu that includes competitors.

Fourth, Grok, from xAI, which was my biggest unknown going in.

A year ago the answer was that xAI didn't have a coding agent; it had a fast, cheap coding model that you could run inside other people's harnesses: Cursor, Copilot, Cline, OpenCode, and so on. That has flipped. As of this recording xAI ships Grok Build, a first-party terminal coding agent, open source on GitHub, with an interactive interface, a headless mode for scripts, and support for running inside other editors through the Agent Client Protocol. The feature list reads like the category's checklist: plan, review and approve before it acts, hooks, plugins, MCP servers, and parallel subagents for big tasks. At the same time, the older fast coding model was deprecated out of GitHub Copilot. So the story went from model in someone else's harness to own harness on own models, which is the same direction Google went by retiring Gemini CLI. One footnote for the ear: xAI itself was folded into SpaceX earlier this year and rebranded, so you may hear a different corporate name attached to it.

The angle that makes Grok worth watching is speed and price. xAI's own positioning for its coding model is fastest and cheapest for agentic coding, served at very high tokens per second, and it says so explicitly. The premium model above it has a large context window and is what the agent defaults to. I couldn't find xAI benchmark numbers for the coding model on the pages I checked, so I won't quote any, and the claims circulating about exact subagent counts and monthly prices are from secondary blogs rather than xAI. A cheap, fast model in a competent harness is a real position in this market, because an enormous amount of agent work is mechanical, and the economics of running eight agents on a mechanical task are very different from running one on a hard one. Whether the harness is as good as the other three is a question I'd want to answer with a week of use, not a launch post.

Positioning in one sentence: a new open-source terminal agent whose bet is that speed and cost, not peak intelligence, decide the mechanical majority of agent work.

That's the headline four. Let me put them next to each other.

Claude Code is terminal-first and composable; it wants to be a Unix tool in your pipeline. Codex is cloud-first and parallel; it wants to be a worker pool you dispatch to. Antigravity is supervision-first; it wants to be the room where you watch several agents and review their artifacts. Grok Build is cost-first; it wants to be the fast cheap one. All four now have a CLI, a headless mode, subagents, hooks, and MCP support, so if you compare feature grids they look the same. They aren't the same, because the defaults and the surfaces push you toward different ways of working, and the way of working is what you're actually choosing.

There's also a practical point about switching. The instruction file convention has largely converged, the tool protocol has converged on MCP, and every one of these has a headless mode, so moving a project from one to another is a day of work, not a rewrite. What doesn't transfer is muscle memory and your accumulated hooks and skills, which is why people who have invested in one tend to stay. If you're new, that argues for picking based on the way of working you want rather than on this month's benchmark, because you'll live with the habits longer than with the model.

Now the reason harnesses exist as a separate category at all.

Every vendor harness ties you, softly or hard, to that vendor's models. If you want to use whatever model is best this month, or a cheap open-weight model for grunt work, or a local model for a private codebase, you want a harness that doesn't care who made the model. That's the pitch of pi and OpenCode, both open source, both very active, and both quite different from each other.

pi, at pi dot dev, is a toolkit before it's a product. Its slogan is adapt pi to your workflows, not the other way around, and the way it does that is by keeping the core deliberately small: a unified API across more than a dozen model providers, an agent loop, a terminal interface, and a set of extension points you write in TypeScript. You can run it interactively, in print mode for scripts, over remote procedure calls, or embed it as a library in your own program. Sessions are a tree you can branch and share. There's a package system for extensions, skills and prompts. And it ships with no built-in permission system. The README says so outright and points you at running it in a container instead, and the same author ships a small Linux micro-VM sandbox for exactly that. That's a strong opinion: instead of the harness deciding what's safe, you put the whole thing in a box and let it run. If you're a programmer who wants to compose your own agent from parts and understand every line of the loop, pi is the one.

OpenCode is a product. Terminal interface, web interface, desktop app, editor extension, and a provider list that runs to something like fifty entries: the big three, the cloud providers, the Chinese labs, local runtimes like Ollama and llama dot cpp, and the gateways. It has a permission and policy configuration, curated defaults, and an optional model gateway called Zen where the team has tested and verified a list of models and you can pay through them instead of juggling keys. One thing worth knowing if you were planning to use your Claude subscription through it: OpenCode's own docs say Anthropic prohibits driving subscription models through third-party harnesses, and the plugins that did that were removed from OpenCode a while back. So bring an API key, or a subscription from a lab that allows it. If pi is a kit of parts, OpenCode is the assembled car with the most dashboard options, and it's the default answer when someone says I want a Claude Code-like tool that runs on any model.

There are others in the open harness space and I'll give them a sentence each. Crush, from the Charm people who make the pretty terminal libraries, is a polished terminal-interface agent. Kilo Code and Cline are editor-extension-first agents that have both grown command-line and SDK forms. And DeepSeek now ships its own open harness, where everything is a plugin, which fits the trend I keep pointing at: everyone who has a model now has a harness.

One more thing the open harnesses give you that the vendor ones can't: you can read the loop. When an agent does something baffling, going into the source of the harness and finding the system prompt, the tool definitions and the compaction logic is a real debugging tool, and with pi or OpenCode that source is a clone away. The vendor CLIs are increasingly open too, Codex and Grok Build both publish theirs, but the system prompts and defaults that shape behavior are still theirs to change. If you want to own your agent's behavior the way you own your build system, open harness plus a model you can pin is the only configuration where that's fully true.

Which brings me to the models you'd put in one of these harnesses. This is the special mentions section, one or two sentences each, and I'm going to lean on what the vendors themselves say and flag it as such.

The Chinese open-weight labs are the reason the harness category matters economically. Qwen, from Alibaba, has a dedicated coder line, a current open series that the team describes as the first release of their top-tier model class as open weights, and its own command-line agent called Qwen Code, all under Apache. Z dot A I's GLM line is pitched, in their words, as the most capable open-weights model for coding, and they sell a coding plan subscription explicitly documented for use inside Claude Code, Cline and OpenCode. That's the clearest example of the model-versus-harness split turned into a business model: their model, someone else's harness, and now also their own agent.

DeepSeek serves its current models with a one million token context and, importantly, an Anthropic-format API endpoint, which means Claude-shaped harnesses can point at it with a URL change. Moonshot's Kimi has a very large open-weight multimodal model under its own bespoke license, not a standard open-source one, plus its own command-line coding agent.

Do any of these deserve headline status rather than a mention? As of this recording, none of them has the harness momentum of the four, and none is the default in a major product, but every one of them claims near-frontier coding results on the newer agentic benchmarks. The benchmark names have shifted, too: the vendors now headline things like SWE-bench Pro and Terminal Bench rather than the older SWE-bench Verified. Treat every number as self-reported, and treat the price gap as real.

The rest of the second tier, one sentence each. GitHub Copilot's coding agent is a cloud agent that takes an issue, plans, and pushes a branch from inside GitHub Actions, and it's the right answer if your team lives in GitHub and wants agents with no new tooling. Cursor is still the editor-first choice and is moving fast toward the same shape as everyone else, with cloud agents, subagents, and a coordinator that plans and delegates. Windsurf has been folded into Cognition's Devin brand after the acquisition, so evaluate it as Devin. Cline is active as an extension, CLI and SDK. Aider, the open-source pioneer that a lot of people started on, hasn't had a commit in several months as of this recording; it isn't archived, but I wouldn't start there today. And Gemini CLI, as I said, is now Antigravity CLI.

So that's the field. Let me close with the decision rule, because the point of all this was that you could pick one and defend it.

Decide by your binding constraint, not by the feature grid. If your constraint is the lab you already pay, meaning your team uses their chat product and you're already on their plan, take that lab's agent: Claude Code, Codex, or Antigravity, and stop shopping. If your constraint is cloud versus local, and you need parallel sandboxed work with pull requests coming back, Codex's cloud or Copilot's coding agent is the shape you want; if you need everything on your machine or behind your firewall, a harness plus a local or self-hosted model. If your constraint is cost, and most of the work is mechanical, look at Grok Build or an open harness with a cheap open-weight model behind it. If your constraint is open weights, for privacy, for control, or for principle, it's pi or OpenCode with Qwen, GLM, DeepSeek or Kimi, and you accept that you're doing more of the integration yourself.

Two rules that cut across all of those. First, run a real task before deciding, not a demo: take a bug from your own tracker that you already know the answer to and watch the agent work it, because how it reads the codebase and how it recovers from a wrong turn tells you more than any launch video. Second, budget for a second tool. Most developers who do this seriously run a primary agent for the hard interactive work and a cheaper one for the mechanical, dispatchable work, and that combination is where the cost and quality both land in the right place. The vendors know this, which is why every one of them now sells a cheap fast tier alongside the smart one. And whichever you pick, learn the harness mechanics, because those transfer between tools far better than any vendor loyalty does.

To recap. Vibe coding named a moment; agentic engineering is where the people who stayed ended up. A coding agent is a model plus a harness, and the harness is the loop, the tools, the permission model, the context strategy and the surface. Claude Code is the composable terminal tool. Codex is the parallel cloud worker pool. Antigravity is the agent manager that shows you artifacts and lets you pick a competitor's model. Grok Build is the new cheap fast one. pi and OpenCode are the open, model-agnostic harnesses, one a toolkit and one a product, and the open-weight coder models from Qwen, GLM, DeepSeek and Kimi are what you put in them. Choose by your binding constraint.

Next episode is Inside a Coding Agent, where we open the harness up: context and compaction, instruction files, hooks, skills, MCP, permissions and subagents, with Claude Code as the running example and Codex and OpenCode mapped alongside.