Seroter's Daily Reading — #823 (July 13, 2026)
Follow into
Save into
Source: Seroter's Original Post
Seroter's Daily Reading, Episode 823. July 13, 2026.
I'm getting ready for tomorrow's big Google I/O Connect event here in India. We spent today doing rehearsals, meeting with startup founders, and community people. And, reading the handful of items you'll find below.
First up is a piece from the PostHog newsletter titled "Stop being the code review bottleneck". The core insight here is elegant: agents write code faster than any human can review, so the solution isn't to review faster—it's to review less. The argument is that if you need to be involved in every code review, you will always be the bottleneck. Instead, build a pipeline that delegates reviews to other agents.
PostHog engineers have come up with four workflow patterns worth stealing. First, make agents review code for you. The key constraint is that the agent that wrote the code cannot be the one that reviews it, because agents are notoriously bad at catching their own blind spots. Better to run multiple reviewer agents with different instructions and even different models, then have a triage layer sort findings into actionable issues, nitpicks, and ambiguous cases that need human judgment. One engineer reported spending about sixty percent of his token budget automating review and CI toil, with no regrets.
Second, delegate PR babysitting to loops. Monitoring CI, re-running flaky tests, keeping branches up to date—these tasks don't need human attention and are perfect for automation. Third, add a PR auto-stamper for low-risk, small changes. PostHog built one called StampHog that automatically approves simple PRs under five hundred lines with no merge conflicts, while routing anything sensitive to subject matter experts. It handled sixteen hundred PRs in a month, eliminating that many Slack interruptions. Fourth, verify by observation rather than reasoning. Agents are good at explaining why their code works, and those explanations are often convincing but wrong. The recommendation is to decompose large changes into small stacked PRs, each independently runnable and observable, then verify behavior by watching it work rather than trusting the agent's rationale.
The second piece is from The New Stack, titled "85% say code review is the new bottleneck. Here's what the AI coding narrative leaves out". This one frames code review as a contract. The moment a change lands on main, every other team starts building on the assumption that it works. Most organizations have never defined what that contract actually guarantees.
The article lays out four layers of confidence: well-formed code that compiles and passes static analysis, internally correct code with passing unit tests, compatible code that honors API contracts, and code that behaves correctly against the real system with real data and real failure modes. The fourth layer is the expensive one—it needs somewhere real to run—and historically, this was too costly to execute before merge. So the industry made a quiet compromise: validate the first three layers before merge, then discover system behavior afterward in shared environments. That compromise worked at human pace, but now coding agents are multiplying PR volume by orders of magnitude.
The result is a pipeline that systematically passes changes whose most dangerous failure modes were never examined. AI-authored changes carry roughly one point seven times as many issues as human-written ones, with logic and correctness errors overrepresented. The infrastructure constraint that justified the old compromise is gone now. Platforms like Signadot enable ephemeral environments where each PR gets its own production-like system to run against, ready in seconds, with isolation achieved through routed traffic rather than duplicating the entire stack. The argument is that teams adapting fastest to agent-assisted development aren't the ones generating the most code—they're the ones who moved system validation to the left side of the merge, so velocity arrives as shipped features instead of a longer queue of unvalidated changes.
The third piece is a blog post titled "Why write code in 2026" by Software Doug. This one makes the case that even with increasingly capable AI coding agents, humans still benefit from writing code themselves. The argument isn't that agents are worse at coding than humans—it's about thinking directly in the execution environment rather than proxying everything through English.
Doug describes writing code as a tool for attention and understanding. When you're just reading and approving code written by agents, you become a passive observer, and slop tends to fly under the radar. But when a human does some work, spikes an approach, and then the agent stamps out the patterns, you participate and own the result. The post makes the point that English is an under-specified language—not a precise way to express computation. For truly algorithmic work, you want to think in executable steps.
He gives a personal example from a codebase where he mentioned using browser local storage one morning before coffee, and that one-off decision got wrapped in so much indirection that the code tripled in size. Agents can amplify our one-off bad decisions by being extremely conservative around them. Going through and joyfully deleting code helped him arrive at a better architecture than just trying to proxy the problem through English. His thinking, authorship, and ability to guide the factory were massively amplified by caring about the code. The takeaway is that any assembly line needs people who occasionally take it apart, dig into the details, and understand the whole picture. Writing code keeps you connected to those details.
The fourth piece is from XDA Developers: "I let Google Antigravity 2.0 write a microservice from scratch while I ate lunch, and I'm mildly terrified". The title tells you a lot about the tone here. This is a first-hand account of letting Google's latest autonomous coding agent loose on building an entire microservice from scratch, and the author's reaction is somewhere between impressed and unsettled.
What makes this interesting is that the agent didn't just produce code—it demonstrated decent product thinking and UX sense. The experience of not having to babysit a looping agent is described as weird. When you notice that the AI is making reasonable architectural decisions and showing something like judgment about user experience, it changes the dynamic in ways that feel strange. It's one thing to have an agent generate boilerplate or refactor code. It's another to watch one reason through a problem space and come out with something that feels thoughtful.
Across these four pieces, there's a common thread: the relationship between human judgment and AI capability is evolving rapidly. The PostHog article and the New Stack piece both tackle the review bottleneck from different angles—one focused on workflow automation, the other on infrastructure. The Doug piece reminds us that staying engaged with the code matters, even as delegation becomes easier. And the XDA piece captures that moment of mild terror when the agent starts showing something that looks like judgment. The through-line is that the question isn't whether to use these tools, but how to stay meaningfully involved in the software you're building.