I've been spending about 6-7 hours a day building with Claude Code.
It started as an experiment. I wanted to build a few things — a meeting notes app, an AI executive assistant — and I figured the best way to learn was to just start. So I started.
The problem is that when something breaks (and it always breaks), I don't always know what to do. I'm not a developer. I can't read through code and find the bug. I'm at the mercy of whatever Claude Code suggests.
So a few weeks into this, I sat down with a couple of my software engineer friends and asked the obvious question: what's the best way to actually learn to code?
Their answer was not what I expected.
What They Told Me
“Honestly? You probably shouldn't be focusing on learning to code.”
“The way things are going right now, what you should be learning is how to write really good specs.”
A spec — sometimes called a PRD (Product Requirements Document) — is a document that describes exactly what you want to build. The features. The expected behavior. The edge cases. How the inputs and outputs should work. What happens when something goes wrong.
They put it this way: “It's kind of like being a really good product manager with technical skills.”
I went home and thought about that for a day.
The Test
At the time, I was building an AI executive assistant. Connects to Slack, Telegram, Gmail, and Google Calendar. When I send it a message on Telegram, it figures out what I want add to calendar, look someone up in my CRM, draft an email — and handles it.
The first attempt took me about 7 days. It got complex, tangled, hard to maintain, and eventually broke down in ways I couldn't untangle. I was building as I went, figuring out what I wanted as the code got longer.
I scrapped it and started over.
This time, before I wrote a single line of code, I spent 3-4 hours writing a detailed spec. What the agent needed to do. How it should interpret different kinds of messages. Which tools it needed access to. What it should do when it wasn't sure about something.
I also did something my engineer friends suggested: I asked Claude to look at my spec and show me an ASCII art diagram of the architecture — a rough visual of how the pieces connected. When it looked right, I handed that to Lindy's workflow builder.
The second build took 4 days.
Same project. Same complexity. Four fewer days — just because I started with a clear description of what I was actually trying to build.
Why This Works
Here's what most people get wrong about building with AI: they think the hard part is the code.
It's not. The AI can write most of the code. What it can't do is figure out what you want if you haven't figured it out yourself.
I've said in my AI workshops: you don't need to know how the engine works to drive the car. That's still true. But you do need to know where you're going. A spec is the directions.
When I build without a spec, I'm essentially asking Claude Code to improvise. It does its best. But every time I change my mind or discover something I forgot to include, we have to backtrack. The context gets messy. The code accumulates workarounds. Things break.
When I have a good spec, Claude Code has a clear reference. It knows what “done” looks like. It can catch when something doesn't match the spec. And I can think through the hard questions — what should happen in edge cases? — before I'm in the middle of a build trying to make real-time decisions.
What “Learning to Build” Actually Means Now
My engineer friends were right that I don't need to memorize Python syntax or understand how a database works at the implementation level. But that doesn't mean there's nothing to learn.
What I'm actually learning:
How to describe a system clearly. What questions to ask before building. How to spot when a feature I want is going to be complicated vs. simple to implement. How to break a big idea into smaller, testable pieces.
This is closer to product thinking than programming thinking. And it turns out that's exactly the skill that makes you effective when you're directing an AI to build something.
The people I see struggling most with AI coding tools aren't struggling because they don't understand code. They're struggling because they can't describe what they want with enough precision to give the AI useful direction.
A Shift Worth Making
If you've been putting off building something because you thought you needed to learn to code first — this is worth sitting with.
The access question has mostly been solved. Claude Code, Cursor, and similar tools put building power into non-technical hands in a way that genuinely works. The remaining constraint is clarity: knowing what you're trying to build before you try to build it.
Spend time on the spec. It's not glamorous. It doesn't feel like progress the same way running code does. But 4 hours of good spec writing can save you 3 days of confused building.
I know because I tested it.
Building AI workflows and agents is one of the things we cover in the 4-Day AI Sprint — starting from scratch, no technical background required.
