Testing

Put the Tip List Down for a Moment I began this article as a collection of Boris Cherny’s Claude Code habits. That version had a problem: social posts age with models and product releases, while fan-maintained collections tend to mix personal advice, previews, and impressive-looking statistics. A sharp opinion can become a historical footnote before the article reaches its readers. So I took the slower route. Product claims in this revision come from Anthropic or the official Claude Code documentation. Untraceable numbers, second-hand quotations, and claims of universal superiority are gone. Boris’s way of working remains an inspiration, but it is not treated as a specification. ...

Why Does Getting Better at This Make Me More Tired? Let me start with a strange thing I banged my head against for a long time before I understood it. When I first started using Claude Code, the productivity gain was visible to the naked eye: an afternoon’s work covered what used to take two days. Once I got fluent, the gains kept coming — but so did the exhaustion at the end of each day. Because I was doing the same thing all day long: watch it finish, judge whether it’s right, think about what to say next, hit enter again. ...

This is part two of “The Super Individual’s Gear Stack.” If you haven’t read the overview , start there — every judgment in this piece rests on the yardstick that essay proposed: does an advance in a layer of gear help only you, or does it help all of your competitors at the same time? ...

Suppose you actually have one now — an agent that takes a job end to end. Pulls the data, writes the code, runs the tests, opens the PR, updates the docs. It doesn’t need you feeding it prompts line by line. You hand it the task at night and go to sleep. The real question isn’t whether it finishes. In coding, research, and content workflows, model capability is often already sufficient to produce a plausible result. That does not mean capability has stopped mattering everywhere: in unfamiliar domains and genuinely novel tasks, it can still be the limiting factor. But once an agent is capable enough to act, a different bottleneck appears — ...

“It Runs” Is Not a Reliability Standard Most personal AI workflows begin with one acceptance test: did it produce something? A draft appears, a patch compiles, ten pages become one, and the task feels finished. After enough repetitions, however, the costly failures are rarely dramatic. They arrive quietly: a polished paragraph built on a stale source, a tool call that never completed, a plausible plan that solved the wrong problem. ...

Test-driven development is easy to explain when the function under test adds two numbers. Write a failing test, make it pass, then improve the implementation without changing its behavior. The difficulty begins when the function calls a language model and five different answers may all be acceptable. That does not make TDD obsolete. It means the word test has to become more precise. For an AI application, I use TDD as a discipline for discovering contracts. Some contracts are exact: a parser must reject malformed JSON, an authorization check must not leak another tenant’s data, and a tool call must match its schema. Other contracts are statistical: a support assistant should resolve most routine cases, cite the supplied policy, and rarely invent a refund rule. The first group belongs in ordinary tests. The second belongs in evaluations and monitoring. ...

Independent development creates a seductive illusion: once the stack is chosen, the product is halfway built. I used to make long lists—frontend framework, database, authentication, payments, email, analytics, monitoring. The more complete the list looked, the safer I felt. But that safety came from the feeling of construction, not from evidence that anyone needed the thing. My rule is simpler now: the scarce resource for an independent developer is not code. It is the ability to place limited attention on the right problem. A stack should help you move cheaply, learn quickly, and reverse a decision while the evidence is still thin. ...

Introduction: Do Not Learn the Model from the Chat Window The first encounter with a large language model creates a powerful illusion. Something on the other side of the screen appears to have read widely, reasoned carefully, and chosen to explain itself. It can write code, summarize papers, preserve a tone across a conversation, and offer a polished rationale for an answer that is completely wrong. The chat window shows behavior, not mechanism. Fluency hides missing evidence. Completeness hides uncertainty. A human voice invites us to overestimate how firmly the model is connected to the world. ...

In March 2024, this page was a long collection of Sora prompts. It belonged to the brief season when a research preview could become a small open-source movement before most people had touched the product. We copied examples, named camera movements, and tried to infer a grammar from a handful of remarkable clips. That guide can no longer honestly call itself a guide to “mastering Sora.” The Sora web and app experiences closed on April 26, 2026. OpenAI says its Sora API will be discontinued on September 24, 2026. A page that still teaches Sora as a growing platform would turn search traffic into misinformation. ...