Claude Sonnet 5 landed this week, June 30, 2026, as the new default on Claude Free and Pro and the new occupant of the middle tier: Haiku below it, Opus 4.8 above, Fable 5 and Mythos 5 at the top. The pitch from Anthropic is the one practitioners care about — Opus-adjacent capability at Sonnet economics, aimed squarely at high-volume agent loops where Opus pricing compounds fast. One wrinkle sharpens the switch decision. Fable 5 is back in Claude Code, redeployed the morning after Sonnet shipped, which puts the top of the lineup back in reach and moves the ceiling any switch has to weigh against.

Two things matter more than the headline. First, the architecture shift: extended thinking is gone, replaced by adaptive thinking that runs on by default and interleaves reasoning between tool calls. The effort parameter now defaults to high in both the Claude API and Claude Code. Second, the pricing has a catch the announcement does not foreground. The list price looks flat against Sonnet 4.6. The new tokenizer means your invoice may not be.

If you drive coding agents for a living, this is the model you will be pointing your harness at by default. The question is whether to switch today[1], reach past it, or wait two weeks and measure.

TL;DR

• New default everywhere. Sonnet 5 is the default model on Free and Pro at launch. API ID claude-sonnet-5, Bedrock anthropic.claude-sonnet-5, Vertex coming soon.

• Extended thinking removed; adaptive thinking is always on. Manual thinking: {type: "enabled", budget_tokens: N} now returns a 400 error. Depth is set by effort (low, medium, high, xhigh, max; high by default on the API and in Claude Code), and the model reasons between tool calls without prompt engineering — the architecturally significant change for agentic work.

• 1M context, 128k output, January 2026 cutoff. Repo-level reasoning at Sonnet pricing.

• Agentic coding 63.2%, per Anthropic’s comparison chart, versus 58.1% for Sonnet 4.6 and 69.2% for Opus 4.8. Likely SWE-bench Pro, not Verified — and no Verified score is published yet.

• Pricing looks flat, isn’t quite. $2/$10 per MTok intro through August 31, then $3/$15 — same list price as Sonnet 4.6. But the new tokenizer generates 1.0–1.35x more tokens for the same text, so “same price” is misleading at the invoice level.

• Fable 5 is back in Claude Code (July 1) as the practical ceiling above Opus — priced higher, with a retrained safety classifier that reroutes offensive-cyber work down to Opus 4.8. Details below.

What Anthropic shipped

Sonnet 5 sits in the workhorse slot of the lineup. Haiku 4.5 at $1/$5 handles cheap high-volume work. Opus 4.8 at $5/$25 is the heavy lifter. Fable 5 and Mythos 5 sit above Opus, both dark at Sonnet 5’s launch, though Fable returned to Claude Code on July 1 (more below). Sonnet is the tier you point at the bulk of your agent traffic, and the one whose economics decide whether a coding-agent product is viable.

The specs are current-generation and unsurprising on paper: 1,000,000-token context window, 128,000 max output tokens (300,000 on the Batch API with the beta header), text and image input, January 2026 knowledge cutoff. Anthropic calls it “the most agentic Sonnet model yet,” which is marketing, but the architecture underneath the phrase is the actual story.

Extended thinking is gone. If your code sends thinking: {type: "enabled", budget_tokens: N}, Sonnet 5 returns a 400 error. That is a breaking change for any harness that sets thinking budgets explicitly. Grep your codebase for it before you flip the model ID. In its place is adaptive thinking: always on, with depth allocated dynamically by the model and steered through the effort parameter — low, medium, high, xhigh, or max. The default is high on both the API and Claude Code, with xhigh available above it for the hardest coding and agentic tasks.

The piece that matters for agents is that adaptive thinking automatically enables interleaved thinking. The model reasons between tool calls. It reflects on what a tool returned before deciding the next action, and it does this without you wiring up a scratchpad or a reflection prompt. For anyone who has built an agent loop by hand, that is the part you used to engineer yourself, now folded into the default behavior of the model.

About that benchmark number

Anthropic’s launch chart gives an agentic coding comparison:

Model Agentic coding score Claude Sonnet 4.6 58.1% Claude Sonnet 5 63.2% Claude Opus 4.8 69.2%

Source: Anthropic’s comparison chart, via TechCrunch. Now the caveats, because this is where launch-day coverage tends to get sloppy.

That 63.2% is almost certainly SWE-bench Pro — the harder multi-file agentic eval — not SWE-bench Verified. The two are not interchangeable, and the numbers live on different scales. The Opus 4.8 figure in the same chart (69.2%) matches its published SWE-bench Pro score, which supports the Pro read. Anthropic has not published a standalone SWE-bench Verified number for Sonnet 5. The comparison chart is an image, with no underlying table released at launch.

So here is the trap. If you go looking, you will find a 82.1% SWE-bench figure attached to “Claude Sonnet 5.” Do not use it. That number comes from February 2026 pre-launch speculation about a different model iteration — a phantom Sonnet 5 with a “Dev Team Mode” that never shipped in the form described. The model that launched today has different characteristics. Any spec sheet dated before June 30 is describing something else.

What can you say with confidence? Sonnet 5 sits meaningfully above Sonnet 4.6 on agentic coding and a few points below Opus 4.8. For reference, the most recent third-party leaderboard before launch had Sonnet 4.6 at 79.6% SWE-bench Verified and Opus 4.8 at 88.6%. A reasonable expectation puts Sonnet 5’s Verified score somewhere in the low-to-mid 80s — but that is my read of where the gap lands, not a number Anthropic has confirmed. Treat it as judgment, not data.

On the safety side, Anthropic reports lower hallucination and sycophancy rates than Sonnet 4.6, better refusal of malicious requests, and stronger resistance to prompt injection. By design, it also carries intentionally weaker cybersecurity exploit capability than Opus 4.8.

Pricing and the tokenizer tax

The list price is the easy part:

Model Input $/MTok Output $/MTok Claude Haiku 4.5 $1.00 $5.00 Sonnet 5 (intro, through Aug 31) $2.00 $10.00 Claude Sonnet 4.6 $3.00 $15.00 Sonnet 5 (standard, from Sep 1) $3.00 $15.00 Claude Opus 4.8 $5.00 $25.00

At standard rates, Sonnet 5 carries the identical list price to Sonnet 4.6: $3/$15. Through August 31 you get an introductory $2/$10. Read quickly, that says “same price, free discount for two months.” Read the footnote and it says something else.

Sonnet 5 uses the same tokenizer as Opus 4.7, which encodes the same text into roughly 1.0–1.35x more tokens than pre-Opus-4.7 models, depending on content type. List price is per token. So at the standard September rate, identical workloads can cost up to 35% more than they did on Sonnet 4.6 — same sticker, more tokens on the meter. The introductory pricing is doing real work here: the 33% input discount roughly offsets the tokenizer inflation through the end of August, which is almost certainly the point. Come September 1, the offset disappears and the effective increase shows up on the invoice.

The practical move is dull and necessary. Run a representative slice of your actual workload through Sonnet 5 and measure token consumption directly. Do not assume cost neutrality from the matching list price. The teams that got burned on the 4.6-to-4.7 transition were the ones who read the sticker and skipped the meter.

Where it sits in the market

The framing that fits the launch is that the workhorse-tier fight has moved off “which model is smartest” and onto “how cheaply and reliably does it run without a human watching.” That is the right frame for anyone shipping coding agents, where margin lives or dies on the per-task cost of the driver model.

Anthropic positions Sonnet 5 as cheaper than OpenAI’s GPT-5.5 and Google’s Gemini 3.1 Pro at introductory rates, and more expensive than Gemini 3.5 Flash, which holds the budget slot. I’d treat the competitor pricing as directional rather than precise — those comparisons come from launch coverage, not from cross-checked primary pricing pages, and competitor list prices move. The shape is more reliable than the digits: Sonnet 5 is priced to undercut the premium workhorses and to sit above the bargain tier, which is exactly where Anthropic wants the default coding driver to land.

The use case Anthropic names is the one this audience will actually hit: high-volume agent loops where Opus pricing compounds. CI review bots. Test generation. Batch transforms. Multi-step autonomous workflows that run for a while without supervision. Daniel Shepard at Zapier told TechCrunch that a two-part automation which “used to stall halfway” now finishes end to end. A single data point, and a vendor-friendly one, but it points at the right capability: completion of long autonomous chains, not raw single-shot smarts.

What this means for agentic coding

The interesting architecture is the harness story. Default-high effort plus interleaved reasoning means the model arrives already configured for the agent pattern most teams hand-build: think, act, observe the result, reflect, act again. You do not prompt-engineer your way to a reflective agent anymore. It is the out-of-box behavior. For harness authors, that shifts the work — less coaxing the model into reasoning between steps, more managing the effort dial so a 12-file rename does not quietly run at high and burn tokens it never needed.

Watch that dial. effort defaults to high, and high effort spends more tokens than the job often warrants. The same lesson from the Opus 4.8 cycle applies: the cost surprises come from leaving the reasoning budget maxed on work that did not need it. Drop to medium or low for mechanical tasks. Reserve high for the hard ones.

And the 1M context window at Sonnet pricing is the underrated piece. Repo-level reasoning — cross-file refactors, full-codebase audits — without chunking, on the model you were already going to run for volume.

The ceiling moved: Fable 5 is back

Then there is the ceiling, and in the days around this launch it moved. The most capable public Claude model most teams could actually run was Opus 4.8, at roughly 88.6% SWE-bench Verified on the Morph leaderboard. Fable 5 sits higher on that same board, in the mid-90s, though that figure is a third-party read and Anthropic has published no Verified score of its own. What moved here was less capability than access: at Sonnet 5’s June 30 launch, Fable was dark. Anthropic had suspended Fable 5 and Mythos 5 on June 12 to comply with a U.S. export-control order, and with no way to verify user nationality in real time, it pulled both models for all users.

That reversed a day later. On June 30 the Commerce Department lifted the order, and on July 1 Anthropic redeployed Fable 5 globally across the Claude Platform, Claude.ai, Claude Code, and Cowork. As I write this, my Claude Code /model picker offers Fable 5, and I’ve set it as my default for new sessions. So the practical ceiling is no longer Opus. It is Fable — with two asterisks.

The first is access and price. Through July 7, Fable 5 counts against up to 50% of weekly usage limits on Pro, Max, Team, and select Enterprise plans; after that it shifts to usage credits, and cloud-provider access on AWS, Google Cloud, and Microsoft Foundry is still being re-enabled in phases. Per token it prices well above the Opus tier: Anthropic’s model docs list it at $10/$50 per MTok, double Opus 4.8’s $5/$25, and the new tokenizer encodes the same text into more tokens again, so the effective gap is wider than the sticker. This is not the model you point at bulk agent traffic. It is the one you reach for on the problems that stall everything below it.

The second asterisk is the reason it came back at all, and it lands squarely in coding work. The suspension traced to a report from Amazon researchers who found a prompt that got Fable 5 to identify software vulnerabilities and start describing how one could be exploited, before its guardrails blocked the attempt from reaching a working exploit. Anthropic’s fix was not to weaken the model but to retrain the safety classifier sitting in front of it, and the new one blocks that specific technique in more than 99% of cases. When the classifier fires, the request doesn’t error. It reroutes to Opus 4.8 in the same session, re-run and labeled with the model that actually answered. The documented trigger categories are offensive cybersecurity work (building exploits, malware, or attack tooling), plus most biology and chemistry, distillation attacks on Fable itself, and frontier-model development.

Here is where it gets concrete. Ask Fable 5 to write exploit code against a security vulnerability and you can watch it hand the task down to Opus 4.8 mid-session, a quieter, older model finishing what the newer one declined. For defensive security work that reversion is a real cost, not a hypothetical. Anthropic is candid that the tighter cyber filter routes more benign coding and debugging requests to Opus than teams would like, and developers have already reported the classifier over-firing on routine defensive-security work, auto-switching to Opus on tasks like CVE triage. The billing follows the block: a request stopped on input is charged at Opus rates; one stopped midstream bills Fable rates for the tokens already produced, then Opus for the rest.

Should you switch your default driver?

For most coding-agent work, yes — but measure first, and mind the calendar.

Switch now if you are running Opus 4.8 on tasks that do not strictly need it. The capability floor rose; a real share of Opus traffic will run acceptably on Sonnet 5 at a meaningful discount, and the intro pricing through August 31 makes the test cheap. This is the clearest win in the release.

Switch now, with care if you are upgrading from Sonnet 4.6. You get better agentic coding, interleaved reasoning by default, lower hallucination and sycophancy. But grep for explicit thinking budgets first — they will 400 — and run your token measurement before September 1, when the tokenizer tax stops being masked by the intro discount.

Wait, or stay put if you are on Priority Tier with Sonnet 4.6 — it is not available on Sonnet 5 at launch, so the choice is staying on 4.6 or jumping to Opus 4.8. And if your cost model is tight and unmeasured, the matching list price is a trap; spend the two weeks measuring before you commit budget to it.

There is now a fourth move the launch-day framing didn’t include: reach past Sonnet entirely. With Fable 5 back in Claude Code as of July 1, the hardest problems that Sonnet 5 and even Opus 4.8 stall on have a home again, at a price that keeps it off your bulk traffic and with a security governor that bounces exploit work down to Opus. For volume, Sonnet 5 is the driver. For the few tasks that justify the top of the lineup, the top of the lineup is reachable again.

Anthropic built Sonnet 5 to be the default driver model for the agent era, and on the architecture, it earns the slot. Adaptive thinking with interleaved reasoning is the correct shape for a coding agent, and shipping it as the default behavior removes work that harness authors used to do by hand. The asterisk is the invoice. The list price tells you one thing; the tokenizer tells you another. For the next two months, the introductory rate hides the difference. After that, the teams that measured will know what they are paying for, and the teams that read the sticker will get a surprise in their September bill.

Bob Matsuoka is CTO of Duetto and also writes about AI business at AI Power Ranking.

Related reading:

• I Tracked Every Token — What a $1.07 bug fix reveals about AI coding economics, and why per-token pricing hides the real bill.

• The Agent Unlock: Why Opus 4.5 Changed How I Work — When a top-tier model crossed the line into autonomous coding that holds up under real work.

• Breaking: Opus 4.6 and Agent Teams — A model release read for what it changes in day-to-day agent workflows, not just the benchmark chart.

• AI Power Ranking — Tool comparisons and benchmarks for AI practitioners

• LinkedIn Newsletter — Strategic AI insights for CTOs and engineering leaders

[1]: Complicating “today”: with Fable 5 back as a Claude Code option (and, for some of us, the new default for hard sessions), the switch question isn’t only Sonnet-5-or-not. It’s which tier each task belongs to, Fable included. See “The ceiling moved: Fable 5 is back” below.

This is Part 3 of a three-part read on the Fire Horse year in AI coding, the payoff the whole series was building toward. Parts 1 and 2 walked twelve coding models across the twelve animals of the zodiac and two hemispheres — the Chinese front-runners and the $60 billion SpaceX-buys-Cursor deal in Part 1, the Western incumbents and the collapse of the Western open flank in Part 2. Now the question all of it was built around: who controls the inference, what they do with your prompts, and whether the answer can change without your consent.

TL;DR

• The community read is convergence with a ceiling — and the real endorsement is behavioral: Chinese models reached ~61% of top-10 token consumption on OpenRouter in one February week, with DeepSeek alone near 17.6%.

• For enterprise, the practical data-safety ranking is: self-host > AWS Bedrock / Azure AI Foundry > US inference hosts > OpenRouter ZDR > direct Chinese API.

• China’s National Intelligence Law means a written no-train promise from a China-domiciled vendor is not a clean answer for regulated work, whatever the privacy policy says.

• CrowdStrike measured DeepSeek-R1 producing insecure code at a ~50% higher rate on politically sensitive prompts — and the bias persisted when running the open weights locally. Self-hosting is not the escape hatch you assume.

• Provenance was a proxy. The DeepSeek risk and the SpaceX-Cursor risk are the same underlying exposure, and the Cursor deal makes the flag-over-the-lab heuristic useless.

What developers are actually saying

Cut through the benchmarks and the community lands on one sentence: convergence with a ceiling.

The gap has collapsed for the bulk of coding work. For autocomplete, summarization, refactoring known code, and the high-volume long tail, Chinese open-weight models are competitive and dramatically cheaper. Where they still lose is the hardest agentic, multi-file, novel-algorithm work — the jobs where finishing is the whole point. Every hands-on test in my research told the same story from a different angle, and the animal sections in Parts 1 and 2 carry the specifics: Kimi’s “could not put it all together,” Flash’s confusion off-script, the Dog that finished when the Monkey could not.

Two things stand out about the endorsements. No prominent named engineer — no Karpathy, no Willison — has publicly endorsed a Chinese model for production coding; the praise is essentially all pseudonymous Hacker News handles. But the real endorsement is behavioral. On OpenRouter, Chinese models reached roughly 61% of token consumption among the top-10 models in one week this past February (around 45–51% of platform-wide tokens by April), with DeepSeek alone at about 17.6% top-10 share — reportedly exceeding Google and OpenAI combined in one snapshot. One caveat on the volume story: the Chinese models dominate tokens, not revenue. Anthropic accounts for roughly 12% of OpenRouter tokens but about 46% of its revenue, which is the cheap-volume-versus-paid-difficulty split showing up in the billing. Developers are voting with their tokens even when they will not put their name on a blog post.

The behavior that dominates is routing. Use the cheap or local model for the long tail; escalate to Claude or GPT for high-stakes correctness and novel work. That is not a compromise people settled for. It is the rational architecture, and it is what most serious teams already run.

The enterprise question

Here the conversation stops being about capability and starts being about who can read your prompts. The three Chinese vendors are not equivalent, and the differences are material.

DeepSeek is the hard case. Its terms of service permit training on user-submitted data by default. There is no zero-data-retention option. Data is processed in China. No SOC 2, no HIPAA BAA. Its own privacy policy describes collecting prompts, chat history, uploaded files, voice, device and OS details, IP, device identifiers, crash logs, and — the line that stops procurement officers cold — “keystroke patterns or rhythms,” stored on “secure servers located in the People’s Republic of China,” retained “as long as needed,” which analysts read as indefinite.

Moonshot (Kimi) is better but not clean. Its policy permits using API content to “develop and improve the services” — no ZDR — though it hosts in Singapore. Singapore residency is a real improvement over data-in-China, but Moonshot’s core operations are Beijing-based, which matters for the legal point below.

Alibaba (Qwen) has the strongest commitment of the three. Alibaba Cloud Model Studio states explicitly that it “will never use your data for model training,” offers multiple regions including US and EU, and Alibaba carries institutional accountability the others lack — Hong Kong-listed, with an international regulatory track record.

The caveat that overrides all three privacy policies is China’s National Intelligence Law, which requires Chinese companies to “support, assist and cooperate” with state intelligence work regardless of what their terms say. A written no-train commitment from a China-domiciled vendor is subject to that law. For regulated industries, the only clean answers are self-hosting open weights or routing through Western-managed infrastructure where the inference never touches a Chinese-operated service.

Which gives a practical ranking. From safest to least:

1. Self-host the open weights. Bedrock, vLLM, Ollama, your own GPUs. The weights are open; the inference is yours. (One asterisk, in the security section below.)

2. AWS Bedrock or Azure AI Foundry. DeepSeek and Qwen run in the provider’s environment, data stays in your selected region, no interaction with Chinese-operated services. AWS contractually guarantees no training on your data; Azure runs Qwen in your tenancy.

3. US inference hosts. Together AI, Fireworks AI, DeepInfra run the open weights on US infrastructure.

4. OpenRouter with ZDR. OpenRouter supports zero-data-retention per-account, per-key, or per-request ("zdr": true), but does not enumerate which specific Chinese-model endpoints honor it, and the National Intelligence Law caveat still applies upstream.

5. Direct Chinese API. Convenient, cheapest to wire up, and the option you cannot defend in a regulated procurement review.

“It’s complicated” is a non-answer. The ranking is the answer.

A cautionary security finding

One result deserves its own section because it survives self-hosting, which most people assume is the escape hatch.

CrowdStrike tested DeepSeek-R1 and found it produced insecure code at a higher rate on politically sensitive prompts. The baseline vulnerable-code rate was about 19%; it rose to roughly 27% when prompts contained CCP-sensitive terms — a relative increase of about 50% off that baseline, not a 50-point jump. CrowdStrike frames this as emergent misalignment, not a deliberate backdoor, so read it as a behavioral artifact rather than intent. The operational detail: the bias persisted when running the open weights locally. Self-hosting does not fix alignment baked into the weights. You can air-gap the model and the bias rides along.

Booz Allen found a related pattern: three of four Chinese models produced more security flaws when the user was described as US government, with Qwen3-Coder adding roughly 130% more vulnerabilities under a government persona. The authors stop short of alleging deliberate backdoors, and you should too — the mechanism is unproven. But the measured effect is real.

The counterpoint keeps this from being a blanket indictment. In one test, Kimi K2.5 posted the lowest aggregate vulnerability score of the group, below the US comparison model. The Monkey’s brilliance shows here too. The concern is not uniform. It is model-specific, prompt-specific, and measurable — which means it is something you test for, not something you assume.

For completeness on the public record: South Korea’s PIPC found in April 2025 that DeepSeek transferred user prompts and device data to a ByteDance-affiliated cloud without consent. Wiz found a publicly exposed, unauthenticated DeepSeek database in January 2025 leaking over a million log lines including chat history and API keys (secured quickly after disclosure). Government-device bans exist in Italy, Australia, Taiwan, South Korea, the Netherlands, the Czech Republic, Germany, India, and roughly 17 US states. But note what does not exist: a nationwide US API ban. “DeepSeek is banned in the US” overstates the situation. The Congressional pressure is real — the House Select Committee sent formal letters to Airbnb and Cursor in April 2025 over Chinese-model data concerns — but it is pressure, not prohibition.

The flag was never the variable

Now back to the governance question, with the whole zodiac in hand.

Every concern in the enterprise section comes down to control of the model layer. Who controls inference. What they do with your prompts. Whether a no-train promise is durable. Whether the governance can change without your consent. None of it is intrinsically about China — China is the jurisdiction where the control question has the sharpest legal teeth, because of the National Intelligence Law.

The Cursor acquisition raises the same question from the other direction. Read the enterprise objection to DeepSeek and the enterprise objection to a SpaceX-owned Cursor side by side and they rhyme. Both are: a single owner now controls the layer that sees all your code, the no-train and retention guarantees can be revised by that owner, and you have limited visibility into what happens upstream. The DeepSeek version has a foreign-intelligence-law wrapper. The Cursor version has a change-of-control wrapper. The underlying exposure — your IP flowing through infrastructure you do not control, governed by terms the owner can change — is the same exposure. Beijing on one side, Boca Chica on the other. That is where Sanchit Vir Gogia’s line from Part 1, Cursor sitting “close to the intellectual-property bloodstream,” stops being an analyst soundbite and becomes the whole argument.

That symmetry is what the zodiac quietly demonstrated. A Chinese frame walked through twelve animals and landed on Anthropic, OpenAI, Google, Meta, and Mistral as readily as on Moonshot, DeepSeek, Alibaba, and Zhipu. The frame fit the whole field because the flag over the lab was never the real variable. Provenance was a proxy for the question that matters — who controls the inference and what they are permitted to do with it — and the Cursor deal makes that proxy useless. You can no longer reason about model risk by asking which flag flies over the lab.

Practical routing guide

Strip out the geopolitics and a workable default emerges. This is roughly how I would set up a team today, animals included where they help. (The capability and access details behind each label live in Parts 1 and 2.)

The long tail — autocomplete, summarization, classification, tagging, structured extraction, refactoring code you already understand. This is 80–90% of volume, and it belongs to the Rabbit and the Rat. Use the cheapest capable model. Gemini 3 Flash if you are already in Google’s ecosystem. A self-hosted Qwen or Kimi if cost and data residency both matter. Gemma locally for pure structured-text utility, Gemma 3n on the edge, Codestral for fill-in-the-middle tab completion. The quality difference against a frontier model on this work is hard to detect, and the cost difference is 5–20x.

Routine multi-file work in a known codebase. Composer 2.5 as Cursor’s default — the Snake — or DeepSeek V4 / Kimi K2.6 through a vetted inference path. Cheap, capable, fine when the task stays on the rails.

High-stakes correctness, novel algorithms, off-script agentic work, deep architecture. This is the Dog and the Tiger. Claude Opus or GPT-5.5. This is where “Kimi just could not put it all together” and “Flash gets confused when a task goes off-script” stop being quotes and start being your Tuesday. Pay for the model that finishes.

Regulated or IP-sensitive work. Ignore the leaderboard and start from the data-safety ranking above. Self-hosted weights or Bedrock/Azure first; provenance second. If EU residency is the binding constraint, the Rat’s sovereignty pitch (Mistral on-prem, EU-only) is the one place provenance actually buys you something — though weigh it against a free self-hosted Qwen. And run the CrowdStrike test yourself — generate security-relevant code with and without sensitive context and diff the output before you trust any model in this tier, Chinese or otherwise.

The meta-point: the right answer is almost never one model. It is a routing policy. The teams getting real value here are not picking a winner. They are matching each class of task to the cheapest model that clears the bar for that task, and escalating only when the work demands it.

Where this leaves us

A Fire Horse year is supposed to be bold and unruly, and the field obliged. The Chinese models have largely arrived in the high-volume, low-stakes parts of your workflow — cheaper, open, and good enough that you would struggle to tell the difference. On the hardest work, the Western frontier still holds a real lead, and the cost of getting that work wrong is exactly where the price premium earns out. The clearest casualty of the year is the Western open-weight story: Meta and Mistral built the movement and got passed on code, and the open coding lead now sits with the Chinese labs.

But the durable lesson of this year is not about China. It is that the model layer inside your IDE is a governance surface, and ownership of that surface is now in motion — a $60 billion acquisition on one side, a foreign-intelligence statute on the other, and the same question underneath both. Where does my code go, and who can read it, and can the answer change without my consent? The zodiac was a device, but it made the point cleanly enough: twelve animals, two hemispheres, one set of questions. Provenance was the comfortable proxy. After this year, the proxy is gone. You have to ask the real question now, and you have to ask it of everyone — including the editor you have trusted by default.

Bob Matsuoka is CTO of Duetto and writes about AI-powered engineering at HyperDev.

Related reading:

• AI Power Ranking — Tool comparisons and benchmarks for AI practitioners

• LinkedIn Newsletter — Strategic AI insights for CTOs and engineering leaders

This is Part 2 of a three-part read on the Fire Horse year in AI coding. Part 1 set up the conceit — twelve coding models mapped to the twelve animals of the Chinese zodiac, in a year (丙午, the once-in-sixty Fire Horse) that earned its reputation for upheaval — and walked through the Chinese front-runners and the $60 billion SpaceX-buys-Cursor deal that reframed the whole field. (See Part 1 for the benchmark caveats; every version number and vendor-versus-independent distinction below assumes that three-question rule.)

This part is the Western field, and it carries its own argument. The Western frontier still leads the hardest work, the off-script agentic jobs where finishing is the whole point. But the Western open-weight story collapsed. Meta and Mistral built the open movement, and both got outrun on code by the Chinese open models. The open coding lead crossed an ocean, and that is the thread this part follows to its end.

TL;DR

• The Western frontier still leads the hardest agentic work, and on that tier the price premium earns out — the Sharda “$200 beat the $30” verdict lands here.

• Gemini 3 Flash dethroned its own bigger sibling on coding (78% vs 76.2% SWE-bench Verified). The “cheap weak Flash” framing is obsolete; watch the citation error that attributes the 78% to the old 2.5 Flash.

• Gemma 4 jumped roughly 3x on coding in one generation (LiveCodeBench v6 80.0% vs Gemma 3 27B’s 29.1%), and Gemma 3n runs multimodal in 2–3GB on the edge.

• Llama stalled — stale lineup, a closed pivot (Muse Spark), 15.6% Aider against ~5x-higher Chinese open models, and Yann LeCun saying the Llama 4 results “were fudged a little bit.”

• Mistral sells sovereignty more than raw capability now, and the EU-data edge is narrowing. Set Llama and Mistral side by side and the open coding lead has crossed an ocean.

The animals that hold the line

The order here runs roughly down a visibility-and-strength gradient: the frontier reasoners first, then the local family, then the two foundational Western open-weight players that built the movement and got passed.

Dog — Claude (Anthropic)

The dog is loyal, faithful, and protective, the one that finishes the job and guards the gate. Claude Opus is the model developers reach for when correctness matters and the one that holds the line on guardrails. Repeatedly in the research, it is also the one that finished.

The capability story is about consistency under pressure. DataScienceDojo ran Kimi K2.6 against Claude Sonnet 4.6 and found Kimi capable but Claude more consistent — Claude added a DELETE endpoint nobody asked for, flagged a Redis warning, and applied type-level validation unprompted. Composio’s harder test landed on the line Part 1 first quoted from the Monkey’s side: “Opus was expensive, but it finished. Kimi just could not put it all together once the task got real.”

And the GLM thread from Part 1 closes here, on the economics. Ashish Sharda’s much-quoted “I Tested GLM-4.6 for 2 Weeks and Went Back to Claude” landed on the argument against pure cost optimization: “The $200/month AI model beat the $30/month alternative. Sometimes expensive is worth it.” That was an older GLM, and the framing has aged — GLM-5.2 now posts the top open-weight index score in the field and sits #2 on Code Arena, so the cheaper model is no longer a lightweight you outgrow. The point that survives is narrower and still holds: on the hardest agentic work, Opus is the one that finishes, and the developers pairing GLM for volume with Claude for the hard problems are routing to exactly that tier. The dog is expensive to keep. It also guards the thing you cannot afford to lose.

Tiger — GPT (OpenAI)

The tiger is bold, fierce, and competitive, a predator that leads from the front. GPT-5.5 leads the field on terminal work, topping Terminal-Bench 2.0 by 13 points.

The tiger does not appear much in the open-weight cost debate because it is not playing that game. Its claim is one hard surface: the command line, where an agent has to chain real operations against a real environment and not lose the thread. Cursor’s routing guidance sends shell-heavy terminal work to GPT-5.5 for exactly this reason. On its territory, it leads.

Rooster — Gemini (Google)

The rooster is showy, observant, punctual, and loud at dawn. The whole Gemini family struts in fast and crowing, and the loudest crow is internal: the lean Gemini 3 Flash dethroned its own bigger sibling, Gemini 3 Pro, on coding. The framing most people carry for Flash is obsolete. “The cheap, weak sibling” stopped being true at the end of last year.

Gemini 3 Flash shipped December 17, 2025, and beat Gemini 3 Pro on coding: 78% SWE-bench Verified for Flash against 76.2% for Pro. The smaller, cheaper model won. That 78% figure is the source of a common citation error — people attribute it to Gemini 2.5 Flash, which is the previous generation. The number belongs to the 3 Flash family. If you see “Flash beats Pro at 78%,” confirm which Flash before you repeat it.

The current Flash earns the upset. Gemini 3 Flash runs roughly 4x cheaper than 3 Pro (around $0.50/M input), about 3x faster (218 tokens/sec), scores 90.4% on GPQA Diamond, and Cursor, Cline, JetBrains AI, and Gemini CLI adopted it immediately. The latest, Gemini 3.5 Flash, beats Gemini 3.1 Pro on Terminal-Bench 2.1 at 76.2% and is described as Google’s strongest agentic model.

None of which retires Pro. The developer consensus is hybrid routing, not replacement. Flash handles 80–90% of the work — summarization, classification, tagging, structured pipelines, autocomplete — indistinguishably from Pro. Pro still earns its keep on architectural reasoning, complex multi-file refactors, novel algorithms, and the off-script agentic tasks where, as one developer put it, “Flash gets confused when a task goes off-script.” Cursor’s routing still sends deep-architecture and long-context work to the heavyweight reasoning tier, and Pro is the Gemini family’s answer there. The rooster reasons deep in one body and runs fast in the other, and that “off-script” line could be the epigraph for this entire field.

Rabbit — Gemma (Google’s open-weight family)

The rabbit is gentle, quiet, and home-bound, and Gemma is Google’s open-weight family — the calm local helpers that never pretended to be frontier coders, then quietly got 3x better at code in one generation. The Gemma arc runs across three things: the workhorse, the leap, and the tiny one that runs where nothing else will.

Start with the leap, because it dates everyone’s article. Gemma 3 is previous-generation. Gemma 4 landed April 2, 2026 (up to 31B dense plus a 26B MoE) under a full Apache 2.0 license, and the jump is large. On LiveCodeBench v6, Gemma 4 31B reportedly scores 80.0% against Gemma 3 27B’s 29.1% — roughly 3x better at coding in a single generation. That number is vendor and secondary-source, not yet on an independent leaderboard, so hold it loosely; the generational jump is the durable part.

Gemma 3 was the quiet local utility the family was known for, not a coder: agentic tool use on τ²-bench Retail at 6.6%, and Fixstars’ hands-on found hallucinations on technical detail and no capacity for complex agentic VSCode work. What Google marketed was the LMArena 1338 score, which beats GPT-4o and Claude 3.7 Sonnet — but that measures chat preference, not coding ability, and the two should not get conflated. None of which made Gemma 3 useless: it earned real adoption as a free local utility for JSON extraction, log parsing, and code explanation.

Then there is Gemma 3n, the tiny edge variant that fits where nothing else does. Clever architecture lets the full 5B and 8B models run in 2GB and 3GB of memory, multimodal across image, audio, video, and text. A privacy and offline play, not a coding rival. The rabbit wins by being where the others cannot go: edge devices, air-gapped machines, the laptop with no connection.

Access runs through Ollama (override the default 2048 num_ctx or context keeps falling out), llama.cpp, LM Studio, and Vertex AI. No native Cursor or Windsurf integration.

Pig — Llama (Meta)

The pig is the sign of abundance and generosity. That was Llama: Llama 2 and Llama 3 became the base layer for the open-weight movement, the foundation under thousands of derivatives, fine-tunes, and quantizations. Meta’s generosity built the ecosystem everyone else now competes in. The pig is also the sign of complacency, and the 2026 Llama story is a provider that got too well-fed to move while leaner animals ran past it on code.

The lineup went stale, then went closed. The Llama 4 models shipped in April 2025 and were never refreshed; the ~2T Behemoth was shelved as of May 2026; Muse Spark, released that same month, is Meta’s first closed-weight, API-only model, reportedly lagging on coding; and Llama 5 slipped to roughly 2027. Andrew Ng called the retreat from open weights “a significant loss for the developer community.” The biggest model in the family is stuck in the pen, and the family stopped being fully open.

The coding numbers are why none of that got forgiven. On Aider Polyglot, Llama 4 Maverick scores 15.6% — against Kimi K2 at 59.1%, Qwen3-235B at 59.6%, and DeepSeek-V3.2 Reasoner at 74.2%, roughly a 5x gap to the Chinese open models. And it doubles as the cleanest benchmark-trap example in the series, the callback to Part 1’s rule. For LMArena, Meta submitted a conversationality-tuned variant that ranked around #2; the actual public release ranked #32, and LMArena rebuked Meta for the swap. Yann LeCun, who left Meta in November, told the Financial Times in January 2026 that the Llama 4 results “were fudged a little bit.” One case study in why a vendor number means nothing until an independent leaderboard confirms it.

Llama still ships under the Llama Community License, not an OSI-approved one, and has been passed in both openness and downloads — DeepSeek (MIT) and Qwen (Apache 2.0) are more open, and Qwen overtook Llama as the most-downloaded open family on Hugging Face, with Chinese models holding four of the top five open-weight slots — GLM-5.2 now the #1 open-weight model on the Artificial Analysis index, ahead of Qwen, Kimi, and DeepSeek. The money did not buy the code scores: Meta runs the best-funded open lab there has ever been, and r/LocalLLaMA’s reaction to Llama 4’s coding was negative anyway. Access is everywhere, and no first-party coding default anywhere, because the scores do not earn one.

Rat — Mistral (France)

The rat is first in the zodiac, clever and nimble, the outsider that thrives in the cracks and punches above its weight. Mistral fits cleanly: the European challenger named for the cold, fast wind off the Alps, a fraction of OpenAI’s war chest, surviving against far larger labs by being efficient and by owning a niche nobody else can — sovereignty. It made its name with Mistral 7B in September 2023, which beat Llama 2 13B at half the parameter count. The rat against the pig, literally, on the first release.

The current flagship open model is Mistral Large 3 (December 2025), a 256K-context MoE under Apache 2.0 that Microsoft markets as “the strongest fully open model developed outside of China” — praise and an admission in one sentence.

On coding, keep two models straight, because the names invite a mistake. Codestral (codestral-2508) is a fill-in-the-middle specialist: its FIM pass@1 is around 95.3% (vendor-reported, class-leading), and it quietly wins the tab-completion slot in a lot of editors. Its Aider Polyglot score is only 11.1% (independent) — but that is a FIM model measured on an agentic task, the same “which benchmark, which task” trap the Llama section just walked through. The agentic model is Devstral, which scores 53.6–61.6% on SWE-bench Verified. Use Devstral, not Codestral, for SWE-bench comparisons — and ignore any source citing “Codestral 2 with Apache 2.0,” which does not exist.

The rat’s real moat is jurisdiction, not a leaderboard score. The pitch is sovereign AI: data never leaves the EU, GDPR and EU AI Act native. The French Ministry of Armed Forces signed a 2026–2030 framework; Macron told citizens to “download Le Chat rather than ChatGPT.”

Be fair about the limits. The EU AI Act edge is narrowing — Mistral, OpenAI, Anthropic, Google, and Microsoft all signed the EU AI Act Code of Practice in July 2025, while Meta declined and the Chinese firms did not, so the real divide is US/EU signatories versus China and Meta, not Mistral alone. And the skeptic’s line is hard to answer on capability: why pay Mistral on-prem when you could run Qwen for free?

The coding lead crossed an ocean

Set the Pig and the Rat side by side and the thesis arrives from a fresh direction. Llama and Mistral are the two foundational non-Chinese open-weight players, the labs that built the Western open movement, and both have been outrun on coding by the Chinese open models — the Dragon, Ox, Monkey, and Goat from Part 1. The Western open-weight story in 2026 is Meta retreating to a closed model and Mistral surviving on a sovereignty niche rather than on raw capability. The coding lead did not just shift between companies. It crossed an ocean.

That leaves the frontier still in Western hands for the hardest work, and the open flank fallen. Which sets up the question the whole series was built around. Twelve animals across two hemispheres, and underneath all of them, one question: who controls the inference, and can you trust it with your code? Part 3 is the governance reckoning.

Bob Matsuoka is CTO of Duetto and writes about AI-powered engineering at HyperDev.

Related reading:

• AI Power Ranking — Tool comparisons and benchmarks for AI practitioners

• LinkedIn Newsletter — Strategic AI insights for CTOs and engineering leaders

This is Part 1 of a three-part read on the Fire Horse year in AI coding, the one that sets up the frame and walks through the disruptors.

2026 is the Year of the Horse in the Chinese zodiac, and not the ordinary kind. It is a Fire Horse year — 丙午, Bing Wu — the pairing that comes around once every sixty years. The last one was 1966. Tradition gives the Fire Horse a reputation for boldness, intensity, and upheaval, the kind of year people are warned about rather than wished. As a frame for the state of AI coding tools, it is almost too neat. This is the most chaotic, multi-polar stretch the field has seen, and a large share of the disruption comes from Chinese labs. The animal fits twice.

I had a different article planned. A straight survey of Chinese coding models, Kimi and DeepSeek and Qwen, and whether you should trust them with your code. Then SpaceX agreed to acquire Cursor for $60 billion in stock. Anysphere, Cursor’s parent, would become a wholly owned SpaceX subsidiary; the deal was announced June 16 and is expected to close in Q3. SpaceX absorbed xAI back in February, which means the editor sitting inside 64% of Fortune 500 development workflows now answers, eventually, to the same org chart as Grok. The acquisition reframed the whole piece.

Because the question developers keep asking about DeepSeek and Kimi is “where does my code go, and who can read it?” That now applies to the most popular AI editor in the enterprise. The model layer inside your IDE has become a governance problem, and it does not much matter whether the party on the other side is in Beijing or in Boca Chica. The shape of the concern is the same. Only the jurisdiction’s law changes.

So I kept the Chinese-model framing and pushed it further. To organize the field, I mapped twelve models to the twelve animals of the zodiac, one animal per model family, which forced the labs that ship a half-dozen variants into a single sign with their internal rivalries inside the section. The mapping is most certainly a device (but a fun one -- don’t hate!), and it makes a quiet point on its way: the animals land on Chinese and Western labs alike, and a Chinese frame ends up describing the whole field. That is the through-line this series pays off in Part 3 — provenance was always a weak proxy for the question that matters, who controls the inference and what they are allowed to do with what passes through it.

This part covers the frame, the methodology behind every number below, and the front-runners pushing the field. Part 2 turns to the Western incumbents and the collapse of the open-weight flank. Part 3 is the governance reckoning the series builds toward.

TL;DR

• It is a Fire Horse year, the once-in-sixty-years sign of upheaval, and AI coding earned the label: a $60B acquisition, a collapsing capability gap, and a dozen credible model families from both hemispheres.

• Almost every benchmark number you have seen for a Chinese coding model is either self-reported or conflates versions. Kimi K2 alone has shipped six named releases in eleven months. Treat headline scores as marketing until an independent leaderboard confirms them.

• DeepSeek competes on price, not the hardest work: V4-Pro runs 34–86x cheaper than Opus 4.8, scores 80.6% on SWE-bench Verified, and falls behind where the work gets difficult.

• Qwen has the cleanest enterprise story of the Chinese front-runners — Bedrock, Azure, Apache 2.0 licensing, and it just passed Llama as the most-downloaded open family on Hugging Face.

• Cursor’s own default model, Composer 2.5, is built on Moonshot’s Kimi K2.5. The strongest model in the most-deployed enterprise editor is already a Chinese-origin model fine-tuned by an American company.

• The quiet spoiler is GLM-5.2 (Zhipu): the #1 open-weight model on the independent Artificial Analysis index (#4 across all models) and #2 on LMArena’s Code Arena, from a lab most Western developers were not tracking.

The benchmark trap

Start with some discomfort. Most of the numbers in this debate are unreliable, and not because anyone is lying outright. They are unreliable because of two structural problems: version conflation and contamination. This section is the methodological spine for the whole series, so it sits up front.

Take Kimi K2. Here is the release history: K2 in July 2025, K2-Instruct-0905 in September, K2 Thinking in November, K2.5 in January 2026, K2.6 in April, and K2.7 Code this month. Six checkpoints. When a blog post says “Kimi scores 65.8% on SWE-bench,” that was the original K2. K2.6 scores 80.2%. Those are different models with the same nickname, and people cite them interchangeably. The result is a comparison that means nothing.

Contamination is the second problem, and it is worse because it is invisible. SWE-bench Verified is a static dataset. Models trained after its release have, to varying and unmeasurable degrees, seen the answers. SWE-rebench, presented at NeurIPS 2025, rebuilt the evaluation on decontaminated tasks and watched scores fall across the board: GPT-4.1 dropped from 31.1% to 26.7%, LLaMA-3.3-70B from 18.1% to 11.2%. The Llama drop returns in Part 2, where Meta’s benchmark numbers get a chapter of their own. The headline numbers are inflated, and the inflation is not uniform.

So here is the rule I use, and the one I would suggest you adopt. When you see a coding score, ask three questions. Which exact version? Self-reported or independent? On a contaminated benchmark or a fresh one? The most trustworthy independent sources right now are the Aider Polyglot leaderboard, the Artificial Analysis Intelligence Index, and Scale AI’s SWE-bench Pro. Everything else is a starting point, not a conclusion. A zodiac of twelve animals is also twelve moving targets. Every name below has a version number, and sometimes a whole product line, hiding behind it.

The animals that lead

With that caveat doing its work, here is the field as of mid-June, one animal per family. The Horse and Dragon open the series — the acquisition that reframed it and the lab that moved the market — then the rest of the Chinese front-runners, before a closing reveal that ties the East to the West.

(Fire) Horse — Grok (via SpaceX)

The year’s own animal, and the only one that arrives by acquisition. The Fire Horse is fast, wild, and short on guardrails, which is a fair description of how Grok is charging into developer tooling — not by building a foothold but by buying one. SpaceX merged with xAI in February 2026. Grok itself has about 6% enterprise adoption and no developer-tools presence to speak of. Then, on June 16, SpaceX agreed to pay $60 billion in stock for Cursor — announced, not yet closed, with the deal expected to complete in Q3.

The strategic logic is plain: buy the distribution Grok could not earn. Cursor reportedly sits in 64% of the Fortune 500 and runs roughly $4 billion in annualized revenue, up from $2 billion in February. Grok had the model and none of the reach. The horse does not wait for permission.

No changes to model access have been announced, and no commitment to keep Cursor model-agnostic post-close has been made either. The analyst concerns are specific. Jason Andersen of Moor Insights: “xAI’s models and treatment of guardrails are very different than what Cursor has stood for,” and “Will Cursor be able to point at models other than Grok?” Justin Greis of Acceligence on the data posture: “For many enterprise customers, Cursor’s zero-data-retention policy was not simply a security feature” — it was foundational to procurement approval. Sanchit Vir Gogia of Greyhound put the structural point plainly: Cursor “sits inside the act of software creation, close to the intellectual-property bloodstream.”

Hold that last quote. It is the hinge of the governance argument, and Part 3 picks it up where this part leaves it.

Dragon — DeepSeek

The dragon is the only mythical creature in the zodiac, the sign of power and good fortune, and it goes to the only model that actually moved the market. DeepSeek is the lab that produced “the DeepSeek moment,” the release that made Western labs recalculate. It earns the dragon.

First, kill a rumor. There is no DeepSeek R2. The CEO was reportedly dissatisfied with it, Reuters noted no timeline, and every “R2 spec sheet” circulating online is speculation that contradicts the next one. If a comparison cites R2 numbers, the comparison is fiction.

The real timeline runs through the V-series, ending at V4, released April 24, 2026, as the current flagship — a trillion-plus-parameter MoE under an MIT license.

The much-cited V4 figure, SWE-bench Verified at 80.6%, is vendor-reported and does not reproduce independently — treat it as a DeepSeek claim, not a confirmed result. On the harder SWE-bench Pro, V4-Pro scores 55.4 against Claude Opus 4.7’s 64.3 — meaningfully behind where the work gets difficult. Same pattern runs through the whole series.

Price is where DeepSeek actually competes. One dollar buys about 1.15 million output tokens from V4-Pro versus roughly 40,000 from Opus 4.8 — call it 34x cheaper on input and 86x on output. For high-volume, low-stakes generation, that math is hard to ignore.

The hands-on reports split the way you would expect: capable, cheap, uneven. One developer found V4-Pro generated “subpar slightly buggy code” on sequential tasks; another said V4 Flash “often outdoes Kimi 2.6 on problems involving complex spatial reasoning.” One operational note that will bite people: the deepseek-chat and deepseek-reasoner endpoints retire July 24, 2026. If you have them wired into anything, migrate now.

Ox — Qwen (Alibaba)

The ox is the methodical workhorse, dependable and unglamorous, and Qwen is the Chinese player most developers have not actually evaluated. That is a mistake, because it has the cleanest enterprise story of the three: the broadest legitimate access, and the compliance paperwork to back it.

The current flagship is Qwen3-Coder-Next, released February 2026. Vendor-reported SWE-bench Verified lands at 70.6–71.3%, but the number to trust is independent: Scale AI scored last July’s Coder-480B at 38.70 (±3.55) on SWE-bench Pro, sobering against the vendor figures. The original Qwen3-235B marketing was inflated too — Artificial Analysis put it at 17, below average for its class — while the 2507 refresh is legitimately competitive at 25.

The hands-on reads are mixed. A Better Stack test pitted a smaller Qwen 3.5 variant against Claude Sonnet 4.5 and Claude won decisively; Qwen produced a blank project and could not self-diagnose. Artificial Analysis also flags Qwen3-235B-2507 as “very verbose,” burning 15M tokens to run their index versus an 8.1M average, which quietly inflates real-world cost even when the per-token price looks low.

Now the part that decides things for anyone in a regulated shop. Qwen has the broadest legitimate access of any Chinese model, and it just passed Llama to become the most-downloaded open family on Hugging Face. Apache 2.0 licensing on most releases (verify per version). It runs in your own environment on AWS Bedrock — where AWS guarantees customer data never trains Qwen — and on Azure AI Foundry inside your own tenancy, with local options through Ollama and vLLM. In Cursor it is not native; you need Cursor Pro+ and a custom-model config. That compliance posture is the Qwen story, and Part 3 ranks exactly where it lands on data safety.

Monkey — Kimi (Moonshot AI)

The monkey is clever, versatile, mischievous, and the sharpest tool-user in the zodiac — exactly the K2 family’s profile. It is the agentic one, brilliant and inconsistent in the same breath. “High ceiling, low floor” is a monkey’s whole personality.

The K2 family is the open-weight model that made Western labs pay attention. It is a trillion-parameter sparse mixture-of-experts design built for repo-scale work, and that is where developers praise it most — large context, real understanding of how files relate to each other. The current flagship is Kimi K2.7-Code (June 12, 2026): 1T total parameters, 32B active, 256K context, thinking mode forced on, and reportedly about 30% fewer reasoning tokens per task than K2.6 (independent). Pricing runs $0.95 per million input, $4.00 output.

The independent numbers are respectable. On Aider Polyglot, the original K2 scored 60.0%, ahead of Claude Sonnet 4 at 56.4% and behind Opus 4 at 70.7%. On the Artificial Analysis Intelligence Index v4.1, K2.7-Code sits at 42 (K2.6 was 43), strong among open models but now behind GLM-5.2’s 51 for the open-weight lead. Where Kimi keeps its edge is agentic stability, not the raw index — the troop holds together under load better than the score alone suggests.

The community read is more textured. K2.6’s launch pulled 592 points and 303 comments on Hacker News, with several people calling it “another DeepSeek moment.” The praise centers on context and cost — one developer reported dropping Claude Pro at $20/month for Kimi via Ollama and “haven’t hit usage limits a single time.” The skepticism centers on reliability: “high ceiling but low floor” came up more than once, meaning capable but inconsistent run to run.

That inconsistency shows under load. In Composio’s hard agentic test, the verdict was blunt: “Opus was expensive, but it finished. Kimi just could not put it all together once the task got real.” Kimi is excellent until the task stops being routine. Part 2 returns to that line from the Dog’s side.

Access is easy. OpenRouter lists it at roughly $0.60–0.74 per million input tokens and $2.50–3.50 output; the direct API runs through platform.moonshot.cn; it works in Cursor as a custom model via OpenRouter. And the detail to hold onto: Cursor’s own Composer is built on Kimi K2.5. The Snake section, below, is where that lands.

Two vendor claims to flag. Kimi’s Agent Swarm reportedly spawns up to 100 sub-agents across roughly 1,500 tool calls — the monkey troop in literal form, interesting and unverified. And treat the HumanEval 99.0 figure for K2.5 with suspicion: HumanEval is near saturation, so a score that high tells you the benchmark is exhausted, not that the model is.

Goat — GLM (Zhipu)

The goat is gentle, creative, and persistently underrated — mild on the surface, a pleasant surprise once you give it a chance. GLM is the quietly capable one. In one widely shared account it was “the first open model that was actually usable” for code, with a Hacker News developer (handle MintsJohn) rating it around ChatGPT-4.0 level, more than most expected from an open model at the time.

GLM also anchors the most-quoted cautionary tale of the season. Ashish Sharda’s “I Tested GLM-4.6 for 2 Weeks and Went Back to Claude” reads as a knock, but it is two weeks of a developer living inside GLM before deciding the premium model was worth the money. The goat held its own long enough to make the comparison a real one — a better daily driver than the headline suggests. Part 2 carries the verdict that comparison reached, on the Dog’s home turf.

Snake — Composer (Cursor’s own model)

The snake keeps hidden wisdom and waits in the grass until you step on it. Composer fits because it conceals what it is: Cursor’s in-house model wears an American badge over a Chinese-origin base — Moonshot’s Kimi K2.5 — and most people who run it daily have no idea.

The naming confuses people, so be precise. There is no third-party product called Composer. It is Cursor’s in-house coding model, a mixture-of-experts design RL-trained for software engineering, built on Moonshot’s open Kimi K2.5.

The version history runs Composer 1 (October 2025, shipped with Cursor 2.0), Composer 1.5 (February 2026), Composer 2 (March 2026, Kimi K2.5 base confirmed by Cursor), and Composer 2.5 (May 18, 2026, current). Composer 2.5 scores 79.8% on SWE-bench Multilingual and 63.2% on CursorBench v3.1, trained on roughly 25x more synthetic tasks than Composer 2. Cursor claims it “matches Opus 4.7 at about 1/10th the cost.”

Keep the layers straight: Composer is the model, Cursor Agent is the harness that runs it, and Composer 2.5 is the default model in that harness. Cursor’s own May routing guidance: deep architecture and long context to Claude Opus 4.7, shell-heavy terminal work to GPT-5.5, general default to Composer 2.5.

Sit with the implication. The default model in the most-deployed enterprise AI editor — the one SpaceX just paid $60 billion for — is a Chinese-origin open-weight model fine-tuned by an American company. The boundary a lot of enterprises thought they were enforcing (”no Chinese models in our stack”) was already crossed before the acquisition was announced. Provenance was the easy part to police. It turns out it was also the part nobody was actually policing.

That is where the East-rises story stops being about which labs ship from Beijing. The boundary enterprises thought they enforced was already inside their default editor. Part 2 turns to the Western field that is supposed to be the safe choice — the incumbents that still lead the hardest work, and the open-weight movement outrun on code.

Bob Matsuoka is CTO of Duetto and writes about AI-powered engineering at HyperDev.

Related reading:

• AI Power Ranking — Tool comparisons and benchmarks for AI practitioners

• LinkedIn Newsletter — Strategic AI insights for CTOs and engineering leaders

The myth that won’t die

AI is magic. Just ask it a question, get an answer. Type a prompt, receive working code. The tools are so good now that methodology doesn’t matter—you can wing it and still get results.

This breaks down the moment you try to build anything real.

This manifesto distills what nine months of daily AI-assisted development has taught me. The research is finally catching up—and the findings match what I was seeing six months before the studies came out.

What follows is the opposite of “just ask GPT.”

First, pick the right tool for the job

In my current workflow, ChatGPT is a pal. Claude is my colleague.

I don’t mean that as shade—and this may shift as tools evolve. ChatGPT excels at casual conversation, quick lookups, creative brainstorming, general-purpose chat. When you want to explore an idea without structure, when you’re killing time, when you need something that feels effortless—ChatGPT is designed for that experience.

But professional AI work requires different architecture. Claude.AI offers project-based organization with persistent context, custom instructions per workspace, and document integration that maintains state across sessions. Analysis of 2,500+ repositories found that project-aware approaches like Cursor achieved 39% higher merged PR rates—a University of Chicago team measuring real GitHub outcomes, not survey data. Stateful conversational systems consistently show higher user satisfaction over stateless alternatives in controlled studies.

This isn’t because of model quality—Opus 4.5 and GPT-5.2 trade benchmark scores depending on the task. It’s because of infrastructure. ChatGPT treats each conversation as ephemeral. Claude Projects treat each workspace as a persistent collaboration environment with its own knowledge base, instructions, and accumulated context.

The underlying principle transcends any specific tool: project-scoped state beats conversation-level ephemera for professional work. If Claude Projects didn’t exist, I’d build the same pattern with custom tooling. The tool matters less than the architecture.

Professional work happens in projects. So that’s where the methodology starts.

Rule 1: Don’t write your own prompts

Every project gets its own detailed instructions—written by Claude, not by you.

This sounds counterintuitive. Why would you outsource prompt writing to the same system you’re prompting? Because research consistently shows AI-optimized prompts outperform human-written ones by significant margins.

Google DeepMind’s OPRO study found LLM-generated instructions beat human-designed prompts by up to 50% on Big-Bench Hard tasks. The Suzgun & Kalai Meta-Prompting Framework showed meta-prompting surpassed standard prompting by 17.1%, expert prompting by 17.3%, and multipersona prompting by 15.2%. A 2025 ScienceDirect study on industrial applications found “the structure of the prompt itself had greater influence on determinism and correctness than the choice of LLM.”

The methodology: When starting any Claude Project, I ask Claude to write the project instructions. I describe what I’m building, what matters, what I want emphasized. Claude drafts instructions optimized for how Claude processes context. I review, refine, iterate—but I’m editing Claude’s work, not writing from scratch.

Here’s why this works: LLMs have specific attention patterns, context prioritization quirks, and interpretation biases. A prompt optimized for how the model actually processes language will outperform one optimized for how humans think prompts should work. The SPRIG Framework found a single AI-optimized system prompt performs on par with task-specific prompts across 47 different task types—and those optimized prompts generalize across model families, parameter sizes, and languages.

One caveat matters: A 2025 MIT Sloan study found automatic prompt rewriting degraded performance by 58% when it overrode user intent. Human oversight of AI-generated instructions remains essential. Don’t just accept whatever Claude produces—review it, test it, refine it. But start from Claude’s draft, not your own.

For knowledge work specifically: Each Claude Project in my workflow has detailed custom instructions even when the work is generic. Writing projects get tone guidance, formatting preferences, citation requirements. Research projects get source evaluation criteria, synthesis approaches, output structure. Coding projects get architecture patterns, testing expectations, documentation standards. The instructions aren’t boilerplate—they’re optimized context that shapes every response.

Rule 2: Make your context searchable, not just present

Cramming documents into a project isn’t context management. It’s hoarding.

The Lost in the Middle phenomenon, documented by researchers at Stanford and UW, showed accuracy degrades over 30% when critical information sits in the middle of long contexts. Chroma’s July 2025 study evaluating 18 LLMs confirmed that performance degrades as input length increases—even on simple tasks. More surprisingly, shuffled incoherent context sometimes outperformed logically structured input.

More context isn’t automatically better. Strategic context is better.

The foundation is working in defined projects. Every significant task gets its own Claude Project—not a continuation of some sprawling conversation that’s accumulated context about twelve different topics. A project for client work. A project for research. A project for each codebase. The discipline of organizing work into discrete, focused workspaces is where methodology starts.

Claude.AI automatically RAG-indexes documents you add to projects. This matters. Your documents aren’t just sitting in the context window hoping Claude notices the relevant paragraph. They’re indexed and retrieved semantically—Claude searches them based on what’s relevant to your current query. This turns document-heavy projects from context-window-stuffing into actual knowledge bases.

But RAG indexing only works when you give it something worth indexing. I’m deliberate about what goes into each project:

• Project-specific documentation (not everything that might be tangentially relevant)

• Reference material I’ll need repeatedly

• Examples of the output quality I want

• Previous work that should inform new work

My implementation adds a second layer for code: I use mcp-vector-search, an MCP server that AST-chunks all code in a project and makes it semantically searchable. This matters because of how code context works.

The cAST paper from Carnegie Mellon found AST-aware chunking improved code generation Pass@1 by 2.67-5.5 points across benchmarks, with Recall@5 improvements of +4.3 points. The principle: chunk boundaries aligned with complete syntactic units—functions, classes, modules—preserve semantic integrity that naive text splitting destroys.

When Claude needs context about a specific function, it searches the vector database and retrieves the relevant code chunks with their surrounding context. It’s not wading through 50,000 lines hoping the important bit isn’t lost in the middle. It’s querying a structured knowledge base and getting precisely what’s relevant.

For knowledge work without code: The same principle applies. Don’t dump every related document into a project and hope for the best. Curate. Organize. Consider which information actually matters for which tasks. If you’re working with extensive reference material, external RAG systems (research shows knowledge graph-based RAG reduces hallucinations by 20-30%) beat relying on context window alone.

The question isn’t “how much context can I add?” It’s “what context actually improves output quality for this specific task?”

Rule 3: Build verification into your workflow

AI checking AI works—when structured correctly.

Hallucination rates vary wildly depending on how you measure. Vectara’s leaderboard shows 0.7% for the best models on closed-book QA benchmarks, climbing to 29.9% for weaker ones on harder tasks. For code specifically, one study of AI-generated code found security vulnerabilities in 48% of samples—though this varies by language, task complexity, and vulnerability definition. Apiiro research found AI-generated code introduced 322% more privilege escalation paths and 153% more design flaws in their analysis.

The pattern is consistent: unverified AI output ships bugs. Maybe not every time. But often enough that verification isn’t optional.

My verification stack has two components:

First, unit test coverage. When Claude Code generates or modifies code, I require tests for any significant functionality. Not because I don’t trust the code, but because tests surface the gaps between what I asked for and what was implemented. Tests catch the “almost right, but not quite” problem that 66% of developers cite as their top frustration.

Second—and this is the part that surprises people—I use GPT to proofread Claude’s writing output. Different model, different training data, different biases. When GPT catches something Claude missed, that’s signal. When both agree, confidence increases.

State-of-the-art LLMs can align with human judgment up to 85% for evaluation tasks when used correctly. Hallucination detection tools achieve 90-91% accuracy. AI code review tools like CodeRabbit achieve 46% bug detection accuracy versus traditional static analyzers at under 20%, with teams reporting 40% reduction in code review time.

But LLM-as-judge has documented limitations. Hallucination “echo chambers” form when generating and evaluating models share biases. Best practices from the research: use binary yes/no questions (outperform complex scales), prompt LLMs to explain ratings, use multiple evaluators with voting or averaging.

The enterprise standard: 76% of organizations now include human-in-the-loop workflows to catch hallucinations before deployment. Knowledge workers spend an average of 4.3 hours per week fact-checking AI outputs. That time isn’t overhead—it’s the actual cost of making AI work reliable.

For knowledge work: Every significant document I produce with AI assistance gets reviewed by a different model before it ships. Sometimes that’s GPT reviewing Claude. Sometimes it’s Claude reviewing its own earlier work with fresh context. The specific models matter less than the principle: verification is not optional.

The gaps that remain

Two problems Claude.AI doesn’t solve yet.

Cross-project knowledge. Every project is an island. Work you did in one project doesn’t inform another. If you’ve solved a similar problem before, Claude doesn’t know unless you manually copy context over.

You can build this yourself with git—treat your Claude Projects like a monorepo where related work lives in the same repository structure, manually maintaining connections. I expect Anthropic will ship native cross-project search eventually. Until then, it’s manual work or custom tooling.

Temporal decay. Documents you added six months ago sit alongside documents you added yesterday, weighted equally. Static context gets stale. Your project instructions reference approaches you’ve since abandoned. Old architecture docs describe systems that no longer exist.

Claude.AI doesn’t rank by freshness. It doesn’t know that your January notes are probably less relevant than your December work. Kuzu-memory builds freshness weighting into its knowledge graph architecture—newer information surfaces more readily. But that’s external tooling solving a problem the platform should handle natively.

Both gaps will close. The question is whether you wait for Anthropic or build workarounds now.

The implementation pattern

Here’s what this looks like in practice:

Starting a new project:

1. Create a Claude Project—one project per distinct area of work

2. Add curated documents that will be RAG-indexed automatically

3. Ask Claude to draft project instructions based on what I’m building

4. Review and refine those instructions, testing with sample tasks

5. For code projects, initialize mcp-vector-search to create searchable code context

During work:

1. Work within the project, maintaining accumulated context

2. For code: rely on vector search for targeted retrieval rather than full-codebase prompts

3. For knowledge work: let Claude’s RAG indexing surface relevant document sections

4. Track what context actually improves outputs and prune what doesn’t

Before shipping:

1. For code: run tests, check coverage, verify the implementation matches intent

2. For writing: have a different model review for errors, inconsistencies, hallucinations

3. For anything significant: human review of the AI-verified output

4. Document what worked for future project instructions

What this isn’t

This manifesto isn’t about making AI slower or more bureaucratic. It’s about making AI reliable enough to trust with professional work.

If you’re exploring an idea, prototyping something throwaway, or just need a quick answer—open a chat, ask a question, move on. Nothing wrong with casual AI use for casual tasks.

But the moment stakes rise—production code, client deliverables, work you’ll be accountable for—methodology matters. The developers in the METR study who were 19% slower? They were using AI the casual way—open a chat, ask a question, accept the output, repeat. No structured context. No optimized prompts. No verification layer. They felt faster while actually slowing down.

The teams seeing 27-39% productivity gains for junior developers in the MIT/Harvard/Microsoft field experiment? They had structured workflows, integrated tooling, and verification processes.

The difference is methodology.

The bottom line

Professional AI work in 2026 requires three things:

Structured instructions: Don’t write your own prompts from scratch. Have AI draft optimized instructions, then review and refine. The research shows 17-50% improvement from structured prompting approaches—gains you’re leaving on the table with casual use.

Strategic context: More isn’t better. Searchable, organized, task-relevant context beats document hoarding. Work in defined projects. Let Claude’s RAG indexing do its job. Add AST-aware code chunking for development work. Deliberate document organization following the U-shaped attention curve.

Systematic verification: AI checking AI works when structured correctly—different models, binary evaluation questions, multiple passes. But human-in-the-loop remains the enterprise standard because 46% of knowledge workers report making mistakes based on AI hallucinations.

The opposite of “just ask GPT” isn’t slower, more complicated AI use. It’s AI use that actually delivers the productivity gains the marketing promises but casual usage fails to achieve.

I’m Bob Matsuoka, writing about agentic coding and AI-powered development at HyperDev. For more on multi-agent orchestration systems, read my analysis of what a Pattern Master does or my deep dive into the benefits of multi-agent orchestration.

I’ve been running Claude.AI Desktop as a lightweight “AI OS” on my Mac for months. The connector ecosystem turned it into my command center—Linear integration for project management, Google Drive for document access, the whole MCP stack piping context wherever I need it. Works well. Mostly.

The crashes are what finally broke my patience. Long-running research tasks, complex context synthesis, anything pushing past an hour—Claude.AI Desktop would inevitably barf and lose everything. No graceful degradation. Just gone.

So when Anthropic announced Cowork as “Claude Code for the rest of your work”? That caught my attention. This came right on the heels of /chrome going to beta for all paid users—the browser agent that lets Claude navigate websites, fill forms, and execute multi-step workflows. Two releases in quick succession that look like the first real push to close the gap between developer-focused Claude Code and everyone else.

Here’s where things get interesting: I’m on vacation this week, but I’m about to step into a new CTO role (announcement coming soon). I wanted to do proper research on my new company—reviewing their Github repos, digging through Confluence documentation, mapping out their JIRA workflow. Tasks I would have tackled with Claude Code before, but figured Cowork might handle just as well.

The verdict? Cowork is a solid step forward with one critical gap that’ll frustrate power users.

What Works

Cowork handles long-running tasks dramatically better than Claude.AI Desktop. The architecture borrowed from Claude Code makes an immediate difference.

Simon Willison’s analysis revealed that Cowork spins up a full Linux virtual machine using Apple’s VZVirtualMachine framework. Your designated folder gets mounted into a containerized environment. This explains the stability—Claude isn’t wrestling with macOS filesystem quirks directly, and crashes in the VM don’t take down your whole session.

Like Claude Code, Cowork sets up to-do lists for complex tasks, breaks work into manageable chunks, and reports progress as it goes. I kicked off a documentation analysis task and walked away for two hours. Came back to find structured notes organized by topic, saved right where I asked for them on my local filesystem.

VentureBeat’s coverage mentioned that Anthropic built Cowork in roughly a week and a half—Boris Cherny confirmed this timing on X. That recursive approach (building Cowork with Claude Code) shows in how the tool handles work. It thinks in files and folders, not conversation turns. Output lands where you can use it.

For straightforward productivity tasks—organizing a mess of screenshots into a spreadsheet, sorting a chaotic downloads folder, drafting reports from scattered notes—Cowork does the job without hand-holding.

Where It Falls Short

But here’s the thing: Cowork is no Claude Code.

My research project needed context that spanned multiple systems. Github code structure, Confluence documentation patterns, JIRA workflow history. Each piece informed the others. I expected to orchestrate this from Claude.AI—have it delegate tasks to Cowork, maybe kick off /chrome sessions to pull information from web interfaces, then synthesize everything back into my working context.

That coordination doesn’t exist yet.

What I found instead: each tool operates in isolation. The Register’s coverage captures the limitation—Cowork sessions don’t persist memory across logins, and there’s no cross-device sync. More critically for my use case, there’s no native handoff between Claude.AI conversation context and Cowork’s working memory.

I ended up building my own bridge. Created a folder that both Cowork and I could access, used artifacts as handoff files, manually copied context back and forth between sessions. Functional but clunky. Still faster than the alternative—I wouldn’t have attempted this research at all without Cowork (or Claude Code). The coordination overhead was real, but so was the output.

One TechPlanet user’s early report echoed this: “while Cowork can handle complex tasks, it sometimes lacks the nuanced understanding needed for context-specific decisions.”

Multi-session work with accumulating context? Still painful. Each Cowork session starts fresh, and you’re responsible for priming it with whatever prior work matters.

The Integration Gap

What I expected: Claude.AI as the orchestration layer. Feed it a complex research goal. Have it break the work down, delegate filesystem tasks to Cowork, dispatch browser automation to /chrome, then pull everything back together with its memory of our ongoing conversation.

What I got: Three capable tools that don’t talk to each other without significant manual intervention.

Anthropic will probably close this gap—the Connectors architecture for linking to third-party services already exists in Claude Desktop. Axios notes that Cowork can combine with Claude’s other features like the Gmail connector. But the coordination layer that would make these tools feel like one coherent system? Not there yet.

For developers comfortable with Claude Code, you already have workarounds. Shell scripts. MCP servers. Custom tooling. Cowork isn’t adding much if you’re already operating at that level.

For the productivity users Anthropic is targeting with the “not just developers” messaging? The isolation between tools will feel arbitrary. Why can’t I just tell Claude to “research this company using whatever tools you need and summarize what you find”?

The Upside

After a week of testing, I’ve settled into a workflow: Claude.AI handles memory and complex context management. It holds the ongoing conversation, maintains my research threads, keeps track of what we’ve already figured out.

Cowork is a capable executor for tasks that benefit from filesystem access and longer attention spans. The stability alone makes it worth using for anything that would have crashed Claude.AI Desktop before.

The gap is coordination. Right now, I’m the integration layer—shuffling context between tools, managing the handoffs, keeping track of what each system knows.

That’s manageable for someone who’s used to working this way. Less acceptable for the mainstream productivity users this launch targets.

The Bigger Picture

The pattern unfolding in software engineering is hitting productivity work now. Two sectors should be watching.

First: SaaS no-code solutions. Zapier, Make, all those 70% solutions that almost do what you need but never quite get there. I’ll use Cowork over any of them for complex automation, even with current limitations. If Anthropic ships cloud/desktop sync—and they’re clearly building toward it—these platforms will need to move significantly further up the stack or watch their core use cases evaporate. The friction of “almost works” loses to “actually works” every time.

Second: certain productivity roles. The pattern I wrote about Monday with pattern masters applies here. Roles heavy on information gathering, document synthesis, and routine coordination are compressing fast. The roles expanding: strategic thinking (someone still has to decide what to build), pattern recognition and synthesis (connecting dots across domains), human service work (empathy doesn’t automate), and integrators who can scale operations across systems.

The transition won’t be uniform—smaller orgs will feel it first, regulated industries slower—but the directional pressure is obvious.

The Reality of Research Preview

Fortune’s analysis positions Cowork as a competitive threat to AI productivity and automation startups. Maybe eventually. Right now, it’s what Boris Cherny said it was: “early and raw, similar to what Claude Code felt like when it first launched.”

The pricing reinforces this. $100 to $200 per month for Claude Max, which you need to access Cowork at all. That’s enterprise money for a research preview that doesn’t yet integrate with the rest of Claude’s ecosystem.

I’ll finish my company research when I get home, probably back in Claude Code where multi-session context management works better. But I’ll keep testing Cowork for the standalone tasks where its stability advantage matters.

What I’m really waiting for: seamless coordination between Claude.AI’s conversation context, Cowork’s filesystem capabilities, and /chrome’s browser automation. When those three tools talk to each other natively, we’ll have something worth getting excited about.

Until then? Cowork is a solid research preview that shows where Anthropic is heading. Just don’t expect it to replace your existing workflows quite yet.

I’m Bob Matsuoka, writing about agentic coding and AI-powered development at HyperDev. For more on AI productivity tools, read my analysis of Claude Code’s evolution to agent orchestration or my deep dive into the future of software engineering.

I published a snarky article yesterday (Thanksgiving day) morning trashing AntiGravity and questioning Google’s scattered, unfocused strategic direction. I need to do a bit of a mea culpa.

Not because I was wrong about the coding capabilities. Not because Google suddenly has a coherent strategy. I stand by all of that.

I was wrong because I completely missed the real opportunity.

AntiGravity may end up being the best end-user browser testing tool we have.

The Penny Dropped Mid-Afternoon

Here’s what happened. I’d been grinding through my usual workflow—Claude Code for the heavy lifting, Augment Code for quick iterations—when I needed to verify some UI changes across a client project. The tedious kind of work. Click through forms, check responsive behavior, verify that the dropdown actually drops down.

Normally this means either scripting something in Playwright (time I don’t have), using Safari with AppleScript (painful), or just... clicking through things manually like it’s 2015.

On a whim, I pointed AntiGravity at my codebase and asked it to review my recent commits, understand what I’d changed, and test the affected UI components.

And then I watched something impressive happen.

A browser window appeared with a cool blue aura—Google’s visual indicator that the agent has taken control. It started navigating to pages I’d modified. Filling out forms. Scrolling through content. Moving between sections. All while the agent in the IDE was tracking everything: console logs, network requests, visual state changes.

Slow? Yes. Deliberate, even. But completely autonomous and remarkably thorough.

What Makes This Different

I know what you’re thinking. Playwright exists. Puppeteer exists. I’ve written my own MCP browser plugin that I was planning to finish “someday.” There are other browser MCP tools out there. Hell, you can cobble together Safari automation with AppleScript if you hate yourself enough.

But all of that misses the point.

The integration here runs deep. This isn’t just browser automation bolted onto a coding tool. It’s a single agent that can:

1. Read your entire codebase

2. Understand your recent commits and what changed

3. Either read an existing test plan or build one based on what you’ve touched

4. Execute that test plan in an actual browser

5. Report results back with console logs, screenshots, and video recordings

That last part matters. When something breaks, you get the actual console output. Not “test failed on line 47.” The real error messages from your real application.

Ihor Sasovets, a former SET engineer, spotted this immediately: “As an ex-SET engineer, I know how much time you spend on selecting the right selector, adding necessary waits and so on. I believe that Antigravity can help you to automate a lot of the processes.”

Simon Willison noted that it “plays a similar role to Playwright MCP, allowing the agent to directly test the web applications it is building.”

So I’m not the only one who noticed. But I might be the first to call it out as the primary use case rather than a side feature.

A Workflow That Works

Here’s the scenario that every engineer knows and every QA team hates:

You’ve done a few days of coding. Features are “done.” Time to hand it off to QA. But you haven’t really tested it yourself because—let’s be honest—browser testing is tedious as hell and you’ve got other things to do.

Now instead of building a test plan manually or throwing it over the wall with a vague “I changed some stuff in the checkout flow,” you can:

1. Point AntiGravity at your branch

2. Ask it to review your commits from the past few days

3. Have it build a user-facing test plan based on what you actually changed

4. Say “now run it”

The agent fires up a browser, takes over with that blue aura, and starts methodically working through test scenarios. Form submissions. Navigation flows. Error states. Responsive behavior.

When it’s done, you’ve got documentation of what was tested, screenshots of key states, and a clear record of any failures—complete with the technical context from your codebase that a human QA tester would have to ask you about.

Google Didn’t Intend This

Let me be clear: this is not what Google built AntiGravity for.

The official announcement positions it as an “agentic development platform” where agents “autonomously plan and execute complex, end-to-end software tasks.” Browser control is framed as verification—the agent writes code, then checks that it works.

Nowhere does Google say “hey, use this as your QA automation tool.”

But that’s often how the best use cases emerge. Slack was supposed to be a gaming company. Instagram started as a check-in app. Sometimes you build something and users find the actual value.

I’m predicting that browser testing will become AntiGravity’s killer app. Not because Google intended it, but because nothing else combines codebase understanding with browser control in quite this way.

The Token Reality Check

Now the bad news.

One small feature testing session—maybe 20 minutes of browser interaction—ate through my entire free token allocation.

This won’t be cheap to run regularly.

The free tier is basically enough to see if the tool works for you. Any serious usage is going to require paid tokens, and based on my initial experience, the cost-per-test-session is going to be meaningful. We’re not talking Playwright-level costs here. We’re talking LLM inference costs for an agent that’s reasoning about your codebase and orchestrating browser actions simultaneously.

For individual developers doing occasional testing? Probably fine. For teams wanting to run comprehensive test suites? Budget accordingly.

Where This Fits In My Stack

I’m not dropping Claude Code. I’m not abandoning Augment Code. AntiGravity’s actual coding capabilities remain... let’s call them “developing.”

But I can see this becoming my third most-used tool, specifically for one narrow but persistent pain point: technical code review paired with user experience validation.

The integration between “I can read all your code” and “I can also control a browser” is something I haven’t seen anywhere else. That combination solves a specific problem I’ve been hacking around for months.

My half-finished MCP browser extension? Deleted. The janky AppleScript automation I cobbled together? Gone.

The Caveats You Should Know

A few things to keep in mind before you get too excited:

It’s slow. Not “annoyingly slow” but definitely “watch it happen rather than fire and forget” slow. Each action requires reasoning, and reasoning takes time.

Stability is inconsistent. DevClass reported “model provider overload” errors and repeated agent terminations during their testing. I hit similar issues—not constantly, but often enough to notice.

Security concerns are real. Johann Rehberger documented multiple vulnerabilities including remote command execution and data exfiltration risks. The tool has broad system access by design. That cuts both ways.

Chrome only. No Firefox. No Safari. No WebKit testing. If cross-browser validation matters to your workflow, you’ll still need traditional tools.

Bottom Line

I was wrong about AntiGravity. Not about the coding quality (still mediocre) or Google’s strategy (still scattered). I was wrong about where the value lives.

There’s nothing quite like this for integrating technical understanding of a codebase with the ability to carefully control a browser. The agent doesn’t just click buttons—it knows why it’s clicking buttons because it read the code that made them.

Google probably didn’t plan for this to be the headline feature. But I predict it will be.

Just budget for the tokens.

I’m Bob Matsuoka, writing about agentic coding and AI-powered development at HyperDev. For more on AI coding tool evaluation, read my analysis of The AI Coding Tools Market Correction or my deep dive into Multi-Agent Orchestration in Practice.

Hero Image Prompt: A browser window with a subtle glowing blue aura around its edges, showing a partially-filled web form. Code editor visible in the background, slightly out of focus. The browser dominates the foreground with a sense of autonomous control—no human cursor visible, form fields filling themselves. Cool blue and purple tones, technical but approachable aesthetic. 4:3 aspect ratio.

I spent the day putting GPT-5.1-Codex-Max through real-world testing on actual production features. Not demos, not toy projects - features for my AI Power Rankings site, tracked through proper tickets, evaluated by my multi-agent orchestration system.

The results? Claude MPM gave it a B-. Not my assessment - an AI orchestration framework evaluating another AI tool based on delivered work quality.

That grade tells you everything about where Codex-Max stands: technically competent, meaningfully improved over the original Codex, and fundamentally too late to matter competitively.

TL;DR

• Tested Codex-Max on two production features for AI Power Rankings, tracked via mcp-ticketer with full receipts

• Claude MPM evaluation: B- grade on delivered work quality

• Significant improvements over original Codex - better UX, stronger coding capabilities

• Critical gap: No local operations, no deployment automation, no QA integration

• Augment Code’s single agent handles full lifecycle including deployment/QA that Codex-Max can’t touch

• Bottom line: Solving Q1 2025’s problem in Q4 2025 when the market has moved to complete workflow orchestration

• Better than vibe coding, but that’s no longer the competitive bar

The testing setup: real features, real tracking

I don’t do toy demos. When I evaluate tools, I use them on actual production work and document everything. For Codex-Max, I assigned two features on AI Power Rankings:

1. Feature enhancement for tool comparison views

2. Data integration improvements for ranking algorithms

The methodology was straightforward: Codex-Max handled the full implementation, creating and managing its own tickets through mcp-ticketer - its MCP integration works fine. When it was done (or done-ish), I brought in Claude MPM to assess the results and fix issues, also using proper ticket tracking and updates. This isn’t me giving vibes-based opinions - it’s one AI system reviewing another’s delivered work based on measurable outcomes.

The receipts are public: GitHub Issue #52 shows exactly what was attempted, what succeeded, what failed, and how long everything took. You can see the actual code Codex-Max produced in the implementation branch.

What Claude MPM found

The B- grade breaks down into specific strengths and weaknesses:

What Codex-Max got right:

• Clean, readable code generation

• Reasonable architectural decisions for straightforward features

• Significantly better UX than the original Codex

• Multi-file editing that actually worked most of the time

• GitHub integration that properly understood PR context

Where it fell short:

• No ability to handle local deployment workflows

• Zero QA automation capabilities

• Cloud-only execution created friction for iterative testing

• Context preservation degraded on longer tasks despite compaction claims

• Required more hand-holding than expected for edge cases

The specific example that crystallized the problem: When the feature needed deployment validation and QA checks, Codex-Max just... stopped. It generated the code, opened the PR, and that was it. My agents handle local ops deployment and QA automatically - Codex couldn’t touch any of that workflow.

The timing problem: Q1 in Q4

Here’s what makes this interesting: If I’d had Codex-Max five months ago, in Q2 2025, I would have been thrilled. The improvements over the original Codex are substantial. The UX polish is real. The coding quality bump matters.

But we’re not in Q2 2025. We’re in Q4 2025, and the market evolved faster than OpenAI shipped.

What would have been competitive in January 2025:

• Better code generation than GitHub Copilot

• Multi-file editing with reasonable accuracy

• Cloud execution for async workflows

• GitHub integration for PR reviews

What the market actually looks like in November 2025:

• Complete workflow orchestration from specification to deployment

• Multi-agent systems handling specialized tasks in parallel

• Local operations integration as table stakes

• Full QA automation and testing frameworks

• Context preservation across days-long development sessions

Codex-Max improved a single-agent cloud execution model. The market moved to orchestrated multi-agent systems with full lifecycle coverage.

In AI development tools, nine months isn’t a product cycle. It’s a generation.

What modern tools handle

My daily driver is Claude MPM on top of Claude Code - that’s what handles my orchestration needs. But here’s what makes Codex-Max’s limitations so stark: Even Augment Code’s single agent handles everything Codex-Max can’t.

To be fair to Codex-Max: I didn’t spend as long building scaffolding for it as I would for Claude Code. I gave it an AGENT.md file (converted from my CLAUDE.md), but I didn’t invest the same level of context setup. That said, the comparison to Augment Code remains instructive - Augment doesn’t need extensive scaffolding because it builds a thorough semantic index of your entire codebase automatically. That’s where modern tools actually are.

Deployment automation: Augment Code manages local deployment, runs validation checks, and handles rollback if needed. Codex-Max stops at code generation.

QA integration: Augment Code triggers test suites, analyzes failures, and iterates on fixes. Codex-Max requires manual testing.

Context acquisition: Augment Code builds semantic indexes automatically, understanding codebases without manual scaffolding. Codex-Max relies on explicit configuration and context seeding.

Local operations: Augment Code executes locally with full filesystem and process access. Codex-Max lives in cloud sandboxes with limited local integration.

Modern tools handle the complete development lifecycle with minimal setup overhead. Augment Code does it with a single agent and automatic context acquisition. I do it with Claude MPM’s multi-agent orchestration and explicit context management. Both approaches work - they just represent where the market actually is.

The fact that a single modern agent handles what Codex-Max can’t shows this isn’t a fundamental AI limitation. It’s an architectural choice OpenAI made that the market already moved past.

What Codex-Max delivers

Credit where it’s due: OpenAI shipped meaningful improvements over the original Codex.

The UX polish is real. The terminal interface works smoothly. The GitHub integration feels native rather than bolted-on. The multi-file editing produces sensible diffs. The cloud execution model eliminates local environment concerns for teams that want that abstraction.

The coding quality improved. Comparing Codex-Max output to original Codex shows clear advancement. The code is cleaner, the architectural decisions are more sound, and the edge case handling is better. That 77.9% SWE-bench Verified score isn’t marketing fiction.

The compaction technology works. Tasks do run longer than the original Codex’s hard limits. The 24+ hour sessions OpenAI advertises are real, though in practice I found context degradation kicked in well before that for complex features.

For teams that don’t have orchestration frameworks, don’t need deployment automation, and primarily want better code generation with nice GitHub integration, Codex-Max represents a solid upgrade. It’s a good tool.

It’s just a good tool for a problem space that evolved past it.

Better than vibe coding—but that’s not the bar anymore

Codex-Max beats casual “vibe coding” - developers prompting ChatGPT or Claude for code snippets and copying them over.

That’s not the competitive bar anymore.

The bar in Q4 2025 is:

• Complete workflow automation from specification to deployment

• Multi-agent orchestration handling specialized tasks in parallel

• Full lifecycle coverage including ops, testing, and monitoring

• Context preservation across multi-day development sessions

• Local and cloud integration based on actual workflow needs

Codex-Max cleared the “better than copy-paste from ChatGPT” bar. It didn’t clear the “competitive with actual orchestration frameworks” bar.

For hobbyists and individual developers doing straightforward features, Codex-Max might be an improvement over their current workflow. For teams doing serious development work with orchestration systems, it’s a step backward from where they already are.

The architectural problem: single-agent vs. orchestration

Codex-Max improved a single-agent model. The market moved to orchestrated multi-agent systems.

Single-agent limitations:

• One context window (even with compaction)

• One reasoning path

• One set of tool integrations

• Sequential execution only

Multi-agent advantages:

• Specialized agents for different tasks (research, coding, testing, deployment)

• Parallel execution across workstreams

• Persistent shared memory across agents

• Coordinated hand-offs at natural boundaries

I can spin up Claude MPM with specialized agents for:

• Specification agent: Analyzes requirements and creates detailed specs

• Architecture agent: Designs system structure and integration points

• Implementation agent: Writes code following architectural guidelines

• Testing agent: Creates test suites and validates functionality

• Deployment agent: Handles local ops, QA checks, and rollout

• Review agent: Evaluates overall work quality and assigns grades

That’s not aspirational. That’s what evaluated Codex-Max and gave it a B-.

OpenAI optimized the wrong abstraction. They built a better single agent when the market needed orchestration infrastructure.

Market context: the window closed

The timing becomes even more painful when you look at the competitive landscape:

Claude Code Max ($200/month): 7-hour autonomous sessions, local-first execution, full MCP support for tool integration, sub-agent coordination

Augment Code ($50-100/month): Complete lifecycle automation, deployment integration, single-agent simplicity with full capability

Cursor ($20-200/month): Model-agnostic deep indexing, local execution, proven developer adoption

GitHub Copilot ($10-39/month): Ubiquitous IDE integration, massive installed base, continuous improvement

Codex-Max at $200/month (Pro tier) matches Claude Code Max’s price but not its capabilities. It matches the capabilities of tools costing 1/4 the price but lacks their features.

The positioning is stuck between market segments. Too expensive to be the “good enough” option. Not capable enough to be the “complete solution” option.

What this means for OpenAI

This isn’t just a product timing miss. It reveals a strategic challenge:

OpenAI treats AI coding tools as improved single agents. The market treats them as orchestration infrastructure for multi-agent workflows.

That’s a fundamental difference in how you approach product development:

Single-agent optimization focuses on:

• Better code generation quality

• Longer context windows

• Faster execution

• Smoother UX

Orchestration infrastructure focuses on:

• Agent coordination protocols

• Shared memory systems

• Tool integration frameworks

• Workflow automation patterns

OpenAI delivered the former. The market needs the latter.

The compaction technology is clever. The UX improvements are real. The coding quality gains matter. But they’re all optimizations of an architecture that became obsolete while OpenAI was building it.

The larger pattern

This isn’t unique to Codex-Max. I’m seeing the same pattern across the AI tools market:

Companies that win: Ship fast, iterate based on actual usage, adapt to market evolution

Companies that struggle: Build technically impressive solutions to problems that moved on

OpenAI’s challenges:

• Long development cycles

• Feature announcements without product availability

• Building for what the market was, not what it’s becoming

The market’s evolution:

• Quarterly shifts in competitive dynamics

• Rapid adoption of new paradigms

• Ruthless abandonment of tools that don’t keep pace

In fast-moving technology markets, timing isn’t just important - it’s definitional. A technically superior solution shipped nine months late loses to an adequate solution shipped on time.

Bottom line

OpenAI built a good product that arrived after the market moved on. Codex-Max would have been competitive in Q1 2025. It’s not competitive in Q4 2025.

The B- grade from Claude MPM captures this perfectly: Technically competent, meaningfully improved, fundamentally inadequate for current market needs.

For developers evaluating tools:

Skip Codex-Max if: You need deployment automation, local operations integration, QA workflows, or multi-agent orchestration. Use Claude Code Max or Augment Code instead.

Consider Codex-Max if: You want better code generation than Copilot, like cloud execution, primarily work with GitHub, and don’t need full lifecycle automation. At $20/month (Plus tier) it might make sense.

In AI development tools, market evolution outpaces product development cycles. Building the best version of yesterday’s architecture loses to shipping adequate versions of tomorrow’s architecture.

OpenAI solved Q1 2025’s problem in Q4 2025. That’s not fast enough.

I’m Bob Matsuoka, building multi-agent orchestration systems and writing about practical AI development at HyperDev. For more on AI coding tools in practice, read my analysis of Claude Code’s multi-agent capabilities or my comparison of orchestration frameworks in production.

Back in June, I wrote about how PowerPoint kills creativity through forced context-switching. My solution? Stay in Claude.AI’s artifact system, generate React slideshows, dodge the whole presentation software problem.

Then I actually used Gamma. For real work. Fifty-plus presentations since June.

And it’s... complicated.

Here’s what happened: I needed client decks fast. The Claude.AI artifact approach works great for internal stuff, but clients expect actual presentation files they can edit. So I started having Claude.AI generate Gamma-optimized prompts from my writing, then feeding those into Gamma’s AI.

The workflow stuck because it actually works.

The Workflow That Accidentally Solved My Problem

My process now looks like this: Write the core content in Claude.AI (where I’m already thinking), ask Claude to “generate a Gamma-optimized prompt from this,” paste that into Gamma, wait about 30 seconds.

What comes out? Surprisingly good first drafts.

Gamma’s gotten noticeably better at data layouts. Early on, every deck looked identical—same card structures, same visual hierarchy, same boring templates. Now there’s actual variety. Charts that make sense. Diagrams that don’t look like they came from a 2010 PowerPoint template pack.

The image generation is genuinely fast. Much faster than DALL-E 3, which matters when you’re iterating on client deliverables with tight deadlines. Quality’s solid for presentation purposes—not fine art, but better than stock photos.

Speed became the killer feature. From prompt to reviewable deck in under a minute. For comparison, building the same deck manually in PowerPoint? Easily an hour. Even my Claude artifact approach took 15-20 minutes of tweaking.

Gamma also has a new agent which solves the biggest problem with decks — one way flow (the difficulty of changing content in slide format). The agent is basically a format-aware LLM that can make prompt-driven changes ON THE FLY, respecting the structure of the deck. It’s magic. Try this in Powerpoint: “Let’s fix “We” vs “I”. I am the author of the proposal, and should be shown for any action in the proposal. ‘We’ can be used to imply that implementing action is a team effort.”

What Still Sucks

Themes remain formulaic. You can spot a Gamma deck instantly. That “modern, clean, professional” aesthetic they’re known for? It’s also their limitation. Every deck feels like it came from the same design system because, well, it did.

Custom branding takes work. Not impossible, but friction exists. Clients with strict brand guidelines require manual adjustment of colors, fonts, layouts. The AI doesn’t learn your brand preferences across presentations.

Export compatibility has gotten better but still breaks occasionally. PowerPoint imports lose some formatting. Google Slides handles it reasonably well. PDF works perfectly, which is what most clients care about anyway.

The big context-switching problem from my original article? Still there. I’m still developing ideas in Claude.AI, then moving to Gamma to package them. Better packaging doesn’t solve the fundamental workflow break.

The $68M Series B Changes Nothing (And Everything)

Gamma just raised $68 million at a $2.1 billion valuation. Andreessen Horowitz led the round. The company hit $100 million ARR with only 50 employees and claims 70 million users.

Those numbers matter. Not because they make Gamma’s product better, but because they signal where the market’s going.

AI-powered presentation tools aren’t a feature anymore. They’re a category. The $2.5 billion subsegment of presentation software is growing at 25% annually. Traditional slide software (PowerPoint, Google Slides, Keynote) collectively represent $7.8 billion, but they’re legacy infrastructure now.

What’s interesting: Gamma reached profitability and stayed there for 15+ months before this raise. That’s rare in AI tools, where most companies burn through capital chasing growth. The economics actually work.

The funding goes toward addressing weaknesses—customer support infrastructure (Trustpilot shows a brutal 2.1/5 rating) and enterprise features. The $20 million secondary component gave early employees liquidity, which suggests the founders are playing the long game rather than rushing to exit.

Multi-Model Orchestration Actually Matters

Here’s the technical piece worth understanding: Gamma doesn’t use a single AI model. They orchestrate across multiple models—primarily Claude Sonnet and Gemini Flash, with OpenAI tested regularly but not favored.

This matters because different models excel at different tasks. Claude Sonnet handles complex content generation and structural thinking. Gemini Flash provides cost-efficient image generation and quick iterations. The company runs hundreds of A/B tests to optimize model selection per task.

When they tested Claude 3 Haiku, it delivered 30% better user satisfaction and 20% higher free-to-paid conversion. That’s not incremental—that’s the difference between sustainable business and burning capital.

The architecture uses block-based HTML instead of traditional slides. More responsive, more web-native, more flexible than the slide metaphor PowerPoint established 40 years ago. This is what I meant in my original article about dodging the medium that kills flow—Gamma at least tries to escape the rigid slide structure.

Competitive Reality: Nobody Else Gets Close

I’ve tested the alternatives. Beautiful.ai focuses on design automation with limited AI content generation. Pricing starts at $12/month but no free tier, positioning it as premium design-first. Their “Smart Slides” auto-adjust layouts nicely, but you’re still building content manually.

Tome raised $81 million and hit 10 million signups fast, but the product feels unfinished. $16-20/month gets you narrative-focused presentations with PDF-only export. The dark-mode-default aesthetic works for pitch decks but fails for client-facing business presentations. Limited to 400-character prompts, so complex decks require extensive manual work.

Canva offers Magic Design for Presentations as one feature among dozens. The $10/month pricing undercuts everyone, but presentations aren’t the focus. Export compatibility to PowerPoint breaks constantly. Format preservation? Forget it.

Microsoft Copilot costs $66-87/month minimum (Copilot plus Microsoft 365 E3/E5 licensing). Enterprise security and Microsoft Graph integration appeal to large organizations, but the economics are brutal for individuals or small teams. Plus, no transitions, videos, or tables in AI-generated slides initially. English-only at launch. Accuracy requires manual review.

Pitch positions as collaboration-first with basic AI (”Start with AI” limited to 400 characters). $20/month per user, $80/month for business tier. Excels at real-time collaboration and analytics, but the AI feels like an afterthought.

Gamma sits in the sweet spot: $8-15/month with genuinely useful free tier (400 one-time AI credits). Better AI content generation than anyone except Microsoft, but without enterprise complexity or costs. Multi-model orchestration surpasses all competitors except Microsoft, and Gamma’s web-native format differentiates from traditional slides.

A Concerning Trust Problem

Here’s what concerns me: Gamma’s Trustpilot rating of 2.1/5 across 39+ reviews represents a reputational risk for a B2B tool claiming 70 million users.

Common complaints? Customer support ignoring refund requests for weeks, AI-generated automated responses with no human follow-up, image quality described as “chaotic and glitchy” for professional use, promised premium features not delivered after payment.

The volume of negative reviews remains small relative to the claimed user base, suggesting either sampling bias toward extremely dissatisfied customers or concerning patterns in user experience that could block enterprise adoption.

For context: Product Hunt rates Gamma 4.6-4.9/5 across 170+ reviews. G2 shows 4.3/5. Microsoft Store rates 4.2-4.3/5. The polarization between professional users (who love it) and dissatisfied customers (who hate customer support) creates risk.

The Series B funding presumably addresses this—50 employees can’t support 70 million users effectively. Scaling customer support infrastructure takes capital and systems, both of which this round should provide.

My Original Critique Stands (Mostly)

Go back to “I Hate PowerPoint.” My argument: any context switch from brainstorming to presenting breaks creative momentum. The medium forces you to chunk ideas into slide formats before the ideas are fully formed.

Gamma doesn’t solve this. You still develop ideas in one place (Claude.AI, docs, notes), then move to Gamma to package them. It’s a better publishing tool, not a thinking tool.

But—and this matters—the workflow I’ve developed minimizes the friction. Claude.AI generates the Gamma prompt from my raw thinking. Gamma builds the deck structure. I review and refine in Gamma rather than rebuilding from scratch.

That’s not elimination of context-switching. It’s reduction of friction within the switch.

The speed advantage matters more than I expected. When you can go from raw ideas to reviewable deck in under two minutes, the context switch feels less disruptive. Not zero, but manageable.

For client work specifically, Gamma solves a real problem: clients expect presentation files, not React component artifacts. The output needs to be editable by non-technical people using familiar tools. Gamma delivers that in a format that imports reasonably well into PowerPoint and Google Slides.

What This Says About AI Presentation Tools

The market validated my “I Hate PowerPoint” thesis in an unexpected way. The problem isn’t PowerPoint itself—it’s the forced chunking of ideas into presentation formats before ideas are fully developed.

AI tools like Gamma reduce the friction of that chunking. They don’t eliminate it.

The $68 million Series B at $2.1 billion valuation signals that investors believe AI-powered presentation generation is a durable category, not a temporary feature. The 25% CAGR growth projection for AI-specific presentation software through 2030 suggests the market expands rather than substitutes.

But here’s what keeps me skeptical: conversational AI interfaces could eliminate standalone presentation tools entirely. Anthropic’s Claude or OpenAI’s ChatGPT could embed presentation generation natively, competing with dedicated tools. Why leave your conversation to generate a deck when the conversation can generate the deck without context-switching?

Gamma’s current advantage—multi-model orchestration, prompt engineering culture, extensive A/B testing—represents a technical moat. But moats erode when platform companies decide to compete directly.

Bottom Line

I’ve created 50+ presentations in Gamma since June. It works. Fast, reasonably good output, improving steadily.

Does it solve the PowerPoint problem? No. It makes the problem more tolerable.

The workflow I’ve developed—Claude.AI for thinking, Claude-generated prompts for Gamma, Gamma for packaging—reduces friction without eliminating the fundamental context switch.

For client-facing work where deliverables need to be presentation files, Gamma beats the alternatives. For internal work or pure creative thinking, my Claude artifact approach still feels cleaner.

The $68 million raise and $2.1 billion valuation validate that AI presentation tools represent a real category with sustainable economics. Gamma’s capital efficiency (reaching this scale on $90 million total raised) and profitability distinguish it from cash-burning competitors.

But the ultimate solution to “I Hate PowerPoint” isn’t better presentation software. It’s eliminating the need to translate ideas into presentation formats at all. When that happens—when conversational AI can deliver the final format without leaving the conversation—tools like Gamma become legacy infrastructure.

For now? Gamma’s the best execution of a flawed category. Which means I’ll keep using it while hoping something better comes along.

Related: I Hate PowerPoint - my original argument about why presentation software kills creative flow, and my follow up first talking about Gamma.

The quickest gains in AI productivity don’t come from replacing senior developers doing complex architecture. They come from automating workflow tasks that slow everything else down—migrations, test generation, documentation updates. Tactical work that needs doing but doesn’t need deep thinking.

I’ve been using Warp for exactly this workflow automation. It’s been effective for my own day-to-day needs. But after my friend Chris Bunk recently introduced me to Goose—he’s another technical leader who’s practicing agentic development—I’m realizing it might be better suited for this specific use case. Not because Warp fails at workflow automation (it doesn’t), but because Goose was built specifically for it without the pressure to become a general-purpose platform.

Goose fits a particular niche—a framework purpose-built for workflow automation without the VC pressure to become everything to everyone.

Block released it in January 2025 with zero monetization strategy. No freemium tier. No enterprise upsell. No growth targets. Just “here’s a thing we built for workflow automation, maybe it’ll work for you too.”

What vibe coding actually means

When Andrej Karpathy tweeted “vibe coding” on February 2, 2025, he captured something real: the difference between building production systems and spinning up tactical solutions. Prototypes. Scripts. Tools that solve immediate problems. The kind of work where you want AI to handle execution while you focus on the actual problem.

Goose landed in this space naturally. Block’s engineers use it for 30-60 minute tasks—code migrations, generating tests, building applications from Figma designs. Not “let’s architect a new service” work. The “let’s just get this done” work that delivers immediate productivity gains. They’re handling infrastructure work, test coverage improvements, documentation updates. The stuff that needs doing but doesn’t need architectural thinking.

Block’s open source bet

Block released Goose with zero monetization strategy. No freemium funnel. No enterprise tier. No conversion targets. The architecture is straightforward: CLI interface + Rust-based desktop app, core execution engine that interprets requests and coordinates tasks, and MCP server extensions. You describe what you want—”migrate this component” or “increase test coverage above 80%”—and it handles execution.

The MCP integration provides connections to hundreds of pre-built servers for GitHub, Jira, Slack, Google Drive, databases, browsers. Not because Block needed that breadth, but because the community built it.

Block CTO Dhanji Prasanna positions it as strategic open source. The Apache 2.0 license means full permissiveness for enterprise customization, modification, whatever. No strings.

The timing mattered. MCP emerged as a potential industry standard, and Block collaborated with Anthropic on protocol development. When OpenAI adopted MCP in March 2025 across ChatGPT and their Agents SDK, followed by Microsoft’s integration through GitHub Copilot Studio and Azure AI, that early positioning paid off.

Financial backing comes from Block’s operating budget. No VC pressure to hit ARR milestones or monetize the user base. The open-source strategy also serves Block’s hiring needs—engineers care about working at companies that contribute meaningfully to open source. Hacktoberfest 2025 participation, grant programs for external developers, active Discord community.

The project picked up significant traction—over 20,000 GitHub stars in nine months. For context, that puts it in the top tier of AI coding tools by community engagement, though still behind established players like Continue (48K stars) or Cursor (25K). The adoption came through engineers finding something that works and telling other engineers about it, not through marketing campaigns.

What it actually does

For vibe coding and workflow automation, Goose delivers autonomous task execution with LLM flexibility. It interprets multi-step requests, generates code across files, executes commands to test implementations, captures and debugs errors, iterates until completion.

LLM support includes Claude (3.5 Sonnet/Haiku), all OpenAI models, Gemini, DeepSeek, local models via Ollama, 20+ providers through the Tetrate router. You’re not locked into any single vendor. For local development with privacy concerns, Ollama integration matters.

The MCP ecosystem bet matters more than current features. As OpenAI, Microsoft, Google DeepMind, Replit and Sourcegraph adopt MCP, the protocol becomes infrastructure. Community-built MCP servers for Stripe, Postgres, or internal systems work with minimal friction across Goose, OpenAI’s agents, any MCP-compatible tool.

Goose vs Warp: Different models, different results

Goose charges nothing for software. You pay LLM API costs—$100-300/month for heavy development usage. Compare that to Warp, which raised $73 million and prices at $15/month Pro, $40/month Turbo, custom Enterprise.

The meaningful difference isn’t features—it’s architecture philosophy. Warp’s multi-threading runs multiple agents simultaneously with a management interface. A consulting firm using Warp’s multi-agent capabilities documented substantial productivity improvements in their case study, though specific figures should be viewed as user-reported results rather than controlled benchmarks. Goose can run multiple instances in different terminal windows, but coordination is manual. Works fine for vibe coding where you’re spinning up quick tasks. Less useful for complex orchestration.

Warp’s $73 million war chest enables engineering velocity that community projects can’t match. They employ approximately 69 people building features, refining UX, closing enterprise deals. Multi-threaded agent execution with orchestration UI, status tracking, completion notifications provides reported time savings for heavy users according to their customer data. For complex orchestration where you’re managing five different workstreams simultaneously, this matters.

Terminal-Bench performance ranks Warp #4 with 52% success rate. The product experience shows notable consumer-grade polish—the kind of attention to detail that reduces adoption friction substantially. Platform integration creates network effects through Warp Drive’s team knowledge base that stores runbooks, workflows, environment variables that agents automatically access.

Goose’s local-first architecture provides different advantages. It runs entirely on-machine by default with zero data transmission except user-chosen LLM API calls. No telemetry. No analytics. No cloud dependencies beyond optional MCP connections. For financial services, healthcare, government agencies, this enables deployment in air-gapped environments. Security teams can review source code line-by-line, modify for internal requirements, deploy in classified environments.

Cost transparency eliminates subscription fatigue: $0 software + ~$100-300/month in API calls. A 500-developer shop pays $90,000-240,000 annually for Warp Pro or Turbo. Goose costs $0 for software plus $120,000-300,000 in LLM expenses—potentially cheaper, though requiring internal IT support.

Both models work. Commercial tools deliver polish and multi-agent orchestration. Community tools deliver transparency and focused workflow automation. Different approaches for different workflow needs.

Where productivity gains actually happen

Test generation? Comprehensive test suites in 20 minutes instead of two days. Documentation updates? Feed Goose your codebase, let it generate accurate docs while you solve actual problems. Dependency migrations? The tedious-but-straightforward work that burns hours—Goose handles it autonomously.

Community response sits around 6.5/10 on enthusiasm—genuine interest without “this changes everything” hype. Engineers appreciate specific solved problems. One developer: “I created a custom CLI command... I don’t know Go that well... Goose did it all for me in ~30 minutes.” Another: “My sister had been asking me for months to help her build a Google Docs extension but I kept putting it off. Today, we built one in just 30 minutes with Goose.”

Adoption patterns show 70% real usage versus 30% curiosity. External validation includes Databricks featuring Goose at their Data + AI Summit 2025, hundreds of community-built MCP extensions.

So what does this tell us?

Goose validates targeted application for workflow automation with clear use cases. Block’s engineers using it weekly for specific infrastructure tasks, migrations, and test coverage work prove the model works—they’re automating tactical work that slows everything else down, not trying to replace core product development with AI.

What Goose shows is what tools look like when commercial pressure doesn’t force them to promise everything. Warp needs to justify $73 million in funding with subscription revenue and enterprise deals. Every product decision gets filtered through monetization strategy. Goose has none of that pressure. Block builds what their engineers need. The community builds what the community wants.

For developers choosing tools, understand what you’re optimizing for. Workflow automation where AI delivers real gains? Goose excels—local-first, cost transparent, focused on the tasks that deliver value. Complex orchestration requiring parallel agent coordination? Warp’s multi-threading provides documented productivity improvements.

Most teams end up using both for different workflow contexts. Workflow automation is where AI coding productivity gains actually happen—and focused tools built without commercial pressure often deliver that value better than platforms trying to solve every problem.

The Claude.AI editor drove me nuts for months. Not the kind of "minor annoyance" nuts—the "throw my laptop out the window" variety.

You'd think a company building AI assistants could figure out document editing. Wrong. The editor would lose track of changes, ignore edit requests, or just... forget what we were working on mid-conversation. Classic case of brilliant AI trapped in amateur tooling.

That changed this week. Quietly, without fanfare, Claude.AI shipped what looks like a complete editor overhaul. Tool calls now bundle into threads. The interface feels snappier. Most importantly? It actually remembers what we were doing (so far so good). It also doesn't 're-type' the entire artifact to show the change, it only updates the specific section you changed. So feels snappier. I still think we need direct editing (hello GPT Canvas!).

What Was Broken (And Why It Mattered)

The old Claude.AI editor followed what I call the "nuclear option" approach: send everything to the LLM every single time. Want to fix a typo? Upload the entire document. Need to adjust one paragraph? Here's 50 pages of context the AI doesn't need.

This created two massive problems:

Direct editing was impossible. You couldn't just change a sentence—you had to describe the change and hope Claude interpreted your request correctly. Like dictating edits to someone who might not speak your language. This is still broken, IMO, but better.

Context bleeding everywhere. The AI would see every word of your document on every edit, creating bizarre behaviors where it would "fix" things you didn't ask it to touch. Change a title? Suddenly it's rewriting your conclusion.

Worse, the editor kept losing track of incremental changes. I'd request three small edits, and Claude would make two of them, ignore the third, then act like everything was fine. When you pointed out the missing change, it would either claim it already made it or suggest starting over.

Professional writing workflows don't work this way. You need precise control, reliable execution, surgical changes. The old editor felt like performing surgery with a sledgehammer.

The Threading Revolution

The new system bundles tool calls into conversation threads instead of treating each edit as an isolated event. Sounds simple. Changes everything.

Now when I request multiple document changes, they flow together as a coherent conversation rather than disconnected commands. The AI maintains context about what we're working on, remembers the sequence of changes, builds on previous edits rather than treating each one as starting from scratch.

Example: Yesterday I asked Claude to:

1. Restructure the introduction

2. Add more specific examples in section three

3. Tighten the conclusion

Under the old system, this would have been three separate "send the entire document" operations. The AI might have forgotten the introduction changes by the time it reached the conclusion. Or applied contradictory formatting across sections.

The new threading approach handled all three requests as parts of a single editing session. Context carried forward. Changes built on each other. No weird inconsistencies or forgotten requests.

Visual Features That Actually Help

The interface updates aren't just cosmetic. The new visualization features make the editing workflow more transparent—you can see what Claude is thinking about, which sections it's focusing on, how changes connect to each other.

This matters because AI editing requires trust. When the system ignores a request or makes unexpected changes, you need to understand why. The old editor was a black box. Make a request, cross your fingers, hope for the best.

The updated interface shows you what's happening. Not full transparency—it's still an AI making decisions—but enough visibility to build confidence in the process.

What Still Needs Work

The editor improvements are significant, but this isn't a complete transformation. Some fundamental limitations remain:

The "send everything" model persists. Threading makes it smarter, but Claude still processes entire documents rather than making targeted edits. This creates latency and cost issues for larger documents.

Complex formatting gets messy. Rich text, nested lists, image placements—anything beyond basic text structure can confuse the AI. It's better at understanding what you want but still struggles with precise formatting control.

Version control is nonexistent. No branching, no revision history, no way to compare document states. If Claude makes changes you don't like, your only option is asking it to undo them or starting over.

The Bigger Picture

These editor improvements signal something important about AI tool development. The companies succeeding long-term aren't just building better models—they're building better interfaces for working with those models.

Claude's AI capabilities have been strong for months. What held back adoption was the frustrating experience of actually using those capabilities. Fix the interface, and suddenly the AI becomes more valuable.

This pattern repeats across AI tools. GitHub Copilot's success isn't just about code generation—it's about seamless IDE integration. Cursor works because it handles the editing workflow thoughtfully, not just the AI suggestions.

The Claude.AI editor still isn't perfect. But it's finally usable in professional workflows. That's the threshold that matters—not perfect AI, but good enough AI wrapped in tools that actually work.

Should You Try It?

If you've avoided Claude.AI's editor because of past frustrations, it's worth another look. The threading system alone makes document collaboration significantly more reliable.

For professional writing workflows, it's particularly valuable for:

• Draft restructuring - The AI maintains better context across large changes

• Content iteration - Multiple rounds of edits build coherently rather than conflicting

• Collaborative editing - When working with AI on complex documents that need many revisions

The improved editor doesn't change Claude's core AI capabilities, but it makes them accessible in ways that weren't possible before. Sometimes the interface matters more than the intelligence behind it.

Good timing too. As AI writing tools proliferate, the ones that survive will be those that respect how humans actually work—not the ones that force us to adapt to their limitations.

The new Claude.AI editor feels like a step in the right direction. About time.

It’s no secret that I've been a fan of Augment Code since March. When I'm not using Claude Code, they're my go-to backup—consistently getting better and notably faster over the past few months. Their advanced context management and code indexing are impressive achievements. So when they announced Auggie, their new CLI tool, I was intrigued.

I've written before about the limitations of working inside VS Code. CLI-based models for agentic coding just work better for me. So on a train ride up to San Francisco today, I decided to give Auggie a real test on a problem that had been bothering me for days.

The Problem That Wouldn't Die

My Claude MPM framework has this 3D graph visualization feature—an AST-based file explorer using D3.js to render code relationships. Claude Code couldn't crack it across multiple sessions. The complexity of coordinating D3.js rendering with file system analysis kept leading us in circles.

Within 45 minutes on that train ride, Auggie and I had it working.

What Makes Auggie Different

Let me be clear upfront: Auggie doesn't support sub-processes or sub-agents like Claude Code does. It's a single-process tool, full stop. No spawning specialized agents for different tasks, no parallel exploration of multiple solution paths.

But here's what struck me: sometimes you don't need an army. Sometimes you need one really good soldier who understands the terrain.

Auggie's Context Engine automatically indexed my entire MPM codebase—all the clues I'd left in various files, the CLAUDE.md instructions, the interconnected module relationships. I fired it up and Auggie just... understood. The tool said at one point, "Now I can see the pattern," when working through the D3.js integration. Pretty cool.

This contextual superiority aligns with what I've seen in my broader tool comparisons. Augment Code consistently excels at whole-codebase understanding.

The Claude Code Influence (In a Good Way)

Augment Code clearly studied Claude Code's interface, and I mean that as sincere flattery. The terminal UI looks remarkably similar—so much so that muscle memory transfers immediately. They've even implemented slash commands that Claude Code users will recognize:

• /model for switching between models mid-session

• /task for opening the task manager

• /github-workflow for CI/CD integration

• Custom commands via auggie command <n>

The three operating modes feel natural:

• Interactive mode: Full terminal UI with streaming responses

• Print mode: auggie --print "instruction" for single commands

• Quiet mode: Returns only final output, perfect for piping

Where It Shines

Speed and responsiveness. This thing is fast. Noticeably faster than Claude Code on similar tasks, and much smoother than Codex CLI or Gemini CLI. Response streaming feels instantaneous. They’re using the same models, but CC add’s processing overhead in it’s hugely complex client which Auggie avoids.

Context understanding. The automatic codebase indexing is remarkable. I didn't have to explain my project structure or manually include files. It discovered the relationships between modules, understood my documentation patterns, and applied that knowledge to solve the D3.js problem.

Focus. Without sub-agent capabilities, Auggie forces you to think differently. Instead of orchestrating multiple agents, you're having a focused conversation with one highly capable assistant. For the Three.js debugging session, this constraint actually helped—we stayed on target instead of exploring tangential paths.

Input validation against project context. Here's something unexpected: I accidentally pasted a prompt from a different project during one session, and Auggie caught it immediately. "That doesn't seem related to your current codebase," it said, asking for clarification. Claude Code would typically just run with it, trying to solve whatever you throw at it regardless of relevance. This kind of sanity checking shows Auggie isn't just indexing your code—it's actually understanding your project's boundaries and purpose.

The Early-Stage Reality

Let's talk about what's missing, because these limitations matter.

No image support. You can't paste screenshots or diagrams into Auggie. For visual debugging or UI work, this is a real problem. I couldn't show it what the broken D3.js rendering looked like.

Large text blocks fail. Pasting substantial code snippets or logs often breaks the UI. The input handling isn't as robust yet. I had to work around this by referencing files rather than pasting content directly.

No sub-agents means no delegation. While focused single-process work has advantages, complex projects that benefit from parallel exploration hit a wall. Claude Code can spawn specialized agents for testing while another handles implementation. Auggie can't.

Diff visualization is rough. Multiple users cite this as a dealbreaker, and I understand why. The diff rendering is primitive compared to Claude Code's mature implementation. You're often accepting changes on faith rather than clear visual confirmation.

The Remote Agent Question

Augment offers Remote Agents as a cloud-based feature—up to 10 parallel agents working 24/7 on your codebase. But these aren't integrated with Auggie CLI yet. They're accessible through VS Code, with CLI integration "on the roadmap."

This feels like a missed opportunity. If Auggie could trigger Remote Agents from the CLI, even without native sub-process support, it would address the parallel processing limitation.

The Verdict: Right Tool, Right Job

After that train ride success, I'll continue using Auggie for specific types of problems. When I need focused, deep work on a complex technical issue—especially one requiring comprehensive codebase understanding—Auggie excels.

For single-problem debugging sessions where context matters more than parallelization, Auggie often outperforms Claude Code. The D3.js issue that stumped multiple Claude MPM sessions fell to Auggie's superior context grasp in under an hour.

But Claude MPM remains superior for orchestrating complex, multi-faceted development where you want specialized agents handling QA, documentation, and implementation simultaneously. Different tools for different jobs.

Should You Try It?

If you're hitting context limitations with Claude Code, absolutely. The $50/month developer tier gets you about 600 messages—expensive for individual developers, but the Context Engine might justify the cost if you work with large codebases.

If you need multi-agent orchestration, stick with Claude Code or wait for Auggie's Remote Agent CLI integration (and frankly I suspect Augment Code will be adding multi-agent support in the relatively near future)

If you're frustrated with token management and context windows, Auggie's automatic indexing feels like magic.

Bottom Line

Auggie CLI is an impressive early effort that gets some fundamental things very right. The Context Engine's automatic codebase understanding is genuinely superior to anything else I've used. The single-process limitation forces focused problem-solving that can be surprisingly effective.

But it's still early days. The missing image support, text input limitations, and primitive diff visualization create real friction. The lack of sub-agent support isn't just a feature gap—it's a philosophical difference that limits certain workflows.

I'm keeping my Augment Code subscription. For focused, context-heavy debugging sessions, Auggie has already proven its worth. That D3.js problem would probably still be unsolved without it.

I’m not wondering whether Auggie can replace Claude Code—it can't, and that's not the goal. The question is whether its superior context understanding justifies adding this tool to your arsenal.

For me, solving that persistent D3.js issue in 45 minutes on a train answered that question.

Have you tried Auggie CLI? I'm curious how others are working around the sub-agent limitation. Hit reply and let me know if you've found creative solutions.

Related Reading:

• How I Trained Augment to Run Git and GitHub - Teaching AI proper Git workflows

• Why Augment Code Is Betting Beyond the IDE - Deep dive on Remote Agents and the future direction

When Google announced Opal, their new vibe coder entry, I had to try it. The space currently has Bolt, Lovable, Replit, and V0. Lovable leads the pack with Bolt gaining ground thanks to its Figma partnership. V0 does interesting work with API-driven vibe coding and design system integration.

So what's Opal's angle?

I'm not sure, actually. It looks more like a no-code tool than a proper coder. Maybe that's the point—point-and-click coding. I gave it a detailed prompt to build a travel intelligence platform requiring vector-based semantic search, database integration for knowledge storage, real-time data collection from multiple APIs, and export functionality including PDF generation. The system needed to handle user profiles, routing optimization, and offline capabilities.

Opal created a basic visual workflow with input nodes for "destination" and output nodes displaying text suggestions. No database schema, no API integrations, no file export capabilities. When I asked it to use form controls instead of text prompts for user input, it ignored the request entirely.

What Opal actually builds

Google's Opal creates visual workflow diagrams rather than actual code files. Users describe their app in natural language, and Opal creates a node-based flowchart showing inputs, AI model calls, and outputs.

You never see traditional code in JavaScript, Python, or React. You can edit prompts within each node, but the underlying execution stays hidden. This positions Opal closer to automation tools like Zapier than to legitimate code generation platforms.

The workflow consists of input nodes for data entry, processing nodes for AI transformations, and output nodes for displaying results. Unlike competitors that produce downloadable, deployable code, Opal apps remain locked within Google's ecosystem with no export capabilities.

Here's what struck me: this misses recent advances in deployable-code workflows that the market has embraced. Every serious vibe coder now gives you actual code you can deploy, modify, and own.

The competitive landscape Google entered

According to reports from tech publications tracking the space, Lovable raised $7.5M in Series A funding and their GitHub repository shows substantial community adoption. They generate production-ready React/TypeScript code with full GitHub integration. Their "Select to Edit" feature lets you directly manipulate components, and Supabase integration provides authentication, databases, and edge functions.

Bolt formed a strategic partnership with Figma, allowing users to transform Figma designs into production apps with one click. This integration, powered by Anima, strengthens the design-to-development workflow without requiring acquisition costs.

V0 by Vercel has carved out a niche as a UI specialist, releasing its "v0-1.0-md" model via API for premium subscribers at $20-30/month. They generate actual React components with proper TypeScript definitions.

Replit Agent offers browser-based development across 50+ languages, leveraging bounty service data where users describe projects in natural language. Their $20/month Core plan includes deployment infrastructure.

Notice the pattern? They all produce actual code. Files you can download, modify, deploy, and scale.

What developers actually said about Opal

One Medium author built an AI calisthenics assistant in 10 minutes, praising the "frictionless sharing" but acknowledging limitations for complex applications.

A Hacker News user encountered what they described as "possibly the ugliest error I have ever seen" when attempting to build a complex community gathering app. While this represents one user's experience, it illustrates the challenges Opal faces when handling multi-faceted requirements beyond simple, linear workflows.

Developer blog posts consistently describe it as "Canva, but for mini-apps." That's misaligned with what many developers prioritize in production tools.

The pattern in early feedback suggests Opal serves as a tool for rapid prototyping and idea validation rather than serious development. Success stories focus on content creation tools, productivity apps, and educational helpers—all front-end focused applications without backend complexity.

Technical gaps that matter

The technical comparison reveals fundamental problems. Opal offers no API generation, database integration, server-side logic, or authentication systems. Compare this to Lovable's native Supabase integration, Bolt's Node.js server support, or Replit's multi-language API capabilities.

Opal apps remain trapped on Google's servers with link-based sharing only. No custom domains. No GitHub integration. No export options.

This isn't just a feature gap—it suggests a different understanding of developer priorities. Developers need more than visual automation—they need control, scalability, and code portability.

My assessment: Wrong market positioning

Google Opal misses advances that define the current vibe coding movement. We're not looking for visual workflow builders. We want tools that enhance our development capabilities while maintaining code quality and control.

Industry reports estimate the low-code/no-code market at various sizes, but the value in vibe coding specifically comes from tools that generate real, deployable code. Opal's visual workflow approach exists in automation tools and adds limited value beyond integrating Google's AI models into a flowchart interface.

For complete beginners and hobbyists, Opal might find a niche. It competes more with traditional no-code tools than development platforms. But without backend capabilities, code export, or production scalability, it suggests a different understanding of where this market has moved.

It's Google, so don't count them out entirely. But personally, I found it underwhelming on key developer criteria. If you want a flexible no/low-code tool for simple workflows, this might work for you. If you want to generate actual code you can deploy and scale, stick with the established players.

The industry has moved beyond visual builders toward real code generation. Opal misses this shift into a problem we've already solved better elsewhere

.

Related Reading

Google Jules First Look: Not Ready for Prime Time - my hands-on review of Google's autonomous coding agent

I've been using Warp as my primary terminal for some time now. It's a good addition to anyone's desktop—fast, modern, with features that improve daily workflow (no more looking up command parameters - ever!). So when they announced Warp Code, their AI coding assistant, I was curious but also cautious. Terminal companies expanding into AI development tools? We've seen this story before.

But here's the thing: they got some basics right immediately.

What Works

The LLM access is solid. Claude Sonnet 4 and GPT-4o as options—no proprietary models, no compromises. You can switch between models per conversation, though I found myself sticking with Claude for most coding tasks. When I'm debugging TypeScript compilation errors or wrestling with Chrome extension manifests, I want reliable reasoning. Warp Code delivers that.

The integration feels natural within Warp's existing environment. Unlike bolt-on AI features that feel foreign, this builds on Warp's command suggestions and workflow integration. When you're deep in a debugging session, asking the AI doesn't break your flow.

It handles straightforward coding questions competently. During my testing session building a Chrome extension, Warp Code correctly explained manifest syntax requirements and suggested proper TypeScript configurations. For standard debugging workflows—understanding error messages, suggesting configuration fixes—it performs as expected.

The pricing sits at $20/month with an annual discount for basic access. There's also a $200/month tier for heavier usage, though most developers won't need it for occasional AI assistance.

The Fundamental Problem

Here's where things get interesting—and problematic.

Modality confusion is real. You're coding in an IDE or editor, but the AI assistant lives in your terminal. This creates constant context switching that breaks flow. When Warp Code suggests file changes, I still need to manually navigate to my editor, find the file, and implement the changes. It's functional, but it's not fluid.

The terminal isn't built for code review. Warp Code can generate solutions and debug problems, but reviewing complex outputs feels cramped in a terminal interface. Compare this to Zed, which embeds rich data viewers—interactive trees, formatted JSON, side-by-side diffs—directly in the editing environment. Warp Code shows you text. That's it.

Context handling has limits. The AI remembers our conversation within a session, but start a new terminal window and you're starting fresh. For ongoing development work, this means repeatedly re-establishing project context.

The Bigger Question

Testing Warp Code surfaced something I've been thinking about across all these AI coding tools: What differentiates them when they're all using the same frontier models?

Claude Sonnet, GPT-4o, the emerging reasoning models—the core AI capabilities are increasingly similar. The prompting strategies are converging. The basic workflows (chat, generate, iterate) are nearly identical.

The real differentiators are becoming infrastructure:

• Tree-sitter parsers for code understanding

• Semantic indexing for large codebases

• Build system integration

• Context management across sessions

• UI/UX for complex data review

But here's the question that keeps surfacing: Where is coding actually heading?

If AI can handle more routine coding tasks autonomously, the primary interface might shift from "place where I write code" to "place where I direct and review code." That's a fundamentally different tool category.

Warp Code feels like it's positioning for this transition. Rather than trying to replace your IDE, it's building the command-and-control interface for AI-driven development. Issue commands, review outputs, iterate on requirements—all from the terminal where you're already orchestrating builds, deployments, and system interactions.

Bottom Line Assessment

Should you try Warp Code? If you're already using Warp and occasionally need AI assistance with coding questions, yes. The AI integration is competent, the model access is high-quality, and it enhances rather than disrupts existing terminal workflows.

Will it replace your primary coding setup? No. The modality gaps are too significant for complex development work. You'll still do your actual coding elsewhere.

Is it positioned correctly for the future? That's the interesting question. As coding becomes more agent-driven, the terminal might indeed become the primary control interface. Warp Code feels like an early experiment in that direction.

The real test isn't whether Warp Code works today—it does, for what it attempts. The test is whether their architectural assumptions about the future of coding interfaces prove correct.

Warp Code is available now with Claude Sonnet 4 and GPT-4o integration. $20/month with annual discount for basic usage; $200/month tier for expanded access.

The full refactoring work is available on GitHub if you want to see what was accomplished.

What Works

The core functionality delivered. When I asked it to systematically break down large TypeScript files into logical units, Zen Coder handled it competently. It read my project's INSTRUCTIONS.md files correctly, generated clean code that followed established patterns, and maintained proper imports throughout the refactoring.

The "Repo Grokking" feature genuinely understands codebases. Unlike tools that work file-by-file, it demonstrated comprehensive awareness of my project structure. Made sensible decisions about module separation. Kept architectural consistency across multiple files.

One feature genuinely impressed me: the session summarizer. At the end of our work, it provided this kind of clear overview:

"We have successfully fixed the test failures in the codebase after merging the refactor/prepare-codebase branch into main. Fixed ModelInfoUtils.ts... Fixed OutputHandler.test.ts... Fixed ReviewExecutor.ts... Ran the full test suite... Committed and pushed changes..."

That's genuinely useful documentation—the kind developers want but rarely take time to write themselves. It understood scope, tracked what was fixed, presented it clearly.

The Complexity Problem

Here's where Zen Coder loses me: it's built around "multiple specialized agents" that supposedly handle different aspects of development. Coding Agent, Unit Test Agent, custom workflow agents.

But during my entire refactoring session, I never understood when I'd want a different agent or why switching would help. The system never explained the benefits or suggested optimal contexts for agent switching.

I used the default interaction for everything. It worked fine. The promised "agent orchestration" felt like marketing, not meaningful functionality.

UX Issues That Add Up

Several design decisions created unnecessary friction:

Terminal confusion: When Zen Coder launched commands requiring my input, it just waited. No indication it needed my response. I spent several minutes wondering if it was processing before realizing I needed to hit enter. Basic UX oversight.

Even worse, it had the annoying habit of executing commands in a terminal, then immediately closing that terminal and reverting to the previous one. So I couldn't see what happened in the terminal session. Want to check if that command worked? Good luck—the evidence just disappeared.

Permission redundancy: Despite approving changes through Zen Coder's tools, it kept asking permission to run those same tools. The "step limit" feature pauses after certain steps, which felt redundant when it's already asking for individual command approval.

Missing system instructions: Despite its repository analysis capabilities, Zen Coder repeatedly asked for help understanding my repo in new sessions. It offers manual instruction input, but there's no automatic way to read existing instruction files (INSTRUCTIONS.md, .cursorrules) that most developers maintain. If it can read my entire codebase, why can't it discover my documented conventions?

Plugin-based sessions: The UX reminded me of Zed's approach—session history with exposed artifacts—but felt clunkier because it's running as a plugin rather than native integration.

Market Reality Check

The research confirms my experience. InfoWorld's review characterized Zen Coder as "wet behind the ears," noting its innovations "aren't ipso facto better" than competitors generating correct code immediately.

Technical limitations include:

• Repository analysis takes significant time with apparent full reprocessing on refresh

• Agent repair capabilities limited to simple bugs versus complex whole-repo fixes

• Error-corrected inference pipeline doesn't demonstrably outperform models that generate correct code initially

Team Features Nobody Asked For

Zen Coder's major differentiator is team collaboration—creating and sharing "Zen Agents" across organizations. The platform emphasizes workflow standardization and institutional knowledge transfer.

This sounds compelling in theory but reflects a fundamental misunderstanding of how developers work. We want tools that help us code better, faster, with fewer errors. We don't want to manage agent libraries or orchestrate workflow handoffs.

The pricing model—550 "Premium LLM Calls" per user per 24 hours at $19-39/month—adds complexity without clear value over straightforward subscriptions.

Different Tools for Different Jobs

Against established alternatives, Zen Coder's value proposition is unclear:

Regular Claude delivers the same underlying capabilities with less ceremony. Claude's coding assistance is excellent without agent orchestration overhead.

Cursor offers superior user experience, more intuitive interface, competitive pricing at $20/month. The IDE experience is simply better.

GitHub Copilot provides universal familiarity, seamless integration, enterprise trust through Microsoft backing. Does what most developers need without complexity.

Windsurf delivers more polished implementation, cleaner interface, competitive features at lower cost.

Augment Code operates in similar fashion to Zen Coder—remote agents, multi-step operations—but with a far more streamlined interface within VS Code. Where Zen Coder's agent orchestration felt like marketing theater, Augment's remote agents delivered practical value. I'll cover this in detail in a separate review, but the contrast is telling: similar underlying concepts, dramatically different execution quality.

Zen Coder excels at repository understanding and offers team collaboration features. But these advantages don't overcome the UX friction and implementation gaps.

Bottom Line

Zen Coder isn't broken—it's overcomplicated. The core technology works, agents produce quality code, repository understanding is genuinely useful. But it wraps these capabilities in unnecessary complexity that creates more problems than it solves.

The platform feels designed by people who think about AI development theoretically rather than practically. Real developers want tools that get out of their way, not platforms requiring them to think about agent orchestration and workflow management.

For teams satisfied with existing AI coding tools, there's no compelling reason to switch. The promised collaboration benefits don't materialize for most development workflows, and technical execution lags behind more polished alternatives.

If you're looking for AI coding assistance, stick with proven options. They deliver the same core benefits with less friction and more predictable experiences.

Zen Coder represents the kind of overengineered solution that happens when startups feel compelled to differentiate in crowded markets. Sometimes the simpler tool really is the better tool.

Based on hands-on testing with TypeScript refactoring and comprehensive market research. Your experience may vary.

On Friday, I published a piece about why I hate PowerPoint and demonstrated how Claude AI can quickly turn outlines into functional slideshows. I stand by that approach during the development phase—when you're iterating on structure, having an interactive model that responds to prompts beats wrestling with slide templates every time.

But I'm eating a little crow today after actually trying Gamma.

Turns out, purpose-built AI designed around turning ideas into presentations might actually be how most people solve their presentation problems going forward. Who knew?

The Gamma Reality Check

I took the demo slideshow I'd created for one of my clients—the same one I'd used to demonstrate the Claude approach—and literally copy-pasted the text outline into Gamma without any modifications. That's it. No formatting, no style guidance, no design direction.

Gamma picked out the style, illustrations, and format entirely by itself. In literally no time, with zero effort on my part beyond the paste operation, it turned that raw outline into a genuinely stunning presentation.

Here's the actual result

Were I to give that presentation again, I'd likely use this version. The visual design, the flow, the polish—it's exactly what you'd want for a client-facing deck without the usual hours of formatting hell. Pretty impressive considering it had nothing to work with but plain text bullets.

The Refined Workflow

Does this mean always use Gamma? Not quite. Here's what I think the optimal workflow actually looks like:

Phase 1: Structural Development Use Claude (or similar) for rapid iteration on content and structure. The back-and-forth of refining bullets, reordering sections, and testing different angles works best when you can prompt your way through changes instantly.

Phase 2: Final Polish Once your structure is solid, tools like Gamma shine. Copy-paste your refined outline—no formatting required—and let it handle everything: visual design, illustrations, layout, typography. The fact that it made intelligent design decisions from nothing but raw text bullets is genuinely impressive.

The limitation remains: Gamma isn't as interactive for mid-stream edits. If you want to rearrange bullets or restructure sections, you're better off going back to the prompt-driven approach, then re-generating the polished version.

What This Really Means

This experience reinforces something bigger: AI prompting over traditional tooling is clearly where UX is heading.

Instead of:

• Opening PowerPoint

• Choosing a template

• Fighting with slide layouts

• Manually formatting elements

• Spending hours on visual consistency

We get:

• Copy-paste your outline

• Let AI make all design decisions

• Get a polished result instantly

• Focus purely on content quality

The fact that Gamma produced a client-ready presentation from nothing but raw text bullets—no style guidance, no formatting hints, no design direction—demonstrates how far this approach has already come.

Gamma represents the first wave of this shift, and while I don't know if it's the best solution, it's pretty impressive. More importantly, it validates the fundamental premise: when AI can understand intent and execute design decisions, the traditional software interaction model starts looking absurd.

The Honest Assessment

My Friday point about Claude for slideshow development? Still valid for the messy, iterative work of getting your ideas straight. But Gamma has shown me that the final presentation layer is ripe for this kind of AI-first approach.

The real insight isn't that one tool beats another—it's that we're seeing the emergence of a genuinely better workflow. Prompt-driven content development feeding into AI-powered design execution.

That's not just an incremental improvement over PowerPoint. That's a completely different category of solution.

Bottom Line

I still hate PowerPoint. But I'm starting to love what comes after it.

The future of presentations isn't about better slide software—it's about describing what you want and having AI figure out how to make it compelling. Gamma gets us closer to that reality than anything I've used before.

Now I just need to figure out how to expense a Gamma subscription as "competitive research."

Then along comes Zed.

I'll be honest: I wasn't familiar with this editor before diving in. But after spending serious time with it on a real testing framework conversion, I'm convinced they've cracked something fundamental about AI-first development environments. They didn't start with an editor and add AI—they started with the AI session and built an editor around it.

What Zed Actually Is

Zed positions itself as a task-focused, minimalist editor built around three configurable pane areas. You get an editor window (which you can dismiss entirely if you're doing pure AI work), a context-aware navigation pane that intelligently toggles between file trees, code outlines, and git status, and here's the key: a dedicated AI session view where the real work happens.

The interface feels deliberately uncluttered. After years of VS Code's extension sprawl and notification chaos, Zed's clean lines are refreshing. But don't mistake minimalism for lack of power.

The AI Experience: Claude-Quality Results

Zed offers multiple model choices, but I worked primarily with Claude Sonnet. The responses felt identical to Claude Code, matching the quality I've seen using Claude Code in VS Code. Same reasoning patterns, same ability to understand complex instructions.

I put this to the test with a real workflow. I fed Zed my Claude.md reference file (the one I've customized with project instructions, file references, and development workflows) and asked it to handle a testing framework conversion. Not only did it parse and follow the instructions correctly, but it seamlessly worked with the GitHub API to create issues, managed Git branching, and maintained context across a complex, multi-step process.

It did make one mistake initially, forgot to work in a feature branch, but Zed recovered smoothly by re-scoping all changes to the proper branch structure. A small miss, but handled well.

What impressed me most: when I asked Zed to commit changes, it automatically re-reviewed the project instructions I'd provided earlier. This is context management that Claude often misses—maintaining awareness of core project requirements across long sessions. The fact that Zed preserves and actively references foundational instructions shows sophisticated session state management.

Even more impressive: Zed took my workflow instructions seriously and kept working on CI/CD test requirements until they actually passed. Unlike Claude, which tends to give up when tests fail repeatedly, Zed persisted until it got them working. Good thing too—I'd been skipping those failing tests for weeks. Zed basically forced me to clean up technical debt I'd been avoiding.

In terms of raw AI capability, this is Claude Code territory. But the interface makes all the difference.

The Streaming Session Revolution

Here's where Zed fundamentally changes the game. Unlike static diffs, Zed streams each micro-change as a real-time breadcrumb trail. You're not just watching aggregate results—you're seeing the AI's thought process unfold sequentially.

Each edit appears granularly: "Updating function signature," followed by the actual change, then "Adding error handling," with its corresponding code. Unlike traditional editor-based changes where you can't trace which request triggered which modification, Zed's session view maintains perfect lineage.

But here's the killer feature: full terminal session capture. When Zed runs tests, builds, or any command-line operation, you see the entire terminal history embedded in the session. Each interactive run becomes a timestamped moment you can scroll back to and review.

This is profound. You're not just getting code changes—you're getting the complete development context. Test failures, build outputs, deployment logs, all integrated into a coherent narrative of what the AI actually did.

If I were Anthropic, I'd be looking at this interface as a superior paradigm to plain terminal interactions. The session view provides visibility that transforms AI coding from blind trust to informed collaboration.

One fix needed: scroll position jumps when reviewing past edits.

Architecture Enabling AI Innovation

What makes this possible is that Zed didn't start with an existing editor and bolt on AI features. They built everything from scratch in Rust with AI workflows as a first-class consideration.

The team completely rewrote their approach from Atom's JavaScript/Electron foundation. Nathan Sobo's team implemented what they call a "custom streaming diff protocol that works with Zed's CRDT-based buffers to deliver edits as soon as they're streamed from the model." You see the model's output token by token, which creates the granular change tracking I described above.

Their GPUI framework treats the entire interface like a video game, rendering everything on the GPU. This isn't just for performance—it enables the seamless integration of terminal sessions, code changes, and AI interactions into a single, coherent stream.

By owning the full stack from Tree-sitter parsing to GPUI rendering, they could architect tight integration between their "fast native terminal" and "language-aware task runner and AI capabilities." This is why terminal sessions appear seamlessly in the AI session view rather than feeling like separate tools awkwardly connected.

The contrast with Atom is striking. Where Atom used "an array of lines, a JavaScript array of strings" for the buffer, Zed uses "a multi-thread-friendly snapshot-able copy-on-write B-tree that indexes everything you can imagine." This architectural foundation enables the real-time collaboration and streaming AI features that define Zed's experience.

Performance and Polish

Zed's Rust foundation delivers on its performance promises. The editor is genuinely fast—no spinning wheels, no stuttered typing, no lag switching between files. Coming from Electron-based tools, the responsiveness feels almost shocking.

I found myself closing the traditional editor pane entirely, working in a two-screen setup with git/tree view on the left and the AI session on the right. And here's the concerning part: I might prefer this UX to VS Code with Claude Code integration.

Also lots of little niceties: when you “copy relative path” in the file browser, it automatically adds it to context. Another is that it can allow changes and modifications to the stream and handle them automatically, integrate them into their workflow while then resuming the tasks they were working on before.

One UX improvement I'd love: show the current git branch consistently, regardless of whether you're in code view or git view. Small detail, but it matters for workflow awareness.

That said, I'm convinced enough that I'm already planning to use Zed for several upcoming projects.

Pricing Reality Check

Zed's pricing is refreshingly straightforward: $20/month for 500 prompts, then usage-based billing beyond that (at the time of writing). For context, I converted roughly 50% of the testing framework for a substantial codebase (47,000+ lines of TypeScript) using 150 prompts.

If you're doing heavy AI-first development—100% prompt-driven like I was testing—you'd probably exhaust the 500 prompts within a week. But for mixed human/AI workflows, this pricing feels sustainable and affordable.

I suspect they'll adjust pricing upward or offer higher-tier prompt packages as adoption grows. The current model feels designed to attract users rather than maximize revenue.

Bottom Line Assessment

Zed has earned a spot among my favorite new development tools. It might be superior to Augment, and it's definitely a better AI coding experience than traditional editor-based approaches.

The streaming session view alone justifies trying Zed. Watching AI development unfold with full context—code changes, terminal outputs, git operations—provides insight into AI reasoning that other tools simply can't match.

Is it perfect? No. The scroll behavior needs fixing, pricing will likely increase, and you're locked into their ecosystem rather than enhancing your existing workflow.

But they've solved a fundamental UX problem that most AI coding tools ignore: how do you make AI development visible, trackable, and collaborative rather than mysterious and opaque?

What This Means for AI Development Tools

Zed proves that AI coding tools need rethinking from the ground up, not just bolting AI features onto existing editors. The session-based paradigm offers advantages that traditional editor-based or terminal-based approaches can't match.

More importantly, it demonstrates that UX innovation matters as much as AI capability. Claude's reasoning power paired with Zed's interface creates a development experience that's genuinely superior to either component alone.

For developers frustrated with existing AI coding workflows, Zed deserves serious evaluation. For established players in this space, it should be a wake-up call about the importance of interface design in AI-first development environments.

Zed doesn't just add AI—it rethinks what working with it should feel like.

Multiple specialized agents handling different aspects of development. A local MCP bridge connecting to your actual environment (something I use extensively in my own AI workflows). The promise of truly autonomous coding—not just assistance, but "set it and forget it" development where you hand off a task and come back to finished work.

After spending time with CodeDroid on a real bug fix for my AI code review tool, here's what I found: great architectural vision, flawed execution, and a product that isn't ready for serious development work.

What Factory AI Gets Right

The specialized agents concept makes sense. Instead of one monolithic AI trying to handle everything from coding to testing to documentation, Factory breaks this into distinct Droids: CodeDroid for implementation, Review Droid for pull requests, QA Droid for testing, and others for specific workflow stages.

The local MCP bridge approach clicked with how I already work. Having an agent that can actually interact with your local environment—run builds, execute commands, understand your project structure—feels like the natural evolution beyond browser-based coding assistants.

Most importantly, CodeDroid actually solved the specific bugs I reported. It understood my workflow for creating GitHub issues, worked properly in a feature branch, and delivered fixes for the problems I described. That's table stakes, but worth noting when so many AI tools struggle with basic task completion.

The Fundamental Architecture Problem

Here's where things get interesting, and not in a good way.

Factory markets itself as autonomous, but requiring users to manually switch between agent "modes" isn't autonomous behavior. A proper multi-agent system should have an orchestrator agent that takes your task, understands the full workflow, and delegates appropriately. It should hand off to documentation agents when specs need updating, QA agents when testing is required, research agents when context gathering is needed—and just return results.

Right now, it's more like an app switcher for different AI roles than a true autonomous system. You pick your agent like you're picking a tool from a menu—not assigning a task and letting the system run with it.

When I asked CodeDroid to handle my bug fix, it never automatically transitioned to testing phases or involved other agents. I got code changes but no validation that the broader system still worked. For something positioning itself as enterprise-grade autonomous development, this feels like a fundamental architectural oversight.

Speed That Kills Productivity

The performance issues are brutal. Compared to Cursor's sub-30-second turnarounds or Claude Code's near-instant drafts, Factory's response times feel stuck in staging. We're not talking about marginally slower—this was painfully, productivity-killingly slow.

The bigger problem is feedback. Factory's UX assumes you'll start a task and walk away, but even if that's the intended workflow, you need meaningful progress indicators. Instead, you get minimal feedback during long operations, making it impossible to tell if the system is working or stuck.

This might be token conservation at play—enterprise pricing models often encourage batched operations over interactive responsiveness. But when tools like Claude Code deliver near-real-time responses with superior quality, the value proposition breaks down.

UX Contradictions

The interface reveals more complexity than it should. If autonomy is the goal, the system shouldn't be asking me to watch a context panel like a flight dashboard. But that's exactly what Factory does—three separate windows (session, context, history) compete for attention when the promise is hands-off operation.

Basic usability issues compound the problem. The history window proved useless—I could never parse what tasks were actually running. Multiple times, dialog boxes for accepting changes were hidden behind other columns, leaving me confused about why the system appeared stuck.

When CodeDroid needed permissions for non-trivial operations, it required manual approval or would halt progress. Again, this contradicts the autonomous positioning. Either work in a feature branch where it can do everything safely, or build proper permission models that don't require babysitting.

Execution Gaps That Undermine Trust

CodeDroid fixed the specific issues I reported, which is good. But it didn't catch other TypeScript compilation errors and linting issues that already existed in the codebase. To be clear—it didn't cause these problems, but it didn't identify them either. More problematically, it claimed successful builds and mentioned fixing these problems, but when I tried to actually compile and run the code, things failed.

I'm not sure how it tested its changes if the build was broken. Maybe that's QA Droid's job, but without automatic handoff between agents, these gaps become visible and concerning.

The system also failed silently on GitHub API integration. I have a specific workflow where my AI tools create issues using environment variables, but CodeDroid couldn't execute this despite acknowledging the limitation only after attempting the work. For enterprise-grade tooling, upfront capability assessment should be standard.

Quality Doesn't Match the Claims

Despite reportedly using Sonnet models, the output quality felt inferior to what I get from Claude Code or Augment Code. This might be prompt engineering, context management, or architectural overhead, but the results matter more than the underlying model choice.

When you're positioning as premium enterprise tooling with autonomous capabilities, the bar is high. Traditional "assisted" tools like Cursor feel more autonomous in practice because they maintain momentum, provide clear feedback, and deliver reliable results.

The Trust Problem

Autonomous coding only works if you trust the outcomes. And trust, in this space, isn't earned by marketing—it's earned by builds that run and issues that don't come back two days later.

When CodeDroid claims it fixed linting errors but leaves broken builds, when it reports successful testing without actually running tests, when it silently fails on API integrations—that erodes confidence rapidly. The fundamental promise is that you can hand off work and trust the results. But if you still need to verify everything manually, validate builds, and debug what actually happened, the tool hasn't delivered on its core value proposition.

How I'd Fix This

Look at what actually works in autonomous AI development. Codex Web gives you a clean dashboard view of progress with real-time updates. Jules keeps the interface minimal because the AI does the heavy lifting. Devin doesn't even have a traditional interface—you communicate via chat and it shows you results.

Factory has this backwards. They're exposing complexity that should be hidden while failing to provide the essential feedback you actually need.

If I were Factory, here's what I'd build: A dashboard that shows clear progress indicators and task delegation in real-time. Full autonomous operation within feature branches—no permission requests for basic operations. Automatic orchestration between agents without manual mode switching. And actual integration with workflow tools—not just API calls that silently fail, but native JIRA, GitHub Issues, and Linear integration that works reliably.

The current three-column interface feels like they're trying to show off their technical sophistication rather than solving user problems. That's not enterprise software—that's demo software.

Where This Goes From Here

Factory AI has raised significant funding ($20M+) and secured enterprise customers, suggesting the market believes in the vision. The multi-agent architecture, local environment integration, and autonomous positioning represent thoughtful approaches to where agentic coding should evolve.

But execution matters. Speed issues make the tool unusable for iterative development. UX contradictions undermine the autonomous claims. Quality gaps break trust when you most need reliability.

I see potential here, and hopefully they'll get there. The concept is sound, and some foundational pieces work. Until Factory closes its execution gap, it's not ready for prime time. The ideas are there. The trust isn't.

For teams evaluating agentic coding tools, stick with Cursor, Claude Code, or Augment Code until Factory addresses these fundamental execution problems. The promise of true autonomous development is compelling, but promise isn't product.

Tested on Factory AI CodeDroid beta with a TypeScript/Node.js project. Your experience may vary, especially as they iterate on performance and UX issues.

My friend Ophir introduced me to SuperWhisper a few weeks back. It's not breaking news—many of you probably already use it or something similar. But after integrating it into my daily workflow, I'm starting to see something bigger happening here. Something that connects to what we've been exploring with agentic coding tools and the broader shift toward more natural human-computer interaction.

What SuperWhisper Gets Right

SuperWhisper is an AI-powered voice-to-text tool that runs locally on macOS. At its core, it's elegantly simple: hit a hotkey, speak, release, and your words appear wherever your cursor was. But the execution is what matters.

Accuracy that consistently delivers. I'm a fast typer—always have been. Never felt constrained by typing speed for either coding or writing. But SuperWhisper's transcription accuracy genuinely impresses. It handles technical terminology with precision, understands contextual nuances, and filters background noise effectively. More importantly, it maintains reliability when I switch between casual explanation and technical specifics mid-sentence.

Zero-friction activation. Control key brings up the interface, Control key closes it and processes. That's the complete interaction. No context switching, no separate applications, no workflow disruption. It integrates seamlessly into whatever you're already doing.

Local processing with robust privacy. Everything runs on-device using Whisper models. No cloud dependencies, no data transmission, no latency from API calls. Your thoughts remain precisely that—yours.

Where This Gets Interesting

Here's what I've noticed after a few weeks of use: I'm not just replacing typing—I'm changing how I think through problems.

Considering the practical implications, this technology represents more than efficiency gains—it fundamentally changes how we approach problem-solving. When I'm working through complex architectural decisions, I find myself speaking through the challenges while examining the code. The verbal exploration forces greater clarity than scattered written notes ever could. For longer documentation, the difference becomes even more pronounced—instead of starting and stopping to craft sentences mentally before typing, I maintain natural conversational flow that ultimately produces more accessible technical content.

The Bigger Picture: Prompting Over Tooling

This shift in how I think also signals something broader happening in the dev world. As AI assistants become better at understanding natural language requirements and generating structured output from conversational input, the friction between human intent and machine capability continues to decrease.

Think about it: we've already established that AI can handle complex coding tasks when given clear specifications. Tools like Cursor, Codeium, and others are getting remarkably good at understanding intent and generating functional code. The bottleneck isn't AI capability—it's our ability to communicate what we want effectively.

Typing, for all its efficiency, is still fundamentally constrained. We think faster than we type, and we speak more naturally than we write. When you can verbally describe a problem, provide context, and iterate on solutions through conversation rather than careful text crafting, the entire dynamic changes.

In Practice: What This Looks Like

I've been experimenting with voice-driven workflows across different scenarios:

Code documentation. Instead of dreading comment blocks and README files, I speak through the explanation while looking at the code. The natural flow of verbal explanation often catches edge cases and assumptions I'd skip in written docs.

Issue tracking. Creating GitHub issues or Jira tickets by speaking through the problem, reproduction steps, and acceptance criteria. The conversational format makes these artifacts more useful for both AI assistants and human collaborators.

Code review discussions. When leaving feedback on pull requests, speaking the comment and then editing produces more constructive, clearer feedback than starting from a blank text box.

Architectural thinking. This one surprised me. When working through system design decisions, speaking through trade-offs and implications helps identify weaknesses in my reasoning that pure thought or written analysis might miss.

AI prompt crafting. Here's a benefit I didn't anticipate: voice dictation fundamentally improves how I interact with AI tools. When typing prompts, there's always the temptation to be concise—your fingers get tired, you want to get to the point quickly. But with AI, detailed prompts consistently produce better results. SuperWhisper excels at cleaning up your speech stream, removing the "ums" and "ahs" while preserving your actual intent. What you're left with is precisely what you meant to say, as detailed as necessary. Since I'm not constrained by typing fatigue, I can provide all the context, examples, and nuance that lead to superior AI output. More detailed instructions mean better prompts, which mean better AI collaboration.

Limitations Worth Noting

SuperWhisper isn't perfect, and voice-to-text isn't universally better than typing.

Privacy considerations you might not expect. Here's something I discovered the hard way: while dictating this very article, I had another video meeting window open in the background that I'd forgotten to mute (there was nobody else on the call, I was just waiting for someone to show up. But still...). When I switched back to that window, SuperWhisper had helpfully transcribed the entire conversation for me. This isn't a flaw in the product—it's a reminder that frictionless tools demand heightened awareness. If it's audible, it's capturable.

The accuracy, while impressive, isn't 100%. Technical terms, proper nouns, and code-specific language still require cleanup. You'll find yourself developing verbal habits to work around transcription quirks—spelling out variable names, using "dot" instead of periods for method calls, that sort of thing.

Environmental constraints matter more than with typing. Background noise, other people talking, video calls—all potential disruptions. And there's still something to be said for the muscle memory and direct brain-to-keyboard connection that experienced developers have cultivated.

Should You Try It?

Simple answer: Yes.

SuperWhisper offers a free tier with 15 minutes of Pro features, then basic functionality forever. The Pro subscription starts at $8.49/month or $84.99/year for unlimited use and access to larger AI models. Even if you only use it for documentation and longer explanatory text, it'll pay for itself in reduced friction.

But the real value isn't just productivity—it's the shift in how you approach problem-solving and communication. When the barrier between thought and text disappears, you start thinking differently about how to structure explanations, document decisions, and collaborate with both human and AI partners.

The End of Typing?

Are we looking at the eventual obsolescence of typing for developers? Probably not completely. Code structure, symbol manipulation, and certain kinds of precise editing will likely remain keyboard-centric for the foreseeable future.

But for the growing portion of development work that involves explanation, documentation, specification, and high-level problem-solving? Voice is starting to make a compelling case. Especially as AI assistants become better at understanding natural language requirements and generating structured output from conversational input.

Voice isn't replacing typing—it's expanding what we mean by "input." And as AI systems grow more capable of parsing our intent, that expansion becomes a shift in workflow, not just modality. The real game changer isn't dictation. It's the frictionless path from thought to structured output.

SuperWhisper offers a generous free tier that includes core voice-to-text functionality across all applications, meeting recording and transcription, unlimited access to smaller AI models, custom prompt control, and email support—providing substantial value for everyday use without any monthly cost. For users requiring advanced capabilities, the Pro tier ($8.49/month, $84.99/year, or $249.99 lifetime) unlocks the full feature set including your own AI API key integration, unlimited access to both cloud and local AI models, automatic translation from any language to English, audio and video file transcription, and priority support. The annual plan includes two free months, while the lifetime option offers the best long-term value. Students can access additional discounts, and all paid plans include a 30-day no-questions-asked refund policy, making it risk-free to explore SuperWhisper's full capabilities.

Google already has Firebase Studio, which feels like v0 but somehow worse. Now they're entering the autonomous agent space with Jules, positioning it as a competitor to tools like OpenAI's Codex. Given Google's resources and engineering talent, I expected this to be a more polished entry into the market.

I was wrong.

What Jules Promises

Jules is designed as a PR-based autonomous agent that can read your codebase, understand issues, and implement fixes directly through GitHub pull requests. Powered by Gemini 2.5 Pro, it operates asynchronously in secure Google Cloud VMs, promising to handle everything from bug fixes to feature development. The concept is solid—point it at a problem, let it analyze your code, and watch it create a targeted solution.

The integration approach makes sense too. Rather than trying to replace your development environment, Jules works within the GitHub ecosystem you're already using. It's meant to be the autonomous contributor that never sleeps, handling routine fixes and feature implementations while you focus on architecture and strategy.

The Reality: Day One Disappointment

My first attempt was straightforward: fix a chatbox on a homepage that wasn't making requests to the OpenAI assistants API. Simple debugging task, clear scope, exactly the kind of work an autonomous agent should handle well.

Jules immediately hit heavy traffic issues. I wasn't alone in this experience—multiple users reported access problems due to overwhelming demand. The developer community echoed similar frustrations, with widespread reports of "System is experiencing heavy traffic" messages lasting for hours. One user described giving Jules "a big task" in the morning, then waiting "several hours" with only traffic warnings.

The system couldn't handle basic load, throwing "unexpected error" messages before I could even get started. When it finally responded, the conversation was more frustrating than helpful.

I asked if it could read GitHub issues directly. The response was telling: "I am an AI assistant and I do not have the capability to access external websites, including GitHub. Therefore, I cannot directly read GitHub issues."

This fundamental limitation became a common complaint among early users. Multiple developers described giving Jules "pretty explicit instructions" about their codebase, only to have it "do what it wanted and failed," wasting one of their precious 5 daily credits on something they specifically told it not to do.

Missing the Mark on Basic Functionality

The limitations became more apparent as I continued testing. Jules asked if I wanted to enable notifications for when "a plan is ready or code is ready for review." This suggests it does eventually produce work, but the path to get there involves significant manual intervention.

The developer community revealed the broader scope of these issues. Users reported mixed results on code quality, with one comparison showing Jules writing 2,512 lines versus Codex's 77 lines for the same task. While more code isn't necessarily worse, users debated whether Jules was "overcomplicated with code duplication and unnecessary boilerplate."

Others hit timeout issues. "Jules was unable to complete the task in time" became a common complaint, with the tool failing to finish work within its allocated timeframe. The 5-tasks-per-day limit meant these failures burned through users' daily quota quickly.

Compare this to Codex Web, which reads your full codebase, understands context, and operates with minimal friction. Jules feels like it's solving the wrong problem—asking developers to become intermediaries in their own automation workflow.

What Google Got Wrong

Reflecting on this experience, the most concerning aspect isn't the expected growing pains of a beta release. Google's own FAQ acknowledges that task failures are common, citing "broken setup scripts or vague prompts" as typical causes. These operational issues are fixable with time and resources.

Rather, it's the fundamental design decisions that suggest Jules wasn't built by people who actually use autonomous coding tools regularly. If you're building a GitHub-integrated coding agent, direct repository access should be table stakes. Requiring developers to manually copy issue content defeats the entire purpose of automation—it's like building a self-driving car that needs someone to read the road signs out loud.

Google has the engineering resources to solve these problems. They have access to vast amounts of code and sophisticated language models. Yet Jules feels rushed to market, more concerned with matching competitor announcements than delivering genuine value.

The Broader Picture

This release highlights a concerning pattern in how big tech companies approach AI tooling. There's pressure to ship something, anything, to show they're not falling behind. But shipping broken tools that frustrate developers doesn't advance the field—it sets it back.

Firebase Studio suffered from similar issues. Instead of building something genuinely better than v0, Google shipped something that felt inferior. Now they're repeating the pattern with autonomous coding agents.

The autonomous coding space is heating up rapidly, with multiple players announcing similar tools within days of each other. Microsoft revealed its own background coding agent in GitHub Copilot at Build, and the community is already comparing capabilities. But this rush to market seems to prioritize announcements over user experience.

The developer feedback reveals this tension clearly. While some users found success with simple tasks, describing 5-minute fixes that "worked perfectly," others struggled with server slowness, task timeouts, and the tool ignoring explicit instructions. The 5-task daily limit means every failure hurts, burning through your quota with nothing to show for it.

Should You Try Jules?

Not yet. Save yourself the frustration.

Jules might evolve into something useful as Google addresses these fundamental limitations. The company has the resources and talent to fix what's broken. Some developers acknowledge it's "experimental/alpha" and expect improvements, noting that Google released it free specifically to gather feedback.

But the infrastructure problems combined with basic design flaws suggest Google underestimated both demand and the core requirements for autonomous coding agents. I'll revisit Jules when it can handle basic tasks without requiring manual workarounds and when the servers can actually stay online under load.

Until then, there are better autonomous coding tools available that actually work as advertised. The autonomous coding space is moving fast, with real innovation happening from smaller, more focused teams. Google's entry feels like they're playing catch-up rather than leading, and it shows in the execution.