Agent architecture, zero-bugs data, and the models that won't decide

00:00:04 A blog post from mendral walks through the two ways to place an agent harness — inside the sandbox or outside it — and the tradeoffs that only show up after you've picked one. Every production agent has a harness. The loop sends prompts, executes tool calls, feeds results back, and repeats until the model says it's done.

00:00:26 The question is where that loop lives. When the harness runs inside the sandbox, everything is in one container. The LLM calls go out from inside, tool calls execute locally, and skills and memories live on the container's filesystem. This is what Claude Code looks like when you run it on your laptop, or when you spin it up in a remote container.

00:00:49 It's straightforward. You grab the off-the-shelf harness and ship something that works. When the harness runs outside the sandbox, you get things the inside model can't give you. Your credentials stay out of the sandbox — the loop holds the API keys, user tokens, and database access.

00:01:09 The sandbox holds only the environment the agent needs. There's nothing in there for the agent to escape to, so there's no credential model to enforce. You can suspend the sandbox when the agent isn't using it. Most of what an agent does doesn't need a sandbox at all: thinking, calling APIs, summarizing, waiting on CI.

00:01:31 With the harness outside, you provision one only when the agent needs to run a command, and suspend it whenever it's idle. When the harness lives inside the sandbox, the sandbox has to stay alive the whole time. Sandboxes turn into cattle instead of session-holders.

00:01:49 If one dies mid-session, the loop provisions a new one and keeps going. Multi-user stops being a distributed filesystem problem and becomes a shared database instead. The tradeoff is real. Off-the-shelf local harnesses stop working once you move the loop out, because they all assume a local filesystem.

00:02:09 Durable execution becomes your problem — an agent session can run for hours and has to survive deploys. You need something like Inngest for checkpointed execution. The filesystem question is where the real engineering lives. Modern agent harnesses have skills, memories, subagents, and plans — all of which assume a local filesystem.

00:02:32 The clean answer is to stop pretending the sandbox has one. Put memories and skills in a database, but keep the agent's read and write tools identical so it doesn't know the difference. Bash remains a leak past the virtualization layer. Nothing stops the agent from running grep through a bash session and bypassing the abstraction.

00:02:55 You get best-effort guards and a system prompt telling the agent not to do that. It's good enough for now, which is a long way from solved. The author picked the outside model and spent the post explaining the three problems that showed up on a Tuesday and needed answers before Monday's sprint.

00:03:15 Daniel Stenberg — the author of curl — published a note on whether we're approaching zero bugs. He tracks the age of reported and fixed vulnerabilities in the curl codebase. The argument is straightforward: the more bugs we fix, the fewer remain. But every merge risks a new one.

00:03:34 The question is whether detection tools are finding bugs faster than we can fix them, and how we'd know when we're getting close. His proposed signal: if the tools are this good, detection should soon only catch very recently added vulnerabilities. The age of newly reported bugs should plummet toward zero, and the average age of the total collection should drop over time.

00:04:00 If we were close to zero bugs, the bugfix rate would plummet. The tools would have found most problems already, and there wouldn't be many left to fix. The data from curl doesn't show that. The vulnerability age curves haven't budged, and the bugfix rate hasn't started falling.

00:04:19 We're not close. Stenberg's note is notable because he's been fixing bugs in curl for decades and isn't writing from the perspective of someone who wants to believe in the tooling. He's the one who has to deal with the backlog. The graphs don't lie, even when you wish they did.

00:04:38 What the data implies is that the gap between detection and remediation is structural. Tooling gets dramatically better at finding problems, but the fix pipeline — understanding, authoring, reviewing, testing, deploying, waiting for users to update — doesn't keep pace.

00:04:57 The detection curve and the remediation curve move at different speeds. Whether the gap is a tooling problem or an organizational one determines what you can actually do about it. Stenberg's data suggests the latter, which is much harder to solve.

00:05:14 Someone built a YAML-based spec format called feature.yaml, complete with numbered requirements you can reference in code and tests. They built it after what they call a period of AI psychosis — spending hours writing specs and building agent harnesses for building products.

00:05:33 The author assembled what they call an army that worked together like a mini dark factory. One agent ran for 90 minutes unsupervised. The output worked, which is more than many companies can say, but it was still a bit sloppy. What changed was noticing a sub-agent numbering requirements and referencing them across the codebase.

00:05:57 The author was disgusted at first. Tight coupling of spec to code is bad, right? But then they thought: maybe that's the point. The requirements survive implementation, testing, and review as stable identifiers. They call these ACIDs — Acceptance Criteria IDs. Each requirement gets a stable, numbered ID.

00:06:18 You can track acceptance coverage, navigate PRs by requirement, and annotate with states. A tool called acai.sh pushes specs and code refs to a dashboard where requirements are marked Completed, Accepted, or Rejected. The author is honest about the tradeoffs. ACIDs rely on stable numbering, which creates zero friction when drafting a spec but requires care when revising — you have to re-align the code whenever your spec changes.

00:06:49 The feature.yaml format is opinionated: you write one spec per feature, and design or superficial requirements don't belong in it. The author later discovered SpecKit, OpenSpec, Kiro, and Traycer, each solving a slightly different problem. Acai.sh's differentiator is acceptance coverage tracking across many implementations — a real problem when the same feature ships across frontend, backend, microservices, and multiple repositories.

00:07:21 One observation from the piece stands out. If your application was generated instantly the moment you started typing, and the output was unsatisfactory, you wouldn't start hand-editing files. You'd extend the prompt. In that world, the spec is the only thing of value.

00:07:40 It's not a new idea. Requirements have always existed. But the tools are changing the cost of writing them down precisely enough to track, and that cost curve is the lever, not the generation speed.

00:07:54 Mercury runs approximately two million lines of Haskell. They serve over 300,000 businesses, processed $248 billion in transaction volume in 2025, and are obtaining a national bank charter. Their engineering organization largely hires generalists — most have never written a line of Haskell before joining.

00:08:15 The article on the Haskell Blog is notable because it's not written by someone defending the language's purity. It's written by an engineer at a growing fintech, looking at operational reality with the kind of honesty you get when money is involved and things break at 2 AM.

00:08:35 The key insight is that types encode operational knowledge that survives when people leave. It's not about purity as a correctness proof — it's the less romantic but more practical value of types as a form of institutional memory that the compiler enforces. When a new engineer joins and asks how to write a transaction, the type system answers them.

00:08:59 When a senior engineer leaves, the answer remains. The article walks through the patterns that keep the codebase sane. Purity as a boundary, not a property — dangerous things are tolerable when fenced in and hard to misuse. The goal is to make the right thing the only option: instead of documenting incantations in a wiki, structure types so the correct operational procedure is the only door in the room.

00:09:28 They adopted Temporal for durable execution. A Temporal workflow is, in an important sense, a pure function over its event history. The determinism requirement — a replayed workflow must produce the same sequence of commands — is the same constraint Haskell imposes on pure code.

00:09:48 Side effects are isolated into activities. The workflow orchestrates; the activities execute. Domain errors are modeled as domain types, not HTTP status codes. A payment that fails because of insufficient funds should be an InsufficientFunds type, not a 402. The article calls out code that throws HTTP status exceptions even when it runs in cron jobs, where nobody is reading them.

00:10:14 A cron job does not have a caller waiting for a 409. The error has propagated through the system because the original abstraction was coupled to its transport layer. The piece treats the type system as an operational aid rather than a correctness proof. Its value is that it encodes institutional knowledge in a form that survives churn.

00:10:38 In a fast-growing company, people leave, people transfer teams, and the things they knew walk out the door unless written down in a form the compiler can read. Because the compiler is more disciplined than the average wiki page.

00:10:54 On the LocalLLaMA subreddit, someone burned about 20 hours of side-by-side compute on two RTX PRO 6000 Blackwells comparing Qwen3.6-27B with Coder-Next. The result: they're essentially tied. Across 40 test cells at N=10, Coder-Next shipped in 25 cases and 27B-thinking in 30.

00:11:15 That's a statistical tie with overlapping Wilson confidence intervals. On the face of it, that makes sense. 27B is a later-gen dense model that's heavy on thinking. Coder-Next has roughly three times the parameters but only activates 3B at a time as it works. Depending on what you're trying to do, either could be the correct choice.

00:11:41 The most interesting finding is that 27B with thinking disabled was the most consistent shipper of work — 95.8 percent across the full 12-cell grid at N=10. The mechanism is real. The documented word-trim loop in the thinking mode halves with no-think, going from 4 out of 10 cells to 2 out of 10.

00:12:04 The thinking trace itself introduces inconsistency. The 3.6-35B-A3B variant fell flat on its face so often for tasking that it didn't seem worth carrying forward. The folder was kept as failure-mode evidence. The benchmark matters because it's one of the few actual side-by-side comparisons between these models, and it was run by someone with access to real hardware and a willingness to burn compute.

00:12:35 The point isn't which model wins. It's that the gap is so narrow it doesn't meaningfully exist, and for many use cases, the non-thinking variant of a smaller model outperforms the thinking variant of the same model. VRAM and quant level matter enormously for the practical choice.

00:12:56 If someone has 48 gigabytes of VRAM, they can run Qwen 3.6 27B at Q8 with 264K unquantized context, or Coder-Next at Q4 with context offloaded to CPU. The choice depends on what the hardware gives you, not what the benchmarks say in isolation.

00:13:15 A pull request in VS Code enabled Co-Authored-by Copilot in commits regardless of whether the user used Copilot. The PR title is straightforward: enabling AI Co-Author by default. The response on Hacker News was 1,333 upvotes and 707 comments, most of them negative.

00:13:33 The change makes commit attribution opaque. Anyone can push with Co-Authored-by Copilot whether they used it or not. The engineering community pushed back on that opacity. It's a small change with outsized consequences for how we track who wrote what in a codebase.

00:13:51 The concern isn't about Copilot specifically. It's about attribution transparency in general. When tools make it easy to add a Co-Authored-by line to any commit, the signal degrades for everyone who reads commit history. And when the line appears by default rather than by choice, you lose the ability to trust it as a genuine indicator of collaboration.

00:14:15 It's the kind of change that makes sense in isolation. Why not attribute AI assistance automatically? But the community response shows that opacity in attribution has costs that don't show up in the diff. That's the local reading. Seln.