Agentic Engineering Weekly for July 25 - August 1, 2026

Jo Van Eyck

Jo Van Eyck

— 12 min read
Share
Agentic Engineering Weekly for July 25 - August 1, 2026

More takes on the software factory, ranging from "nobody has cracked the software factory yet" to "all you need are tests". A new benchmark reveals requirements one checkpoint at a time and puts the first real number on how fast a codebase decays in the hands of an agent. OpenAI and DeepSeek cut prices in the same week that your sessions became unportable. 80 companies signed a letter about open weights and one very notable name did not. Graph engineering is an old idea with a new label.

My top 3 picks this week

  • Why Software Factories Fail: Benchmarking the new frontier: None of today's benchmarks measure real-world long-term software engineering. This is one of the first attempts at doing so. (article)
  • Open Weights and American AI Leadership: Read the safety section and the distillation paragraph, and note who is missing from the signature list (article)
  • Formal methods with Hillel Wayne: Hillel makes the same argument: software engineering is one of the only professions with a long history of open source and public knowledge sharing, which is one of the reasons software has become AI's first "killer app". Also worth a listen if you're interested in formal verification and property-based testing. (podcast)

This week's article

pair-grilling is the new pair-programming

When an agent writes most of the code, the expensive part of our work moves up- and downstream: deciding what to build and how to build it out, and later verifying results. I'm currently experimenting with moving the pairing upstream too. Pair grilling is two humans and one agent, where the agent interviews both of them about a feature until the spec is airtight, and only then starts implementing. All the design questions land before a single line of code exists, the pair reaches shared understanding, and the pull request review turns into a formality.

The software factory is real but uncracked

Huntley's post on what's lacking to properly build out software factories mostly lists things that have nothing to do with agents. Sandboxing, monorepo, reproducible builds, CI/CD, identity and secret management, and smashing corporate friction in the realm of developer experience. His blunt warning: if someone is selling you a software factory today and they are not in the tiny cohort who have spent two years trying and mostly failing, they are selling bullshit. The puzzle is being solved as we speak, but the pieces being assembled are still a work-in-progress.

Uncle Bob also got up from his lounge chair. He started coding in the late 60s, and his current strategy is to not read any of the code his agents write, because that is the only way he can take full advantage of their productivity. What he does instead is surround the agents with extreme constraints: unit tests, gherkin tests, QA procedures, quality metrics, mutation testing, coverage. Confidence in the code comes from surviving this gauntlet rather than from inspecting the diff. Kent Dodds reaches the same conclusion from thirty years further down the career ladder.

Will all this lead to a world with "software factories"? Undoubtedly, but we still have a way to go, infrastructure to build out and shit to figure out.

Worth reading:

Codebase decay in numbers

Every long-horizon coding benchmark until now divulged the whole problem description up front, which measures something closer to puzzle-solving than to real-world software engineering. SlopCodeBench does the opposite: each challenge arrives as a series of checkpoints, and the model has no idea about the later ones. Dex Horthy ran Opus 4.8, Sonnet 5 and Opus 5 through a seventeen-checkpoint subset for six hours. Opus 5 won with (a mere) four strict passes out of seventeen, and three of those four were the opening checkpoints of a single problem.

The quality metrics are where it gets interesting, because they are computed deterministically rather than by asking another model whether the code looks nice. Opus 4.8's duplication climbed 4x. By the end, one line in six was a copy of another line. Horthy's own summary of the cost analysis: every dollar buys correctness, nobody buys enough of it. Quality might turn out to become a "token spend dial" where you turn it up to your desired quality level, but most people are severely underestimating the number of tokens required for acceptable long-term results.

This week we also got an interesting write-up on the correlation between software design, refactoring and token costs. The early conclusions: proper software design saves massively on input tokens, but not so much on the costlier output tokens.

Worth reading:

The cost of intelligence is racing to the bottom while switching costs climb

Two price events of note this week. OpenAI cut GPT-5.6 Luna by a startling 80%. DeepSeek released V4-Flash at $0.14 per million input tokens and $0.27 output, a model that is pushing the Pareto-frontier and arguably the best value-per-intelligence available right now. The mechanism behind the OpenAI cut deserves some attention: they used 5.6 Sol to drive these optimisations. Mostly a "look ma: recursive self-improvement, the singularity is just ahead" marketing statement, but still cool.

Now hold that next to Dwarkesh Patel's arithmetic. If an H100 equivalent could run a human-level software engineer, then at market rates for engineers that H100 should rent for more than $250.000 a year, roughly fifteen times today's spot price. Today's prices are a bet that capability stays approximately where it is. Meanwhile total spend keeps rising even as per-token prices fall, which is Jevons doing exactly what Jevons does. The token grey market has arrived too, with resellers pooling API keys from abused free trials and unprotected support bots.

Some things are getting cheaper, some things are getting more expensive as well: inference APIs are steadily filling your sessions with encrypted reasoning, hidden search results, opaque compaction and encrypted subagent messages. You could easily move your prompts from one harness to another. You increasingly cannot move your session. That is a familiar trade in a new costume. The moment to do something about it is now, while switching is still slightly annoying rather than your next enterprise transformation.

Worth reading:

Open weights stopped being a technical preference and became a coalition

NVIDIA's Jensen Huang published a public letter titled "Open Weights and American AI Leadership" that went out with roughly eighty signatories: NVIDIA, Google, Microsoft, Meta, OpenAI, IBM, Cisco, Cloudflare, Hugging Face, Mistral, the Linux Foundation, Y Combinator. The argument runs through access, competition and customer control, but the sharpest section is about safety, and it inverts the usual framing. Relying solely on closed models is not inherently safe, because they can be breached, misused, or fail in ways outsiders cannot detect. Concentrating capability behind a handful of closed models creates a small number of single points of failure.

The most-discussed fact about the letter was the absence of some signatories. Anthropic published its own position on open-weights models separately rather than signing, and Dario Amodei's reasoning is worth a read next to the letter. One paragraph in the letter is doing political work: it draws a firm line between distillation as a legitimate, long-standing technique for model improvement and unlawful extraction from closed models, and asks policymakers not to conflate them. Joan Westenberg's response cuts straight at that seam: distillation is a mirror, and the US labs just hate what they see.

What makes this current rather than theoretical is the release of Kimi K3. An open-weight model standing toe to toe with the frontier changes what a letter about open weights is actually arguing for. It stops being a values statement about ecosystems and becomes a competitive position about who captures the next layer of the stack. It seems that Jensen will be selling shovels to all those gold seekers for a good while longer.

Worth reading:

Graph and loop engineering is orchestration rediscovered now that the nodes are worth connecting

LangChain published some interesting articles on "loop engineering" and "graph engineering" this month. Graph engineering is not a new idea, it is the latest name for a well established approach, and it is the same idea behind loop engineering and harness engineering. What changed in 2026 is the quality of what sits in each node (i.e. individual agents actually became useful). After several years of optimising single agents through prompt, context and harness work, the nodes finally became reliable enough that wiring agents into sequences, loops and graphs compounds capability rather than only compounding error.

The most useful framing in the loop material is the "loopcrafting" stack: the agent loop, then a verification loop around it, then an event-driven loop, then hill-climbing. Each layer needs its own instrumentation, and the failure modes at each layer are all distributed-systems classics wearing new hats. Fan-in, fan-out, duplicate work, conflicting state, cycles, deadlocks, unclear ownership. Rahul Garg's piece on the orchestrator's tax gives heuristics on how and why to carve out subagents: the value of a subagent is not the time saved or the parallelism it affords, it is what the subagent keeps out of the orchestrator's context window. Every token in there competes for attention. Subagents are a context management technique.

I keep coming back to a four-question test whenever a new "engineering" buzzword shows up. What old practices does this resemble? What changes because an LLM is involved? What new failure modes appear? And what do I do differently tomorrow? Graph engineering passes on the first three and stumbles on the fourth for most teams, because the tax nobody budgets for is that human judgment does not parallelize. It routes through one serial processor, which is you. Addy Osmani's autonomy slider is another phrasing of the same constraint: autonomy is not a fixed setting, it is a dial you set per task, turned up only as far as you can still cheaply verify the result.

Worth reading:

Designing code for humans turned out to be how you design it for agents

Modem's codebase is roughly 99.9% written by AI agents, which makes their write-up the closest thing available to a controlled experiment on what agents actually need from a repository. The answer is three levers, and every one of them is a classic. The names you choose, the types you define, and where you put your explanations. Ubiquitous language stopped being a communication nicety and became machine-readable infrastructure, which is a strange and slightly delightful vindication for all of us DDD old-hats.

Valentina Servile argues we should still design code for humans, and that full autonomy for agents is a mistake. Radability and understandability is not just a courtesy extended to colleagues. It is a property of the system that happened to benefit colleagues and now greatly benefits agents. Software design is context engineering. Ian Cooper's gear metaphor is the most practical framing I have seen written down for choosing how much of that property to trade away on a given task.

There is a false dichotomy at play here, and it is "design for humans" versus "design for agents". The interesting question is where the design work happens now that typing is cheap. I am finding that it moves upstream, into the conversation before any code exists. Two people and an agent, with the agent interrogating both of them about a feature until the specification is airtight, front-loads exactly the decisions that used to surface three days later in review or in production. The pull request becomes a formality that verifies the implementation matches an agreement everyone already made. Disagreement about intent moves out of review, where it blocks flow, and into the design conversation, where it is cheap.

Worth reading:

Substitutes or complements is decided by what your profession left in the training data

Imagine an alternate universe where nobody ever published source code. No open source movement, no GitHub, no StackOverflow. That universe still has tens of petabytes of public binaries, far more than today's frontier training sets. So at some point the models get good at producing complete working applications from specifications, skipping the source code step entirely. Software gets vibe-rolled rather than vibe-coded, because there is no code. It is worse software, and it is free.

In that universe, a software engineer adds nothing to the process except cost. Binaries are equally inscrutable to everyone, so an engineer has no advantage in supervising the output over a non-technical person. Engineers and AI become substitutes rather than complements, and the whole thing feels alienating and terrifying. Narayanan's point is that this is not a hypothetical for most professions. It is the actual lived experience of artists and many others, because in most fields the finished work is available to train on while almost nothing that went into making it ever got published.

Our profession got lucky through a historical accident. We published not just outputs but specifications, plans, mockups, issues, pull requests, code reviews, bug fixes and an entire culture of arguing in public about why we did things. That missing middle is exactly what makes agents amplify us instead of replacing us, and it is why the barrier to entering a new language or codebase has dropped by roughly two orders of magnitude. The corollary: companies now racing to capture tacit knowledge and process traces (hi Zuck!) are mostly doing it in pursuit of automation, and Narayanan's thesis is that the same captured material is what would make augmentation possible instead. Which of those two things it becomes is a societal choice, not a technical decision.

Worth reading:

Quick Hits

Curated from 302 sources across articles, podcasts, and videos. Week of July 25 - August 1, 2026.

Read more