We can't find the internet
Attempting to reconnect
Something went wrong!
Hang in there while we get back on track
Turn agent corrections into checks the system enforces
The most useful AIE Code material came from @poteto (Lauren), in notes TheTuringPost posted and swyx shared. They describe how her team made coding agents trustworthy:
- Clean the code agents copy from. Agents copy whatever looks like an established pattern, including workarounds and deprecated code .
-
Make each correction enforceable. Each time you correct an agent, ask whether the fix can become a lint rule, type constraint, test or better API. A growing AGENTS.md still depends on the agent following every instruction . Her team limits React's
useEffectto framework internals because agents kept misusing it, and it enforces import boundaries between processes . - Give agents tools to inspect the product. That means debugging tools, reusable CLIs, and a "feature map" that describes the app from the user's side. Then ask agents for screenshots, videos or state diagrams rather than written explanations .
- Spend heavily on verification. The team uses runtime verification and is trying property-based UI testing and TLA+. Most of her tokens go to verification . Agents now test releases, find bugs, open fixes and merge them automatically, but building enough trust for that took about six months .
Reported results: 11,000 PRs in a month with a revert rate around 0.5% .
Kent C. Dodds's friction log. On ThursdAI, Dodds described three goals for a software factory: produce good work, catch mistakes, and limit the damage when one gets through . He also makes agents report what was painful in the codebase, then has another agent fix those problems . The setup is a Kody automation with a very short skill that tells the agent to run one CLI command, which returns the next step. The steps are: mark the PR ready, wait for CI and agent review, fix errors, merge when everything passes, then report what was bad about the process .
incident.io's numbers. These come from The Pragmatic Engineer. Usage took off once engineers ran several agent sessions in separate worktrees, and nearly 80% of production PRs now include agent-generated code . Spend fell from about $4,500 to about $1,600 per engineer per month after the move from Opus 5 to Opus 5.5 . About 80% of that goes to Claude and 20% to Cursor . PRs per engineer rose only about 10% at the median but about 70% for tenured engineers. New hires hold off on AI for their first month . Most incidents now come from missing information about production rather than bad code, so the team is building ways for agents to observe production .
Theo: Opus 5.5 for work you can verify, Fable 5.2 for judgment calls
In "Stop Picking The Wrong Model," Theo agrees with starting on Opus 5.5 at medium effort but prefers high. He says medium ends its turn too soon, and he avoids Max . He uses xhigh for tricky work that needs a lot of testing, such as Windows bugs or replaying large logs . Use Haiku for bulk pattern-matching across files, not for writing code .
- Prompt tip: Opus rarely questions the task it's given. Adding "If you think this is a good idea, do it. Otherwise, suggest something else" meaningfully improved his results .
- His rule: if the work can be verified and you can iterate toward it, Opus is enough. For work that needs creativity or exploration, or when Opus keeps going in circles and you need a call on whether to ship, use Fable . Fable is slightly more likely to let issues slip in review .
- Worked example: Opus built a test environment for performance problems on very long T3 Code threads, but missed the key bug. Theo then had Fable verify that setup and look for the cases that broke. It found that unresolved to-do lists pulled in the whole thread history, and proposed sending the goal as a separate JSON field. That cut data over the wire about 150x in some cases .
Separately, Theo turned his worst cases (bad mobile internet plus very long threads) into a measurable target to improve against, using fake devices and iOS simulators .
Gemini 4 Hydrogen: cheaper and faster, with mixed early reports
Hydrogen scores 54.3% on CursorBench at default effort, against 39.6% for Gemini 3.8 Flash. It costs $1.50/M input and $7.50/M output tokens (evals) . Antigravity reports 57% on Terminal-Bench 4.1 .
Antigravity also added Orchestrator, which splits tasks between Carbon and Hydrogen. Google says it uses 24% less quota and finishes the same tasks 19% faster . Nicholas Moy's advice for Ultra users is to use Hydrogen for quick tasks and save Carbon tokens for high-level work . Google's Ivan Leo prototypes with Hydrogen because it can call several tools at once. He sends long investigations across the codebase to Carbon. In one case, Carbon reproduced 400 errors, traced them to a permissions change in a merged PR, and drafted a message to the person who merged it .
The pushback:
- Pricing. Simon Willison points out that Hydrogen is only 25% cheaper than Argon and Carbon. He also found its pelican SVG drawings notably worse .
- Speed. Theo calls its speed "garbage" next to Sol and Opus, even with those running at regular tiers rather than fast ones .
Also worth knowing
- Modal's sandbox design: Erik Bernhardsson argues that a harness should run for a long time outside short-lived sandboxes, possibly one per tool call. That design makes it easy to spawn subagents, snapshot work and resume it . Modal doesn't mandate a coding tool. Engineers moved from Cursor to Claude and Codex, and some are trying OpenCode .
- ADEMark v1 benchmarks coding tools against a bare CLI using the same Mac mini, tasks and model. Most tools used fewer tokens than the bare CLI, and one sat at 16% CPU while idle .
- Claude Meetings adds Claude to video calls so it can build docs and whiteboards during the call. It's rolling out in beta on Team and Enterprise plans . Alex Albert presents it as a way to give Claude context it would otherwise be missing .
- OpenAI published its practices for securing persistent agents . It also announced two cyber products, Daybreak Defense Factory and Daybreak Red Team .
- Build an agent factory around three safeguards: produce quality work, catch mistakes through verification and review, and limit the blast radius if errors get through. Keep a friction log by asking agents what was painful in the codebase, then assign an agent to remove those bottlenecks.
- In Kent C. Dodds’s Cody workflow, a repository-backed automation and a short skill invoke a CLI that gives the agent its next step: mark a PR ready, wait for CI and agent review, fix reported errors, merge when green, then log what was painful—even after deployment.
- Treat factory engineering as an empirical improvement loop: define workflows in code; record agent conversations and artifacts; run evaluations; have agents use eval results to improve the factory; and replay past tasks across models, harnesses, and skills. For verification, Zack Lloyd also pointed to computer-use checks or formal methods as ways to reduce reliance on human code review; upfront specs can help too.
- Warp’s team tests models and harnesses on its own tasks rather than choosing by reputation: it routes simpler work to open-weight GLM 53, uses open models such as Soul or Astra for more complex work, and compares options including Opus 5.5 and Pi versus Codex. Cost is one consideration; Lloyd said Anthropic models are expensive.
- Google’s Ivan Leo uses Hydrogen for quick prototyping and iteration, citing its speed and concurrent tool calls, and sends long, difficult codebase investigations to Carbon. In one Kaggle model-proxy incident, Carbon reproduced 400 errors locally, dispatched background tasks, traced the cause to a permissions change in a merged PR, identified who merged it, and drafted a message. For swarms, he described a strong model mapping unknowns and fast Hydrogen models executing the work in parallel, with agents coordinating through a shared message board.
- In a Bitri setup with Swift-focused tooling, Ray Fernando gave Fable 5.2 an intent-level challenge to build a multiplatform app; it wrote Metal shaders and repeatedly verified and checked its work. His takeaway was to give capable models an agentic environment and tooling that let them iterate, rather than relying only on prior assumptions about how to approach the task.
- Start most coding work with Opus 55 at medium effort; Theo prefers high because medium can stop too soon and check too little. Use higher effort for checking or audits, reserving X high for unusually complex work such as Windows issues or large logs that need replay tests.
- To reduce Opus’s tendency to accept and expand a task, add: “If you think this is a good idea, do it. Otherwise, suggest something else.” Theo says this prompt change materially improved his results.
- Theo’s rule of thumb: use Opus for verifiable work and meticulous, high-risk checks; try Fable 52 for creative or ambiguous problems, different solution ideas, or when Opus is circling and you need a ship-or-not judgment. Fable can be more willing to let issues slide and is more likely to miss something, so it is not the safer choice for exhaustive checking.
- In a T3 Code long-thread performance investigation, Opus built an edge-case test environment but missed that an unresolved task list near the start of a thread caused the full history to be included. Theo had Fable verify the setup and explore the edge cases; it proposed separating the goal into its own JSON field, cutting data sent over the wire by about 150× in some cases.
- Use Haiku 55 for bulk analysis, such as pattern-matching across many files or classification, routing, and extraction; Theo advises against using it to write code.
- For learning from ML code, the interview recommends asking Claude or ChatGPT to write a small example, modify it, and explain each line; the demonstrated PyTorch trainer is explicitly a toy, not production training.
- For hands-on model experimentation, the demo uses an open-weights model in free Google Colab on a T4 runtime, with no special plan required.
- Riley used Claude Projects from his phone to orchestrate a staged build: he first asked the agent to research Screen Studio and outline desktop and iOS MVPs, then approved the plan; he kept design in a separate web design-board session while Mac sessions built both apps and a landing page.
- He let the agent work for 20–30 minutes, then tested on his Mac and iPhone and gave specific feedback rather than a general “make it better”: desktop playback quality and a missing recording overlay, plus excess glare and flicker in the iOS app.
- He reports using about 20–25 prompts across parallel sessions over a few hours to produce the apps, landing page, and launch/UGC videos; he judged the Mac app less refined than the iOS app, so the rapid build still needed iteration.
- Brown started a Claude Project from his phone by asking Claude to research Screen Studio and draft desktop and iOS MVP plans for approval. He then split work across a Mac session for implementation, a separate web-thread design board, and another session for the landing page. He let the agent work for 20–30 minutes before returning to test.
- He tested the builds on his Mac and iPhone and fed the agent specific issues to fix: low-resolution desktop playback and a missing recording overlay, excessive iOS glare and flickering, and desktop editing that flashed when changing corner radius.
- He also requested separate marketing-asset work: a 30–40-second Blender launch video with RunPod rendering and a UGC ad using an 11 Labs voice. He says roughly 20–25 prompts across parallel sessions over a few hours produced the Mac and iOS apps, a landing page, and launch and UGC videos; he judged the Mac app less refined than the iOS app and expected more refinement time could improve it.
-
Treat the codebase as an input to the agent: clean up deprecated code, workarounds, and questionable patterns it may copy. Turn recurring corrections into enforceable lint rules, type constraints, tests, or APIs rather than relying only on a growing
AGENTS.md; prevent predictable errors with structural constraints such as limiting ReactuseEffectto framework internals and enforcing import boundaries. - Make the product easy for agents to inspect with reusable debugging tools and CLIs plus a user-facing feature map. Ask agents for screenshots, videos, or state diagrams so reviewers can verify behavior rather than rely on a convincing explanation.
- Invest heavily in verification: the described team uses runtime verification and is exploring property-based UI testing and TLA+ model checking; Lauren says most of her token usage goes to verification. Automate release testing, bug-fixing, and merging only after the loop is reliable—the team reportedly spent about six months building trust in its environment first.
- The post reports that the team shipped 11,000 PRs in a month with a revert rate around 0.5%, alongside improvements in startup, typing, and switching chats.
Simon Willison reports that Gemini 4 Argon and Carbon have the same token price, Hydrogen is 25% cheaper, and Argon/Carbon prices are set to double on Dec. 1. In his pelican-on-bicycle SVG comparison, he says Hydrogen’s results are notably worse; the accompanying description reports shorter runtimes and fewer output tokens for Hydrogen than Argon or Carbon at each thinking level.
ThePrimeagen finds the labels “Argon,” “Carbon,” and “Hydrogen” confusing, asks for “small, medium, and large” instead, and says he cannot tell how Argon and Hydrogen relate to the Terra and Luna models.
The speaker describes a Hugging Face setup where a sandboxed agent could reach an internet-connected machine running Artifactory, then reportedly exploited Artifactory to access external evaluation benchmarks. For coding-agent deployments, this is a reminder to audit indirect network routes and connected helper services, not only the agent’s direct internet access.
Anthropic’s Fable 5.2 coordinated a team of 1,000 agents on ambitious, long-horizon work to formalize a proof of Fermat’s Last Theorem, within stated safety boundaries—a notable multi-agent scaling result, though the post does not provide a workflow developers can reproduce.
- incident.io’s agent use accelerated when Claude Agents made multi-agent coordination easier and worktree tooling improved; engineers began running several agent sessions in separate worktrees instead of driving one session, and nearly 80% of production PRs now include agent-generated code.
- incident.io asks new hires to hold off on AI for their first month after finding that heavy AI use immediately after joining was associated with worse medium- and long-term performance; the initial month is used to learn the codebase. In its Oct 2024–Oct 2026 comparison, weekly PRs rose about 10% at the median, 30% at the mean, and 70% for tenured engineers.
- After Opus 5.5 replaced mostly Opus 5 usage, reported AI spend fell from about $4,500 to $1,600 per engineer per month; at the lower level, about 80% went to Claude and 20% to Cursor.
- To compare AI spend with output, incident.io uses an “effort point” for a medium-sized human- or agent-written PR, with an AI model estimating complexity from XS to XL. Cost per effort point varies by work: infrastructure spent about 5× more than almost every other team, partly because exploration, analysis, and benchmarks consume tokens without necessarily producing PRs—evidence against a single per-PR cost target.
- For code quality, the team improved the codebase for AI use, tightened Cursor Bugbot rules, and found newer models produced better code. Most incidents now stem from missing production-environment information rather than faulty code, so the team is building feedback loops for agents to observe and learn from production.
Dodds’s general agent-workflow advice is to provide agents with more context and tools; the linked example uses connectors to let a bot work from messages, such as identifying calendar events or helping manage client bookings. Before going all in, he advises planning how to share what an agent does with other people and agents, and points to Kody (kody.codes), which he says works with @bot.
Kody’s v2026.11.12 release adds collaborative workspace Files for uploading, browsing, previewing, and sharing files, with live page editing, presence indicators, and anchored comments across documents and media. Kent C. Dodds called it a “huge deal” and described the concept as “Dropbox/Google Docs/Notion, but it's agent first.”
Peter Steinberger says his team wrote about how OpenAI runs persistent agents . The linked announcement says OpenAI is sharing fleet-management best practices, and frames persistent agents as contractor-like systems that can act proactively in the background and perform whole job functions, but may also take misaligned actions or write arbitrary code with unintended consequences . The announcement links to the OpenAI blog post .
Steinberger echoed Vercel’s claim that developers need not learn to write “this” because agents will, and that Vercel made its agents good at it . The linked project is the vercel-labs/ui GitHub repository .
Google introduced Gemini 4 Hydrogen as a fast, capable model, available to all tiers of Google AI Studio and the Gemini API; paid Google AI Pro and Ultra subscribers can also use it in Google Antigravity. Logan Kilpatrick says he uses Hydrogen daily and reports that, in one comparison, it finishes tasks 2.5× faster than Gemini 3.8 Flash, is much smarter, and has 5× less fabrication.
A conference slide described in the post’s image alt text, titled “The software factory at speed,” reports 1,306 merged PRs, 91% from cloud agents, and a 40-minute median open-to-merge time.
In a sponsored demo, the presenter says he used an open-source TypeScript framework called MCP Use to build an MCP server that renders an app UI inside chat; connecting the GitHub repo enabled deployment to a custom domain on every commit, and pasting the URL into Claude made the app available there. The sponsor also offers evals across clients, checks intended to help MCP apps pass review in the Claude and ChatGPT app stores, and analytics on agent usage and failures.
- Modal engineers use AI for code writing routinely; the interviewee estimates a 2–3× productivity change and describes delegating both tedious work and some complex tasks. More experienced engineers reportedly use agents especially heavily, including to generate hundreds of thousands of lines overnight for prototypes.
- Their tool choices are deliberately open: the team initially used Cursor, has more recently used Claude and Codex, and some engineers are trying open-source options such as Nightshift and OpenCode. Modal does not mandate a tool, preferring internal competition while the space changes quickly.
- For agent harness architecture, the interviewee favors keeping a long-running harness outside shorter-lived execution sandboxes—potentially one sandbox per tool call. He argues this makes it easier to spawn subagents, explore branches in parallel, and clone, snapshot, and resume sandboxes; Modal reports a median sandbox lifecycle of about 12 seconds, with a long tail of longer runs.
Alex Albert says getting good work out of Claude often means finding missing context and closing that gap; he cites Claude Meetings as one way to bring in that context and says it has proved useful internally. Claude Meetings adds Claude to a team video call to build documents, whiteboards, and other artifacts during the conversation; its beta is rolling out on Team and Enterprise plans.