I’ve been working on teaching myself to code with AI for six months. It feels strange that it took me this long to have the aha moment, but here we are.
I’ve finally hit the point where the model does exactly what I want it to most of the time with minimal intervention. I didn’t get a better model. I just got a better plan.
That said, I primarily use Claude for everything. I do most of my planning in Claude, and then I use it with Cline (inside Cursor) for coding.
Cursor is fine, but I’ve found that Cline is more effective for agentic coding. This flow works pretty well with Cursor, but I value my time more than the extra bucks it costs to get it done faster.
I’ve started using Cline so much, and so well that I’ll probably drop Cursor eventually, but we’ll see.
The Plan
The plan has several components: architecture, planning processes, coding processes, review processes, and process iteration.
I want to be very clear. I don’t do any of this by hand. I work with the model to generate all this.
Architecture
It doesn’t REALLY matter which one you use. It mostly matters that you use one that’s proven to work.
There are a few reasons for this:
- Human coders can use it to be successful
- The model has seen a bunch of examples, so it knows what you’re talking about
- You can understand what it’s doing
Personally, I use domain-driven design. I’ll write another article on why sometime. You can use vertical slice, event-driven, or even simple CRUD. As long as you’re consistent and understand it, you’ll be good.
Planning process
For the fluffy part of planning, I’m not sure it matters which methodology you use. Just make sure you use it well.
For the other part, I think it’s incredibly important to structure your plan in a specific way. Here’s what I do:
The fluffy stuff
This is what your product manager writes at work 😉
Product brief
At the beginning of the application, I define a product brief. This is a high-level overview of the application. It includes:
- The vision of the project
- The features I expect to include, and what phase they’ll enter into the product
- The overall architecture
- Other fluffy things that don’t contribute to this workflow
Project brief (or epic or whatever you call it)
At the beginning of each project, I write a project brief. This is a hig
