Seroter's Daily Reading — #843 (August 11, 2026) · Seroter's Daily Reading

Listen: https://blossom.buildtall.systems/57dc1997e4e87257dc844c7d474107b3eb5d28de2d601304bc375fbb0ba5d0f1.mpga

Episode 843 — August 11, 2026

Here's your Daily Reading for today.

Leading off, a big substantive piece from Andreessen Horowitz on the state of computer-using agents — the question being, can these things actually sit at a desk and do the work? The short answer is yes, in the right conditions, and it's moving faster than people expected. The piece traces how the benchmark numbers have jumped dramatically over the past year — best models now scoring around 85% on tasks where humans average around 72%. That's a real inflection point. But the more interesting insight is what the benchmark number doesn't tell you. The data shows that production deployments are real and growing, but they're concentrated in standardized, repeatable back-office workflows: updating CRMs, processing IT tickets, logging into government portals, pulling data from retailer sites. One operator the piece profiles runs fifteen to twenty million automated portal interactions per month, using agents as a self-healing fallback when a retailer changes their UI overnight — and they've cut the engineering team dedicated to scraper maintenance in half. The key insight running through the whole piece is that the model itself is increasingly commoditized. The operators running millions of tasks couldn't tell you which model they were using — their vendor swaps it underneath them like a cloud provider swaps hardware. The durable advantage is everything around the model: the runbook, the caching strategy, the escalation logic, the permission structure, the knowledge of how one specific company actually gets work done. That context lives in process documentation and recorded videos of people doing the job and access credentials and test cases — none of it general, all of it specific to a company and often a team. Which means the moat is not the frontier model capability, it's being the vendor an enterprise is allowed and able to use at scale in production. And on the economics, the numbers are interesting. A computer-using agent runs roughly six to eight dollars an hour at full inference cost, with a real-world range of three to fifteen depending on how the harness is built. That's roughly break-even against offshore BPO at around ten dollars an hour fully loaded, and it's a significant discount against US back-office labor at thirty to forty-five dollars. And the cost curve is going in one direction.

Next, a piece from Silicon Valley Product Group on what the product role actually means, and it draws on something unexpected — an analysis from Benedict Evans arguing that just because everyone can now build things with AI doesn't mean everyone will build the right things. Evans makes a useful distinction between people who are good at recognizing pain and people who are good at seeing the general problem behind that pain — that's the first skill. The second is the ability to discover an effective solution, not just to recognize that a problem exists. And the third is understanding enough about the broader business — the sales org, legal, compliance, finance — to find a solution that actually works inside a specific company, not just for a specific customer. The author maps these to familiar product concepts: problem discovery, value risk, and viability risk. The core argument is that these are the skills your product team depends on you for, and they're harder to automate than the tooling. It's a useful reminder that product thinking is a craft that develops over time, not something that gets fully subsumed by a better prompt.

Over on the Google Developers blog, a piece that makes a strong case for Go as the ideal language for AI-assisted software engineering. The argument hinges on a shift in what matters most — historically developers measured languages by how easy they are to write, but when an AI can generate hundreds of lines per second, the bottleneck flips to reviewing and maintaining what was written. Go was designed from day one around software engineering rather than programming — around team collaboration, long-term maintainability, and opinionated simplicity. That shows up in a few specific ways. First, Go ships with a built-in formatter, test framework, dependency management, and security tooling all in the standard toolchain, so AI and humans have the same consistent foundation. Second, Go prioritizes readability over writability — the language is designed so that code written by a senior engineer, a junior developer, and an LLM all look roughly the same, which makes AI-generated code much easier for a human reviewer to verify. Third, the static type system means the compiler catches hallucinated properties and type errors immediately rather than letting them slip to runtime, and the compilation speed is fast enough that an AI agent can iterate through its own corrections efficiently. And then there's the compatibility promise — Go code written today will compile and run on the latest toolchain without change, forever, which is a huge advantage when an AI is generating thousands of changes per day and the codebase needs to remain coherent over years. The piece is a thorough case, and a lot of it comes down to the idea that when AI is on the team, the language features that support human collaboration become the ones that matter most.

Google also announced the expansion of their subsea cable network in the Americas — three new cables called Alisios, Canoa, and OlaLuz, connecting Chile, Panama, the Dominican Republic, and Bermuda. The quotes in the announcement are worth reading — government leaders framing this as a bridge for their countries into the global digital economy, a way to cultivate local tech talent and drive economic opportunity. The cables include branching units that allow future expansion, following the same approach Google has used in the Pacific with their Connect initiative. It's infrastructure work that doesn't get a lot of attention in the developer press, but the connectivity picture matters for how quickly regions can participate in the digital economy.

From Tom Johnson at I'd Rather Be Writing, a dispatch from the Ai4 conference in Las Vegas — twelve thousand attendees, four hundred exhibitors, seven hundred sessions. Johnson's focus was on what was absent rather than what was present, and a few things stood out. First, agents were everywhere as a theme, but the Skills specification — the open standard for giving general-purpose agents domain-specific capabilities — was essentially absent from the conversation. His take is that this is because the Skills model doesn't fit the vendor playbook. You don't need to hire an enterprise agent vendor if you can write a Skill file and connect it to a general-purpose model that already has access to your codebase and tools. The vendors at a trade show are selling proprietary platforms with lock-in, and an open, transportable specification doesn't create a sales motion the same way. Second, Johnson noted that among four hundred exhibitors, not a single one had a solution for automated technical documentation. He asked a vendor about it and got a blank stare. His interpretation is honest — either documentation isn't a problem that automated solutions can solve well, or the audience at a conference like this just isn't technical writers, so there's no commercial incentive to pitch them. He also pushes back on the idea that conferences are actually places where you learn things. Learning, he argues, requires practice, experimentation, feedback, and time between sessions to try things out — not three days of firehose. Conferences are good for big ideas and team morale, not for walking away with practical strategies.

From Addy Osmani on Substack, a piece on agentic code quality that argues quality in an AI-driven development world has to live in the constraints you set around your agents, not in human code review alone. The premise is straightforward: agents can generate enormous volumes of code, and no human team can read it all. The way you maintain quality is through quality gates — tests, mutation testing, complexity metrics, type checking, security scanning — that sit around the agent's proposals and decide whether something is safe and correct enough to ship. An agent can propose anything; your constraints decide whether that proposal crosses the production boundary. The piece distinguishes between constraints that shape work before it begins, constraints that give feedback while the agent is running, and constraints that gate whether output goes to production. The interesting tension is around autonomy and trust — agents can fail in ambiguous situations or when the environment changes unexpectedly, and the harness has to be designed to handle those cases gracefully. Johnson — sorry, Osmani — also argues that human attention is the scarce resource now, so it should be directed to the nuanced problems that require judgment, and automated guardrails should handle everything else. The broader point is that software quality isn't a single metric — it's a collection of signals, correctness and maintainability and security and performance, and each signal needs its own constraint in its own place in the pipeline, not a single review at the end.

On a lighter note, a piece from Laurentiu Gabriel on how they use LLMs to learn complex topics, and the approach is genuinely creative. Rather than just asking a model to explain something, they run a three-step loop: ask a model in plan mode to build foundational knowledge on a topic, then ask it to review the accuracy of that knowledge base, then ask it to build a low-poly, Rollercoaster Tycoon-style simulation of the topic. The result is an interactive animation that's accurate and free of hallucinations because the model built it from its own verified knowledge base. They've done this for chip manufacturing, rocket engines, F1 engines, EUV lithography machines, and how LLMs work. Gabriel has also published a Skill file for creating these kinds of learning animations. It's a good example of using AI not just to retrieve information but to build intuition through interactive simulation — a genuinely different approach to the problem of learning something deeply.

Google announced an expansion to their AI Professional Certificate on Coursera, adding a new vibe coding course to the curriculum. The vibe coding angle is interesting — it's about describing what you want in plain language and letting AI handle the implementation details. The certificate has apparently become the most popular generative AI certificate on Coursera since launching earlier this year, with millions of learners and enterprise adoption from companies like Deloitte, Verizon, Lyft, and Walmart. The piece features a profile of a former Walmart truck driver in Arkansas who used the certificate to build four internal applications, including one called Get My Driver Home that condensed daily reporting meetings down to fifteen-minute huddles. The framing is accessible and practical — no coding experience required, and the course teaches you to plan, test, debug, and deploy real applications.

Finally, a sharp piece from PostHog's Cleo Lant on whether agents are really killing the UI. The premise is familiar: you hear that agents are the new users, software is losing its head, the API is all that matters, and everyone who learned Figma should learn Bash. Lant's counter-argument is that this is mostly a Silicon Valley perspective, and it's wrong. The core observation is that if a human can do something in your product, an agent should be able to do it too — but that doesn't mean the UI goes away. It means you need to design for two entry points: one that an agent can complete end-to-end without a human in the loop, and one for the human who lands in the middle of a process that the agent set up and needs to understand what's been done and what comes next. The piece walks through PostHog's own examples — their npx wizard that sets up an account and scans a codebase, their Slack app that turns a message into a draft pull request, their MCP server that lets an agent create feature flags and launch experiments. What's interesting is that even their headless users — people using the MCP to interact programmatically — still end up looking at the web app to see their data and click around. A terminal is a UI. A chat window is a UI. Slack is a UI. The screens worth building now do different work: approval workflows where an agent has a change ready and needs a human yes, structured diffs instead of summaries, undo buttons next to anything an agent can do autonomously, and feeds that let you instantly tell which actions came from a colleague and which came from a bot. The piece closes with a useful reframe — agents might be the primary users of software by volume soon, but by meaning, there's no agent without the person who set it in motion. The future is hybrid, not headless.

No Nostr signer detected