engineering

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.

Sean Goedecke argues that fully understanding your codebase is a small-team luxury. In large systems nobody understands it all, and effective engineers work from partly correct theories, making educated guesses and dealing with the consequences. He frames “pure” engineering (small codebases, complete understanding) and “impure” engineering (large systems, partial models) as different professional cultures, and treats understanding as one value to trade off among many, like performance or compliance.

A useful counterweight to cognitive debt: if full cognitive coverage was never on offer at scale, agents are not taking away something we actually had. Uncle Bob’s gauntlet of constraints is one way of living with that.

Manifest ran an LLM router for four months, classifying requests into complexity tiers and routing them across providers to cut costs, then killed it. A prompt alone does not reveal how hard a task is, prompt caching (cache reads 75 to 90 per cent cheaper) undercuts the savings, and switching models mid-workflow hurts consistency. Their conclusion: a good router stays sticky to one model, doing its job “by, ironically, not doing it”.

The HN discussion broadly agrees that frontier models are now interchangeably good for everyday work, and that nobody has time to learn each model’s quirks when a new one lands every week. The consistency point rhymes with cognitive coverage: switching tools constantly means never really knowing them.

Gergely Orosz “cannot help but see the concept of code reviews fading away”. A rock-solid, very experienced engineer he spoke to reviewed all their AI-generated code until Fable, then concluded the review was pointless and stopped, except for key parts. One anecdote, but from a careful observer of engineering practice, and consistent with where Uncle Bob and antirez already landed. The open question is what replaces review as the quality gate; Graphite is betting it doesn’t need replacing.

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.

Alexander Belanger of Hatchet distils Postgres operations into tiers: schema design, indexing and short transactions first; then understanding the query planner (EXPLAIN ANALYZE, accepting that seq scans sometimes make sense) and tuning autovacuum before bloat accumulates; then the sharp tools like FOR UPDATE SKIP LOCKED queues, partitioning, and trigger-based migrations. The framing that sticks: “queries either seq scan or they don’t”, so optimisation is more binary than it feels.

The HN discussion mostly adds what the guide leaves out: monitoring and alerting for the few fatal failure modes, and a backup and restore plan, which several commenters reckoned is the real first item on any survival guide.

Steve Krouse’s problem with spec-driven development: most software can’t be specified up front, because “software is a creative act, where you figure out what you’re building as you build it”. You need your hands in the details, reacting to incremental versions.

A useful tension with the constraints school (constrain the agent, Uncle Bob’s gauntlet): constraints assume you know what to constrain.

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?’”

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.

Patrick Nadeau at Autodesk Research argues that spec-writing discipline puts the burden on the wrong side: build constraints into the agent’s environment instead. He sorts them into three kinds: generative (tests, and especially test oracles that compare against a reference implementation), interpretive (give the agent a debugger so it can test its hypotheses about existing code), and elicitative (have it interview stakeholders to resolve ambiguity before implementing). The common thread is grounding the agent’s output in an external source of truth.

Same instinct as Uncle Bob’s gauntlet of constraints, but engineered into the system rather than bolted on.

A free handbook of the unglamorous fundamentals of building financial software: representing money (precision, rounding, currency, FX), double-entry ledgers, value time versus booking time versus settlement time, immutability and audit trails (and how that squares with GDPR), idempotency and full resumability of money flows, reconciliation, and controls like four-eyes and segregation of duties. Appendices walk end-to-end flows such as a crypto withdrawal. The kind of domain knowledge that usually lives only in the heads of people who’ve been burned.

In the HN discussion, a fintech veteran vouches that it matches five years of hard lessons (answering the now-obligatory “is this AI slop?” question), and the sharpest thread warns against using minor-units integer amounts as an interchange format, however clever it feels.

A nice description of the anatomy of a harness with the memorable formula Agent = Model + Harness

Ryan Lopopolo on five months of building an internal OpenAI product under one constraint: zero manually-written lines of code. Everything, application logic, tests, CI config, documentation, observability and internal tooling, came from Codex. About a million lines and roughly 1,500 merged PRs, starting from an empty repository in late August 2025, with three engineers driving the agents. That works out at 3.5 PRs per engineer per day, and the rate went up rather than down as the team grew to seven. They estimate it took about a tenth of the time hand-writing it would have.

Harness engineering is the name for what the humans did instead of coding. The scarce resource is human time and attention, so the job becomes designing the environment the agent works in: humans steer, agents execute. When something failed, the response was not to prompt harder but to ask what capability was missing and make it legible and enforceable. Review has largely followed:

Humans may review pull requests, but aren’t required to. Over time, we’ve pushed almost all review effort towards being handled agent-to-agent.