If you start with a blank canvas, it’s quite tricky to get the defaults right while building apps. Previously I used to prompt the LLMs like a rookie by saying “fix this, add this, build this”, and so on. Realised that the app is only as good as our ability to carefully prompt them.

I came across Harper Reed’s blog talking about his own LLM-aided coding workflow, I felt like sharing something similar based on what I’ve learnt. Harper goes through a lot more LLM assistants, but my advice here is specific to Cursor IDE:

Idea Honing

This is where you have a natural conversation with the latest reasoning model to think the whole design of the app with you. You want the chat assistant to find gaps, poke holes, ask carefully considered questions which you might have not considered. The assistant is your “philosopher in residence”.

Ask me one question at a time so we can develop a thorough, step-by-step spec for this idea. Each question should build on my previous answers, and our end goal is to have a detailed specification I can hand off to a developer. Let’s do this iteratively and dig into every relevant detail. Remember, only one question at a time. Here’s the idea: (Idea)

At the end of the question-storm, you will end with a natural conclusion, you would now need to synthesize this chat thread into something more concrete. This is where you convert this into developer-ready specification.

Now that we’ve wrapped up the brainstorming process, can you compile our findings into a comprehensive, developer-ready specification? Include all relevant requirements, architecture choices, data handling details, error handling strategies, and a testing plan so a developer can immediately begin implementation.

Create a /docs folder in your project directory, and add this file created under specs.md

Once it creates this, I do another round of “poking holes” just to be sure.

Poke holes into this essay and find gaps wherever possible.

I also exhaust my Perplexity Deep research credits to make an extensive whitepaper based on the specs.md file.

I then carefully examine the tech architecture defaults, and prefer to pick the ones which are LLM-friendly (for instance, as of 9 Mar, 2025, Rails 7.2 is more LLM-friendly than Rails 8.1).

Once I’m confident with the specs.md file, I move on to the next stage.

Planning

I prefer to test the specs at each stage of development, and to ensure that the tests pass as planned. Especially when non-coders (such as myself), have no idea if what’s running is actually working or not, this is a great litmus test to progressively expand the scope of the app.

Draft a detailed, step-by-step blueprint for building this project. Then, once you have a solid plan, break it down into small, iterative chunks that build on each other. Look at these chunks and then go another round to break it into small steps. Review the results and make sure that the steps are small enough to be implemented safely with strong testing, but big enough to move the project forward. Iterate until you feel that the steps are right sized for this project. 

From here you should have the foundation to provide a series of prompts for a code-generation LLM that will implement each step in a test-driven manner. Prioritize best practices, incremental progress, and early testing, ensuring no big jumps in complexity at any stage. Make sure that each prompt builds on the previous prompts, and ends with wiring things together. 

There should be no hanging or orphaned code that isn't integrated into a previous step. Make sure and separate each prompt section. Use markdown. Each prompt should be tagged as text using code tags. The goal is to output prompts, but context, etc is important as well. 

@specs.md

It should output a prompt plan that you can execute with aider, cursor, etc. I like to save this as docs/ prompt_plan.md in the repo.

I then have it output a todo.md that can be checked off.

Can you make a `todo.md` that I can use as a checklist? Be thorough.

After each phase, ensure that you also provide the reason as to why the scope of each phase was chosen and how it's stacked.

I do this to also understand why each phase is written in a specific way, and why the order was chosen as such.

As you continue to build the app, you can cross off items from the todo list as shown here in this example app:

# blogggg Implementation Checklist

## Phase 1: Core Infrastructure Setup

### Rails Foundation

- [x] Create new Rails 8.0.1 app with PostgreSQL

- [x] Configure modern components:

- [x] RSpec + FactoryBot

- [x] Database Cleaner

- [ ] Configure Hatchbox.io deployment:

- [x] Implement health check endpoint

- [x] Write infrastructure tests:
...
...
...

Now you have a robust plan and documentation that will help you execute and build your project.

The workflow looks something like this

• Build the prompt-plan.md, specs.md and todo.md.
• Set up the boilerplate
• Set up git version control and keep pushing commits during important milestones
• Run code phase by phase based on the prompt-plan.md document.
• After each phase, run integration tests and ensure all of the pass successfully
• Once successful, move on to the next phase and continue

Now you have a robust plan and documentation that will help you execute and build your project.

Surprising and scary.