Seroter's Daily Reading — #822 (July 10, 2026)
Follow into
Save into
Source: Seroter's Original Post
Episode 822 — July 10, 2026
This is Seroter's Daily Reading for July 10th, 2026. Richard got in from a long trip and had a smooth travel day — flights on time, decent wifi, got some sleep, and made it from plane to hotel in under an hour. That's a personal record worth celebrating.
Let's get into the articles. There's a good mix this time: coding agents, infrastructure evolution, and some hiring data that puts a number on how much the job market has shifted toward AI.
Starting with a piece from Markus Eisele on O'Reilly, republished as part of their Main Thread newsletter. The title is Why AI Coding Agents Still Need Clear Specs, and the argument is essentially that the accounting matters more than ever. The mental model spreading through dev communities right now is that agents are smart enough to figure things out, so you don't need heavy upfront specification anymore. Just describe your goal loosely, let the agent explore, and correct as you go. The article argues this is wrong — not because agents aren't capable, but because you're not eliminating cost. You're just deferring it and making it harder to see.
The piece lays out two poles. At one extreme, minimal spec: you describe intent loosely, agents interpret freely, work starts immediately. Upfront human effort is near zero. What accumulates downstream is correction loops, review cycles where a human acts as the oracle for every output, and rework when the agent was solving the wrong problem. At the other extreme, full formal specification: TDD, BDD, Gherkin scenarios, acceptance criteria locked down before any code runs. Upfront human effort is real and visible. But downstream verification looks fundamentally different because the tests are the oracle. Pass or fail. No human fatigue.
The key insight is that what you're actually trading off is when you pay and in what currency. Minimal spec front-loads token cost and back-loads human judgment. Heavy spec front-loads human effort and back-loads almost nothing, because automated verification doesn't scale with runs. The total cost of both approaches traces a U-shaped curve when you plot it against specification completeness, and the sweet spot sits somewhere around well-structured acceptance criteria or BDD scenarios. Not at zero, and not at a forty-page formal requirements document.
There's a point in the piece that I found particularly sharp: the old problem in software engineering was always specification. Not typing. Not syntax. The hard part was agreeing what should exist, what should never happen, which trade-offs matter. Agents don't remove that problem. They make it more visible. In the old world, vague requirements ran into human slowness. In the agent world, vague requirements run into machine speed. Code gets cheap, and the bottleneck shifts into specification and verification.
The piece also notes that spec validation itself is a distinct cost category that tends to get ignored. A spec can be internally inconsistent, incomplete, technically correct but untestable, or precisely what you wrote but not what you meant. An agent executing faithfully against a flawed spec produces something that's difficult to debug — it passed every check it was given, but the problem was upstream. The correction loop has to unwind not just code but reasoning.
What's interesting is that the article doesn't just argue for more human-written specs. It proposes using agents to write and validate the spec before implementation agents run against it. A spec-drafting agent produces a first version from rough intent, a spec-validation agent stress-tests it for consistency and completeness, and a test-writing agent translates surviving claims into executable checks. You review the result, which is faster than writing from scratch. The critical detail is that the spec-writing agent shouldn't just produce polished fog. It should name assumptions, separate goals from nongoals, produce examples and counterexamples, and identify which requirements are mechanically testable versus which ones still depend on human judgment.
The practical takeaway is that the optimal investment point is task-dependent. For a single agent on a small, well-bounded task, structured intent — a goal, examples, nongoals, a few acceptance criteria — is usually enough. BDD may be overkill. Zero spec is still lazy accounting. For deterministic work like API integrations or CRUD services, the breakeven sits further right. More specification pays off faster because the domain is constrainable and the tests are automatable. For multi-agent systems, the sweet spot shifts right again because the handoff between agents becomes the product. Every agent boundary needs a contract: schema, invariants, validation checks, failure behavior.
Moving on. Google announced that AlphaEvolve is now generally available to everyone on Google Cloud. AlphaEvolve is an evolutionary algorithm system — essentially a framework where AI generates candidate solutions, evaluates them against a fitness function you provide, and iteratively evolves toward better results. It's been used internally at Google for things like optimizing TPU circuit layouts and improving Cloud Spanner's storage compaction. Now it's available as a managed service.
The announcement includes a long list of customer results that reads like a conference keynote highlight reel. BASF used it to build a digital twin of their global supply chain, improving planning and forecasting by over 80 percent. Coolblue optimized their e-commerce demand forecasting pipeline, getting over 5 percent improvement in forecast accuracy. FM Logistic improved warehouse routing by 10.4 percent on top of an already highly optimized baseline, saving over 15,000 kilometers in staff travel. JetBrains used it to accelerate IDE performance algorithms, with gains of 15 to 20 percent. Klarna doubled throughput on one of their largest ML training pipelines while improving model quality, all under the reproducibility constraints of regulated financial services. Over three weeks, the system explored nearly 6,000 candidate programs, discovering deep architectural rewrites that no engineer would have tried.
There are results from Infineon on chip design, Kinaxis on supply chain optimization, PacBio on genomics accuracy, Pebble on GPU serving performance with a 56 percent relative error reduction, Qbraid on quantum error-correcting codes, Schrödinger on molecular discovery with a 4x speedup, WPP on campaign prediction models with a 5 to 10 percent accuracy gain, and several others including Oak Ridge National Laboratory running it on a supercomputer for GPU kernel generation.
The two inputs you need to get started are a seed program — the initial algorithm written as code, with the optimizable segments designated — and an evaluator, which is a deterministic client-side script that compiles, tests, and scores the mutated candidates, returning scalar metrics for AlphaEvolve to maximize. It's an interesting model because your evaluator runs wherever you want, and you query the AlphaEvolve API to get candidate solutions, run them through your evaluator, and submit scores back. If you have well-defined performance metrics and a codebase to optimize, it's worth exploring.
Shifting gears to architecture. Derek Comartin published a piece on Code Opinion titled Multi-Tenancy Isn't About Databases. This is a good reminder that the question isn't shared database versus database per tenant — that's the wrong starting point. The better question is what you're actually trying to isolate. Data? Compute? Deployments? Schema changes? Performance? Different types of failures?
The piece walks through the spectrum. At the data level, you can have shared tables with a tenant ID, a shared database with separate schemas, pooled instances where subsets of tenants share infrastructure, or a database per tenant. At the compute level, you can have shared instances, pooled instances for groups of tenants, or completely dedicated compute. The trade-off is efficiency versus control. Shared infrastructure is simpler to maintain and more cost-effective, but isolation gives you more control at the cost of more complexity.
The key insight is that every shared resource creates coupling. Shared database means shared schema, shared migrations, and shared performance. Shared compute means shared failures and the noisy neighbor problem where one tenant floods the system and affects others. Rate limiting is one tool to address noisy neighbors, but it doesn't solve everything because the API might be fine while the database is still getting hammered.
The piece makes the point that tenants are not all the same. At the start, they might seem uniform, but over time you realize some have heavier workloads, larger data imports, or stricter compliance requirements. A common pattern is to start with shared everything, then pool small tenants together, large tenants together, and eventually move the biggest ones to dedicated infrastructure.
The real takeaway is that multi-tenant architecture is not a database pattern. It's about isolation at multiple levels, and you choose where to share and where to isolate based on the blast radius you're willing to accept, the noisy neighbor risks at each layer, and the specific requirements of different tenants.
There were a couple of articles this week where I couldn't pull the full content due to bot protection — one from Romin Irani on Google Cloud about the spectrum from chat to autonomous engineering —The Antigravity Loop— and one about the MCP 2026 draft spec —The Future is Stateless: MCP 2026 Draft Spec—. Seroter flagged both as worth reading if you can access them. I'll link them in the show notes.
On the topic of the collapsing stack, Battery Ventures published a piece titled From Dirt to Tokens: How AI is Collapsing the Walls Between Apps and Infrastructure. The thesis is that the cloud era taught us that infrastructure and applications could thrive as separate layers, and now AI is breaking that assumption. The companies winning in AI own the full stack, from chips to tokens.
Cursor is the example. Started as an AI autocomplete tool powered by OpenAI and Anthropic, evolved into a fully agentic IDE, started developing its own custom model, and with SpaceX's acquisition, it now adds compute for both training and inference. The argument is that Cursor's path is the reference architecture for winning agentic AI companies.
The piece discusses three shifts observed among AI application companies and AI infrastructure leaders. First, the full-stack AI thesis is now a real debate. The journey typically looks like this: start on frontier closed-source models from Anthropic or OpenAI to find product-market fit, then migrate to open-weight models like GLM or Kimi and run your own inference for cost and control. The migration is harder than it sounds because prompt engineering is deeply model-specific, so switching tends to break things in non-obvious ways. Teams that do this well build deep evals and benchmarks so they can measure whether quality holds when swapping models.
Second, inference engineering is becoming a new core muscle. As more companies adopt open-source models and run their own inference, the know-how to do it efficiently is becoming a platform team discipline. Training and inference are fundamentally different jobs requiring different hardware. We're already seeing this split — Google recently divided its newest TPU generation into two distinct designs, one tuned for training and one for inference.
Third, the tokenomics are getting serious. One company at the table is spending roughly a thousand dollars per engineer per month on coding agents and expects to triple that with more capable models. Across a two-hundred-engineer org, that's five to seven million dollars a year. This is pushing teams to build internal systems like LLM gateways that route requests to the most cost-effective model and cache aggressively to avoid paying twice for the same work. Coinbase is cited as an example — by defaulting engineers to cheaper open-weight models through an internal gateway and layering in smart routing and caching, they cut their AI bill nearly in half even as token usage kept climbing.
The piece concludes with the observation that the most valuable engineers going forward won't be the ones who only build applications or only optimize infrastructure. They'll be the ones fluent in both, who understand fine-tuning, distillation, and inference economics as readily as UX and workflow design. The model-performance team barely existed eighteen months ago; today it's one of the most sought-after functions in AI.
On the other side of the stack, Google announced LiteRT.js, a JavaScript binding of LiteRT for running AI directly inside the web browser. LiteRT is Google's on-device inference library, previously available for Android, iOS, and embedded systems. LiteRT.js brings it to the web through WebAssembly, enabling web developers to run ML models entirely client-side.
The performance numbers are impressive. For classical computer vision and audio processing, LiteRT.js outperforms other web runtimes by up to 3x on CPU and GPU inference. For demanding real-time applications like object tracking or audio transcription, leveraging GPU or NPU via WebGPU or WebNN delivers 5 to 60 times speedup compared to standard CPU execution. The benchmarks were run on a MacBook Pro with M4 Apple Silicon.
What's interesting about this is what it enables. Enhanced user privacy because data never leaves the device, zero server costs for inference, and ultra-low latency because there's no network round-trip. You can do object detection, depth estimation, image upscaling, and audio processing entirely in the browser. The architecture leverages XNNPACK for CPU acceleration, ML Drift for GPU acceleration via WebGPU, and the WebNN API for NPU support, which is still experimental in Chrome and Edge.
For web developers with existing TensorFlow Lite models, LiteRT.js offers a path to migrate from TensorFlow.js to a more performant runtime. There's also LiteRT-LM.js for language model support. If you're building anything with on-device AI in the browser, this is worth evaluating.
Wrapping up with some hiring data. A Dice report found that job postings for roles with AI in the title jumped 173 percent year over year in Q1 2026, while software development job postings dipped 22 percent in the same period. More striking: in just over two years, the share of tech job postings highlighting at least one AI skill went from 15 percent in January 2024 to 73 percent in May 2026. That's a massive shift in a short time.
Tech hiring growth is uneven across industries. Finance and banking tech postings jumped 47 percent year over year, compared to 23 percent overall. Unemployment for tech professions dropped below 3 percent for the first time, according to CompTIA's review of official labor data. The hiring manager quote from Robert Half captures it well: technology leaders don't simply need more people, they need people with the right expertise. Many organizations are under pressure to move faster on automation and modernization, but professionals with those skill sets can be difficult to find.
That's episode 822. Lots of threads connecting across the articles — the tension between deferring cost and paying upfront shows up in the spec discussion and in the infrastructure ownership debate. The skill shift toward AI is driving both hiring demand and the new engineering disciplines that Battery talked about, like inference engineering and model performance. See you next time.
- Why AI Coding Agents Still Need Clear Specs — Markus Eisele on O'Reilly
- Solve harder problems with AlphaEvolve — Google Cloud Blog
- Multi-Tenancy Isn't About Databases — Derek Comartin on Code Opinion
- The Antigravity Loop: From Chat to Autonomous Engineering — Romin Irani on Google Cloud
- Own the Outer Loop — Addy Osmani on Substack
- The Future is Stateless: MCP 2026 Draft Spec Arrives in MCP Toolbox — Google Cloud on Medium
- From Dirt to Tokens: How AI is Collapsing the Walls Between Apps and Infrastructure — Battery Ventures
- LiteRT.js, Google's high performance Web AI Inference — Google Developers Blog
- AI skills now listed in 73% of tech job postings — CIO Dive