agents

Lilian Weng’s argument is that recursive self-improvement in AI will arrive through the harness, not through models editing their own weights. The harness, in her definition, is “the system surrounding a base model that orchestrates execution and decides how the model thinks and plans, calls tools and acts, perceives and manages context, stores artifacts, and evaluates results”. Because a harness is just code, it is a much more tractable target for improvement loops than the model itself.

Y Combinator’s software team has open-sourced qm, an agent platform for a whole company rather than one person, living in Slack and on the web. A headless TypeScript core with Postgres handles identity, dual-scoped memory and permissions (personal workspaces plus shared team projects), sandboxed tool execution, and crons for background automation. The harness itself is pluggable: Claude Code, Codex, OpenCode or Pi. MIT-licensed and designed to be forked privately rather than consumed as a product.

A production-scale data point for the ideas in anatomy of an agent harness and harness engineering.

“Your AI writes like a LinkedIn post. Make it write like a Boeing manual.” SimpleEnglish is a skill that forces LLM documentation into ASD-STE100, the controlled language aerospace has used since 1983 so a tired mechanic cannot misread an instruction: measured 72.9 per cent fewer violations across six Claude models, with AI slop dying as a side effect. The underlying observation (via @geogristle) is that controlled languages built for human safety turn out to be exactly the constraint that stops models writing filler.

In the HN discussion, several people want it for their own emails and Slack messages, one shows an output that is still wordier than real STE, and another notes drily that this is the third ASD-STE100 submission in a fortnight: this week’s trend, though maybe a good one.

Uncle Bob Martin (coding since the late 60s) no longer reads the code his agents write. Instead he surrounds them with extreme constraints, from unit and gherkin tests to mutation testing, and trusts code that has “run the gauntlet of all of my constraints and tests”.

The polar opposite of cognitive coverage: commit at zero understanding and bet the harness makes up for it. Harness engineering and Jason Swett’s TDD skill, taken to the logical end.

Jina Yoon’s framework: autonomy should depend on the task, not the model. “Trusting your agents just because the models got smarter is like skipping your seatbelt because you got a nicer car.” Two questions decide it: is the work easy to check, and are mistakes cheap to undo? That yields four levels, from assistant mode (hard to check, costly to undo) up to self-driving (easy to check, cheap to undo, like dependency updates), with PostHog examples of moving work up the ladder.

The checkability axis is doing the same work as the constraint-building in constrain the agent.

Anthropic removed over 80 per cent of Claude Code’s system prompt for the Claude 5 generation with no performance loss, and this post generalises the lessons: rules give way to judgment, worked examples give way to well-designed tool interfaces, everything-upfront gives way to progressive disclosure, and manual memory management gives way to auto-memory. For your own setup: keep CLAUDE.md thin and focused on genuine gotchas, prefer pointing at code (specs, test suites) over describing it, and let skills guide rather than constrain.

Practical vindication of the map-not-manual approach this repo’s AGENTS.md already takes.

Kenton Varda: building software by prompting agents without ever reading or editing the code “isn’t actually a new thing. It’s just called being an engineering manager”, a different skill with decades of accumulated practice behind it. The analogy is genuinely useful, but it has a gap worth holding onto: a human team carries far more durable memory and shared context between tasks than an agent team does, so the management playbook doesn’t transfer cleanly.

Dex of HumanLayer argues the lights-off software factory fails for a structural reason: RL training for coding models has no fast, reliable oracle for maintainability. “There is no penalty for eroding codebase maintainability”, only pass/fail on immediate tests, and design damage that compounds over months can’t be backpropagated. Harness engineering fixes the speed problem, not the quality problem. His answer: front-load alignment (product review, architecture, program design before coding), build in vertical slices, and keep humans reviewing inside constrained workflows: 2 to 3 times faster safely rather than 10 to 100 times faster into chaos.

A structural argument for why the dark factory level stays out of reach, and grist against Uncle Bob’s gauntlet: tests can’t price in design erosion.

The HN discussion ranges from “one of the best writeups of how RL shapes model behaviour” to accusations that software factories are Rube Goldberg machines and their proponents self-appointed experts, via the honest observation that human PR review was never that great to begin with.

Boris Cherny (creator of Claude Code) hears the same thing everywhere: one person is 10x-ing their output with Claude and the rest of the org hasn’t caught up. He maps adoption as four steps, and the key observation is that tokens alone never move you forward: each step needs the next set of bottlenecks broken and the next set of guardrails built. In practice that means giving Claude ways to verify its own work end to end, auto permissions, automated code and security review, and interfaces for managing multiple agents. On measuring return, prefer the counterfactual to usage dashboards: would you have spent the engineering hours anyway, and what would they have cost?

Tariq’s formula for the ideal prompting technique: thin prompts, thick artifacts and context, thin skills. Nine words that compress a lot of hard-won practice: put the effort into durable context the agent can read (specs, tests, docs), not into elaborate per-task prompts or over-prescriptive skills.

Dan Austin built a pipeline where an agent is handed a training task (“teach a model to do X”), writes a complete RL training job (environment, reward, dataset, hyperparameters), and submits it to real GPUs. Then he RL-trained the agent itself, rewarding it when the models it trained got better. Reward climbed from about 0 to 0.63 over 54 steps, and transferred to a held-out task family. Everything is open-sourced, including write-ups of the failed pilots.

On your own machine an agent leaves two bad options: approve every command and babysit the prompt, or --dangerously-skip-permissions and hope nothing is one rm -rf from disaster. Clawk is the third option: cd into a repo, type clawk, and Claude Code (or Codex, or a shell) works inside a disposable Linux VM with your code mounted. The agent gets full autonomy inside walls, instead of limited autonomy on your laptop.

The HN discussion asks the obvious question (why not just Docker: answer, kernel isolation), jokes about agents escaping container jail, and reveals a crowded field: Fly Sprites, virtdev, take-ai-control. Agent sandboxing is having a moment.

Can Bölük analysed token distribution across about two million agent tool calls: 91 per cent of tokens go on reading the codebase, 9 per cent on edits. That kills the intuitive plan-with-a-frontier-model, implement-with-a-cheap-model split, because the cheap executor has to reread everything the frontier model already read; in his tests the split actually cost 14 per cent more than the frontier model working alone. A plan document is “a literal postcard, describing a journey to a model that never took it”.

Their fix, prewalk, hands over the frontier model’s actual context window after its first successful edit: 92 per cent of the performance at 53 per cent of the cost.

A visualisation tool that replays coding-agent sessions on a 3D map of your codebase. Watching where the agent walked, file by file, is a novel angle on the understanding problem: not reading the diff, but seeing the journey that produced it.

Salvatore Sanfilippo: many devs aren’t maximising automatic programming because they still look at the code. “Doing it makes you the bottleneck. Your time is better invested in new ideas, QA, design, and asking yourself what is your goal.” Striking from the author of Redis, a codebase famous for being read line by line.

Same camp as Uncle Bob, and the opposite of the short leash method.

Dax Raad: being in the loop matters, but people misread what the loop is for. Your job isn’t to micromanage the agent into executing steps the way you would; “it’s to come up with cool things for it to work on”. A neat one-line answer to the bottleneck question Patrick JS raised: deciding what should exist.

The Claude Code team’s taxonomy of loops, pinning down a term the discourse had left fuzzy: agents repeating cycles of work until a stop condition is met. Turn-based (the ordinary agentic loop), goal-based (/goal with an evaluator model checking your stop condition: “get the Lighthouse score to 90, stop after 5 tries”), and time-based (/loop and /schedule for recurring work or polling external systems). The practical advice: encode your manual verification steps as skills so the agent can check its own work end to end, and make the checks as quantitative as possible.

Patrick JS: agents are solving coding, not engineering, and engineering is exactly where the current problems live: taste, judgment, constraints, systems thinking. “The bottleneck didn’t disappear. It moved from ‘can you write the code?’ to ‘can you tell what should exist?’”

The poster can’t reach flow state with coding agents: “a bicycle that just brakes abruptly every couple minutes. I stop, wait, review, prompt again.” The thread is a good sample of 2026 workflows people have built around the problem: TODO files as free-text prompt queues, JSX templating languages for context piping, custom harnesses running in VMs with their own email accounts and Linear boards, and agents generating diagrams of their changes at different abstraction levels to speed up human understanding.

Greg Slepak’s counter to full delegation: plan and break down tasks first, review every diff before granting permission, never YOLO mode, commit after each subtask, and require AI-assisted PRs to be self-reviewed before human review. “You keep yourself in the loop at all times instead of removing yourself.” His claim is that even Fable 5 writes inefficient, ugly code without active oversight.

The direct opposite of Uncle Bob’s approach: maximum cognitive coverage, paid for in speed.

The HN discussion split neatly: half thought this is just how anyone serious already works (“are you guys just YOLOing everything these days?”), half thought it’s slower than writing the code yourself, plus a jab at the genre of AI-workflow advice written after a couple of months of personal use.