Seroter's Daily Reading — #866 (September 14, 2026) · Seroter's Daily Reading

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

Daily Reading for Monday, September 14th, 2026. This is episode 866. Seroter is in New York City today, judging a hackathon run by Major League Baseball, and he managed to walk seven miles around the city in between. A great start to the week, and a good reminder that AI is helping all sorts of people build all sorts of things.

Let's get into the articles, and this is a packed one, so I'll move briskly.

First up, a blog post called The Feature Flag Graveyard, on how a safety net becomes technical debt. The piece opens with a familiar story: you wrap a new endpoint in a feature flag, roll it out to five percent of users, and feel like a deity. Fast forward twelve months and your codebase has two hundred and fourteen flags, nobody remembers who created half of them, and turning one off breaks authentication in staging. The author's point is sharp: you haven't built a resilient delivery system, you've built a dynamic, non-deterministic branching maze. The real kicker is the math. Ten active flags isn't one code path to test, it's a thousand potential system states running in production at once. And there's the Knight Capital story, the trading firm that lost four hundred and forty million dollars in forty-five minutes because a repurposed feature flag turned on dead code. The core rule here is memorable: a feature flag is an unpaid loan, financial debt with compounding interest. If you don't budget time to remove the flag, you haven't finished building the feature. The fixes are practical, too: classify flags by lifetime, make them expire in CI/CD, pair every new flag with a cleanup ticket, and treat flag removal as an ongoing habit rather than a quarterly hackathon. Give your flags an expiration date.

Next, a piece from O'Reilly Radar called The Interfaces Are Arriving. This one argues that the most consequential AI news of the past year came from a standards body, not a model release. Anthropic donated the Model Context Protocol to the newly formed Agentic AI Foundation under the Linux Foundation, and Google handed over Agent2Agent to the same family. Companies that compete fiercely on models are now cooperating on the interfaces between them. The author's framing is that standards change the economics of integration work. Networking became an ecosystem when machines agreed on interfaces, and programming tools followed the same path with the Language Server Protocol. MCP standardizes how an AI application connects to tools and context, while A2A covers agents discovering and talking to each other across vendors. There's real adoption here: over ninety-seven million monthly SDK downloads for MCP, more than a hundred and fifty organizations behind A2A. The practical upshot is reuse: one MCP server for an internal ticketing system can serve every compatible IDE, chat app, and agent. But the article is refreshingly honest about the limits, too. A schema captures the shape of a tool's arguments, but its meaning still lives in a free-form description a model has to interpret. And a signature ties a statement to an identity, but it doesn't tell you which identities deserve authority. The recommendation: treat these integrations like libraries, with owners, versions, and tests, and pin versions because the specs are still moving. Specs like MCP and A2A have staying power, and teams need a plan for working with them.

Now, one of my favorites of the week, Confessions of an Unrepentant Slop Snob from Charity Majors. This is a wonderfully candid post. She describes watching her company split in half: one side furious at receiving twenty-page docs full of AI padding, the other side furious that anyone would question their faster workflows. The most telling detail is how often the word dehumanizing came up, people no longer feeling a human connection with their coworkers. Her argument resolves the tension with a single distinction: every job language does for us is either functional or relational. When you're collaborating on a document or a diff, the idea is what matters, and AI is just another tool, so be ruthlessly outcome-oriented. But when the value of the writing comes from the fact that a particular person thought it or felt it, AI-generated text registers as a violation. She uses performance reviews as the sharp example: if your manager's review of you was obviously written by a chatbot, the trust between you is damaged. Her honest confession is that she developed a genuine rage reflex for AI slop, unfollowing writers and refusing to give her scarce attention to people who couldn't be bothered to write their own hello. The takeaway is that relationship maintenance cannot be automated, and the slick, sycophantic, uncanny quality of AI prose is somehow more alienating than messages that are plainly automated. For functional output, fire away. For personal communication, write it yourself.

Fourth, an InfoWorld piece on why DBAs are right to be skeptical of AI — and where they're wrong. The gist is that we'll never fully engineer away mistakes as long as a person is in the loop, and honestly, we want a person in the loop making the real decisions. The author's case for AI is that it follows a process more consistently than a person under pressure tends to. It's easier for a human to say forget it, I know a shortcut, than it is for a well-constrained model to deviate from its instructions. Add structured skills to the mix, and use agents to address a shortage that isn't going away.

Fifth, a big one from Marty Cagan over at SVPG, called Strong Opinions, Loosely Held. This is the narrative version of a keynote, and it's built around a question he couldn't shake: in light of all that has changed, what did you used to argue was true that you no longer believe? He draws the line at the first edition of Inspired in 2008 and lays out ten things he got wrong. A few stand out. He completely understated the importance of business viability, burying it under feasibility, largely because he'd spent his career building developer tools where you could get away with weak business skills. He didn't understand how strongly product people would be drawn to problem discovery and turn themselves into gatekeepers, leaving too little time for solution discovery. He emphasized the wrong why, the reason we're working on a problem, when the more important question is why people are using or not using our product. And he regrets telling people to be the CEO of the product, a message that wasn't exactly humility. He also admits he tried to ignore politics, which was naive, and that he didn't appreciate how deeply people crave predictability and how that's at odds with outcomes. It's a refreshingly honest audit, and a useful exercise for any of us to perform. What have you learned in the past years that upends an opinion you once held?

Now the big story everyone was talking about over the weekend: Anthropic CEO Dario Amodei outlined a plan to slow AI development. In a blog post, Amodei called for pacing the frontier and laid out three broad strategies, and he said Anthropic is unilaterally committing to one of them. Sam Altman chimed in to say OpenAI would follow, and Elon Musk posted that Dario is right. The trigger here is a wave of dire warnings, including a researcher who resigned from Anthropic warning that leading AI companies are gambling with our lives. Amodei's first concrete step is embedded evaluators, third-party folks like METR who get badges, desks, and laptops, and enough access to verify that companies are actually following their safety commitments. He also called for coordination among labs in democratic countries on safety standards and limits on the pace of progress, and acknowledged the China question, arguing that chip controls and cracking down on distillation could widen America's lead. Seroter's take is worth noting: it's fine if labs want to govern themselves, but he doesn't see why governments need to do it for them. There's genuine skepticism from critics too, who argue this looks like regulatory capture in action.

That connects directly to the next piece, P(doom), from Armin Ronacher. Armin doesn't buy the doomer hype. He read Amodei's post, appreciated it, and still found himself in strong opposition. His central observation is that there's a weird idea floating around that there's something to be paced at all, when really there are only two companies in this game right now, Anthropic and OpenAI, and they come from the same origin. He argues that open weight models are the true form of automatic pacing, a kind of mutually assured destruction, and notes that the models actually causing issues today are all closed-weight American models. He's blunt that this is a total regulatory failure: Europe's AI regulation is two years old and misses the problems we actually have, while the US is turbo capitalism paired with sinophobia. His own worry isn't a nuke or an extinction event, it's what this does to us as humans, and the new tax companies are paying to model providers. It's a valuable counterweight to the doom conversation.

Eighth, a Medium post on GitOps for AI Agents on Google Cloud, covering ArgoCD, Config Sync, and GKE. The article itself was blocked when it was fetched, but the idea is straightforward and Seroter notes he hasn't seen much on GitOps for agents. It makes sense, especially when you're dealing with fleets of them, treating your agents' configuration the way you'd treat any other infrastructure as code.

Ninth, a Latent Space piece from Vinoo Ganesh on the rise of the forward deployed engineer, and how to do the job right. Vinoo has built the function three times, at Palantir, Citadel, and now Kepler, and he makes a compelling case that today's FDEs are doing fundamentally different jobs that happen to share a name. At an a16z fellowship dinner he found sales engineers, quota-carrying reps who can write Python, and consultants with statements of work, all calling themselves forward deployed. His definition is sharper: the FDE is an extension of the product team, solving customer problems in order to earn the insight that informs what gets built next. He puts it memorably: an FDE's job is to collect nouns and verbs, the operating model that lives in people's heads and not in any textbook. And the output has to be a product, not one happy customer. An FDE engagement that ends with one delighted account and nothing changed upstream has failed at the only thing the role exists for. If you're just selling hours, you're consulting, not building an asset.

And finally, a quick one from Google: DevFest is back. From October first through December thirty-first, it's the world's largest community-led technology conference, with more than eight hundred events across a hundred and fifteen countries. This year's theme is Build, Secure, Scale, focused on the agentic era, with hands-on codelabs and workshops across Gemini, AI Studio, Antigravity, Firebase, and more. If you want to sharpen your skills, there's probably one near you.

A couple of threads to leave you with. There's a real tension running through this episode between building faster with AI and keeping the human in the loop, whether that's feature flags rotting into debt, or AI slop eroding trust, or the debate over pacing the frontier itself. And there's a quieter throughline about discipline: giving your flags an expiration date, treating your agent integrations like owned infrastructure, and auditing your own long-held opinions. Thanks for listening, and we'll see you tomorrow.

Your signing session ended