Seroter's Daily Reading — #742 (March 16, 2026)

Source
Daily Reading List — March 16, 2026 (#742)
Articles Covered
- My custom agent used 87% fewer tokens when I gave it Skills for its MCP tools — Richard Seroter
- Become Builders, Not Coders — Indeed Engineering
- Balancing AI tensions: Moving from AI adoption to effective SDLC use — DORA
- Why context is the missing link in AI data security — Google Cloud
- Run Karpathy’s autoresearch on a Google serverless stack for $2/hour — Karl Weinmeister
- Why the World Still Runs on SAP — a16z
- You’re Not Paid to Write Code — Tech World with Milan
- When to use WebMCP and MCP — Chrome for Developers
- BigQuery Studio is more useful than ever, with enhanced Gemini assistant — Google Cloud
Transcript
Welcome to another episode covering Richard Seroter’s Daily Reading List. This is number 742, posted March 16th, 2026. Eight articles today, and there’s a strong thread running through all of them: the line between AI that helps and AI that creates new problems. Let’s get into it.
Seroter himself kicks things off with a hands-on experiment. He built a custom agent using Google’s Agent Development Kit and measured how many tokens it consumed across six different configurations. The headline number: adding skills — basically structured instructions that tell the agent how to use its MCP tools — cut token usage by 87 percent compared to raw MCP alone. That’s not a small optimization. Without skills, his agent burned through over 28,000 tokens fumbling around with three MCP servers. With skills guiding it, that dropped to under 4,000. The takeaway is practical: if you’re building agents that use MCP tools, don’t just hand them the tools and hope for the best. Write a skill file. Tell the agent what to do with them. It’s the difference between handing someone a toolbox with instructions and handing them a toolbox while blindfolded.
Next up, a really thought-provoking piece from Indeed Engineering titled “Become Builders, Not Coders.” The author, who has over two decades in the industry, makes a case that the era of manual coding has effectively ended, and that engineers need to stop identifying as coders and start identifying as builders. He walks through his own evolution — from dismissing AI tab completion in 2023, to being genuinely stunned by agentic coding in mid-2025, to now routinely producing code in languages he can barely read. What’s interesting is his honesty about the transition. He invokes the blacksmith metaphor — imagine going to sleep knowing hammers and bellows and waking up in a modern metal shop with CNC machines and laser cutters. He’s optimistic overall, citing Jevons Paradox: as coding becomes cheaper, demand for software won’t decrease, it’ll explode. But he doesn’t minimize the pain of transition. It’s a nuanced piece, not the usual cheerleading.
The DORA team published research on AI’s impact on the software development lifecycle, and the findings are sobering. Ninety percent of technology professionals now use AI at work, and most believe it’s made them more productive. But the data tells a more complicated story. Higher AI adoption correlates with increased software delivery throughput AND increased instability. The core tension they identify is what they call the “verification tax” — time saved writing code gets re-spent auditing AI output. Thirty percent of developers report little to no trust in AI-generated code. One engineer put it bluntly: “I feel somewhat more productive, but it’s at a cost. I spend less time writing code and more time babysitting the AI.” They also flag a shifting burden to code reviewers — authors use AI to generate massive pull requests, but reviewers still have to manually audit every line. The big insight: AI is an amplifier. It magnifies the strengths of well-organized teams and the dysfunctions of struggling ones.
From Google Cloud, an article on context-aware data security. Their Sensitive Data Protection service now uses AI-powered context classifiers to understand not just patterns but meaning. The key example: if a user types “my arm is broken and I can’t use the touchscreen,” the system recognizes that as a health context and can flag or redact it. But “my wifi is broken” gets correctly classified as technical, not medical. It’s the same with financial context — identical number strings get treated differently depending on whether the surrounding text says “order number” or “wallet number.” This matters because as AI agents get access to more enterprise data, simple regex matching isn’t enough. You need systems that understand what data means, not just what it looks like.
There’s a fun practical piece about running Karpathy’s autoresearch project on Google Cloud for about two dollars an hour. Autoresearch is an autonomous AI research loop: the agent modifies model code, trains for five minutes, checks if validation loss improved, keeps or discards the change, and repeats. The author ran it on Cloud Run with serverless L4 GPUs, billed by the second. In one hour, the agent ran about six to eight experiments — not the theoretical twelve, because PyTorch spends a few minutes optimizing the computational graph for each run. The agent even autonomously diagnosed and fixed a CUDA out-of-memory error on its first attempt. It’s a neat demonstration that serious AI experimentation doesn’t require massive infrastructure anymore.
A16z published a deep dive on why the world still runs on SAP, and it’s more interesting than the title suggests. The core insight: SAP, Salesforce, ServiceNow — these aren’t just software, they’re accumulated institutional memory expressed as tables, roles, approvals, and exception handling. Upgrading from SAP ECC to S4HANA can cost 700 million dollars and take three years. Lidl once scrapped an SAP transition after spending half a billion. AI doesn’t necessarily replace these systems, but it can make them more programmable and approachable. The opportunity is in the interface and automation layer — turning messy human intent into correct, auditable actions against systems of record. The winners will be platforms that plug into transformation budgets first, then expand into day-to-day operations.
Milan Jovanovic’s newsletter makes the case that you’re not paid to write code. The core argument: engineers who deliver the most value aren’t the fastest coders — they’re the ones who start with thinking, asking questions, and pushing back on requirements. He gives a great example of a “slow checkout” bug where an engineer optimized a database query, but users were actually abandoning checkout because of too many form fields, not speed. Nobody looked at the usage data first. Now that AI can write code faster than humans, this distinction matters more than ever. Code is a liability, not an asset — every line needs maintenance, understanding, and eventual modification. The best outcome is often discovering that coding wasn’t necessary at all.
Chrome’s developer blog introduces WebMCP — and Seroter rightly flags this as something to watch. WebMCP is not a replacement for MCP. They’re complementary. MCP connects AI agents to backend systems — data sources, APIs, workflows. WebMCP connects agents to the frontend — the live web page in a browser tab. The analogy they use: MCP is like a company’s call center, available anytime from anywhere. WebMCP is like an in-store expert, available only when you’re on the website. WebMCP tools are ephemeral — they exist only while the page is open. The practical value is letting website owners control how AI agents interact with their UI, rather than hoping agents figure it out from button labels. If you’re building web applications, this is worth understanding now.
Finally, a quick note on BigQuery Studio’s enhanced Gemini assistant. It’s now context-aware of your open query tabs, can search across projects for datasets using natural language, and can analyze job history for troubleshooting. The most useful feature is probably the job analysis — paste a Job ID and ask why it’s slow, and the assistant breaks down slot contention, data volume, and other factors. It’s the kind of incremental improvement that makes a real difference in daily work.
That’s the list for number 742. The throughline today is clear: AI is getting embedded deeper into every layer of the stack — from model training loops to enterprise ERP to browser interactions to data analytics. But at every level, the same tension appears: AI amplifies what’s already there. Good processes get better. Bad processes get worse faster. The skill isn’t using the tools. It’s knowing what to point them at. Thanks for listening.