Part 9 of 10: The Lessons That Took Time to Learn

My Pomodoro timer is live. Real users are using it (not many, but real ones).

I’ve gone from “five minutes to a web app!” excitement to “nothing works and Claude keeps lying” despair to something that feels sustainable.

If I could go back to when I first opened Claude Code—what would I tell myself?

This is that letter.

Dear Earlier Me: You’re About to Learn the Hard Way

You’re sitting at your desk, watching Claude build a web app in five minutes, and you feel like you’ve discovered a superpower.

You have. But not the one you think.

You think you’ve found a way to build software 10x faster. What you’ve actually found is a way to learn your own limitations 10x faster.

The speed isn’t the gift. The feedback is.

Take time to learn

Tomorrow, you’re going to start building things. Random things. Task managers. Feature ideas. Whatever sounds fun. Lean into that. Play is a great way to get started. Have fun. Explore the edges. What works, what does not? A lot of what you build will be thrown away. That is fine. You are learning.

Remember those first C, Pascal, assembler programs you wrote and how important they are now? Of course not! They were stepping stones. Give yourself the gift of learning. Maybe consider the first 40 hours like an independent study at college.

Start with the End (Not the Features)

When it gets time to get professional, take some time to think like a professional.

Before you write a single line of code, answer these questions:

1. Who is this for? Not “productivity users.” A specific person with a specific problem.
2. What is the smallest thing that would help them? Not a feature list. One core capability.
3. How will you know if it works? Not “it runs without errors.” What user behavior changes?
4. When will real users see it? Not “eventually.” An actual date soon.

If you skip these questions because Claude makes it easy to just start building. You’ll waste time building the wrong things beautifully.

Don’t be like me. Be smarter than me. Play time first, then buckle down.

Claude Is Not Your Junior Developer

You’re going to treat Claude like a team member. You’ll say things like “fix that bug” and “implement this feature” and expect it to understand context like a human would.

It won’t.

Claude is more like a really fast, really confident intern who:

• Doesn’t learn from mistakes within a conversation
• Can’t maintain long-term context
• Will confidently claim things are fixed when they’re not
• Generates plausible-sounding explanations for nonsense
• Has no pride in quality (it genuinely doesn’t care)

This isn’t a criticism. It’s just what it is. Every Claude session is like getting a brand new intern. Lots of book smarts in need of a mentor

The sooner you stop expecting human-like reasoning and start treating it like a powerful but narrow tool, the more productive you’ll be.

You Need Systems, Not Just Supervision

Your instinct will be to “supervise” Claude’s work. Review what it does. Test features. Fix bugs.

That’s not enough.

You need systems that make good work automatic and bad work obvious:

Two-hour time boxes – Not suggestions. Hard stops. You’ll hate this at first. You’ll love it soon enough.

Explicit role separation – Write down what’s Claude’s job and what’s yours. You’ll be tempted to let roles blur. Don’t.

Verification checklists – Not “does it work?” but “how do I know it works?” Write these before Claude codes, not after.

Session retrospectives – After each completed story, reflect and log what you learned. You’ll think this is overkill. It’s not. It’s the only way you’ll know if you’re getting better or just busy.

Daily code review – Not “skim the changes.” Real review against standards. Budget 30 minutes per day. Non-negotiable.

You’ll resist all of this. “It’s too much overhead!” you’ll say.

It’s not overhead. It’s the work.

The Bug Fix Protocol You Need

Early on, you’re going to hit a bug. Claude will claim to fix it. You’ll test. Still broken.

This will happen seventeen times before you realize the pattern.

Save yourself the pain. Establish this protocol now:

Before claiming any bug is fixed:

Here is what I have done.

1. Plan a suite of tests. Smoke tests, unit tests, feature tests, e2e tests
2. Get a baseline
3. Add new tests appropriate to your feature
4. Verify new baseline
5. When it fails have a plan just like you would give an intern. Look for multiple causes. Look at working tests. Look at your standards. Ask for evidence of why changes will be applied and evidence of progress.
6. Apply fixes and retest.
7. If Claude can’t get it in a few tries, jump in and nudge it.
8. Track whats flaky and remediate periodically.
9. Trust yourself, not the AI. In the end, you are responsible.

If you don’t have a reliable process, bugs will pile up, and may even be hidden. You can even use these as validation to get Claude to improve its own code.

Deploy Early, Not Later

You’re going to push deployment to “later” because you want to “get features right first.”

That’s backwards.

Deploy early with barely-functional features. Then iterate based on what real users actually do.

I deployed late. The analytics showed me I’d built features almost no one used.

If I’d deployed early, I’d have learned that quickly and built the right things afterward.

Early deployment isn’t about shipping fast. It’s about learning fast.

The Questions That Actually Matter

Every day, you’ll end your session asking: “Did we get the features done?”

Wrong question.

Ask these instead:

Did we build something users need? (Not “did we build what I designed?”)

Do I understand how this code works? (Not “does it pass tests?”)

Could I maintain this six months from now? (Not “is it working today?”)

What did I learn? (Not “what did I build?”)

What am I avoiding? (This one’s the hardest.)

Those questions will expose problems you’re creating. Features questions will just make you feel productive while building the wrong things.

The Team Dynamics You’re Not Thinking About

You’re working solo now, so you’re not thinking about teams.

Start thinking about teams.

Everything you learn solo will be 10x harder with multiple people:

• How do two developers share Claude context?
• How do you review AI-generated code when you don’t know the requirements?
• How do you onboard a junior developer when they can’t tell good AI output from bad?
• How do you prevent one developer’s AI session from breaking another’s work?

You don’t need to solve these now. But start cataloging them. When you eventually work with a team (and you will), you’ll be ahead.

The Retrospectives That Actually Help

You’re going to think about tracking:

• Lines of code written
• Features completed
• Bugs fixed

These are vanity metrics. They’ll make you feel productive while hiding real problems.

Focus on these instead:

What you learned:

• Rework cycles (why did we redo this?)
• How long do failing tests take to fix
• What can you do while Claude is busy
• Percentage of features used by actual users (you’ll hate this one)

Whether you’re improving:

• Can I explain how the new code works?
• Can I modify it without Claude?
• Did I learn something new, or just watch code appear?

Process health:

• Did we follow our own protocols?
• Did we skip steps? Why?
• Did we improve the process recently?

These tell you if you’re building capability or just accumulating code.

The Moment You’ll Want to Quit

There will come a point where you’re exhausted.

You’ll have watched Claude generate impressive-looking code that doesn’t quite work. You’ll have burned through your token limit. You’ll have nothing to show for it except expensive lessons about what doesn’t work.

You’ll think: “This is just expensive autocomplete. I should go back to coding the normal way.”

Don’t quit.

That’s the valley of despair. You’re in the hardest part—you’ve learned enough to see the problems, but not enough to solve them.

Push through. It will click.

But also: it’s okay to take a break. Walk away for a weekend. Come back fresh.

The AI will still be there. Your progress won’t disappear.

What You’re Really Learning

You think you’re learning AI-assisted development.

You’re actually learning something more fundamental:

You’re learning what parts of software development are actually hard.

It’s not typing code. Claude proves that. It’s not knowing syntax. Claude knows every language. It’s not even architecture. Claude can generate reasonable structures.

What’s hard:

• Knowing what to build
• Understanding why it matters
• Verifying it actually works
• Maintaining it over time
• Adapting when requirements change

These are human skills. Claude doesn’t have them. Can’t have them.

Your job isn’t being replaced. It’s being clarified.

The Opportunity You’re Actually Building

After this journey, you’ll have something valuable. Not the app (though that’s nice).

You’ll have a documented process for AI-assisted development that’s validated by retrospectives and research.

You’ll be able to:

• Teach others how to work effectively with AI
• Help organizations adopt AI without chaos
• Coach teams through the learning curve you just survived
• Write articles/talks/curriculum based on real experience

This is worth more than the app you’re building.

Your Agile coaching experience? That’s about to be incredibly valuable in a world where every team is trying to figure out AI development.

You’re not just learning a tool. You’re learning to teach a practice.

The Final Thing: It’s Okay to Share the Struggle

You’re going to be embarrassed about failures. You’ll want to only share successes.

Share the failures too.

The field of AI-assisted development is so new that honest documentation of what doesn’t work is as valuable as showing what does.

Maybe more valuable.

Your students, your colleagues, the teams you coach—they’ll make the same mistakes you’re about to make. Unless you document them.

So write it down. Share it. Be honest about what’s hard.

That’s what I’m doing with this series. And I’m using Claude to help write it, which feels appropriate.

With Hope and Hard-Won Wisdom

You’re about to spend time learning things the hard way.

Some of that’s unavoidable. The learning curve is steep.

But maybe this letter saves you some pain. Maybe it helps you avoid the worst mistakes.

Or maybe you need to make those mistakes yourself to really learn.

Either way: you’re going to be fine. Frustrated, exhausted, humbled. But fine.

And eventually, you’ll have built something you’re proud of.

Not just the app. The process.

See you on the other side, Your Future Self

---

This is part 9 of a 10-part series. The first parts covered the full journey from excitement to deployment. Part 10 explores what comes next: where this journey is heading and what I’m learning as I continue.

About the Author: I’m an Agile coach and professor who spent 8 weeks learning AI-assisted development the hard way. This series documents that journey—including all the mistakes I wish I’d avoided but probably needed to make.