The Lambo in the Garage: Why Your AI Stack Is Outpacing Your Thinking

Time from idea to first-draft video: under an hour. The same system also spins out podcast versions for promotional audio. The videos are rudimentary right now — useful for training, compliance, instructional content. Not yet polished enough for anything that needs real craft. But that gap is closing fast, and that’s not the interesting part anyway.

Here’s the interesting part: six months ago, this pipeline was not possible. Not at this fidelity, not for a solo practitioner, not in an hour of assembly. And yet, when I finished building it and sat back to look at what I had, the very next thing I did was plan a UX problem exactly the way I would have planned it in 2024.

That’s the thing I want to talk about.

The shovel and what it actually does

There’s an old idea from perceptual psychology called affordance theory. The term was coined by James Gibson in his 1966 book The Senses Considered as Perceptual Systems and formalized in his 1979 The Ecological Approach to Visual Perception. It got pulled into design by Don Norman’s The Psychology of Everyday Things a decade later.

An affordance is what a thing lets you do. Gibson’s definition: “what the environment offers the animal, what it provides or furnishes, either for good or ill.” The key move is that an object’s affordances are real whether or not any particular user notices them.

Take a shovel. A shovel is designed for one job — insert blade into material, scoop, swing, drop. That’s the intent. But a shovel affords more than that. Because it’s long, it affords reaching debris you don’t want to touch. Because it’s stout, it affords prying. Because it has a flat edge, it affords scraping ice. Because it has a sharp edge, it affords chopping roots. None of those uses are why someone designed the shovel. They’re all things a shovel does because of what it is.

Norman’s refinement added an important distinction: there are real affordances (what the thing actually enables) and perceived affordances (what the user recognizes it enables). The gap between those two is where most of our unused capability lives.

The AI tools you’re running today have real affordances that far exceed what any of us perceive them to enable. Your Claude session doesn’t know it’s supposed to stay in its lane. Your second brain doesn’t know that you built it for meeting recall instead of pattern synthesis. The Remotion pipeline I described doesn’t know I built it for training videos; it will render anything a script tells it to render. The tools are stupider than we are about their own limits. And they are also, in a meaningful way, ahead of us about their own possibilities.

The gap between the real affordances of your stack and the affordances you currently perceive — that’s the map of your unused return.

FORGE is a reader-supported publication. To receive new posts and support my work, consider becoming a free or paid subscriber.

Where my new thinking hasn’t been applied

I’ve gotten extremely fast at some parts of my work. I can move from a client idea to market research to a first-pass PRD inside of an hour. I’ve built that pipeline deliberately. I trust it. I use it.

And then I’ll turn around and plan the UX for that same project exactly the way I would have planned UX in 2024. I’ll sketch it. I’ll reach for a pattern I already know works. I won’t stop to ask whether the AI stack I just used to compress a week of research into sixty minutes could be used to generate five UX variants in an afternoon and test them against real usage data before I’ve committed to any of them. I know intellectually that it could. Under deadline pressure, I just reach for what I already trust.

Same thing with technical architecture. I default to the stack I know. I don’t run the AI-assisted evaluation across three alternative stacks that I absolutely could run in the time it takes me to write this paragraph.

The pattern is consistent. I apply new thinking to the glamorous parts of my work — the parts where the “look what I just built” feeling is strong. I don’t apply it to the parts where I already feel competent. The irony writes itself: the places I feel most competent are exactly the places where my thinking has aged the most.

If this sounds familiar, you’re not the only one. This isn’t a personal failing. There’s a name for it, and the research on it is decades old.

Why the people who’ve done the work feel this hardest

In 1942, Abraham Luchins ran a now-famous series of experiments called the water jar problems. Subjects were given a set of problems that all had the same solution — a specific sequence involving three jars of different sizes. After solving five of them, the subjects were given new problems where a much simpler solution was available. Most of them didn’t see it. They kept applying the long method. When Luchins eventually told them “don’t be blind,” more than half of them finally switched.

The name for what they were doing is the Einstellung effect — from the German for “setting” or “attitude.” Once a way of solving a problem becomes practiced, it shows up in your thinking before any alternative does. You stop seeing other paths. Not because they’re invisible — because your mind reaches for the familiar one first and never gets to the comparison.

In 2008, researchers Bilalić, McLeod, and Gobet ran eye-tracking studies with expert chess players. When shown a position where both a familiar winning move and a better novel move were available, the experts’ eyes literally tracked toward the familiar move. They reported considering both. The eye-tracking data showed they weren’t.

The Einstellung effect is not a novice problem. It affects experts more than beginners, because experts have deeper grooves. The thing that makes you good at your craft — the pattern library, the trained intuition, the “I know how this goes” — is the exact thing that blocks you from seeing a better move.

There’s a companion finding from economics. Samuelson and Zeckhauser’s 1988 paper on status quo bias studied people making real decisions about health plans and retirement portfolios. Across a range of conditions, people stuck with the current default at rates that couldn’t be explained by switching cost, information gaps, or risk preference. The pull of the familiar option was simply strong. Even when a better alternative was explicitly offered.

Combine these two effects and you get the pattern I named a minute ago. You’re good at what you do. You have trained methods for every stage of your work. Your stack has expanded dramatically in the last year. But your methods for the stages where you already feel competent are pulling you toward the 2024 version of the work — and they’re pulling harder the better you are at those methods.

This is why the people farthest ahead on the tool adoption curve are often the ones feeling the least return. You built the tools. You set up the memory. You built the jigs and automated the handoffs. And then, under the pressure of actual work, you reached for what you already trusted. And your tools came along for the ride without changing what you asked of them.

Comfort is the tell. The parts of your workflow that feel most settled are the parts where the Einstellung is strongest. If you want to find where your thinking has aged, look for where you feel fine.

One caveat: comfort isn’t always the problem

Some of your settled workflow is genuinely optimized. Not every method you’re comfortable with is a cowpath. Some of them have earned their place through real iteration, and swapping them out would be change for its own sake.

Here’s the test that separates the two. If you can explain why your current method is the best one — specifically, if you’ve compared it to alternatives recently and can articulate what each alternative would cost — you’re looking at optimization. Leave it alone. If you can’t, and you’re defending it with “it’s how we’ve always done it” or “it works fine,” you’re looking at Einstellung.

The diagnostic is the comparison, not the age of the method. A ten-year-old method that you can defend on current terms is still the right one. A six-month-old method you’ve never questioned is still a groove.

Don’t pave the cowpath

In 1990, Michael Hammer wrote an essay for Harvard Business Review titled Reengineering Work: Don’t Automate, Obliterate. The most-quoted line in the piece is this: “It is time to stop paving the cow paths. Instead of embedding outdated processes in silicon and software, we should obliterate them and start over.”

Hammer was writing about enterprise IT in 1990. But the line has aged into something more like a diagnosis for the AI era. Most AI adoption right now is cowpath-paving. Same workflow, faster execution. Same artifact, produced in less time. Same meeting, summarized automatically. Same research, synthesized by a chatbot. The work itself is the shape it was before; the AI just compresses the time.

That’s useful. I’m not dismissing it. Compression is real value. But it is not the value the tools are actually capable of.

Shoshana Zuboff, in her 1988 book In the Age of the Smart Machine, drew a distinction that matters here. She separated automating (using technology to do the existing work with less human effort) from informating (using technology to generate new information, new visibility, and new kinds of work that weren’t possible before). Zuboff’s research — a decade of field studies across multiple industries — found that organizations consistently reached for automation and underinvested in informating. The automation produced modest gains. The informating, where it happened, produced different work entirely.

Forty years later, the pattern is on exact repeat. The AI content you read most of is about automation. “Save three hours a week.” “Automate this workflow.” “Draft this email faster.” All useful. All cowpath-paving.

The practitioners pulling away right now are the ones asking a different question at every stage of their work: what becomes possible that wasn’t possible before? Not “how do I do this faster” but “what is the new form of this?” They’re generating UX variants and testing them against simulated users. They’re running research across five tiers of depth simultaneously and letting the results shape the synthesis. They’re querying months of accumulated client context to surface patterns that couldn’t have surfaced otherwise. None of this is about doing old work faster. It’s about doing work that didn’t exist.

Here’s the test I’ve been applying to my own workflow, borrowed almost directly from Hammer: if I didn’t have the old process, would I design it this way from scratch? If the answer is no, the thing to redesign is the process, not just the tool I’m using inside it.

McKinsey’s State of AI in 2025 found that while AI adoption is now nearly universal in large organizations, the share seeing meaningful business-level impact is a small minority. An executive quoted in McKinsey’s State of Organizations 2026 puts the imbalance bluntly: “for every $1 spent on technology, $5 should be spent on people.” The gap between adoption and impact is not a tool gap. It’s a thinking gap. It is the distance between automating and informating, between paving and redesigning, between how do I do this faster and what is newly possible.

This scales from solo practice to teams

I’ve written this as a diagnosis for solo practitioners because that’s where I can speak with the most authority. But the same pattern applies to teams, and the symptoms are actually louder there.

On a team, the Einstellung effect shows up as “that’s how we do it here.” It shows up as the senior person with the most authority being the slowest to try the new method, because their grooves are the deepest. It shows up as experienced pairs moving more slowly on AI pilots than mixed pairs of senior and junior staff — which is something I’ve heard consistently from operators running these pilots. The newer team member isn’t an apprentice in that configuration; they’re the outside voice the senior member’s grooves can’t provide.

If you’re running a team through this, the audit question scales cleanly. Ask each person to name three parts of their work they haven’t reconsidered in six months. Compare what comes back. The overlapping parts are the team’s cowpaths. Those are the ones worth going after first.

The despair cycle applies to thinking, too

I’ve written before about a pattern I notice in anything worth learning. There’s an excitement phase, then a despair phase, then a hope phase, then a joy phase. Every meaningful skill I’ve picked up — spoon carving, Django, spec-driven development, running a team — has put me through that cycle. The despair phase is where the learning actually happens. The people who skip it don’t grow; they just get frustrated and quit.

I think bias-breaking is a despair-cycle problem, and I don’t see people talking about it that way.

When you switch from a method you’ve practiced for years to a method you’ve never used, your output gets worse before it gets better. That’s not a sign you picked the wrong method. That’s the groove in your thinking reasserting itself. The Bilalić eye-tracking finding applies here directly: your expertise is built on patterns that work, and abandoning those patterns means abandoning fluency. Temporarily. The fluency returns, deeper, on the other side — but only if you stay through the dip.

Most people don’t. They switch to the new method, feel the performance drop, and retreat to the old one under deadline pressure. Which is a completely rational response in any single instance and a compounding disaster across a career.

The fix isn’t willpower. It’s structure. Here’s what’s working for me:

Pick one stage. Not your whole workflow. Not three parts at once. One stage of your work that feels settled.

Apply the affordance question. What does my stack actually enable here that I haven’t asked it to do? Write down three possibilities. Don’t evaluate them yet — just write them down.

Run the new method twice. Not once. Twice. The first pass will produce worse output than your settled method. That’s expected. The second pass is where you start to see what the new method is actually good at.

Hold the comparison honestly. Not “which felt better” — that question loads for comfort every time. Ask: which produced the work I would have wanted a month from now if I could see the future?

Decide after the comparison, not before. Sometimes the old method wins fairly. Sometimes it wins because you didn’t give the new method long enough. Separating those two is what the twice-through forces.

Move to the next stage only after the first stage has stuck for a month. Compounding the dip is how change stalls. One stage at a time is how it sticks.

The audit

Here’s the thing I want to leave you with. Not an exhortation — a question you can answer this afternoon.

Name the three parts of your workflow you haven’t reconsidered in the last six months.

Write them down. Those are the places your thinking has aged the most. Those are your cowpaths. Those are where the Lamborghini sits unused in the garage while you take the beetle out for another drive.

If you want a second question: pick one of those three. Ask what your current AI stack would do with that part of the work if you stopped treating it as settled. Not how it would do the existing version faster — what it would generate that the existing version never did.

The answer might be nothing. The old method might genuinely still be best. But I’d bet, looking at my own list, that it won’t be nothing in at least one case. And one case compounds.

The tools are ahead of us. The capability keeps widening. The bottleneck has moved, and it isn’t where we expected it to be. It’s in the parts of our thinking we never put up for review because they were working fine.

Comfort is the tell. Go audit yours.