Seroter's Daily Reading — #833 (July 27, 2026)
Follow into
Save into
Source: Seroter's Original Post
Seroter's Daily Reading, episode 833, July 27, 2026.
Welcome back. Gemini helped me succeed at the horse races on Saturday. Great use of AI. In today's list, I liked some of the leadership and mentorship content, and there are several pieces touching on how AI is reshaping how we build, govern, and think about software.
Let's start with a piece from Silicon Valley Product Group on The AI Productivity Paradox. The business world is grappling with a strange situation: AI adoption is soaring, investment is accelerating, but sustained impact on performance remains elusive. A recent McKinsey Quarterly piece put it bluntly — companies are moving faster than ever, but results aren't following. Ninety percent of executives say AI has increased the speed of work, but only six percent feel confident they can point to organization-wide AI ROI. So what's the disconnect?
The author argues that most teams are using AI to simply speed up their old way of working — the project model — without questioning whether the model itself was the problem in the first place. It's never been faster to build, which means it's never been easier to run ten times faster in the wrong direction. As one product leader put it, AI makes building easier, but the hardest part remains knowing what to build. The real issue was never that the project model was too slow. The larger issue was that it was designed to deliver output rather than outcomes. And if you apply AI to the wrong process, you just get more of the wrong output, faster. This piece connects to a broader theme I'm seeing across this week's reading — the gap between AI's capabilities and the human judgment needed to use them well is widening, not narrowing.
Speaking of building faster with AI, here's a piece from Squarespace engineering on prototyping with AI. The concept is called Stain the Page — you take an idea, feed it to an AI, and tell it to build a rough proof of concept with the bar set incredibly low. Let the AI handle all the micro-decisions — variable names, CSS, component structure — while you save your mental energy for the high-level architecture and user experience. The point is to get something on the screen quickly so you can react to it. The author describes this as avoiding the void — ideas that would otherwise disappear because the energy required to build them was too high. Once you can see what your idea looks like, you know what you don't like, and that's a faster path to the right answer than starting from scratch. The author used this approach to prototype an AI visibility scanner and had a working proof of concept in under thirty minutes. That tangible artifact let the team skip the exhausting "is this possible?" conversation and jump straight to "how do we make this great?" That's a useful mental shift.
Now, here's an uncomfortable piece from Harvard Business Review on Why Mentoring Matters More in the AI Era. A quiet shift is happening in organizations: AI is automating the very work that once trained employees. The repetition of spotting weak arguments in a memo, interpreting ambiguous data, and anticipating stakeholder concerns — that built judgment. Exposure built intuition. Strip out that layer and you lose your training ground. If the on-ramp for professional judgment disappears, so does the leadership pipeline. And on-demand learning platforms and one-off training sessions aren't enough to close the gap. They don't transfer judgment, pattern recognition, or the tacit knowledge that accumulates through lived experience. The article argues that mentoring must be redesigned from the ground up. It should include clear competency definitions, written mentoring agreements, protected mentor time, and deliberate matching by skills gap rather than org chart proximity. The author makes a point I found important: not everyone can automatically be a mentor. It may take training to do it effectively, but it's well worth the investment.
This is a good moment to shift to a more technical piece that underscores what happens when people without that kind of mentorship or grounding build with AI. There's a detailed article from Shift Mag based on a talk at a developer conference in Croatia on why security must be built in as everyone becomes a builder — Security Must Be Built In as Everyone Becomes a Builder. The author coined the term Ambient Generative IT — the phenomenon where AI-assisted development has become so pervasive that it blends into the organizational fabric. Marketing managers build dashboards, HR teams automate onboarding workflows, sales ops create CRM integrations. None of them are engineers, and most have never heard of row-level security, yet they are all becoming software developers. Shadow AI was involved in twenty percent of all breaches in IBM's latest report, compared to thirteen percent from sanctioned AI. Companies with high shadow AI paid an average of four and a half million dollars per breach, compared to about four million for those with low or no shadow AI. A cybersecurity firm found more than three hundred and eighty thousand publicly accessible applications built with vibe-coding tools, and about five thousand of those had virtually no security or authentication. Around forty percent exposed sensitive data. One common pattern is Supabase-based apps where row-level security is disabled by default, and vibe coders ship to production without enabling it. A single curl command with a publicly available key returns the entire database. Conveniently, no hacking is required. This mirrors an interesting irony: AI genuinely reduces certain bugs. Syntax errors dropped seventy-six percent and simple logic bugs fell sixty percent. But AI introduces architectural authorization flaws — code that is syntactically perfect, passes all tests, but asks the wrong question. It checks "is this user logged in?" instead of "is this user allowed to access this specific resource?" SAST tools cannot catch this because the code does exactly what it says. The problem is that it says the wrong thing. The article frames vibe coding as optimizing for features, not permissions. Access control is an architectural decision made implicitly by AI, and those implicit decisions are often wrong.
Let's stay on the software development theme with a piece from Hugo Bowne-Anderson on O'Reilly Radar about agent harnesses — Stop Overengineering Your Agent Harness. The conversation around harness engineering is dominated by problems from coding and personal agents, but most agents are simpler. Builders should avoid over-engineering for capabilities that newer models may absorb anyway — the Kirby effect — and focus on durable fundamentals. An AI agent harness is the body to the LLM's brain. It handles the loop, tool execution, context management, state, and safety. The key insight is that harness features expire as models improve. Every component in a harness encodes an assumption about something the model cannot do on its own. As models improve, those assumptions expire and the corresponding harness features can be removed. One researcher at Google DeepMind called this the Kirby effect, named after the video game character who absorbs the abilities of enemies he swallows. Manus has been re-architected five times in a year. LangChain's open deep research was rebuilt multiple times in a year. Even Anthropic has torn out Claude Code's harness as models improved. Many common harness patterns — compaction, sub-agents, memory systems, elaborate orchestration — may be absorbed into the models themselves. The practical advice: build the minimum viable harness for the job, add complexity only when a real failure demands it, and revisit those additions whenever a stronger model arrives because yesterday's necessary workaround may be tomorrow's dead weight.
Now a shift to infrastructure. An article from The New Stack on Agent Sandboxes. All four major cloud providers — AWS, Google Cloud, Microsoft Azure, and Cloudflare — now offer isolated code execution as a native primitive for running untrusted agent-generated code. But they built their solutions on materially different isolation stacks. AWS built Lambda MicroVMs on Firecracker, giving each session a dedicated virtual machine with up to eight hours of runtime and a suspend-resume cycle. Google went two ways, using gVisor for GKE Agent Sandbox and Cloud Run adds a lightweight isolated execution boundary within an existing instance. Azure's had Hyper-V based isolation in Container Apps dynamic sessions since 2024, and Microsoft reported that Copilot alone consumes more than four hundred thousand of those sessions per day. Cloudflare built on top of Containers with each sandbox isolated in its own VM. Four vendors, four genuine architectural disagreements about where the security boundary belongs. What unites them is the agreement that agents should not run code on the host. That's a meaningful signal.
And finally, for something more technical, Guillaume Laforge posted a detailed walkthrough on Running Gemma 4 locally on Mac and benchmarking different inference runtimes on Apple Silicon. He tested three approaches: a pure Java inference engine using ARM SIMD intrinsics, llama.cpp with Metal GPU offloading, and Apple's MLX framework. The results varied significantly — the Java engine hit about eight tokens per second on CPU, llama.cpp with speculative decoding hit about forty-five tokens per second, and MLX topped out at over two hundred tokens per second on prefill and around forty-five on generation. He also walked through connecting it all to a Java application using LangChain4j and launching an OpenAI-compatible API server from the MLX toolchain. It's gotten much easier to set up these kinds of benchmarks, and the results are interesting.
Stephen O'Grady at RedMonk weighed in on Meta's potential entry into cloud infrastructure — Meta Compute, Neoclouds and the Future of the AI Infrastructure Market. Mark Zuckerberg suggested it may make sense to rent out Meta's existing compute in some cases, and a new business unit called Meta Compute has been reported. The market reacted strongly — Meta stock rose about nine percent while neoclouds like CoreWeave and Nebius dropped significantly. The analysis makes the case that Meta has deep infrastructure expertise and is willing to invest heavily, but building a cloud business orthogonal to its core model requires organizational commitment that takes time. AWS took about seven years from launch to profitability. And the real signal to watch is who Meta hires. To attract senior cloud talent, money isn't enough — they need a compelling vision. That will be telling.
That's episode 833. A thread running through much of this week's reading is that AI makes it easier to build, faster to prototype, and cheaper to run models locally, but it does not automatically make us better at knowing what to build, safer from the risks we create, or more skilled at guiding the next generation of builders and leaders. Sometimes the hard parts were always the hard parts, and the tooling is just revealing that more clearly.
- The AI Productivity Paradox — Silicon Valley Product Group
- Stain the Page — Squarespace Engineering
- Why Mentoring Matters More in the AI Era — Harvard Business Review
- Security Must Be Built In as Everyone Becomes a Builder — Shift Mag
- Stop Overengineering Your Agent Harness — O'Reilly Radar
- Agent Sandboxes — The New Stack
- Running Gemma 4 locally on Mac — Guillaume Laforge
- Meta Compute, Neoclouds and the Future of the AI Infrastructure Market — RedMonk