Seroter's Daily Reading — #869 (September 17, 2026) · Seroter's Daily Reading

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

Welcome back to Seroter's Daily Reading, episode eight sixty nine, for September seventeenth, twenty twenty six. Today we have a packed list that keeps circling one big question: now that agents are doing more of the actual building, what exactly is left for the humans who used to do it? Let's dig in.

The first piece, from PostHog, asks What happens to engineers when AI writes all the code?. The numbers tell the story: PostHog went from about twenty percent of their monorepo pull requests opened by agents to seventy percent in just four months. So the old definition of an engineer as someone who writes code is breaking down. The author lays out five places engineers will actually spend their time now. First, monitoring the situation, which means watching running agents, responding to customers, checking dashboards, and building the systems that surface the right information at the right time. Second, setting direction, deciding where the software should go, which is now increasingly an engineering job rather than a product manager's. Third, deciding how to build, scoping work and knowing what agents are good at and where their blind spots are. Fourth, evaluating the work of your agents, since code review doesn't disappear just because you didn't write the code. And fifth, improving the whole loop, treating your team as a software factory you refine over time. What stuck with me is the framing that the loop mirrors Boyd's OODA loop: observe, orient, decide, act. Engineers aren't going extinct, but the job is fundamentally shifting from writing code to building the system that builds the product.

Next up, Google announced Agent Anomaly Detection, now in Private Preview on the Gemini Enterprise Agent Platform. Seroter's take is that your agent may be doing exactly what it's allowed to do, but something still doesn't feel right, and this service keeps an eye on that. The idea is that the real risk in agents isn't in the code, it's in the behavior. A session can look totally benign, return a clean answer, and close the ticket, but only later do you notice the agent reached for a tool it shouldn't have, or quietly widened its own access. This new layer reads the reasoning traces, tool calls, and OpenTelemetry logs your agents already emit, then flags behavioral anomalies, suspicious intent, and policy violations. Two details I like: it adds no runtime latency because the analysis runs out of band, and its findings are grounded in the OWASP Agentic Top Ten, so they map to recognized risk categories rather than some bespoke rule set. They're also working on letting customers define their own anomaly detectors in natural language, which is the kind of flexibility enterprises will want.

Then there's a piece from Addy Osmani on Brownfield Agentic Engineering, and this is a genuinely useful one. The core point is that throwing agents at an old, existing codebase is nothing like starting from scratch. In a brownfield system, the repository is no longer a complete description of how the thing actually behaves; there's institutional knowledge, duct tape, legacy services, and expectations other teams depend on that live outside the code. His advice is practical. Draw zones: green for well-tested, isolated code where agents can work in a tight loop, yellow for mixed quality where you write characterization tests first, and red for sensitive stuff like auth, billing, and permissions where you don't allow unsupervised rewrites. A human draws the map, not the agent, because left to its own devices an agent heads straight for the scariest file. He also says write down what the code can't say, nothing else, and lock today's behavior with characterization tests before you let anything improve it. His closing line is the thesis: agents changed the price of trying several implementations, but they didn't change the evidence required to choose one.

Moving on, the Harvard Business Review has a piece on When Persuasion Is (and Isn't) Manipulation. Seroter notes he's studied persuasion for years, and there are ways to use this power for bad purposes. The article traces the long history of persuasion books, from Dale Carnegie to modern behavioral science, and the promise underneath them all: learn how people think, and you can move them. The key distinction the piece explores is where legitimate influence ends and manipulation begins, and it matters because influence isn't just a route to power, it's how you exercise leadership once you have it.

Builder.io published something on How to De-Slop an AI-Generated Codebase, and the advice is tighter instructions, better rules, and more context. The root cause they name is the locality problem: the information needed to make a good change lives somewhere else, three files away or in a helper whose name doesn't suggest what it does. An agent that can't find it just adds another check, another fallback, another helper, and the next agent has to rediscover the same facts all over again. Their prescription is to keep related decisions easy to follow, so it's obvious where input becomes trustworthy, which module owns a behavior, and what callers can rely on. Some fixes are small and local, but others need architectural work, and the first step is gathering enough evidence to tell them apart.

Then Salesforce and Nvidia announced a new reasoning model called Koa, and TechCrunch argues it's everything the AI labs should fear. Koa is Salesforce's first reasoning model, built on Nvidia's open-weight Nemotron, post-trained specifically for sales, marketing, and customer support work. The pitch to enterprises is compelling: it's an open-weight alternative to closed frontier models, it's trained for specific work tasks rather than impossible math problems, it never ingested real customer data so it can't leak it, and it burns fewer tokens for the same work. Salesforce even admits they built their own because until Nemotron arrived there was no sovereign American pre-trained model that was both state of the art and had clear data provenance. The article's point is that enterprise needs are diverging from what the frontier labs offer, and I think Seroter is right that this won't be the entire future of models, but it will definitely be a part of it.

RedMonk's Stephen O'Grady wrote a big one called Agents: The new, New Kingmakers. A decade ago his book argued that developers had become the real power behind the throne, deciding what software lived or died. Now that power is shifting again, this time to agents. He draws the parallels: cost, where token spend now has the steepest slope on the P and L; decision making, where agents increasingly choose the languages and frameworks, to the point companies talk about Agent Engine Optimization like they once did SEO; and velocity, where prototyping now takes a fraction of the time. He catalogs the companies reorienting around agents: Neon says eighty percent of new database instances are now created by agents, Vercel went from under three percent agent-triggered deployments to over half in six months, Daytona deprecated its human product entirely, and there's now an entire sandbox category that exists only because agents exist. His closing question is the sharp one: if agents are the new kingmakers, what does that make developers? Optimistically, emperors. Pessimistically, advisors to the queen.

The Research-Driven Engineering Leadership newsletter asked What decides which tasks product managers are willing to delegate to GenAI?, based on a study of eight hundred eighty five PMs inside Microsoft. Two findings stood out. First, identity shaped delegation: people readily handed off tasks they didn't see as core to their expertise, like formatting and meeting notes, but held back on work tied to professional identity. Second, people kept accountability even when they delegated the task, freely giving away low-accountability work and hanging onto anything they'd personally answer for. Their practical advice: write down who signs off by task type, aim the tools at low-identity work first, and don't trust self-reported adoption numbers, because the people who said they used AI most were often not the ones the logs showed using it most.

Google Cloud has a series on Elevating Antigravity agent skills, Part 3: Parallel subagents, covering parallel subagents. The piece was partly blocked when it was fetched, but the gist Seroter highlights is solid advice, including some anti-patterns to watch for when you fan work out to multiple subagents running in parallel.

And finally, Spotify published a candid look at AI Changed How Spotify Builds. What We Learned (and Fixed) About Quality at Higher Velocity. Their scale is staggering: seven hundred seventy seven million monthly users, a hundred million concurrent clients, and eleven to twelve million backend requests per second. The surprising headline is that AI slop was not their problem. They found no material evidence that AI-authored code directly caused their incidents. What they did find is that the volume of change outpaced their verification controls. Merged changes more than doubled year over year, and their code quality work actually rose from twenty seven percent to thirty one percent of the mix. The new constraint isn't producing change, it's verifying it. Their lesson is that keeping review, testing, rollback, and observability operating at the same pace as development is now a continuous effort.

So there's a through-line across today's list. PostHog says engineers are becoming loop-builders, RedMonk says agents are the new kingmakers, and Spotify shows what it actually costs to verify all that new velocity. The common thread is that the hard part was never writing the code; it's deciding what should exist, knowing what's safe to touch, and proving what you built actually works. Those jobs aren't going anywhere. That's it for episode eight sixty nine. Thanks for listening, and we'll catch you on the next one.

Your signing session ended