On tinkering

The best way to get better at building is to build.

This sounds obvious. It's not. Most people who want to build things spend their time preparing to build instead of building. They read about product management. They take courses on system design. They follow builders on Twitter and bookmark threads they'll never revisit.

Preparing feels like progress. It isn't.

The tinkering gap

There's a gap between understanding how something works and being able to make it. You can read every book on woodworking and still not be able to build a chair. You can memorize API documentation and still freeze when you open a blank file.

The gap closes only one way: by making things.

I call this tinkering—the act of building something small, often imperfect, just to see if you can. Not to ship. Not to impress. Just to learn by doing.

The best builders I know are compulsive tinkerers. They have graveyards of half-finished projects, abandoned prototypes, weekend experiments that never saw the light of day. This looks like failure. It's actually training data.

Why PMs don't tinker

Product managers have a specific version of this problem. We're trained to think in abstractions—user needs, market dynamics, roadmap prioritization. We get good at describing what should exist without ever making it exist ourselves.

This creates a dangerous gap. You can spec a feature without understanding what makes it hard to build. You can prioritize a roadmap without feeling the weight of technical debt. You can talk about trade-offs without having made them yourself.

The best PMs I've worked with could build the thing they were speccing. Not perfectly. Not production-ready. But well enough to understand the problem space from the inside.

LLMs changed the economics

Here's what's different now: the cost of tinkering collapsed.

Two years ago, if you wanted to build a prototype, you needed to know how to code. Or you needed to find someone who did. Or you needed to spend weeks learning enough to be dangerous. The activation energy was high. Most people never cleared it.

LLMs removed that barrier.

I'm not talking about generating boilerplate or autocompleting functions. I'm talking about something more fundamental: the ability to have a conversation with an intelligence that can translate intent into implementation.

"I want a Chrome extension that does X" becomes a working extension in an afternoon. "Can we try Y instead?" becomes an immediate experiment. The feedback loop that used to take days now takes minutes.

This matters more than most people realize.

The new feedback loop

Learning happens in feedback loops. You try something. You see what happens. You adjust. The tighter the loop, the faster you learn.

Before LLMs, the loop for building software was: idea → research → learn prerequisites → attempt → fail → debug → research more → attempt again. The time between "I wonder if this would work" and "I know if this works" could be weeks.

Now the loop is: idea → describe to LLM → see result → adjust → see result → adjust. The time collapses to hours. Sometimes minutes.

This isn't cheating. It's the same acceleration that happened when we got compilers, then high-level languages, then frameworks. Each layer of abstraction let us think at a higher level. LLMs are just the next layer.

The people who will be most transformed aren't engineers—they already knew how to build. It's everyone else. The PMs who always wanted to prototype their own ideas. The designers who wanted to see if their mockups actually worked. The founders who wanted to validate before hiring.

The barrier was never capability. It was friction. The friction is gone.

How to start

If you're convinced but don't know where to begin, here's what I'd suggest:

Pick something small and personally useful. Not a startup idea. Not something to impress anyone. Something you actually want to exist. A script that automates an annoying task. A simple tool that scratches your own itch. The motivation needs to be intrinsic because you'll hit walls.

Use the LLM as a collaborator, not a vending machine. Don't just ask for code. Ask why it suggested that approach. Ask what the trade-offs are. Ask how you'd modify it to do something slightly different. The learning happens in the conversation, not the output.

Ship something, even if it's embarrassing. The goal isn't perfection. It's closing the loop between idea and artifact. A janky prototype you actually use teaches you more than a polished tutorial you completed.

Do it again. And again. The first project teaches you that you can build. The fifth teaches you what you like building. The twentieth teaches you what you're good at building.

Tinkering is how you get reps

There's a reason taste is accumulated reps. You can't develop intuition for what works without making a lot of things that don't. Every abandoned prototype, every "good enough" v1, every decision about whether to add that feature or kill it—these are the reps.

Tinkering is the mechanism. It's how you put in the reps without needing a job that demands them.

And when you tinker consistently, something interesting happens. The reps compound. Project three builds on what you learned in project two. Your intuition sharpens. You start to feel when something is off before you can articulate why.

This is what taste actually is: pattern recognition built from exposure. Tinkering is how you get that exposure on your own terms.

The real unlock

Here's what I've found after building several projects this way: the skill you're developing isn't coding. It's the ability to translate fuzzy ideas into concrete artifacts.

That skill transfers everywhere.

When I spec a feature now, I think about it differently because I've felt what it's like to implement a spec. When I evaluate technical trade-offs, I have intuition because I've made those trade-offs myself. When I talk to engineers, I ask better questions because I've been stuck on the same problems.

This is what tinkering gives you. Not the ability to replace engineers, but the ability to work with them as a peer. Not expertise in implementation, but fluency in it.

The excuse is gone

For years, "I'm not technical" was a reasonable explanation for why someone couldn't build things. Learning to code was a significant investment. Not everyone had the time or inclination.

That excuse is gone.

If you want to get better at building, you can now just... build. The LLM will help you through the parts you don't know. You'll learn those parts as you go. The feedback loop will be fast enough to keep you engaged.

The only thing stopping you is the belief that you need permission. You don't. Open a blank file. Describe what you want to make. See what happens.

The best way to get better at building is to build.

Start.