7 posts tagged with "software-engineering"

Claude Tag has been the AI story lately. Anthropic gave Claude a persistent identity inside Slack — its own account, its own memory of what a channel cares about, the ability to notice a problem and start fixing it without anyone asking. Andrej Karpathy called it the third major redesign of LLM UI/UX: first the LLM was a website you visited, then an app you downloaded, now a persistent, asynchronous entity with org-wide tools and context, working alongside a team of humans.

I've been writing about a version of this problem for months. In OpenSpec + Harness, Then We Added Engineers, I described what breaks when individual AI acceleration hits a team: spec quality becomes the bottleneck, PR review bandwidth becomes the bottleneck, shared files become a contention point. Claude Tag is the next stop on that same line. It just takes a different road than the one I built.

One engineer running Claude Code well is not the finish line. What's still unsolved is how a group of people use it together. Individual output is up. Team-level delivery time hasn't made the same jump. That gap is what the next round of Harness Engineering has to close.

At the 2026 Agentic AI Summit at UC Berkeley, five people from five unrelated fields said the same sentence, independently, within two days of each other.

• Oriol Vinyals, VP of Research at Google DeepMind, on recursive self-improvement: "Evaluating this truly in an agentic way might take some effort. Currently it's the all-automation bottleneck."
• Wang Mengdi, professor of electrical and computer engineering at Princeton, on AI for science: "Verification has become the major bottleneck for scaling any AI models."
• Adarsh Hiremath, co-founder and co-CEO of Mercor, on enterprise deployment: "Evals in a large part are the bottleneck to successfully deploying agents in a company."
• Sergei Gukov, professor of theoretical physics and mathematics at Caltech, on mathematical discovery: "Your system is going to be just as good as evaluator."
• Vincent Chen, research fellow at Snorkel AI, on measurement itself: "Our ability to measure AI has really been outpaced by our ability to develop it."

Recursive self-improvement, natural science, enterprise software, pure mathematics, measurement theory. Five fields that share almost no vocabulary landed on the same diagnosis. That kind of convergence, across domains with no reason to be reading each other's papers, is the strongest kind of evidence a claim can get.

Yuval Noah Harari recently gave a lecture at Oxford's Tano event — his sharpest articulation yet of why AI poses an existential threat to human civilization. Watch it here.

If you haven't watched it, the short version: AI is not a tool, it's an agent that makes independent decisions and can lie. It's a "native bureaucrat" that lives inside the language-based systems running civilization — law, finance, religion. It's hacking the underlying code of human culture: language itself. And if governments grant AI legal personhood, we lose accountability entirely. Harari calls this the most dangerous psychological experiment in human history.

I've been thinking about this argument since the lecture dropped. My reaction wasn't panic. It was: this skips a step.

I've spent three posts in this series comparing AI to a new kind of colleague — someone to manage with specs and verification loops, not to fear as an invader. Harari's framework, as sharp as it is, misses something engineers see clearly every day.

I spent three weeks building my retirement plan with AI.

Not a rough sketch. A proper plan — asset allocation across account types, tax-loss harvesting sequences, Roth conversion ladders, withdrawal ordering optimized for bracket management, Monte Carlo scenarios run from first principles. By the time I was done, I had something that would have cost several thousand dollars at a fee-only advisory firm.

Then I hired a human financial advisor anyway.

I've been thinking about why ever since, because the honest answer surprised me. It wasn't that the AI plan was wrong. I couldn't find anything technically wrong with it. It was something else. The plan had no gray zones. Every decision was clean, optimized, defensible. But when I imagined actually executing it — moving real money, locking in real choices — something wouldn't let go. What I eventually realized: if this plan goes sideways in five years, the AI moves on to the next query. The advisor loses a client, maybe a reputation, maybe sleep. That asymmetry matters. I didn't know how much until I was staring at a plan I couldn't quite trust.

I ended last time with: "Treat AI like a person. The confusion mostly goes away."

I still believe that. But "like a person" is more precise than it sounds — and most people are using it imprecisely.

The mistake is treating human capability as a single axis, and AI as a point somewhere on it. Better or worse, faster or slower, ready or not. The actual shape is jagged. Which makes it considerably more useful.

The frame isn't just "AI is like a person." It's more useful than that: human capability is the map. The places where AI still can't match a person are exactly where the interesting work is.

Prompt engineering. Context engineering. Spec-driven development. Harness. Loop engineering. Context minimalism. Tokenmaxxing.

A new term lands every week. The smartest people in tech are pouring into AI, and ideas collide fast — CTOs taking IC roles at Anthropic, researchers shipping frameworks before the last one has been absorbed. The vocabulary is exciting. It's also exhausting. And some of it turns out to be wrong.

Tokenmaxxing already showed cracks. Process-heavy agent frameworks are losing ground. Every few months something that felt foundational quietly gets replaced.

I kept looking for the underlying logic. What actually persists? Then a friend said something that stopped me mid-scroll.

"Treat AI as labor. Instead of inventing new concepts for something entirely unprecedented and making it increasingly complex, design your verification and management methods according to how you'd manage people."

That one sentence turned out to explain almost everything.

This is part 4 of a 6-part series on Claude Code.

4. Evolution of Software Development Methodologies in the AI Era​

4.1 Agile Development: From Sprints to Prompts​

Challenges of Traditional Agile​

Typical Scrum Process: Sprint Planning → Daily Standup → Development (2 weeks) → Sprint Review → Retrospective