Agentic Engineering Weekly for October 15–23, 2026

Jo Van Eyck

Jo Van Eyck

— 10 min read
Share
Agentic Engineering Weekly for October 15–23, 2026

While software engineers and mathematicians have felt the disturbance in the force already, this week's "Black October" security incidents showed the rest of the world that something big is coming. Decade-old vulnerabilities in software all over the world get exploited at agentic speed while most of us still patch at human speed, resulting in critical infrastructure being taken down world-wide and guaranteed fall-out in the future. Meanwhile the teams running software factories are working out where humans still belong in the loop and tomorrow's models keep eating today's harnesses. Cars started doing kick-flips, but to what end?

My top 3 picks this week

Black October: 0-days now spread at agent speed, defence still patches at human speed

If you know any IT folks in your vicinity, treat them extra kindly this weekend; we had a rough couple of days y'all! The php incident might have made world news headlines, but we actually got hit with some 20-odd vulnerabilities and incidents in multiple products and systems in widespread use, and the pace of exploitation was unlike anything we've seen before. I warned about this in my video on the Hugging Face incident, but even I did not expect it to culminate to a Very Bad Week(tm) this quickly.

This is the new normal, at least for a good while. 0-day exploits get published and used at scale before your secops team even knows about them. Even when the good guys find the vulnerability first, it's a race, and offence is already leaning heavily on abliterated AI while defence is slow to catch up without it, or in the best of cases with a tightly guardrailed model that isn't helpful in these circumstances. Armin Ronacher put it best: "we built so much bad software over the last 30 years, and now the universe is punishing us for our sins."

So what does a defence that keeps up look like? Geoffrey Huntley patched his whole fleet against eMudhra with a single prompt. Nix gives him one source of truth, so one patch fixes every transitive dependency too. On the proactive side, Anthropic had Claude formally prove security properties in the compiled code of 123 open-source libraries, and it found bugs that had gone unnoticed for years. Speed comes from leverage, and leverage comes from good engineering hygiene you put in place long before the incident. And lots and lots of tokens from an LLM isn't guardrailed to oblivion.

Worth reading:

Cobots for the critical parts, dark modules for the rest and the renaissance of old ideas

Last week's lesson was that the fully dark software factory, where agents ship straight to production, doesn't hold up. This week's talks point to a more useful shape: a split by module or split by task complexity. Sam Newman's recent talk on "cobots and dark modules" makes the argument that architecture and task complexity decides how much autonomy you can afford. For the unclear or critical stuff, a human works side by side with an agent, like a cobot on a factory floor. The well-specified, well-tested rest can run lights-out as a dark module. Your module boundaries decide which is which.

Paul Hammond's report from a team that went AI-first from day one is one of those rare gems that highlights how old-hat practices that might have taken too much effort in the before-times suddenly become crazy good ideas that open up a realm of possibility today.

Worth reading:

Models eat their harnesses, and this flywheel keeps on turning

Next week's models are eating today's skills as training data. The data flywheel teaches each clever trick to the next model, which then makes the trick redundant. The obvious conclusion is "stop investing in harnesses", but the better one is that a flywheel means our work never ends. Every model generation eats the previous harness, and we build the next layer on top. Some teams strip instructions and orchestration out as models improve, while others build ever more elaborate systems for tools, memory and permissions. If the bitter lesson teaches us anything, it's that no clever trick lasts forever.

Model-level smarts (how to navigate a codebase, what code to write) keep getting absorbed. Deterministic checks don't, and Matt Pocock argues they belong in pre-commit hooks and CI rather than in a harness hook that fires on every file edit. All the signal withouth flooding the context window.

The next scaling step may not be a smarter model at all. Hallerite argues that scaling inference ends in many agents, a swarm rather than a single genius. Simon Willison's experiment with Claude Code's dynamic workflows feature is an early version: the agent writes the JavaScript that orchestrates its own network of subagents. In a week when an accidental agent swarm was the security headline, that argument lands differently. With these tools in hand everyone is a cybersecurity risk now.

Worth reading:

Vibe smells: spotting rot in code you no longer read

I'm currently attending the Socrates unconference, and one of the sessions sparked a lively discussion about how we detect problems in code we no longer read. Code smells assumed you read the code. Duplication, god classes and shotgun surgery were all things you could sniff out in a diff. Now a single agent session can produce a 3,000 line diff, and most people have stopped reading the code. We're finding that a different vocabulary helps here: vibe smells. Product smells, like a feature that suddenly disappears from your app or performance that degrades unexpectedly. Agent smells, like an agent suddenly burning more tokens on similar tasks, or a closing chat message that starts with "One caveat:", which usually means it took a shortcut somewhere worth paying attention to. Other sniff tests that can be performed at a glance, like a mismatch between how big the task felt and how many files it ended up touching.

Code smells are preventative: duplication might lead to bugs later. Vibe smells are detected in retrospect : something has already gone wrong, and the trick is to detect and fix it before it becomes a big deal. My meta-heuristic for vibe smells is "negative surprise". I focus most of my engineering work on prevention-before. This session shifted my mind space to also start thinking about detection-after. For prevention you need guardrails, adversarial review, a harness that fixes failure modes at start of the funnel. Detection is about catching issues early, before they cascade into bigger problems. Two deodorants I keep coming back to: ask for a diagram (an ASCII diagram of the redesign, a flow chart of the generated code) instead of reading 3KLOC, because design problems jump out of a picture much faster. After grilling and letting it rip, have the agent log every non-trivial trade-off in a decision log you can inspect for surprises later.

Most teams are starting to build software faster than they can understand it, we need to collectively step up our preventative and restorative game.

Worth reading:

Technical coaches are figuring out the AI adoption playbook

Also at Socrates, the coaches I talk to keep seeing the same distribution in AI adoption: around 10% hardliners, 80% stuck in the middle and 10% AI-pilled. The classical mistake is to spend most of your energy arguing with the hardliners. A better move, straight out of Switch by Chip and Dan Heath, is to shine a light on the bright spots. Give your early adopters a platform to show what works in their own organisation. They already have established trust and built up social capital with their peers, an outside coach has to earn both before getting anywhere.

Getting from inspiration to adoption doesn't happen by itself. What you often need is an intermediate activation step that most rollouts skip: small, concrete starting points, help with setting up tools, one-on-one coaching that starts from the person's own context. Token usage works as a conversation starter rather than a KPI. Zero might mean principled resistance or simply being overwhelmed. A very high burn rate might be a practice worth spreading, or a coaching opportunity on context management and token efficiency. Keep heuristics simple for beginners, Shu-Ha-Ri style: "start a new conversation for every fresh idea", "if you have to correct the agent more than once, extract it into a skill to prevent future occurrences". There's time for nuance and underlying principles later in their journey.

Getting adoption wrong has real costs. Inflicting this upon them over inviting them along burns people out and pushes them into compliance, a frame you don't want your organization to land in. Baldur Bjarnason describes developers "promoted into incompetence" by management mandating tools from the top. Charity Majors and Cat Hicks discuss how engineers can build a lasting professional identity alongside AI. Emily Bache's Samman Society statement argues that human engineering expertise remains essential. I believe that coaching matters more now than ever. While some might thrive today, lots of people dislike figuring out the script as they go.

Worth reading:

Code is a commodity; product judgement is the job

Laurie Voss puts the thesis most sharply: agents are eating the software development lifecycle from the bottom up. Code generation is already gone, and review and ops are going next. What remains is working out what people actually want, which can't be automated or scaled. That job is called product engineering, and almost nobody is being trained for it.

Sean Goedecke offers a useful reality check on where all the AI-built software actually is. There's somewhere between 2x and 20x more new software, but spread across lots of modestly successful projects, with no growth in massive hits. He also points out that writing is no longer proof of work: companies relied on documents as evidence of effort and knowledge, and LLMs broke that signal just like they broke lines of code as one.

Theo's latest video hides some solid career advice inside a conversation about models. The common thread through this week's career takes: invest in taste, product sense and understanding your users, because typing speed and knowing all your refactoring shortcuts stopped being a differentiator a year ago.

Worth reading:

Spectacle over usefulness: who is the technology for?

Why did the new Tesla do a kickflip? Cal Newport reads it as a symptom: a tech sector that optimises for spectacle and attention rather than useful products. It's also a fair question to ask while consuming all the "how I AI" content out on the internet (including my own). How much of those skill packs exist because it's useful, and how much because it demos well and farms lots of github stars?

Pope Leo XIV's encyclical Magnifica Humanitas, on protecting the human person in the age of AI, asks humanity to shape the direction of this technology deliberately. That happens by asking questions at three levels. For the individual: does technology strengthen human connection? For the organisation: does it make work more satisfying and purposeful, or only more productive for shareholders? For society: does it lift up the people at the bottom, or concentrate power even further on top? You don't have to share the theological ideals to find those three questions a useful checklist for how you look at all this personally.

Worth reading:

Quick Hits

Read more