Twitter is filled with founders talking about using AI to write code. They’re proud of how fast they ship. They're showing us apps they built in a weekend.
I get it. The speed is intoxicating.
But here’s what I’ve noticed after building several AI-powered products over the last two years: the best software doesn't come from fast coding. Instead you can see they've spent weeks having conversations with AI before a single function gets written.
The problem isn’t that AI writes bad code. It writes pretty good code. The problem is that decent code built on shallow thinking produces shallow products. And shallow products don’t survive contact with real users.
AI made it dangerously easy to skip the hard part.
What Most People Do
Here’s the typical workflow. Someone has an idea. They open Claude Code or Cursor. They type a paragraph or two into it to see if they can generate a spec. In just a bit (often less than a couple hours), they get working code – and that's just amazing these days.
But shipping that code is going to be a bummer – when there's no response at all. It was a fun idea, but the code didn't generate wealth.
The code was never the bottleneck. The thinking was. And every hour spent generating code without sufficient planning is an hour you’ll spend later ripping it out.
What I Did With QuarterShift Instead
I’m building a system called QuarterShift that produces transformation workbooks for experts and coaches. Here’s what my timeline looked like.
The first two weeks, I didn’t touch code. I spent them talking to Claude about how transformation actually happens. How long does real behavior change take? What does the research say about habit formation versus identity shifts? How do you break a 90-day transformation into weekly steps that feel achievable but actually compound?
Two weeks of conversations. Not prompts. Conversations.
Then another week on the interview process. If an expert is going to create a transformation workbook, we need to extract their unique methodology. What questions surface the real framework versus the surface-level advice? How do you get a coach to articulate what they do instinctively?
By now, most people would be desperate to start building. But I spent another week on the worksheet design. What makes a weekly worksheet that someone actually completes versus one that sits in a drawer? How do you sequence exercises so week 4 builds on week 3?
Here’s what happened: each week of conversation made the next week’s conversations smarter. The transformation research informed the interview design. The interview design informed the worksheet structure. The worksheet structure revealed gaps in my transformation model that sent me back for more research.
By the time I was ready to write code, I didn’t have a vague idea and a prayer. I had decision documents. I had question banks. I had worksheet templates grounded in actual research about how people change. The LLM had so much context from our weeks of conversation that the code practically wrote itself.
The weeks of talking weren’t a delay. They were the product development. The code was just the last mile.
The Two-Model Workflow
Here’s something else I figured out along the way. I use Claude for the analysis work. It’s slower and more expensive, but it thinks deeply. Those weeks of conversation? That was Claude helping me build resource files, question banks, decision frameworks, transformation models.
Then when it’s time to build, I hand those resource files to a faster, cheaper model like Llama 4 Scout. Scout doesn’t need to think deeply. It needs to execute well. And it executes brilliantly when you’ve given it rich context files to work from.
Think about that for a second. You’re not choosing between expensive-and-smart versus cheap-and-fast. You’re using the expensive model to create the assets that make the cheap model brilliant.
I've told you this before: The intelligence doesn’t live in the model; it lives in the context files. And those files only exist because you invested weeks of conversation before you wrote a line of code.
The Discipline Nobody Talks About
Everyone wants to show off the app they built in a weekend. I get the appeal. But the founders I’m watching build products that actually work, that users actually stick with, are the ones who resist that urge.
They’re spending their first month thinking, not shipping. Having conversations, not generating code. Building the intellectual foundation that makes everything downstream easier.
The discipline isn’t in the prompting. It’s in the patience to plan before you build. AI didn’t eliminate the need for deep thinking. It made deep thinking more leveraged than ever, because now your thinking directly becomes the context that writes your software.
Stop rushing to code. Start investing in conversations. The software will be better for it.