I shipped Xenia’s entire guidebook module in 4 weeks with AI assistance. It was also completely wrong. Here’s how I learned the difference between fast and fast-in-the-wrong-direction.
Six months in, I was convinced my problem was speed. Not the product. Not the market fit. Speed.
If I could just code faster, ship faster, iterate faster, everything would fall into place. That’s how it worked, right?
Enter Claude.
I could prompt a feature spec and get working code in 20 minutes. A guidebook module for STR hosts; Four weeks. Tests included. Integrated. Done. I was moving at a pace I’d never experienced.
I felt like a genius.
I was actually the opposite.
Here’s the thing nobody tells you: when you remove the friction from building, you expose how much thinking you skipped.
Before AI, you’d hit walls. Hard walls. A technical problem you didn’t know how to solve. A design question you couldn’t answer. You’d have to stop and actually think. These stops felt like obstacles at the time. They were actually the only thing keeping you honest.
With AI, there are no walls. You go from “vague idea” to “shipped feature” in a day. Which means if your idea is bad, you’ve now scaled that badness into production code.
The guidebook module was a masterclass in this. I had assumptions about what STR hosts needed. How they’d use it. What the problems would be. I never talked to anyone about any of it. I just wrote a detailed prompt, got back beautiful, working code, and pushed it live.
Turns out the problem I solved didn’t exist.
This is where the 10-80-10 thing matters.
The split is simple:
10%: figuring out what to build
80%: actually building it
10%: shipping it and learning from users
Claude can fully do the 80%. Hand it a spec, get working code back. But here’s where I went wrong: you can’t delegate the 10’s.
You can’t ask an LLM, “What problem are we actually solving?” You can’t ask “Is this worth building?” or “How will users actually interact with this?” These require you to talk to people, think through edge cases, and sit with uncertainty. The unglamorous stuff.
When I handed off the guidebook module, I skipped both 10s. Half-formed idea straight to production. No conversations with hosts. No “wait, does anyone actually need this?”
The irony is dark: I became less productive the faster I could execute. Because now I had a built, integrated, completely wrong feature. Rebuilding it the right way took longer than building it wrong the first time.
Fast in the wrong direction is slower than slow in the right direction.
1. The 10% before the 80% doesn’t get faster.
Spend the time. Talk to users. Write things down. If you can’t explain the problem in plain language without mentioning your solution, you don’t understand it yet. This part doesn’t scale. AI can’t do it.
2. Delegation has a prerequisite.
You can delegate execution once you’ve nailed the intent. Not before. I treated “I have an idea” the same as “I know what I’m building.” They’re not remotely the same thing.
3. Velocity is useless if it’s pointed the wrong way.
Building 10x faster means nothing if you’re shipping mistakes 10x faster. The question isn’t “how fast can I ship?” It’s “am I shipping the right thing?”
4. Use AI as a pressure test, not a shortcut.
The best use I’ve found: I think the problem is X, so let Claude implement it and see if it falls apart. Use the code to reveal gaps in your thinking. Don’t use it to validate thinking you haven’t done yet.
The tools got smarter. I didn’t. I just got faster at being wrong.
Real skill now isn’t shipping code in 2 weeks. It’s knowing whether you should. It’s doing the thinking nobody can automate. It’s validating before you scale, because scale amplifies everything, especially mistakes.
Smarter tools don’t make you a smarter builder. They just make your mistakes visible faster.
Pay attention. That's the only edge you have.
No posts
Comments
Nothing yet. Say the first thing.
Sign in to join the conversation.