A Bitter Lesson in Finding Needles

I spend most of my weekends on the streets of Hoboken with my daughter, Arabelle, who's nearly 2. While she and I work hard on learning to scooter, we see tons of other toddlers on balance bikes scooting by. It's a bit of an odd sight for me because I never saw a balance bike growing up. I learned how to ride a bike with training wheels. But somewhere along the way, training wheels seemingly became obsolete.

Perhaps this is for the better. I remember numerous times when I'd try to take a fast turn with the training wheels, and the bike would tip outwards. At the time, I didn't know, and had no way of knowing, that you have to lean into a turn and that a bike is designed to lean with you. With training wheels, though, the bike can't lean, so it forces you to crank the handlebars while sitting bolt upright, which teaches entirely the wrong habit.

A balance bike has no pedals. The kids sit on it and push along with their feet. At first, it almost feels like less progress, because they're scooting, not really riding. But they're actually learning the hard part, which is balance, and adding pedals afterward is easy.

As those kids glided past us on a Saturday morning, something clicked. I guess years of building products and absorbing user critiques have left me with a mild case of chronic overthinking, where I pattern-match back to work even on a nice, crisp fall day.

What if we've reached the point where AI models are starting to ditch their training wheels?

Training Wheels for Models

In October 2025, Anthropic introduced Agent Skills, and for a few weeks it felt like everyone I followed was writing and promoting them. A skill is essentially a folder of instructions that teaches Claude how to do a specific task the way you want it done. At its core is a single Markdown file, SKILL.md, with a short name and description at the top and the actual instructions underneath, plus any scripts or reference files the task needs.

Claude only reads the name and description up front and pulls in the rest when a request looks like a match, so you can install dozens of skills without stuffing all of them into the model's context at once.

Here's roughly what one looks like, a skill that turns Claude into the most brutal and satirical cross-functional partner you've ever had:

---
name: roast-my-prd
description: Use when the user shares a PRD, spec, or strategy doc and asks for feedback.
---

# Roast My PRD

You are a skeptical VP of Engineering who has watched 1,000 PRDs fail. You are NOT here to be nice.

ALWAYS follow these rules:

1. NEVER open with a compliment.
2. Find exactly 3 reasons this project will fail, ranked by severity.
3. For every metric in the doc, ask "How will you actually measure that?"
4. If the doc never names a real user, STOP and call that out before anything else.
5. Somewhere along the way, question why we are even reading PRDs.
6. End with the one question the author is most afraid to answer.

Training wheels feel great...almost magical. For the models of late 2025, like Opus 4.5 or GPT-5.1, those capital letters and the numbered list held the model upright on a task it would otherwise wobble through. In this case, it turned an over-eager, here-to-please tone into a dry, hard-nosed Teams message no one wants to read, all in the same afternoon I loaded the skill.

But as we already know, the hand-written rules, routing instructions, and long prompts we bolted onto models to cover their weak spots are being phased out with each new generation, and along the way they've ingrained in us the bad habit of trying to pack our own worldview into these models.

Anthropic said as much in its prompting guide for Claude Fable 5, warning that skills written for earlier models are "often too prescriptive for Claude Fable 5 and can degrade output quality." Its advice is to review those older instructions and remove the ones the model no longer needs, which is a polite way of saying it's time to take the training wheels off. The guide even notes that Fable 5 does a good job of updating skills on its own as it works.

None of this would have surprised Richard Sutton, who wrote about why packing our own worldview into AI keeps losing in a short but now-famous 2019 essay called The Bitter Lesson. His argument is that building our own understanding of a problem into AI feels like progress at first, but over the long run it gets beaten by simpler methods that just use more compute.

If you haven't come across him before, Sutton is one of the founding figures of reinforcement learning, the trial-and-error technique behind AlphaGo and a big part of how today's models learn to reason. In 2025, he and Andrew Barto received the Turing Award for that work, the closest thing computer science has to a Nobel Prize.

Seventy Years of the Same Mistake

More specifically, Sutton says the biggest lesson from roughly 70 years of AI research is that general methods that scale with computation end up beating methods built on human knowledge, and usually by a wide margin. The two general methods he names are search and learning, and both keep winning over hand-built human knowledge because they get better as computers get faster, while what we build goes stale rather quickly.

The difference between the two comes down to when the computer does its work. Learning happens ahead of time, where a system studies huge amounts of data or experience and works out the patterns for itself, the way AlphaGo played countless games against itself or a large language model reads a big chunk of the internet during pretraining.

On the other hand, search happens in the moment, where a system takes the problem in front of it and explores possible answers before committing to one, the way Deep Blue looked at millions of chess positions before every move.

The pattern makes sense when you look at how a strong human chess player thinks, because they do the exact same thing. Magnus Carlsen has built intuition from thousands of games played, and he's always calculating a few moves ahead at the board. And Magnus is uniquely himself because his success was built on his personal experience, not borrowed from anyone else. For decades, researchers tried to hand machines codified human knowledge directly instead of letting them build it on their own.

What makes the lesson bitter is that it runs against our very own intuition and, dare I say, sentience. Researchers look at a hard problem, notice how they themselves solve it, and love building the same journey into the system. The habit sticks because the model seems to learn quickly in the short term, and, more importantly, it's personally satisfying to the researcher. Then, all of a sudden, progress plateaus, and the knowledge that helped early on starts to get in the way.

Sutton walks through a few examples:

1. Chess, where Deep Blue beat Garry Kasparov in 1997 with massive, deep search, to the dismay of researchers who had spent years encoding how grandmasters think about the board.
2. Go, where humans lost again about 20 years later, this time against search plus learning through self-play.
3. Speech recognition, where statistical methods beat systems built on human knowledge of words, phonemes, and the vocal tract.
4. Computer vision, where hand-designed features like edge detectors gave way to convolutional neural networks that learned their own. If that sounds familiar, it's the same edge detection Ben Affleck went viral explaining last month.

None of this comes down to a lack of intelligence on anyone's part. Smart people keep making the mistake because building in what we know feels like progress. If you've read any of my faith writing, this will sound familiar. Humans are remarkably consistent at repeating the same mistakes, even when we can see them coming, and AI researchers are no exception.

Search Scales Surprisingly Well

Of Sutton's two methods, learning gets most of the attention right now, since that's where the frontier labs spend their capex. Search gets significantly less airtime, and I believe it deserves way more, especially for those of us building products on top of models rather than training them.

Search, in Sutton's sense, is any method that gets better results by spending more computation exploring options at the moment of the decision. Deep Blue didn't know more about chess than Kasparov did, but it looked at far more positions than he ever could.

As a PM, that matters to me because search is something a product team can actually design for. We don't control how the next model is trained, but we do control what it can look through, how many times it can try, and how it knows when it has found the right thing.

As models get better, a good search primitive only gets more valuable. A classic example I have reached for lately is grep, the command-line tool for finding text in files, which Ken Thompson wrote in the early 1970s. It has barely changed in 50 years, yet it's now one of the most important tools a coding agent has, because the model on the other end keeps getting better at deciding what to look for. In a lot of ways, grep is about as close to a balance bike as software gets. It does one simple thing, and all the skill comes from whoever is riding it.

Hand-built intent classifiers, keyword rules, and brittle routing logic are exactly the kind of human knowledge Sutton warns about, and they tend to age badly with every model release. A clean, fast, well-permissioned index that a model can query over and over is the kind of thing that gets better with every release, because a smarter model asks better questions of it.

I believe this is also where skills are headed. The ALL-CAPS rules in my roast-my-prd skill are training wheels, and I expect each new model to need fewer of them. The part of a skill that lasts is the part that already works like search, where the model reads a short description, decides whether it's relevant, and pulls in the reference files only when it needs them.

Over time, I expect the instructions to shrink and the library of context a model can look up to grow, until a skill looks a lot less like a set of rules and a lot more like a library the model searches on its own.

Agents That Search in Loops

I want to expound a bit more on what I said above about grep being critical for coding agents to find their way around a codebase. Boris Cherny, who created Claude Code, has talked publicly about how early versions leaned on the standard retrieval-augmented generation (RAG) setup, where code is chunked, embedded, and stored in a vector database ahead of time. The team found that letting the agent just search for itself, running grep and glob, reading files, and refining what it looked for next, worked better.

In the RAG setup, a person decides in advance how the codebase should be chunked and which pieces belong together, and the model is handed whatever comes back from a single lookup. This upfront guess, hard-coded in, is exactly the kind of hand-built knowledge Sutton warns about.

The agentic search loop running on CLI tools makes no such guess. It issues a query, reads what comes back, notices what's missing, and tries again, spending more compute at the moment of the question instead of relying on structure we baked in beforehand. As the model gets smarter, each turn of the loop gets sharper, while the pre-chunked index falls farther behind because it only knows what we told it the day we built it.

I see the same thing in my own work with Claude Code and Codex. When I asked Claude Code how Honcho, an open-source memory library, separates memory from context, it didn't answer from what it already knew. It went and read the storage code, and came back with an answer that was more precise than Honcho's own marketing, which uses "memory" loosely for everything. When I followed up and asked whether it used graphs, it went back into the code and searched again instead of guessing.

The loop is slower and costs more tokens per question, and in most cases I've stopped caring, because I trust that the answer is actually right.

Global Search for Payments

Which brings me to some news. After a year of telling anyone who'd listen that search is underrated, I've been handed the search team at work, so now I have to prove it.

For context, my team has been bringing conversational agents to Fortune 100 treasury teams in J.P. Morgan Access. Now global search across payments sits with us as well. Global search lets a user type one term and look across 5 areas at once: payments and receipts, posted transactions, accounts, inquiries, and payment templates. It covers wires, ACH, real-time payments (RTP), and book transfers, and it runs globally, with restricted bank data for India and Saudi Arabia kept in-region.

I believe this combination positions our team in a pretty unique way. Most teams building agents have to bolt search on from the outside, through whatever APIs another team exposes, on that team's roadmap. Most search teams, in turn, are optimizing for a human typing into a box. We now own both the agent that asks the questions and the search surface that answers them, which means we can shape the index for an agent that searches in loops instead of a person who searches once.

In Trust Is the Rail, I described our payment search agent as starting out as a declarative state machine rather than a reasoning loop, and I still believe an agent that touches payments needs firm limits on what it can do. That said, I have no interest in relearning the bitter lesson ourselves, or in teaching our agents the kind of habits that are hard to unlearn once the training wheels come off. Next year, we want to give our agents a fast, user-delegate-entitled, auditable search primitive they can call as many times as they need.

The loop does the exploring while the systems of record still hold the truth, and as I wrote in Seeing Is Believing, the user still lands on the page in Access where that truth lives.

What's going to be the hill we climb? Every extra turn of the loop adds latency and cost, and a treasurer waiting on a payment status isn't going to admire our architecture while a spinner runs.

Every query has to respect entitlements at the record level, so an agent searching 5 times has to be just as tightly scoped as a person searching once. And we'll need evals that measure whether the loop actually found the right payment, not just whether it returned something plausible.

Betting on the Lesson This Time

If Sutton is right, and 70 years of evidence says he probably is, every piece of the roadmap needs to be scoped so that it gets better as models do. For our search team, I believe that means fewer clever rules about what a user meant and more investment in the boring parts, like freshness, coverage across payment types, entitlement-aware retrieval, and fast responses that an agent can afford to call again and again.

I'm grateful for the chance to take this on, and for a team that's already full of people who think this way. If building search for agents that work with real money sounds like a fun problem to you, we're hiring! You can check out the role here or reach out to me directly.