Seroter's Daily Reading — #861 (September 4, 2026) · Seroter's Daily Reading

Listen: https://blossom.buildtall.systems/ae33e187c0d47ab1e828eae12996be7bd8539290067d74b21c4c53b9c1e94495.mp3

Episode 861, Friday, September 4, 2026. That wraps up the week. Seroter is heading into a long weekend here in the States and will be back with a new list on Tuesday. But before that, there is a full slate today: nine pieces spanning AI incumbents, open weight models, and even the twentieth birthday of jQuery.

Let's start with a big-picture strategy piece from a16z called The Incumbents Are Coming. Seroter flagged that he actually likes it when a dominant leader roars back against a feisty challenger, and that is exactly the story here. The core argument is that AI makes systems of record more important, not less. The theory goes that a customer can now pipe a system's data directly into Claude or Codex and skip the AI-native app altogether, which means an incumbent system of record plus a general agent might be enough to get the work done. That is what Salesforce just announced with Anthropic: a partnership called Claudeforce that lets you work with the Salesforce CRM from inside Claude without ever opening Salesforce. The article says the argument is only partly correct, because the interface and the system of record look like they are unbundling, which creates an opening for AI-native startups to rebundle around the job. The most useful part is a hierarchy of four kinds of agents, from retrieval assistants that just find information, up through process agents that carry out rule-based work, policy agents that apply an organization's playbooks, and finally principal agents that make real judgment calls. A year ago most incumbents were still stuck at the retrieval stage. Now they are moving up. But the piece's key insight is that the job is bigger than the record. A contract is not the legal matter, and a support ticket is not the actual resolution. So the vertical AI startup wins through focus and through a learning loop, where seeing the decisions and corrections that produced a good result is what improves the system. They point to Harvey, the legal AI company, which manufactured its own training curriculum rather than waiting years for customer history. It is a genuinely useful framework for thinking about where startups can still compete.

Next up, a short but important practical warning from the Google Cloud blog called Your Agent Doesn't Know How to Wait. Seroter says he had not come across this idea before, and it is not one that gets discussed much. The point is simple: if your agent needs to wait for an operation to finish, you have to design that waiting correctly. If you don't, your costs can balloon, because the agent may spin polling or repeatedly kick off work while it waits instead of pausing efficiently. Worth keeping in mind the next time you wire up an async tool call.

On a related note, JetBrains has a solid refresher on How to Handle Errors in Go. Seroter's framing is good: whether you write the code yourself or have an AI agent write it for you, you need robust error handling. Go treats errors as values, not exceptions. A function returns an error alongside its other return values, and the caller has the duty to check it. The article walks through returning errors, panic and recover, logging, and the part where people tend to trip up most often: error wrapping. When you bubble an error up through several functions, you should wrap it with context using fmt.Errorf and the percent-w verb, so the original error stays intact and can be unwrapped later. Simply concatenating the message string destroys the type information. For anything an agent generates, these details matter more, not less.

Moving to a couple of research-oriented reads. First, from Harvard Business Review, a piece on how curveball questions can surface the insight you are looking for. Seroter has spent a fair amount of time this year working on asking better questions, and this landed for him. The premise is that we are all taught to ask tough, open-ended questions to get past rehearsed answers, but a curveball question does something more specific: it jolts someone off a well-worn script and reveals what they were not planning to say. It is a useful nudge for interviews, negotiations, and one-on-ones.

Then there is a research digest asking how developer experience shapes the way teams use coding agents. The headline finding is that more experience in a project means more careful, more rigorous use of AI. Researchers analyzed over nine thousand agent-generated pull requests across nearly fourteen hundred repositories, splitting developers into core and peripheral contributors based on their history before agents existed. Both groups delegated at about the same rate, but they delegated different work: core developers sent 42.7 percent of their agent PRs to documentation and testing, while peripheral developers spread their tasks evenly across bugs, features, docs, and tests. The sharpest finding is verification. Core developers reviewed agent output close to twice as hard, and peripheral developers had agent PRs merge with no CI check running at nearly double the rate. Almost three quarters of agent PRs merged with no human modification at all. For engineering leaders, the takeaways are concrete: gate agent PRs on a passing check suite, and route risky categories to a core reviewer.

Two more from Google Cloud. One is a deep dive on caching Docker layers on Cloud Build, with the message that you should stop rebuilding from scratch. Seroter notes these numbers have a big impact at scale.

Then there is a really clever piece from Spotify engineering called Portal by Spotify cut my Claude Code token usage by 90 percent. The author's observation is that most of what a coding agent does is not thinking, it is I/O, reading five files to answer one question, or generating boilerplate that matches existing patterns. All those tokens go to a frontier model that is wildly overqualified. The fix is routing: a plugin called Shunt intercepts large file reads and delegates the bulk reading or code writing to a cheap model running as a declarative mode on Spotify Portal, while Claude only sees the summary. The result was about 90 percent token savings. The honest caveats matter too: you cannot delegate editing or reasoning, because the cheap model misses subtle bugs and does not return reliable line numbers.

Then the centerpiece of the day, an excellent analysis from Stephen O'Grady at RedMonk on How to Think About Open Weight Models. If you have only kept a casual eye on the open model space, this is the primer. He walks through several dimensions. Geography: the largest and best-performing open weight models in 2026 are overwhelmingly Chinese, and enterprise token usage of them on OpenRouter reportedly jumped from 4.5 to 63 percent in about a year, which has already triggered political moves toward a US ban. Licensing: the Linux Foundation submitted its OpenMDW license to the OSI, but whether it gets approved as truly open source is not clear, and it is not even settled law that copyright applies to weights at all. Capabilities: the key question is not whether open reaches parity with the frontier, but when it clears the good enough threshold, and by O'Grady's read that already happened. Risks: Anthropic argues open models are dangerous, yet Hugging Face had to use an unrestricted open model, GLM, to defend itself when guard-railed frontier models declined to help. Economics: open weights are a tactic, not a business model, and China is subsidizing them as a matter of national strategy. And there is a nice bit on release timing and distillation to round it out. It is the kind of piece worth reading slowly.

Finally, a nostalgia trip: Twenty Years of jQuery. Twenty years ago, on August 26th, 2006, jQuery 1.0 shipped, built by John Resig with the motto that writing JavaScript should be fun. jQuery collapsed all the browser inconsistencies into a single dollar-sign selector, and its write less, do more ethos shaped every framework that came after. W3Techs still puts it on roughly 66 percent of websites. A lot of that is legacy, but as Seroter put it, this was a big deal twenty years ago, and everything has gotten a lot more complicated since.

And that is the week. A common thread jumps out: almost everything here is about where intelligence actually lives, whether it is the incumbent's system of record, the open weight model you can run yourself, or the cheap worker model handling the grunt work. We'll see how that shakes out when the reading list returns on Tuesday.

Your signing session ended