Seroter's Daily Reading — #819 (July 7, 2026) · Seroter's Daily Reading

Listen: https://blossom.buildtall.systems/afd0208b17474d33d1de15dc3232b7692068de00cbf80ce0075acd74ed1a138c.mpga

Seroter's Daily Reading, episode 819, July 7, 2026.

Let's get into it. Battery Ventures dropped their latest State of Enterprise Tech Spending survey, and it covers a lot of ground on where agentic AI sits in the enterprise right now. The headline is pretty striking: ninety-four percent of respondents say their organization lacks a consistent, enterprise-wide framework for evaluating AI's return on investment. That's not a small gap. Only sixteen percent see positive ROI on more than half their AI projects. And thirty-one percent see ROI on less than a quarter. So there's a lot of spending happening, a lot of conviction that AI is a real structural shift, but not a lot of clarity on whether the money is actually working.

On the flip side, adoption is robust. Seventy-six percent are already in production with generative AI, and a hundred percent plan to have something deployed within two years. Not a single respondent said they were cutting AI spending. Forty-nine percent are actively deploying agentic AI, up from thirty-three percent six months ago. Eighty-four percent expect AI to materially reshape their software delivery cycle within two years. Code generation and testing are getting the most scrutiny: eighty-two percent are re-evaluating code generation and refactoring, and seventy-five percent are re-evaluating testing and QA automation. These are the two highest numbers in the entire re-evaluation dataset.

One thing worth flagging: security review is the biggest breaking point in the AI software delivery lifecycle. When respondents named the biggest concerns as AI agents become more common in the pipeline, security review and vulnerability management came out on top, followed by compliance and auditability and developer skill degradation. That's a useful signal for anyone building in this space. Also, fifty-three percent of enterprises did see clear ROI on AI in general terms, and the most convinced industries were IT and healthcare. And on the model side, Anthropic's Claude ranked among the top three for seventy-five percent of respondents, ahead of Microsoft at seventy-two and OpenAI at fifty-eight. Though Microsoft's Azure OpenAI and Copilot product is still the single most-used model overall.

Moving on. If you've been watching Go releases with half an eye, you may have missed some of what landed in Go one point twenty-six. A piece from Towards Dev argues that this release quietly fixed the things that were actually annoying with Go 1.26. And the most exciting change, in this author's view, is the rebirth of go fix. It was rewritten from scratch and is now the home for dozens of automated fixers that update your code to modern idioms and APIs. The killer feature is source-level inlining. If you maintain a library and want your users to migrate to a new API, you can write a go:fix inline directive, and go fix will rewrite their code automatically. That means upgrading a Go project to one point twenty-six is one command away. Migrating off deprecated APIs is no longer a manual grep-and-replace. Library authors can ship breaking changes with an automated migration path built in.

On the runtime side, cgo calls got faster, which matters if you have Go services calling into C libraries like database drivers or image processing. There's heap base address randomization, which is a security hardening measure that makes certain memory corruption exploits harder. And there's an experimental goroutine leak profile in pprof that detects goroutine leaks in your test suite. Three new standard library packages shipped: crypto/hpke for hybrid public key encryption, simd/archsimd for SIMD primitives if you want vectorized code without dropping into assembly, and runtime/secret for managing secrets without exposing them in stack traces or panic messages. That last one should have existed years ago and is a real security improvement even in its experimental form.

Next up, a piece from bakadesuyo on overcoming burnout with five secrets from philosophy covering How To Overcome Burnout. This one leans on Byung-Chul Han's work on what he calls the achievement society, and it's a useful frame for why so many of us feel perpetually behind. In a disciplinary society, you fail against a standard outside yourself. In the achievement society, the accusation is that you were inadequate. You didn't live up to your potential. And since potential is infinite and people are not, there's no stopping point. You become your own boss and your own worker, which makes self-exploitation feel like freedom, and that turns out to be more efficient than any external boss ever was. The result is depression and burnout.

The article offers five concrete reframes. First, see the invisible boss. That voice in your head telling you to be productive is not always your conscience. It might be the achievement society doing a ventriloquist act. Notice the thought. Ask whether it's your actual desire before you obey it. Second, hyperactivity is the most passive thing you can do. A packed calendar looks like power from a distance, like a hamster wheel looks like transportation from a distance. The radical act is a calm, firm no. Delay is a kind of sovereignty. Third, stop treating rest as a productivity hack. Rest doesn't need to justify itself by making you a better worker. Rest is valuable because it belongs to the part of life that's not for sale. The author even suggests designating a secular Sabbath, a day that does not exist to fortify tomorrow. Fourth, boredom is not wasted time. Research shows the brain is doing important work when it seems idle, connecting ideas, simulating possible futures, creating meaning. Every time you fill a dull moment with a podcast or a scroll, you're interrupting that process. Schedule some boredom, the author suggests. Twenty minutes, three times a week, no phone, no goals. And fifth, why nothing you ever feels like enough. Han says we're lacking what he calls conclusive forms, things with a clear beginning, middle, and end that your brain can point to and say, that's done. Since enough is a word that only makes sense when there's an ending, we have to draw that line deliberately ourselves.

There's a nice self-aware moment at the end of this piece. The author notes that he writes a blog that often says things like seven ways to be more productive and here's how to stop wasting time. He may have been the ghostwriter for the invisible boss. His advice is to use productivity tools like a hammer: pick it up, build something, put it down. Don't clutch the hammer at dinner.

Alright, next piece. From softwaredoug.com, a contrarian take titled Write Code, Not Specs. The argument is that maintaining specs alongside code means you have two systems, one imprecise and one extremely precise, and now you have to maintain both. This author has moved to a model where code is the source of truth. He establishes patterns in code, and within those established patterns, he has a high degree of trust in agent automation. Outside the carefully tilled garden, trust diminishes. The way to develop this taste, this sense of what good looks like, is to do some of the work. Tests serve as the stand-in for requirements. At a certain level of maturity, the tests become the code. When a few tests actually test something, you let an agent write more while you watch it like a hawk. This gives you a gradually expanding surface of trust. Some areas you trust the agent to be extremely automated. Other, newer areas, you want to be slower, careful, and gradual.

The broader analogy is that using coding agents isn't a higher level of abstraction. It's building a factory. You can't build a factory without designing and hand-crafting prototype parts. Only then can you build up to higher levels of automation. A well-running factory requires a mechanic's skills, not because even a tiny fraction of cars need manual intervention, but because touching some cars improves the factory, develops taste, and keeps the team obsessed with quality. Feel proud of touching code, this author says. It means you care how the factory works.

Next, a piece on On Measuring Engineers as Individuals. This is a sharp one. The setup: a company started measuring every engineer with individual productivity metrics. A few months later, the engineers everyone relied on became less helpful. They stopped jumping into tricky debugging sessions. They stopped mentoring junior engineers unless they absolutely had to. Not because they cared less, but because every minute spent helping someone else made their own numbers look worse. One specific engineer was the best mentor on the team and the person who knew the codebase best. He spent most of his day pairing and unblocking other people. But only one person gets to make the commit. His numbers looked bad, so he went heads-down on his own tickets. His numbers recovered and the team lost the one person who made everyone else faster. By the time anyone connected the dots, he was already interviewing elsewhere.

The problem is structural and predictable. The numbers usually improve in the first quarter after you start measuring this way. Your engineers stop wasting time on work that doesn't count and pour those hours into visible output. PR counts rise. Tickets close faster. The chart goes up and to the right. But the rising line and the collapsing collaboration are the same event. You're not necessarily watching a team get more productive. You might be watching it cannibalize the invisible work that kept it healthy. The collaborative work dies in a predictable sequence. First to go: unblocking a colleague. Pure altruism, no artifact, no commit with your name. Second: root cause analysis. Fixing a bug counts. Understanding why it happened does not. Third: substantive code review. Real review takes time you can't log against a story, so it reads as slacking. Fourth: mentoring and pairing. Then the vacuum fills with gaming: cherry-picking easy tickets, splitting one change into five tiny PRs, inflating tasks, writing verbose code to look good on the metrics.

The piece cites Campbell's Law, from nineteen seventy-six, which says that the more a metric is tied to consequences, the less true your data becomes. Kent Beck put it this way: if you choose to create incentives around measures, know that you will never again receive accurate data.

Moving on. A piece from thenewstack.io on Andrej Karpathy, Google, and Garry Tan agreeing that Markdown is the answer, covering the Markdown Agent Memory Moat, though they're not solving the same problem. In April, Karpathy published an LLM Wiki, a brief text document designed as a personal knowledge base using LLMs. The premise is that an AI agent keeps what it knows as linked Markdown files it can read and rewrite, because a language model doesn't get bored maintaining cross-references and can touch fifteen files in a single pass. A couple months later, Google turned that instinct into a published standard called the Open Knowledge Format. The OKF packages organizational knowledge, metrics, tables, and runbooks as plain Markdown that any agent can read without a proprietary account. Google is calling it version point one, a starting point. Garry Tan at Y Combinator got there first from a different direction. His gstack, a Claude Code setup that crossed sixty-six thousand GitHub stars within weeks, comprises twenty-three specialist roles, each a Markdown file. No runtime, no code, just prose that runs across ten different coding agents.

Three approaches, three different needs, one common solution. The significant factor the piece identifies is that the competitive advantage is shifting from the model to the files. For two years, the belief was that owning the best model meant controlling the developer. That perspective is now shifting. Replacing Claude with another model, gstack continues to operate because the core intelligence evolved but the documentation did not. The moat is shifting from the model to the Markdown a team owns and accumulates over time. A company's OKF bundle, including its runbooks, metric definitions, and architecture decisions, is by design portable across clouds, models, and frameworks. The creator of that Markdown folder now possesses an advantage that the model vendor cannot easily replicate.

Next, Google announced new capabilities for Managed Agents in the Gemini API covering the Expanding Managed Agents in Gemini API. These include background execution, remote MCP server integration, custom function calling, and refreshing credentials across interactions. With the Gemini Interactions API, you call a single endpoint and Gemini handles reasoning, code execution, package installation, file management, and web information inside an isolated cloud sandbox. The background execution feature is notable if you're building agents that need to run longer tasks without holding a live connection. Remote MCP integration means your agent can connect to MCP servers that aren't local. And refreshing credentials across interactions addresses one of the trickier problems in building stateful agent experiences, where a session might outlive a short-lived auth token.

And finally, some labor market data covering the IT Unemployment dip below 3%. IT professional unemployment in the US dipped below three percent for the first time this year, hitting two point nine percent in June. Employers added nearly fifty thousand IT workers across all industries in June amid ongoing AI deployment efforts, according to a CompTIA analysis. Open job postings for tech roles surpassed six hundred thousand for the second consecutive month. Despite overall demand, the technology sector itself trimmed about fifteen thousand five hundred jobs last month and has shed nearly one hundred forty thousand so far this year. AI is the dominant force in those cuts, with companies restructuring around it, automating roles, and reallocating budgets toward new capabilities.

But here's the interesting tension: AI-augmented software development jobs increased by nearly six hundred percent in the last five years, according to a Randstad Digital report. Traditional developer roles grew just twenty-eight percent in the same timeframe. So the new jobs are there, they're growing fast, but they're not necessarily landing in the same companies or the same teams that are doing the cutting. The sector is being reshaped in real time, and the新旧 aren't evenly distributed.

That's episode 819.

No Nostr signer detected