#coding-agents

I downgraded my Claude subscription from $200/mo to $100/mo and started paying Cursor $60/mo instead. The trigger was Wednesday's Claude outage, but the real reason is that GLM-5.2 through Cursor has been fast enough and good enough that the math stopped favoring Opus. If a model is 80% as good as Opus 5 but roughly 7x faster, I'll take the speed and pay for the 80%.

The unscientific test

Same workspace, same CLAUDE.md/AGENTS.md, high effort on both. The prompt was "make a quick tetris game as an html file," followed immediately by "now use cyberpunk colors."

Two setups: Cursor running GLM-5.2, and Claude Code running Opus 5.

GLM finished in 53 seconds. Opus took 7 minutes 5 seconds, though a good 2-3 minutes of that was Opus testing the game with Playwright, which GLM didn't do.

The visuals came out mostly the same. Opus edged it on the blank-slate UI, which tracks with my experience. I trust Opus more when there's nothing on screen to anchor a design. The generated code was close to identical in structure.

Adding Kimi to the pile

For a third data point, Cursor with Kimi K3 on max effort: 4 minutes 3 seconds.

Visuals are fine. The code has a bug, the game doesn't auto-start, and the structure feels a step down: a big list of global variables where Opus and GLM both scoped things more tightly. Again, totally unscientific, but Kimi felt buggier and the code quality "felt" lower.

The 7x

Experiencing near-Opus quality at 7x the speed is genuinely a different thing than reading about it. The loop tightens. You ask, you get an answer, you ask again, all before you've lost the thread.

If this is what 7x feels like, I'd like to see 70x.

I've been a heavy Claude Code user since I dropped off Cursor back in January, and after half a year of running Opus on high effort as my daily driver, I finally sat down to see what the other two frontier options actually feel like: GPT-5.6 Sol inside Codex, and GLM-5.2 inside Cursor. This is a first pass, not a benchmark. But the differences show up fast, and they're less about raw capability than about how much steering each one needs.

Why I stuck with Claude Code

Claude Code with Opus has been reliable in a specific way: I know where the edges are. Tell it to do something and I generally know the outcome before it runs. That predictability is worth a lot, even through Anthropic's downtime and the occasional sense that a model's behavior shifted underneath me. Reliability beats novelty when the tool is load-bearing.

Curiosity won anyway. Both Sol and GLM-5.2 have a lot of hype around them, so both are getting a real trial on real work.

GLM-5.2 in Cursor

The initial, unscientific impression of GLM-5.2 is that it's good. Call it 75 to 80% as capable as Opus 4.8. It gets things done without much intervention and mostly stays on the rails, though it sometimes wanders down an implementation path that needs correcting.

Two confounders help it, and I want to be honest about them. One, Cursor is a good harness. Two, our team runs an extensive developer harness module: skills, documentation, helper scripts, a large pile of team-specific context that gives any model an edge. How GLM-5.2 would perform naked, hitting the API through a simpler agent, I genuinely don't know.

One habit across all of this: force thinking as high as the tool allows. Not max, usually the tier just under it, like high.

GPT-5.6 Sol in Codex

Sol on high thinking seems reasonable on capability. The problem so far is inertia.

Ask it to do something, or suggest something be done, and it says sure, it can do that. Say "okay, go do it," and it says yes, it can absolutely do that. Then I have to say, explicitly, no, go do the thing, now. It reads the letter of what you wrote and pays less attention to the intent behind it, so you have to give it more direct instructions than I'm used to giving.

That friction is hindering my evaluation more than any capability ceiling is. I'll keep pushing on it, because the pedantry might just be a prompting problem on my end.

Where I've landed for now

Big tasks and anything that needs writing, design docs, blog posts, stay in Claude with Opus. Small and medium tasks get delegated out to Cursor and GLM-5.2. Sol stays in the rotation as an experiment until I figure out whether the inertia is the model or me.

A user interface gets noticeably better when you hand your coding agent a writing style guide and tell it to apply the whole thing to every string. Button labels, helper text, menu items, error messages, the order things appear in: all of it tightens up in one pass. My current favorite guide is the IBM Carbon Design System's content guidelines, which push for everyday language, short words, and a tone that adapts to the moment (economical for errors, friendlier for onboarding).

Why this is a good job for an agent

A lot of this used to be slow, committee-shaped work. Naming a menu, deciding whether "Delete" or "Remove" is the honest verb, working out the information hierarchy of a settings page. Hours of deliberation, sometimes days. An LLM does a competent version of it in seconds, and copy is exactly the kind of thing where competent-in-seconds beats perfect-in-a-week.

How to wire it up

Point the agent at the guide and say "apply this writing style guide to all user-facing text." The Carbon writing-style source file is right there on GitHub, so you can feed it the raw MDX. Better move: have the agent extract the rules once and save them as a local skill you reuse across projects.

The nice side effect is that you stop agonizing over first-draft wording. Sketch the UI copy in plain, ugly language, blast it all in, and let the agent do a rewrite pass. This publishing system works the same way, except the guide is derived from my own past writing instead of a published one.

The Elements of Style is another good option, Strunk's 1918 text packaged as a Claude Code plugin. I haven't used it yet, but people keep telling me it's worth installing.

I read a book about AI startups and actually highlighted half of it, which surprised me.

The book is The AI-Native Startup Handbook. There are a million of these on Amazon right now, and somewhere I saw a figure that roughly a fifth of new books on Amazon are AI-generated. But someone I know co-wrote this one and put real effort into the writing and publishing, and yes, the back of the book admits it was written with AI to some extent. I read all of it anyway. The highlights kept piling up.

The harness

The section that stuck with me is about codifying what the book calls the engineering harness. The premise is that taste is the bottleneck. Agents don't have it. Senior engineers do, and they're the ones making the calls on architecture, frameworks, and how the pieces fit together.

The human element doesn't go away. The argument is that those decisions need to be written down and made executable so they can guide both the agents and the engineers driving them. That codification is the harness.

The harness is the engineering output. The code is the byproduct.

That's a hard shift for anyone who identifies with the code they wrote. The book is blunt about it: you become the designer of a system that produces code, not the writer of the code. Some engineers make that transition naturally. Others never do.

Why taste can't be delegated

The line I keep coming back to:

Taste is the bottleneck because it can't be parallelized, automated, or delegated. Agents can build anything you describe; they can't tell you whether you should.

The senior skill the book names is calibrated trust. Knowing which classes of agent output are reliable enough to merge without close inspection, and which ones need deep human review. That's a real skill, and it's different from being good at writing code.

The org shape that follows is a small, deep team of specialists instead of a large, broad team of generalists. The harness handles the broad work. Humans handle the deep work.

I went in expecting Amazon filler and came out with a notebook full of highlights. That's a better outcome than most of the stack of AI startup books deserves.

Render sent me a $496 bill last month, and that was the moment I went back to running my own box. SpaceMolt served 1.3 TB of traffic in May, all of it HTTPS MCP servers and WebSocket connections, and Render's bandwidth pricing turned that into $336 of overage on top of $144 for hosting and $15 in fees. The thing that made self-hosting viable again wasn't a cheaper VPS. It was that Claude Code now does the parts I used to dread.

How I ended up on managed hosting in the first place

Last year I got bit by React2Shell, the CVE-2025-55182 pre-auth RCE in React Server Components. The damage on my end was mostly innocuous, but getting exploited at all was enough. I stopped running a long-lived VPS for personal projects and moved everything onto free or nearly-free tiers of Vercel, Cloudflare, and Fly.io.

When SpaceMolt started, Render.com was the obvious pick. Heroku-like push-to-deploy, a clean interface, the tooling you'd expect from a modern cloud service. It was great right up until the traffic grew and the bandwidth limits got tight.

What changed: the agent does the ops work

A year ago I would have built all of this by hand. Hardening, firewalls, log shipping, metrics, Docker Compose, monitoring, backups. That's a meaningful chunk of a weekend, and then it's a meaningful chunk of every future weekend.

An agent like Claude Code only needs SSH. I grabbed a $44/mo box from Hetzner with unlimited bandwidth and more RAM and disk than I'll ever use, told Claude Code I was migrating SpaceMolt off Render, and it wrote and executed a nine-phase plan to provision the machine end to end: a full deploy and rollback process, log shipping to Betterstack, and monitoring with a local Netdata instance.

I'd never heard of Netdata before this. Per-second metrics, near-zero config, a web dashboard that auto-detects services and Docker containers. It's left me impressed.

The runbooks are the real artifact

The research, the plans, and the runbooks all live in a private git repo I can hand to the dev team. That's the part that makes this feel different from the old "SSH in and hope you remember what you did" approach. The knowledge isn't in my head or buried in shell history. It's written down, versioned, and reproducible.

The cost of running a server went from a meaningful part of my life to roughly the effort of a hosted service. The bill went the other direction.

Building the new North Pole Security site, I kept hitting the same friction: reviewing a page, then typing out a punch list of fixes for Claude Code. Every item needed a page name, a location, and enough context to be actionable. So I had Claude build me a point-and-click sticky note system instead, and now I shift-click on the page, type a note, and it gets fixed. Less typing, more pointing.

What it actually does

The idea was simple. Wouldn't it be nice to leave sticky notes on the page, the way you'd flag a printed mockup with a pen? In a single prompt, Claude Code had nearly the whole thing built.

Each note captures what it needs to be useful: x/y coordinates, window size, the CSS selector under the cursor, and, because Astro emits dev-mode HTML attributes, the source filename and line number. All of that gets compiled into a server-side JSON file. Then a single skill command, /address-feedback, runs through every note with subagents.

It works amazingly well. Fixing things is much faster, but the better part is collaboration. On a screenshare, when someone has feedback I shift-click, type their note, and if there's time I let Claude fix it while we keep talking.

Building your own tools is basically free now

This is part of a larger pattern: you build your own tools to become more efficient. That used to be a hard sell, because throwaway bespoke software was expensive. Most of us still carry that old cost around in our heads.

The calculation has changed. Spinning up a one-off tool is close to free, so the question of whether it's worth automating something tips toward yes far more often than it used to.

The old xkcd math still holds, but the y-axis just got a lot cheaper.

difit does the same trick for diffs

Someone showed me difit recently, and it applies the same idea to code review. Instead of typing your feedback into Claude, you open the diff in a GitHub-style UI and leave comments right on the lines. Those comments get handed back as a prompt, so Claude knows exactly where each change goes.

There's even a /difit-review skill for it. I'm going to try it right after I finish typing this.

One more Claude Code tip

If you aren't running /tui fullscreen, turn it on. Claude manages its own terminal interface instead of leaning on the terminal's, which makes scrollback and mouse clicks far less buggy and makes typing smoother. Run /tui with no argument to see which renderer is active.

Claude has me locked in for now, but only loosely. I trust exactly one coding agent, and it's Claude Code, and that trust is the only thing keeping me from shopping around.

I've been on it entirely since November or December of 2025. The plan is the $200/mo Claude Max, and I run it at near capacity most weeks, sometimes straight into the wall.

Riding the curve

February 2026 was the good part. Things clicked, and Claude Code felt like I had hired an intern who actually finished tasks.

Then April happened. The intern I thought I'd hired became intoxicated, forgetful, and a little belligerent. Same plan, same tools, much worse vibes. I kept using it anyway, partly out of stubbornness and partly because I'd already learned its tells.

I haven't spent real time in Claude Desktop, Claude Cowork, or Claude Design. They read as limited versions of the same thing. The CLI still reigns, sandboxed of course.

The contenders are real

This isn't a "nothing else is good" post. The market is loud right now.

• Qwen 3.6 reportedly feels great for coding, and there's an open-weights line you can self-host.
• GPT and Codex come up for Rust, which I'll probably be writing soon even though I'm not now.
• GLM gets named for user interface work.
• Pi keeps coming up as a sharp coding harness. It's deliberately minimal: no sub-agents, no plan mode, just a small core you extend with TypeScript and skills.

Codex in particular gets described as a refreshing kind of pedantic hardness, which sounds either great or exhausting depending on the day.

Why I'm still here

Trust, mostly. I know the weird edges of Claude Code and Opus. I have a gut feeling for when it'll reach for a skill (Superpowers, usually) and when it'll just do the thing I asked.

Standardization is the other half. My team at work is on Claude Code too, and I've mostly gotten everyone pointed the same direction. That means we can share skills without a translation layer.

Switching costs me that gut feel and that shared setup, all at once.

What I need is time. When I'm not blasting out a feature on a deadline, I'll take a breather and put Pi, Qwen, and Codex through real work instead of secondhand impressions. Until then, Claude Code has me in its tentacles.

Coding agents that produce visual output need a way to look at what they made. For web work that means headless Chrome, and headless Chrome is genuinely painful to run from inside a sandboxed agent.

Chromium and Firefox both rely on Mach-O quirks, macOS entitlements, and Crashpad behavior that don't survive most sandboxes. I run my agents inside nono.sh profiles per project, and Chrome under that setup is a non-starter.

The workaround

Playwright runs fine outside the sandbox. So it lives on a high port and Claude is told, in its instructions, to always talk to the Playwright MCP server there:

$ npx @playwright/mcp@latest --headless --isolated --browser chrome --port 8931

The sandbox just needs to reach localhost:8931 and the visual-review loop works. Claude renders the local service, takes a screenshot, looks at it, iterates.

That mostly works. What it does not solve: stale processes, hanging Chrome instances, zombies. Every so often Chrome spins out and eats all 64 GB of RAM on my M4 MacBook Pro before I notice.

Lighter options

There has to be something simpler than babysitting a browser. Two things caught my eye recently.

Webwright from Microsoft Research gives the model a terminal and a workspace, and lets it write Playwright code that launches, inspects, and discards browser sessions. The output is a reusable script, not a chat transcript. It scores 60.1% on Odysseys against base GPT-5.4's 33.5%, which is a real jump.

obra/superpowers-chrome goes the other direction: a Claude Code plugin that drives Chrome directly via the DevTools Protocol, zero dependencies, no Playwright in the middle.

When you actually need real Chrome

Advanced bot fingerprinting is the case for keeping a full browser around. If the task is logging into a hostile site or completing a real-world flow, real Chrome with a real profile is the only thing that works.

But most of my use is smaller: render a local dev server, screenshot it, ask Claude if the layout looks right. For that, a 64 GB RAM-eating Chromium feels like the wrong shape of tool. I suspect this gets cleanly solved within a year, probably by something CDP-direct and disposable rather than a long-lived browser process I have to nanny.

Claude Code is good at creating skills. Say "create a skill that does X" and it makes one. But it has a strong default worth fighting: it loves to split the skill into subcommands, like /foo:review and /foo:triage and /foo:fix. I don't want a menu. The whole point is automation.

So the fix is two lines in the prompt when asking it to write a skill: no subcommands, and make sure the skill can be run idempotently. Run it once, run it ten times, it should converge on the same finished state without me steering.

Idempotence is the part that matters more than it sounds. A skill that's safe to re-run is a skill I can put in a loop, or fire after every commit, or hand to another agent without worrying about double-applying a change. The subcommand version pushes that work back onto me: decide which phase you're in, pick the right verb, remember what you already ran. That's the opposite of automation.

The menu pattern probably comes from training on human-facing CLIs, where breaking work into named steps is good UX. For a skill that an agent is going to invoke, it's the wrong shape. One entry point, idempotent, done when it says it's done.

Coding agents will happily run whatever they generate, and most of them have your shell, your SSH keys, and your AWS creds one rm -rf away. Sandboxing the agent is the cheapest insurance you can buy, and in 2026 there are finally enough good options that you should pick one.

The landscape splits into a few camps. Full VMs (Firecracker, Lima, OrbStack) give you the strongest isolation and the most overhead. Containers (Docker, Podman, devcontainers) are the default for most people and work fine until the agent needs to touch your real checkout. And then there's the OS-native path: Seatbelt on macOS, seccomp-bpf and Landlock on Linux. Those last two are what the kernel already uses to sandbox App Store apps and Chrome tabs, so the primitives are battle-tested. The friction has always been the ergonomics.

My current favorite is nono. It's a CLI wrapper that uses Landlock on Linux and Seatbelt on macOS to restrict filesystem and network access for any process you launch under it. No container, no VM, no daemon. It ships with profiles for the popular coding agents and lets you write your own, and I've gotten into the habit of creating a profile per project. The agent gets exactly the directories and hosts it needs, and nothing else.

The per-project profile is the part that actually changed my behavior. Once writing a profile takes thirty seconds, you stop talking yourself out of it. The agent can still go off the rails inside the box, but the blast radius is whatever you wrote down, and the rollback story is just git. I'm extremely curious to see where this category goes once more agents ship with sandbox profiles in the box.