Agentic Engineering Weekly for October 9–17, 2026

Jo Van Eyck

Jo Van Eyck

— 11 min read
Share
Agentic Engineering Weekly for October 9–17, 2026

Code is getting so cheap that everything around it starts to crack: Anthropic replaced git, everyone revisits their code review priors, the people who actually tried running lights-out software factories came back with a familiar lesson. Underneath it all, one discipline keeps resurfacing: let the machine grind at the tedium, not the thinking.

My top 5 picks this week

Heads up, I honestly could not cut it down to just 3 this week. So much is happening and being shared publicly (if you know where to look). These 5 pieces are very long and extremely dense, but there's so much alpha in here. Better grab a strong cup of coffee!

Offload the tedium, not the cognitive friction

"AI rots your brain" has been a vibe for a while. Cal Newport walked through a new paper that uses mathematical models to explain how leaning on LLMs erodes our ability to think, and The Independent reported a study where just ten minutes of AI assistance made people measurably worse at sticking with hard problems afterwards. The useful part is Cal's distilled advice: use AI to reduce tedium, not cognitive friction. Do your own weiting. Read long-form text. Find whatever "cognitive gym" works for you. And don't summarize human-written text, a good author is supposed to already have compacted it optimally for a human reader. Leaning on AI summaries strip out exactly the struggle that makes things stick.

The false choice here is "use AI" versus "keep your skills". The real question is where you let the friction happen and where you reduce toil. Carlos Kelkboom, has the sharpest rule I heard this week: the moment he no longer understands a piece of generated code, he throws it away. For him, comprehension is a hard gate, not a nice-to-have. For others, post-factum explainability becomes more important than upfront understanding. Eric Ries draws the same line from the Lean Startup side: speed is fine, outsourcing your learning loop is not. Matt Pocock adds that agents are brilliant tacticians and poor strategists, so somebody still has to care about the long-term shape of the codebase.

This is also why I keep pushing on practices like grilling (where you still do strategic thinking and consider trade-offs), dim factories with humans on the loop at the intent checkpoints, and before/after architecture diffs on every change to keep a running mental model of the system at large. They're mechanisms for keeping your mental model alive while the agent does the typing at breakneck speed. Emily Bache shows what happens without them: put an agent in the typist seat of a mob and the shared thinking that made mobbing valuable evaporates faster than your token quota. Nacho Cougil asks an uncomfortable follow-up: is AI killing XP practices, or are we just letting it?

Worth reading:

"Did a human read it?" is the wrong review question

Lots of people made waves recently by declaring they don't read generated code anymore. The reflexive response is "irresponsible!". The more interesting responses this week reframed the question. Lots of folks argue that "did a human read the code?" is an imprecise proxy for "what could go wrong with this change, and which check, automated or human, is the right one to catch it?".

Mark Seemann pushes back with epistemology and liability: if nobody read it, who actually knows it works, and who is on the hook when it doesn't? Both camps agree on one thing: you need evidence. That evidence can come from formal verification and testing, from production observability, or from honest measurement.

Then there's the skill nobody (except the few engineers working at big tech co's) trained us for: debugging systems whose code no human fully understands. Cindy Sridharan's piece is such a rare read, and her outlook lines up closely with what Uber describes from inside its agentic platform (see the next section). For a hopeful counterpoint: Linus Torvalds used Claude Code to make kernel code more decipherable, and the readability pass uncovered more bugs. Comprehension as the output of AI, not the casualty. Reduce toil for current (and future) you.

Worth reading:

At 10x merge rates, git itself becomes the bottleneck

Anthropic replaced git. As their merges per day grew more than tenfold, source control and CI/CD pipelines became their single biggest development bottleneck, so they migrated to an in-house version control system. Think about what that means. The tool that has absorbed every increase in team size and change rate for twenty years hit its ceiling once agents started pumping out code. When one stage of the pipeline speeds up by an order of magnitude, the constraint simply moves to the next one. Goldratt would not be surprised.

Uber shows the same pattern from inside a big tech agentic platform. Uday Kiran Medisetty walks through how they build internal developer tools, how agents plug into engineering workflows, and how they measure the impact: a rare, detailed look at the plumbing rather than the demo. The leverage is moving to the infrastructure around the agent. Big tech is taking swings and can ride on years of prior developer tool investment. The rest of the world will be catching up for a decade or more.

Geoffrey Huntley takes the argument to open source. If pull requests are the choke point inside companies, they're the choke point in the bazaar too. His proposal: projects that are closed to pull requests and open to remix. Fork it, let your agent adapt it, move on. Whether you love or hate that idea, it's a coherent answer to a real problem: maintainers drowning in agent-generated contributions they can't possibly review.

Worth reading:

The dark factory is unviable; the dim factory with feedback loops works

The "dark factory" pitch is seductive: hand your agents a big spec, turn off the lights, and production-ready software comes out the other end. Cole Medin spent a big chunk of this year building one and concluded it wouldn't work, for a refreshingly unglamorous reason: LLMs can't read our minds. Intent is underspecified until a human looks at the result and says "no, not like that". Code is the ultimate spec. So he rebuilt it as a factory with humans at the intent checkpoints. A dim factory, if you will: mostly automated, with the lights on exactly where judgment is needed. I did exactly that in my own video last week.

The people actually running factories are converging on the same design. Kent C. Dodds shipped 122 PRs in 24 hours, the interesting part is his system: agents file their own friction reports, catch their own mistakes and keep the blast radius of every change small. Maria Gorinova (Tessl) calls these feedback loops that fix your codebase: agents mining their own session logs, PR comments and production signals, then fixing what they find. Her warning matches Cole's: vague intent turns a loop into a mess. Steve Yegge, running around fifty agents on his game Wyvern, is candid about the breakdowns alongside the breakthroughs. Pocock recently introduced his /retro skill.

What most adoption stories skip is the human side. Zach Lloyd's thread on rolling out software factories focuses on exactly that: the organizational and people changes that determine whether a factory takes root or gets ignored while engineers shrug along their normal business.

Worth reading:

Typing code is over; what's left is vision, verification and ambition

Everybody is shouting "be more ambitious" right now. Theo says go bigger. Steve Yegge says all you need is ambition. It's easy advice to post and hard advice to follow. Felix Rieseberg finally wrote the tutorial: ambition broken down into four dimensions you can deliberately increase. Speed (do the thing faster), altitude (work on a bigger version of the problem), depth (go further into it than you normally would) and range (try things outside your usual lane). Each comes with concrete prompts. It turns a motivational slogan into a practice.

Geoffrey Huntley's latest is the best summary I've read of where we are and where we're heading. The models stopped being the constraint a while ago (they're better than the average engineer); what's left is curiosity, vision, verification and agency. His advice is deliberately jarring: delete your skill packs, put the whole system under test, and revisit everything that used to be too hard to attempt. His conversation with Armin Ronacher and Ben Vinegar on State of Agentic Coding covers a lot of ground, from the "curiosity test" to durable agents to why the AI labs cannot afford to fail.

If you want to see what this looks like in someone's actual workday, Amp published two rare peeks inside the heads of some of the most AI-native engineers out there. Thorsten Ball walks through how he uses Amp, and Quinn Slack shows how the team uses Amp to build Amp.

Worth reading:

GitHub stars are a circular signal; the real experiments say the harness beats the model

How do you pick an AI coding tool or technique these days? If you're honest, probably by popularity. Avdi Grimm's rant nails the problem: the social-proof machine is circular. A tool gets stars because influencers mention it, influencers mention it because it has stars, and nobody along the way measured anything. It's vibes all the way down. Popularity has become the main signal driving tool choices, and it's getting absurd. If you're starting to lose sight of the factory forest for the loop-engineering trees, three resources help: Lada Kesseler's augmented coding patterns, Tessl's pattern index, and Matt Pocock's AI coding dictionary. Maps beat leaderboards.

Meanwhile, the few people running actual experiments are finding something more useful than stars. Naresh Jain had coding agents build the same API service with and without a behavioural harness. The frontier model, GPT-6 Sol, passed every evaluation either way. The cost-optimized GPT-6 Luna succeeded in only 3 of 10 runs without the harness, and became reliable with it. LangChain built a model router into their harness that cut median cost per coding task by 64% with no measurable quality drop. The harness is what turns a cheap model into a viable one.

That matters more every week, because we're in a compute crunch. Huntley describes how even OpenAI admits to inference capacity problems. When frontier tokens are scarce and expensive, the teams with a good harness can route most of their work to cheaper models and save the expensive ones for where they matter. That's an engineering edge you build, not one you download based on a star count.

Worth reading:

The lethal trifecta is already running on your laptop

Simon Willison's lethal trifecta is the combination of access to private data, exposure to untrusted content, and the ability to communicate externally. Any agent that has all three can be tricked into leaking your secrets. Michael Patterson makes the uncomfortable point that this isn't a future risk: the coding agent on every developer's laptop already ticks all three boxes. It reads your repo and credentials, it ingests web pages and issue comments, and it can make network calls. And no, "just put it in Docker" doesn't save you from this risk.

The most interesting response this week came from an unexpected corner. Martin Odersky, the designer of Scala, used his Scala Days keynote to reflect on the future of programming and pitched typed tool calling as an antidote: constrain what an agent is able to do in the type system rather than hoping a prompt or a policy holds. Capabilities you can't express can't be abused. It's the same instinct as moving security boundaries outside the agent, but enforced by a compiler.

Worth reading:

Quick Hits

Read more