Digest · November 11, 2026

Things I wrote

Writing things down before opening the agent

I find myself opening a text editor more and more before I send anything to an agent. It forces me to think through what I want to do and explain it clearly. Knowing something the models don’t know helps, but you still have to be able to write that knowledge down and have a feel for how the tools respond to it. Planning and critical thinking still matter, even as the models can figure out more of the details themselves.

Making your judgments part of the system

When you make a judgment or correct an agent, that should feed back into how the system works next time. Otherwise you end up making the same decisions over and over. The system should keep moving without constantly waiting on you, while still knowing when it needs your input. I wrote more about how this could apply beyond software: bringing you decisions in a way that’s easy to respond to, pointing out blind spots, and learning from your preferences. These patterns are starting to work in software, and I think they’ll change how people run other parts of a company too.

Give agents a way to check their work

Giving agents ways to check their work has forced me to think more carefully about what correctness means for each project. If this were done correctly, what would it look like? That’s hard when the work is subjective or there’s a lot of nuance, but having to think it through is useful on its own. For code, it’s worth spending the time to give the agent an environment that’s close to production, where it can run the application, inspect the logs, and use what it finds to make improvements.

Memory needs work between sessions too

A bunch of Anthropic’s article on memory matched my own experience. I use a wiki for my projects and periodically go back through sessions to distill what the models should remember. Their “dreaming” process does something similar: it reads the sessions and existing memories, corrects mistakes, and reorganizes things. I particularly liked that it can change the wiki structure as it learns more. There’s still a ton to figure out here, including when to search the original sessions alongside the wiki.

Things I’m trying

Exploring Shorewood’s handwritten 1950 census records

I spent a few hours with Fable 5.2 building an explorer for the handwritten 1950 census records from Shorewood, where I live. My starting prompt was pretty simple: find the records, build an interactive explorer, and ask me any questions. Most of my follow-ups were asking what else it could visualize or how to make the interface easier to understand. It was more fun to see what it came up with.

I was mostly surprised by how well it read the scanned PDFs. The handwriting is hard to read, and even figuring out how the data is linked together takes some work for a human. Fable figured out a lot of that on its own. Often it had twenty subagents working on different things. I was pretty blown away by how it made sense of all that unstructured data, and by the visualizations and interface it built.

You can search names and addresses and go back to the original handwritten lines. The transcriptions haven’t all been checked, so you’ll still want to look at the source sheets. I also had it make a short film of a census taker working through a street.

Things I listened to

Zach Lloyd - The 2026 Software Factory Standard

I really liked this episode. “Software factory” is getting a lot of buzz and seems to mean something different to everyone, but Zach lays out some principles that could apply across different implementations. A lot of it comes down to being able to test whether the work is correct, then using what you learn to improve the system itself.

Warp saves agent runs and replays tasks with different models and harnesses to compare cost and correctness on its own work.
Their early runs cost about $80 per PR. They were using an expensive model for triage and spawning too many subagents. After changing the workflow, they got that down to roughly $15 to $20.
Agents can look through failed runs and propose changes to the workflow code. They still wanted to build the next part: replaying the old tasks to check whether those changes actually helped.

Kevin Roose - The Inside Story of the 50 Who Built Modern AI

Roose talks about how he used agents while researching his book. He wrote the book himself, but had the models help organize the material and review chapters.

He had agents review chapters as an AI skeptic, a technical historian, and an editor looking at the storytelling. Another agent combined the feedback. He says they caught a couple of factual errors that he and his human editors had missed.
He used NotebookLM to find who had told him a particular story and which sources to contact about an event.
He calls work where you want the effort “weightlifting,” and work you just need done “forklifting.” Writing was something he wanted to do himself. Organizing research and handling administrative work were things he was happy to hand over.

AI Daily Brief - AI Lurches Toward Recursive Self-Improvement

Nathaniel Whittemore talks about the recent experiments with models reading and editing weights, what people are spending on agents, and why companies are still slow to adopt them.

One experiment improved math results by fixing a bug that made the model get stuck in reasoning loops. The episode covers the disagreement over how much that tells us about models being able to improve themselves more generally.
He’s paying for agents to do work he would never have hired someone to do. Hiring would also mean finding and managing that person, which is part of the cost comparison.
He argues that companies are already behind what the models can do. Better models alone won’t get them to change how they work.

More episodes and takeaways are in my Listening Index.

Other things that caught my attention

Posts

Karri Saarinen on companies struggling to keep up with their own output: Everyone can be producing work they think is useful while making it harder for colleagues to keep track of what’s happening. He asks how leaders can follow all of it without reviewing everything themselves.
Cloudflare’s security-audit skill: Has agents look for security problems in a repo, then has other agents try to disprove what they found. The report keeps confirmed issues separate from findings that were rejected or still need checking.
Brian Scanlan’s five-whys skill: Works through what caused an incident and checks the explanation against the evidence. It asks what you’d need to observe to confirm or rule out each proposed cause.

Articles

How Odessia built with agents: I called this a blueprint for going from zero to one. They describe how they share context, use voice prompts, and turn repeated corrections into skills. They also talk about how intense the work became when they could produce more and had more decisions to make.
Shopify’s app rebuild: Thirty engineers rebuilt more than 300 screens in twelve weeks. They get into how they tested without launching a device, kept changes small enough to review, and updated instructions based on review comments. They had the existing app to work from, so they don’t claim this tells us how it would go for entirely new features.
Simon Willison tries interpreting model weights on his laptop: He uses Qwen to identify three of four games from their networks’ weights. He also explains how this differs from having a model use code to modify another model, and how much we can conclude from the experiments so far.
Thinking about investment research as a computational graph: A practitioner at Coatue breaks investment research into smaller steps that can each be tested. Some might work better with code or statistics, and others with a person. There’s still a lot of work in deciding what those steps should be and how to connect them.