Digest · October 14, 2026

Things I wrote

How quickly the models caught up on accounting tasks

The charts in this one took me a while to understand because the comparison looked so odd. Models that had been well behind accountants were suddenly getting the tasks right in a fraction of the time. The study itself tested 12 CPAs on four defined accounting tasks, with files to work through and answers that could be checked. It didn’t test the whole job, including client conversations or the context someone builds up working at a company.

Rocket fuel for curious people

This guy maybe discovered a planet by getting some public NASA data and talking to Claude Code about it. Still needs confirmation, but what a time to be curious about things. I ended up trying a couple of public-data experiments myself after seeing this.

Being more ambitious with these tools

A common failure with these tools is not being ambitious enough. That’s easy advice to give and harder to know what to do with. Felix’s tutorial adds some specificity. One example starts with a quarterly presentation, then backs up to the decision it’s supposed to help with, the raw data, and how you’d check the analysis.

The expertise behind a simple interaction

There have always been people you could have a short-hand conversation with and immediately get aligned. Simple language, a lot of shared understanding behind it. LLMs work similarly. When someone knows what they’re doing, the interaction can look almost effortless. It only looks that way because of the hard-won domain expertise.

Expert interviews as part of the improvement loop

I’ve gotten some workflows in place where I interview users / domain experts about the outputs, record and transcribe the conversations, and feed those transcripts into a skill in my custom harness. The feedback flows back into improving the system. It feels weird how easy that part can be once you’ve done the work to build the system around it.

Rethinking the whole process

A lot of companies are starting to use these tools to improve little pieces of an existing process. You have to start somewhere, but I think there’s a much bigger opportunity to rethink the process entirely. That involves changing things inside a company that are very hard to change. I think the companies willing to do it will have a longer window to benefit than we expect, because most companies won’t. I followed up on the organizational side: people who know how to use these tools need support from leaders willing to rethink how the company works.

Things I’m trying

Playing around with government data. I wanted to see whether there was something underexplored in these datasets that I could dig into. Very early experimentation, and I didn’t keep the code, but I did get into a couple of things:

Great Lakes water levels: Pulled NOAA data from four Lake Michigan gauges and plotted the readings. The first check picked up a known meteotsunami. Then I looked at another sharp change in Milwaukee’s water level and compared it with weather data. Didn’t get far enough to establish what caused it or whether it was already documented.
Seafloor sonar: Downloaded old NOAA sonar data and looked for plumes above the seabed, including whether they showed up when the ship passed over the same area again. They did, though getting the positions right was tricky. The survey covered known seeps, so this was mostly figuring out how to read the data. We didn’t discover a new one.

Things I listened to

Alex Zhang - Academia Is for Ambition

I really like the recursive language model stuff Alex is working on. I shared some RLM material last time; this conversation gets further into how it works and when you’d use it.

The model works through code: reading context, calling tools, and making more model calls for smaller pieces of the problem. The original context stays on disk so it can go back and read it after compaction.
Alex’s argument is that each call can work on a small, familiar task, even when the overall problem is outside what the model has seen before. Breaking up the work this way gives it a better chance of handling a long task.
He still says ordinary context compaction is preferable in many cases because it’s cheaper and faster. RLMs give you another option when that isn’t enough.

Thariq Shihipar - Claude Code’s Next Era

The common thread for me across this one, Alex’s, and Tibo’s: you have to keep rethinking how you work as the models improve. Something that needed a complicated setup a few months ago might be much simpler now.

Thariq suggests starting a new project without a CLAUDE.md and adding instructions when you see the same failure repeat. Otherwise you can accumulate rules for problems the newer model doesn’t have anymore.
Ask for decision or implementation notes. In the eval transcripts he reviewed, the model often considered the right approach and talked itself out of it. With the notes, you can see that and tell it to try the thing it skipped.
He talks about how much domain vocabulary helps. A designer can specify fonts, components, and references. He ends up asking for eight mockups because he doesn’t know how to describe exactly what he wants.

Tibo Sottiaux - We’re Entering a New Era of AI (Again)

Tibo describes going back and forth between running a bunch of agents and having one do the work.

He builds larger agent teams as he takes on harder tasks. Then a better model comes out, one agent can handle more of it, and he shrinks the team again.
A faster model also changed how he worked. He could stay in the flow with one agent instead of keeping several going while he waited.
He describes spending more compute on a second system that watches the working agent for risky actions and prompt injection, and intervenes when needed.

Alistair Smallwood - Where Will Investors Find Alpha in the Age of AI?

I posted about this one, particularly the eval loops. Alistair gets into what they tried and where the models got things wrong.

The models kept reading earnings calls as positive, including calls from companies that missed expectations. Management sounding upbeat wasn’t telling them what they needed to know.
His team also found contradictory answers in the benchmarks they were using. They had to check the grading data itself before trusting the scores.
He uses the output to find things worth investigating. There’s still research to do between spotting a discrepancy and making an investment decision.

Josh Woodward - Why Every Company Now Needs to Think and Operate Like a Lab Team

Josh keeps a list of things that are almost possible, then revisits it as the models improve.

Something on that list might be waiting for faster responses or better handling of a particular kind of input. Those changes can make an idea workable without it being an entirely new capability.
When something becomes possible, he looks for the user problem it could solve and puts a team around it.
He talks about having to unlearn old approaches, and keeping the people experimenting with the models close to the business so that work has somewhere to go.

Justin Solomon - How AI Is Upending the World of Mathematics

Solomon talks about what changes in mathematics when models can produce proofs, including how he checks whether his students understand the work.

A model can generate a proof and a formal system like Lean can check it. That gives you a way to verify the result independently of the model.
A proof can check out and still leave you without much understanding of why it works. Solomon also talks about the harder question of which problems are worth working on.
He gives students a homework problem again on a quiz and uses an oral component to check understanding. Seeing a correct homework submission tells him less now that students can generate one.

More episodes and takeaways are in my Listening Index.

Other things that caught my attention

Posts

Jameson Haslam on a contractor’s quoting workflow: A contractor records site walkthroughs and combines them with measurements, customer history, and pricing information to put together recaps and proposals.
Patrick Collison on agents and purchasing: Agents could do more of the work of comparing products, reading the terms, and catching subscriptions you forgot about. He considers whether that would reward better products, assuming the agents are working for the buyer. I hope this plays out.
Matt Pocock on reviewing recent agent sessions: Go through recent sessions and find where the agent kept getting stuck or couldn’t find things. Use that to decide what to fix in the docs.

Articles

Josh Rosen on traces: What you can learn from model logs, saved sessions, and the files or other changes an agent leaves behind. Having a trace doesn’t necessarily mean you can replay what happened. Related: his software-factory article on making the work visible and improving the process from human feedback.
Uber on building a contract-redlining agent: They tried giving the agent a legal playbook, then found they needed examples of lawyers’ actual edits and the reasons behind them. They also kept it inside Word, where the lawyers were already working.
Building effective agent automations: A worked example of an agent that checks Slack and GitHub on a schedule. It gets into the details that are easy to miss: remembering where the last run stopped, reporting when a source couldn’t be read, and checking that a post went through before marking items as reported.
Anthropic on redesigning source control: Their agents and CI jobs were putting enough pressure on Git that they built their own system. They explain what changes when clients are always online and can ask a server for history or individual files. Their workload is unusual, and they explicitly say this isn’t a general replacement for Git.