Seroter's Daily Reading — #808 (June 18, 2026) — Seroter's Daily Reading

Listen: https://blossom.buildtall.systems/731f75114ee0bff909d2aff2f291ed7c5224d2fe613063127ea736b3202a4743.mpga

Seroter's Daily Reading, episode 808, June 18, 2026. It's a US holiday tomorrow, so I'll see you all back here on Monday.

Let's start with a piece that cuts right to the heart of where software development is headed. It's titled "The Death and Rebirth of Programming", and it makes a simple but arresting argument: code is becoming cheap, but understanding code is not. The marginal cost of producing software is collapsing toward zero thanks to generative AI. A single developer can now generate thousands of lines in minutes. What hasn't collapsed is the cost of knowing what that code does, verifying it, securing it, evolving it. If anything, that's getting harder as volume explodes. The author reframes what we actually own as developers. In the old world, programmers owned code. In the new world, ownership becomes a liability. When code can be regenerated faster than it can be understood, preserving it for sentimental or historical reasons no longer makes sense. The asset is not the codebase. The asset is the system's ability to keep working. There's a psychological dimension here that the piece handles well. Many developers identify as builders and craftspeople. When a machine can produce a competent version of your solution in seconds, craftsmanship no longer lives in the artifact. It lives in framing the problem, defining success, deciding what to keep and discard. The role shifts from maker to architect, from author to managing editor. And that's uncomfortable. The piece also points to the n=1 developer as an indicator species: projects that once required teams now fit inside one person's cognitive boundary, with AI filling execution gaps. But this only works if systems are designed for it. Large, tangled, historically accreted codebases collapse under their own weight when AI accelerates change. Small, modular, disposable systems thrive. It's a thought-provoking read and a useful reframe for what we mean when we talk about software quality.

From reframing programming, let's stay on the AI theme but shift to the organizational level. A new piece from the Engineering Leadership newsletter covers what the top 1% of engineering teams do differently with AI. The data comes from Weave, a platform that measures engineering output based on a question: how long would this PR take an expert engineer to complete? Using that as a standard unit, the difference between the top 1% and the median is exponential, not linear. So what are those top teams doing? First, organizational structure. Many of the best teams are going flatter, running smaller teams, and expecting engineers to own projects end to end. Telnyx runs 200 engineers with zero engineering managers and one VP of Engineering. PostHog keeps teams to a maximum of three people, each with a team lead who reports directly to the VP. Second, spending. The top teams spend more on AI tokens than lower-performing teams, but here's the twist: they're actually getting more value per dollar. Robinhood built a custom agent fine-tuned to their codebase, which keeps costs smaller while increasing accuracy. Spott runs five agents per engineer simultaneously and has significantly higher output per dollar than average. Third, code review. The top 1% teams have far fewer human PR reviews in percentage terms than average teams. But they're using AI code reviews and optimizing those for accuracy. And critically, they're reviewing specs before code is generated, not reviewing code after. As one quoted insight puts it: it's much easier to review 300 lines of markdown than 3000 lines of code. Fourth, bug rates. You'd expect more code to mean more bugs, but the data shows bug rates stay similar even as output climbs. Teams are using AI to test continuously. One example: a company called AndAI has five laptops running AI agents 24/7 doing QA. Finally, deployment frequency. The top teams deploy more, which isn't surprising, but the insight is that batching 10 PRs into one deployment isn't more efficient than deploying each one separately. The goal is consistent, frequent small releases, not big batches. Good data, useful frameworks.

Now if the top 1% are crushing it with AI, why do so many teams feel like the tools aren't delivering? A piece from Blog for Engineering Managers titled "The Reason AI Coding Isn't Working on Your Team" makes the case that the problem isn't the model. It's the harness. The author uses a concrete example: two engineers tried the same AI coding tool in the same month. One spent a weekend setting it up properly, with a context file at the repo root, notes per service, a scoped test command. She one-shotted her feature. The other installed it, pointed it at a million-line monorepo, and asked it to fix the auth bug. Garbage results. Same model, completely different outcomes. The setup is the variable. Martin Fowler's team at Thoughtworks calls this harness engineering: the scaffolding around a coding agent, the context files, the tooling, the way it searches and tests, shapes output as much as the model itself. There's data backing this up from both directions. A METR study found experienced developers were about 19% slower using AI on their own mature codebases while believing they were 20% faster. The DORA 2025 report found AI amplifies whatever your team already is. It speeds up a healthy system and speeds up a broken one. In both cases the model wasn't the deciding factor. The setup was. The piece argues this is a management responsibility, not a platform team problem. Addy Osmani at Google wrote that AI coding at scale stops being a prompting problem and becomes a management problem. The skills that make someone a good tech lead, setting context, defining work clearly, reviewing output, knowing when to step in, are exactly the skills that make AI coding work. And there are real stakes here. When writing code gets cheap, reviewing it doesn't. After AI adoption, PR volume nearly doubles and review time climbs by 91%. AI is also very good at the small, well-defined tickets that used to be how junior engineers learned the system, which raises real questions about mentorship and growth. And trust is eroding: 84% of developers use AI tools but only 29% trust their accuracy. The teams that skip the harness get the worst of both worlds: more code than before, less understanding, seniors drowning, juniors with nothing to grow on. The teams that own the harness get the opposite.

Let's shift gears. "The Architecture of Focus" is a piece on designing your environment for deep work, and it's a useful counterweight to all that AI velocity talk. The core argument is that your calendar is a design document, but most companies run on a schedule built for managers, not makers. The research backs this up hard. Gloria Mark's UCI study found the average knowledge worker spends only 47 seconds on a screen before switching, and it takes over 25 minutes to fully return to the original task after an interruption. Flow research shows entering deep focus requires 15 to 20 minutes of uninterrupted attention. The math is brutal: a full workday of hour-long fragments produces approximately zero minutes of deep work. The piece traces a pattern across centuries. Benjamin Franklin built a system of daily virtues tracked in a ledger. Beethoven structured his mornings for uninterrupted composition. Cal Newport codified it as deep work. Y Combinator runs on a maker schedule: minimal events, a hard Demo Day deadline, a single repeated question each week. Michael Seibel from YC describes solving his Twitter problem not with willpower but by unfollowing everyone, disabling most features, removing the app, turning off notifications. His framing is honest: willpower is not enough, this is an addictive thing, I need an intervention. The strategic point the piece makes well is mathematical. A non-hedging team of equal competence always beats a team that splits its focus. Attention is finite. Every meeting that interrupts a maker is a tax on output. Most companies measure maker productivity in tickets closed or lines of code, but they don't measure the cognitive cost of the context switches those tickets require. The full cost surface is never visible to any single decision-maker.

Quick hits to close out. A new CNCF and SlashData report confirms India as one of the largest cloud native communities in the world, with an estimated 2.25 million cloud native developers as of Q1 2026, about 11% of the global total. Notable stats: 44% of Indian developers use hybrid cloud, exceeding the global average of 34%. And about half of professional AI developers in India are cloud native, highlighting the role of cloud native infrastructure in supporting AI workloads. A younger developer demographic too: 70% of India's cloud native developers are under 35, compared to 39% globally. The India tech community continues to be excellent.

Google's Developer Blog has a piece on combining A2UI and MCP Apps for richer interfaces in agent workflows. A2UI, the Agent-to-User Interface protocol, uses a declarative JSON approach where the host application handles rendering through its own native components. MCP Apps offer creative freedom using iframes but can lead to fragmented user experiences. The piece lays out three integration patterns. Serving A2UI over MCP servers lets developers add natively rendered UIs while leveraging MCP's existing tool connectivity. Running MCP Apps inside A2UI components lets the host wrap a sandboxed iframe for state-intensive modules while keeping the outer design system intact and synchronizing state through an event loop. And running A2UI inside MCP Apps lets developers inject dynamic AI-driven interfaces into legacy applications that don't natively support A2UI. The MCP App bundles its own A2UI renderer and talks to the server through the same MCP mechanics. It's a technical piece but a useful overview if you're building agent-facing interfaces.

A piece from The Growth EQ titled "The Key to Confidence" makes a point that's straightforward but worth sitting with. Confidence comes from evidence, not affirmations. Jalen Brunson after the Knicks championship said his confidence comes from his work ethic. Maya Angelou explained her commanding stage presence by listing decades of study and rehearsal. Sebastian Sawe's coach said confidence based on evidence guided his marathon world record preparation. The inverse is also true. If you're afraid to fail, you play it safe, stay on the sidelines, and face overwhelming doubt. The key is amassing evidence, which requires putting yourself in positions where you might fail. Every area of life where the author has genuine confidence followed a ton of work and a ton of failure. There's no shortcut, no secret, no law of attraction. There's only reps.

Finally, The New Stack has a piece on Cursor, GitLab, and Zed building alternatives to GitHub as AI agents overwhelm the platform. GitHub is now processing about 1.4 billion commits per month, up from 1 billion across all of 2025, with AI agents alone generating more than 17 million pull requests per month. The irony is GitHub helped kickstart the AI coding era with Copilot in 2021 and is now buckling under the weight of it. Cursor announced Origin, a Git-compatible code hosting platform designed from the ground up for AI agents. GitLab announced Project Switch, a redesigned backend that lets agents query repositories server-side rather than cloning in full, delivering up to 50 times faster task execution with up to 3 times fewer tokens consumed. Anthropic is a design partner. Zed announced DeltaDB, which replaces Git's commit model entirely with a continuous stream of fine-grained deltas, linked directly to the conversation that produced them. Brian Douglas, GitHub's former director of developer advocacy, says agents are killing the will for doing open source and suspects GitHub's monthly active user numbers have declined as more developers do review and PR work directly in AI coding tools. Mitchell Hashimoto put it bluntly: AI companies are on track to become GitHub faster than GitHub is becoming an AI company. The piece is worth reading in full. The build versus buy question for AI infrastructure is getting increasingly sharp, and the companies that figure out the model plus tooling stack are the ones positioned to own the next era.

That's episode 808. Short one this week. Back on Monday.