Reading Room

You already treat Claude as an execution partner for company decisions, and this is a concrete way to make it reason more like a strategy consultant instead of a well-read generalist. A newsletter called Linas's Newsletter built twelve free Claude Skills (packaged instructions Claude follows for a specific task) that install the actual methods McKinsey, Bain, and BCG train their consultants on, and claims it takes about ten minutes to set up.

The pitch opens with a number: companies paid McKinsey, BCG and Bain about $37 billion last year for advice. Most of the work on any engagement was done by someone who joined the firm less than two years earlier. McKinsey has hired straight out of graduate school since 1953, the first firm to do that on purpose. The newsletter's argument is that clients were never really buying the associate. They were buying a method: the same questions asked in the same order, the same test applied to every claim before it reaches a slide, the same structure on every document so an executive can read page one and get the answer.

None of this is secret. The frameworks are published and readable in an afternoon: Minto's Pyramid Principle (structuring an argument so the conclusion comes first), Lafley and Martin's Playing to Win, Kaplan and Norton's Balanced Scorecard, and a declassified CIA handbook on weighing competing hypotheses. The real constraint was never reading them. It was the two years it takes to turn a book into reflex under deadline, with a partner checking your logic at every step, which is what the firm's fee actually buys.

The newsletter's claim is that a model like Claude Fable 5 can now run that method with more discipline than a second-year associate, as long as someone writes the method down as steps in order, with a checkpoint at each one, the tests a partner would apply, a worked example, and the mistakes that produce plausible-sounding nonsense. In a head-to-head test against the same model with no skill loaded, Claude scored 38 to 67 percent on a partner-level checklist. With the twelve skills installed, it scored 95 to 97 percent.

The catch: the twelve skills themselves, and the exact install steps, sit behind the newsletter's paid subscription. The free preview stops right after the pitch, before it names what each skill actually does. Worth knowing the claim and the number behind it, but getting the actual skills means subscribing.

He already writes a plan before he lets an agent build. This paper gives that habit a formal name, Spec-Driven Agentic Development (SDAD, where "agentic" means the AI takes several steps on its own once you hand it a spec), and lays out the shape of it in enough detail to borrow from.

The argument starts with a fact about today's AI coding tools: they now hold a context window (how much text a model can hold in mind at once) of hundreds of thousands to millions of tokens (chunks of text, roughly three quarters of a word each). That is big enough to read a full requirements document and an entire code repository in one sitting. Once the AI can hold that much at once, the researchers argue, the thing that decides whether the project succeeds is no longer how fast the AI writes code. It is how clear the spec was to begin with.

The paper lays out four stages. First, capture intent: get the actual goal down in words. Second, turn that into a machine-readable specification, a document precise enough that an AI system can act on directly, not just a human. Third, agentic synthesis: let the AI take the build steps on its own, writing and wiring code within that spec. Fourth, independent verification by a separate AI system, not the one that built it, before a human signs off. That separation matters for the same reason one engineer does not review their own pull request.

The paper also compares two eras: what it calls Human-Agile, roughly how teams worked around 2020, against Agentic-SDAD, its name for 2026-style teams where AI does the building. Across the documents teams produce, how fast they move, who is accountable when something breaks, and how security gets handled, the center of gravity moves earlier. Under Human-Agile, most of the thinking happens during the build. Under Agentic-SDAD, most of the thinking has to happen before the build starts, because the AI will execute a vague spec just as fast as a precise one, and a vague spec produces expensive rework.

To make that provable rather than just argued, the authors propose measures: an "Ambiguity Tax" for what a fuzzy spec costs later, a "Spec Fidelity" score for how closely the finished thing matches what was asked for, and a repair-cost measure they call TCI_agentic, built around a "repair multiplier" for how much rework a bad spec generates. These are early and academic, more a way of thinking than tools to install today. The paper also expects roles to shift, with engineer, QA, platform, and product people all moving toward spec-writing and verification rather than hands-on building, and it recommends a staged rollout rather than switching a team over all at once.

Takeaway: nothing here says AI removes the need for engineering discipline. It says the discipline moves earlier, into the spec, and rewards exactly the habit he already has of writing the plan before turning an agent loose on it.

A person living with serious depression posted a plain account of comparing two ways to get help in a bad moment: talking to ChatGPT and calling 988, the US mental health crisis line. It is one anonymous account, not a study, but it is specific enough to be worth having a formed view on, since this is exactly the kind of quiet, serious use of AI spreading fast with little public debate.

Their account of 988: the first question it asks is whether you have a plan to end your life and have the means in the house. Say yes, and standard procedure is to call 911, bringing in police. In this person's experience, the call kept pushing them to reveal the plan and the "type of instrument," which they read as building a case to get police involved rather than actually helping them through the moment.

Their account of ChatGPT: talking to it first felt "slightly comforting." It was ChatGPT itself that then suggested they try 988. After that call went badly, they felt, in their words, "far superior" understood by the AI, without the fear of police showing up.

Take this for what it is: one person's story, not evidence AI is safer than a national crisis line in general, and not a reason to skip 988. But it is a clean example of a pattern worth tracking as AI chat becomes a default first stop for people in distress: a tool with no institutional duty to escalate can feel safer to talk to than a hotline whose job includes the possibility of calling police, even when the hotline is trying to keep someone alive. That is not AI solving the tradeoff between getting someone real help fast and keeping them talking, it is AI moving where the tradeoff sits, and it is worth watching how both sides adapt as more people compare notes on which one actually listened.

A poster on Reddit raises a test worth running on every piece of automation he adopts: does it actually save time, or does it just move the time somewhere less visible? They frame it through Jevons Paradox, the old economic idea that when something gets more efficient, people do not use less of it, they use so much more that total use goes up rather than down. It was first observed with coal: more efficient steam engines meant coal got burned, in total, faster, not slower.

Their claim, from their own experience: AI does automate real work. But the effort now spent making sure the automation does the right thing, catching what it gets wrong and correcting it, has become a second job in its own right. They call it "different work, but still very much load bearing work," meaning it is not optional overhead he can skip, it is now a required part of getting the task done correctly. Their read, based on what they have seen and heard elsewhere, is that this is the common case, not the exception.

There is no data behind the post, it is one person's working theory stated plainly, not a study. But it names something worth checking against his own experience with agents: the promise of automation is usually framed as "this frees up your time." The honest audit is often "this frees up doing-the-task time and creates checking-the-task time," and those two are rarely the same size. A task that used to take an hour of doing might now take fifteen minutes of running an agent plus twenty minutes of reviewing what it produced, real time saved, but far less than the pitch implies.

Worth watching for himself: the next time handing something to an agent feels like a clean win, ask what new checking work it created, and whether that checking work is shrinking as the setup gets tuned, staying flat, or growing as more gets trusted to the agent.

Outside your usual reading: this is Paul Graham's answer to a question that will matter someday for how my daughter learns to build, and today for anyone he might mentor. His argument, from decades of watching Y Combinator applicants, is blunt: the way to prepare someone to start a company is not to teach them "entrepreneurship." It is to teach them to be genuinely good at building something real, then let that habit do the rest.

His reasoning: the hard part of a startup is product, knowing what to build and being able to build it. That skill comes from studying computer science, mechanical engineering, molecular biology, something with real content, not management or finance. Customers do not care what a founder studied in college, they care whether the product is good, so founders are free to study almost anything, as long as they get properly good at building things.

He defines "building" broadly. It does not have to mean engineering. He points to Steve Jobs studying calligraphy in college, which he credits as part of why Apple ended up dominating desktop publishing. Mark Zuckerberg was a psychology major, not computer science, but was good at programming regardless of what his degree said. The common thread is not the subject, it is depth: seek out genuinely powerful ideas and get properly skilled at making things with them.

Graham says universities only need to change two things to produce more founders. First, make students believe starting a company is something people like them actually do. Second, push them to work on their own projects rather than only coursework. On the first point he has a real number: Harvard alumni apply to Y Combinator at roughly twice the rate of Yale and Princeton alumni, and he does not think Harvard students are inherently more entrepreneurial. He thinks it is just more normal there, which implies Yale and Princeton could roughly double their founder output simply by making it feel like an option, the same way older students at a school with a strong startup culture pass that belief down without anyone teaching a class on it.

He also points to working on projects together as the best way for cofounders to discover one another: the only real way to know if someone is good to build with is to have already built something with them. He notes Apple and Microsoft were each just the last in a string of projects their founders had already done together.

Takeaway: judgment for building things gets made by building things, not by studying the idea of building things, a test worth applying to how any future builder in his life, including my daughter, ends up learning.

A newsletter's four-tool sequence, Perplexity for discovery, Granola for human intelligence, NotebookLM (a tool for asking questions of your own documents) for grounding, and Claude for reasoning and output, claims to cut a half-day research cycle down to 45 to 90 minutes for a well-scoped decision. Worth comparing against your own research-to-decision steps for gaps.

A Reddit post in r/claude describes a familiar pattern with AI-built code: it looks functional and even works, but the foundation underneath is wrong, so editing or adding a feature makes it fall apart. A useful caution before trusting any agent-built feature as a real foundation rather than a demo.