AI

Dario Amodei, CEO of Anthropic, has published an unusually direct argument about the future of AI development: the companies building the most capable models need to slow down. He is not calling for them to stop, or to give up the benefits AI may bring. He is asking them to leave enough time to understand, evaluate, and control the systems they are making more powerful. What makes this worth reading is who is saying it. Amodei runs one of the companies competing to build those models. He faces the same pressure to move faster as everyone else, and he is arguing that the pace itself has become part of the problem. ...

Anthropic published a new piece last week, The AI-Native SDLC Playbook. It is long, detailed, and worth the time. It also lines up closely with what I have been writing here for the better part of a year. The argument at its center takes one sentence: code is no longer the bottleneck. Everything in the document follows from it. Once agents write most of the implementation, the constraint moves to the stages on either side, the ones still running at human speed. Approval queues build. Controls sized for human output stop matching what arrives at them. Governance that meets monthly cannot govern work that ships hourly. ...

A recent episode of Latent Space with Joon Sung Park, co-founder of Simile AI, caused a strange flashback to my student days in industrial engineering. Long before anyone talked about generative AI, we learned to use a piece of software called Arena to build probabilistic simulations of airports, supermarkets, factories, and other complex systems. The basic idea was simple and surprisingly powerful. Instead of changing the real system, you built a simplified version of it on a computer. Customers arrived according to some probability distribution. A cashier took a variable amount of time to serve them. Queues formed, resources became occupied and available again. You could add another checkout lane, change the staffing level, or rearrange a production line, run the simulation thousands of times, and see what happened before spending money in the real world. ...

When an artificial intelligence system gives us a wrong answer, almost everyone reaches for the same explanation, which is that the system never learned the thing we asked about. The information was missing from its training, and so the remedy is to supply more of it, whether that means more data, a larger model, or another round of training on our own internal documents. This explanation has become so common that most organizations no longer treat it as an assumption, and they build their budgets and their improvement plans around it. ...

On a recent episode of Aakash Gupta’s podcast, Oji Udezue ran a product idea through a viability gate he had built as a Claude Code skill. The idea was a tool called Standup Zero that reads Slack comments and assembles a daily standup digest. The gate scored it on six dimensions and returned three moderates. Problem clarity and urgency, moderate, because workflow convenience is not a deep problem. Target user definition, not strong. Differentiation, not strong. Competitive landscape, strong, which on this scorecard counts against you, because it means everyone can build what you are building. ...

A June 2026 NBER working paper matched more than 100,000 GitHub developers against their AI usage telemetry. Developers using autonomous agents committed 180 percent more code. Their releases rose 30 percent. The gain is enormous where code gets written, and it decays at every step after that. Marty Cagan named the phenomenon last week: the AI productivity paradox. He also points out that while nearly everyone now agrees it exists, almost nobody agrees on why. ...

I recently needed to understand a long, cross-departmental process. It was documented across a huge slide deck, a few forms, and half a dozen fields scattered across internal systems. No single source of truth. In my experience, the right tool for this is a checklist. Not a dashboard, not an assistant. Just a simple list of boxes to check in the right order. So I used Claude to read through the materials and produce a tight summary of the process and its steps. I reviewed it, then asked Claude to turn that summary into a checklist draft. I refined it. I’m using it now, and I’ll keep refining it as I go. ...

The last post left the engineering station with a one-line test: if the reasoning behind a decision would be useful to the engineer who touches this code in six months, write it down. That test tells you what deserves an entry, but it does not tell you how to recognize the moment, in the middle of a session, when you have crossed from accepting a suggestion into making a decision. Those are different skills, and the second one is a skill nobody ever had to develop before. ...

A few days ago I kicked off several research tasks in parallel and didn’t check which model was running underneath. All of them defaulted to Claude Opus 4.8. When I looked at the bill, I’d spent $350. So the question became obvious. Was the output better? No. I compared the results against similar research I’d run before on cheaper models. No meaningful difference in quality. I still had to verify every source and go deeper on half the areas myself. The expensive model just sounded more confident while doing it. ...

I ended the last post with a question: the next challenge is not building the Judgment Log. It is whether anyone writes in it once the deadline is two hours away. That question only has a useful answer if the artifact is light enough to actually use. So instead of arguing for it further, I want to show it. Take a fictional but familiar scenario. A checkout flow. A promotional window. A promo code validation feature built using AI-assisted development. It shipped. Three weeks later, it broke when the campaign introduced expired codes. In the post-mortem, nobody could answer the three questions that mattered: what did the PM cut and why, what did the designer choose between, and what did the engineer override. ...