Seroter's Daily Reading — #828 (July 20, 2026)
Follow into
Save into
Source: Seroter's Original Post
Episode 828 — July 20, 2026.
Let's jump in.
First up, a piece from Addy Osmani on Earning taste and judgment. This one's for anyone worried about the entry-level developer path in the age of AI. The core argument is that taste — the ability to judge what's good, choose what to build, and know when you've got something worth shipping — is the durable human skill that won't get automated. And right now, that's exactly what's missing from junior devs.
The problem is structural. Traditional software development trained you through reps. You fix bugs, write boilerplate, make mistakes in code review. That repetition built your judgment over time. But AI agents will automate those reps. So the path from junior to senior — which ran through those reps — is narrowing. The data is stark: as of March 2026, unemployment among recent college grads sits at 5.6%, with underemployment at 41.5%. For computer science graduates specifically, unemployment is 6.1%. Among the most AI-exposed workers aged 22 to 25, Stanford's research shows a 16% relative employment decline. The demand side has shifted too — junior tech postings are down 34% since 2020, while senior roles held steadier.
So what's left for someone trying to break in? Osmani says focus on taste. Build it deliberately. His concrete advice includes reading far more code than you write, keeping a wrong log of every mistake an agent makes to spot patterns, doing things the hard way on purpose to protect your learning, going deep on one system end to end, building evals around a rubric of correctness, and calibrating autonomy per task — turn it up on cheap reversible things, down on expensive failures. He also quotes Kent Beck: it's unlikely AI agents will ever possess taste, so we'll be the ones supplying it in the intersections.
The bigger principle here: anything gradeable by someone else is getting automated. The career is the ungradeable part — choosing what matters, judging honestly when you've got it, answering for it. Do that in public, near the hard problems.
Next, a more practical piece from Jim Bennett on Evals in your CI/CD pipeline. This one's for anyone who's already building AI features and wondering why quality keeps slipping.
Bennett argues that we happily run every unit test on every pull request, but evals — the checks that tell us if our AI is behaving — usually sit in an observability dashboard somewhere while someone changes a system prompt and ships it on vibes. He wants to close that gap.
The mental model is the classic arrange-act-assert loop, with a new eval step inserted before the assertion. Arrange is fetching your golden dataset. Act is running your app against a row. Eval is grading that output with an evaluator — which can range from a simple code check to an LLM-as-a-judge. Then you assert on the score. The key shift is gating on a percentage rather than perfection. AI output is non-deterministic, so demanding 100% pass rates is wrong. Instead you set a threshold — say 70% of rows must pass — and block PRs that fall below it. Arize's own guidance is telling: a 100% pass rate on a fuzzy system usually means your dataset is too easy or your judge is asleep.
He also covers testing your judge. If the LLM-as-a-judge is broken, you get a broken quality gate. So you test it the same way: build a dataset of outputs you've already graded by hand, run your judge against that, and fix the judge prompt before you trust it. Same arrange-act-eval-assert loop, except the thing under test is your evaluator. That's eval-driven development — the discipline you already trust for code, turned back on the tool doing the grading.
Third piece today — Builder.io on Turn User Signal Into What You Build Next. This one's about the handoff problem.
Most software teams run the same process shape: PM writes a spec, designer works it up, engineering builds, someone reviews, something gets kicked back, user testing happens at the very bottom. By the time you get there, you've spent four to six weeks, sometimes months, and you're staring at the question nobody wants to ask: is this actually what the user needed?
Every handoff costs a week or two and loses fidelity. The PM pictures one thing, the designer another, the engineer a third, and the user something different from all of them. Building fast stopped being the hard part. Coding agents are getting better, the cost of writing code keeps dropping, and most teams can ship something quickly now. Knowing what to build is the real work, and that depends on how fast you can learn from what you ship. The fix is getting prototypes into users' hands faster — not by skipping stages, but by compressing the feedback loop so you learn before you've built the wrong thing deep.
Fourth piece: Google Cloud on The Risk of Exposed Cloud Functions and How to Harden. Mandiant security assessments keep finding publicly exposed serverless apps that lack authentication.
The attack scenarios are worth understanding. If a function accepts user input without proper validation — say, a path parameter used to open a file — you can get local file inclusion. From there, attackers can extract secrets stored in the code, review application logic for further vectors, and exfiltrate service account tokens from the metadata server. That becomes a foothold for pivoting to adjacent systems and potentially taking over your whole cloud environment. Mandiant's advice applies to any public serverless deployment, not just Google Cloud.
Fifth piece is a sharp critique from Adron on Loop Engineering. He thinks the whole concept is SDLC in disguise.
The pitch for loop architectures — plan, act, observe, correct, repeat — sounds rigorous and engineering-like. But Adron's take is that it mostly looks like the same slow, ceremony-laden software development lifecycle companies have been stuck in for thirty years, except now we've bolted it onto a language model and called it innovation.
His reframe: a loop is fundamentally an error-correction structure. You loop when you can't get it right in one pass and you have no better way to make progress than to try, check, and try again. The classic SDLC loops because humans forget things, go home at night, and don't share memory. When you lift that structure and drop it onto an LLM, you inherit all those assumptions even when they no longer apply. The model can hold enormous context. It can be given the whole picture at once. So a lot of the loop is solving a problem you've already got the tools to eliminate.
What does he recommend instead? First, front-load context so the first pass is the good pass — spend engineering effort upfront assembling everything the model needs instead of clawing quality back through iterations. Second, decompose along data flow, not along a status board — build a pipeline where each stage has a typed input and typed output and stages connect because one output is literally the next input. Third, make feedback event-driven, not clock-driven — route a specific signal back only when something concrete breaks, not on a fixed reflection cadence. Fourth, push determinism to the edges — let code own validation, tool calls, and formatting, and let the model do only the genuinely fuzzy judgment in the middle.
His request: before wrapping your model in another plan-act-reflect grinder, ask what the loop is actually for. If the honest answer is to cover for lossy hand-offs and missing context, you don't have a loop problem. You have an SDLC you never cleaned up, and the fix is a workflow, not another lap.
Sixth piece: DoorDash's entity cache, covered on InfoQ.
DoorDash built a transparent proxy caching platform called Entity Cache, and the numbers are wild. It sits in front of 50 services across 100 endpoints, serves over 1.5 million requests per second, and maintains 99.99999% availability. They built it on Envoy and Valkey, and it operates within their existing Envoy-based service mesh. Services keep making their existing requests without any code changes, while cache behavior is managed centrally.
The platform does more than cache though. It handles invalidation using Kafka-based events, comparing update timestamps against cached responses. It uses dual TTL thresholds to serve slightly stale data during outages — which proved critical during a multi-hour upstream failure when Entity Cache kept serving valid cached data instead of failing. Envoy removes unhealthy cache instances and routes directly to upstream when needed.
For performance, they optimized buffer pools to reduce memory allocation overhead, used a lock-free single-flight mechanism to prevent duplicate work during cache misses, and implemented probabilistic early refresh based on the XFetch algorithm to reduce cache stampedes. The results: allocation rates down 50 to 60%, per-pod throughput up about five times, P99 latency spikes reduced by up to 80%, and cache hit rates above 90%. Upstream requests dropped 60 to 95% during normal operation.
Seventh piece: Google Cloud made it easier to build highly available, multi-region Cloud Run services.
The new capabilities are readiness probes and service health. Readiness probes give you instance-level health checks so you know exactly when your containers are ready to serve traffic and how many healthy instances exist in each region. Service health aggregates those checks to calculate the overall health of your service per region, exposed via serverless network endpoint groups. When connected to a global external application load balancer, traffic automatically fails away from unhealthy regions.
For public internet apps, you configure Cloud Run with a global external load balancer for automatic detection and failover. For private network apps, you use a cross-regional internal load balancer. Google Cloud notes that service health works best with active-active configurations where multiple regions are actively serving traffic, and they recommend pairing it with read-heavy applications that synchronize data across regions.
The key design considerations: make sure your database layer has regional redundancies too, so you don't have a single point of failure. They also point to managed multi-region solutions like Firestore, Spanner, Cloud Storage, and Cloud SQL for data residency requirements. These capabilities are available in all Cloud Run regions at no additional cost — you only pay for the CPU and memory the readiness probes use.
Eighth piece: Google Developers on Building scalable AI agents with modular prompt transpilation.
When you're first building an agent, a single monolithic system prompt works fine. But as you layer on safety policies, domain-specific rules, formatting requirements, and escalation behaviors, you end up with your entire control plane in one file — and that's where trouble starts. The failure modes: obscured blast radius where adding a sentence has unintended side effects across the whole agent, copy-paste drift where teams duplicate shared logic inconsistently, and deferred runtime errors where you only find missing variables or invalid imports when a specific workflow triggers.
Their solution: treat prompts like build artifacts. Author modular skill files, reduce the scope of each file to encapsulate a specific behavior, and compose them with templating — like including shared safety policies, tool usage instructions, and environment-specific values. The transpiler resolves these dependencies at build time and generates a deterministic artifact you can test, audit, and diff before it reaches the model.
Build-time validation catches missing imports, undefined variables, and circular dependencies. You can also set CI to regenerate the transpiled prompt from source and compare it against the committed artifact — if they differ, the build fails. They also describe a dynamic skills pattern: agents load a stable base prompt for identity and safety, then at runtime retrieve only the specific skill modules needed for the task. And once you have this modular system, agents can theoretically draft new skill modules and open pull requests — with a human reviewing and running evals before merging.
Ninth piece: Linus Torvalds on AI OK in Linux development. His stance is measured and libertarian in the best way.
Torvalds says AI can be a painful tool for maintainers — both from workload and because it keeps finding embarrassing bugs. His solution is to make sure those LLM tools help maintainers instead of just causing them pain. But on the question of whether AI should be used: developers should be free to choose. They're not forcing anyone to use it, but he'll very loudly ignore people who try to argue against other people using it. It's a practical, pragmatic stance: use it if it helps, leave it if it doesn't, and stop fighting about what others should do.
Tenth piece: Designing APIs for agents, from Freestyle.
The premise: most API consumers today do so through agent-written code. This was not true two years ago, and it changes everything. When designing for humans, you optimize for minimal onboarding — get someone productive in fifty lines with defaults handling the complexity. When designing for agents, you optimize for clarity and explicitness. Agents can read your entire docs in one sitting, read all the fields, and fill them in. Defaults are actually bad now because they hide what the code actually does. Errors aren't bad either — for humans, errors in onboarding are friction, but for agents, a precise error is an opportunity to clarify a misconception about your API. In their data, 27% of agent friction comes from errors, so great error design is as important as great docs.
They prefer specific field names to general ones. "Name" is ambiguous — does it mean display name, full ID, scoped ID? Ask an agent to use a field called "name" across ten use cases and it will use it five different ways. Prefer "displayName," "slug," or "externalId" — words an agent can truly understand. They walk through examples of agent-friendly SDKs like Flue Framework, Vercel AI SDK, and their own Freestyle VM API, contrasting them with SDKs that smooth things over for humans but create ambiguity for agents.
Eleventh and final piece: Google Cloud positioning as a leader in Gartner's 2026 Magic Quadrant for Conversational AI Platforms, placed furthest in vision and highest in execution.
Google's showing here is for their conversational AI platform capabilities, and they're positioning Gemini Enterprise for Customer Experience at the center — a platform for building AI agents that can understand customer intent, reason across enterprise knowledge, and take action across business systems. CX Agent Studio is the builder interface, combining models, orchestration, enterprise retrieval, and developer tooling. They're highlighting Home Depot as an early customer, where AI voice agents help customers reach solutions up to 4x faster than traditional phone menus. The agents understand why a customer is calling in under 10 seconds, help complete purchases or initiate service requests, and escalate to human associates when needed.
The pitch is that this runs on Google's first-party AI stack end to end — their custom AI Hypercomputer infrastructure, the Agentic Data Cloud for grounding models in real-time data, and Agentic Defense for security. The idea is that these layers are co-designed to work as a unified system, so teams building on it automatically benefit from ongoing DeepMind research and hardware improvements.
That's the reading list for July 20th. Lots of thread connecting these pieces — the question of what stays human as agents handle more execution, the push to get evals and workflows into production discipline, and the quiet reshaping of developer tooling, API design, and infrastructure around the new reality that most code is written by and for AI systems. I'll see you next time.
- Earning taste and judgment — Addy Osmani
- Evals in your CI/CD pipeline — Jim Bennett
- Turn User Signal Into What You Build Next — Builder.io
- The Risk of Exposed Cloud Functions and How to Harden — Google Cloud
- Loop Engineering Is Mostly Just Broken SDLC Wearing a Costume — Adron
- DoorDash Uses Envoy and Valkey for a 1.5M RPS Proxy Cache with 99.99999% Availability — InfoQ
- Making highly available, multi-region Cloud Run services just got easier — Google Cloud
- Building scalable AI agents with modular prompt transpilation — Google Developers
- AI OK in Linux development, says Torvalds — InfoWorld
- Designing APIs for agents — Freestyle
- Google is a Leader and positioned furthest in Vision and highest in Execution in the 2026 Gartner® Magic Quadrant™ for Conversational AI Platforms — Google Cloud