Building an AI app: when design goes too far š (+ Choosing an IDE)
Exploring different approaches to AI-assisted programming and the challenges of over-engineering
Hereās the continuation of my experiment building an app with AI tools.
Last week I showed you how I went from an idea to initial requirements (project requirements document or PRD for short) for the āMind Fitness Nowā app. I promised to continue with the practical part ā and here it is!
But let me remind you, this isnāt just another app. Even though Iām building it for demonstration purposes, I wanted to create something truly useful. Something that will make users better at being aware of their thoughts ā because thatās where everything starts, right? š
To quickly summarize: thoughts lead to actions and shape how we feel. If we can be conscious of our thoughts most of the time, weāve almost won. šŖ If they wander, we just redirect them where we want.
The āJust One More Featureā Loop
This was the most fascinating part during the PRD preparation: Several times I caught myself in a loop of wanting to add features that seemed essential right from the start. For instance, I listened to two YouTube videos about self-development, got some great ideas and immediately rushed to Gemini, with whom I was creating the PRD. I continued the conversation like: āYou know what, it would really benefit the user if we added this and thatā¦ā
And what happened? Gemini (whom I initially prompted with: Act as the best psychologist and game designer) started āthinking.ā He explained the advantages and disadvantages of my suggestion, and concluded: āSounds good, but start with the minimum.ā This happened several more times! His persistence in keeping me focused on the MVP (Minimum Viable Product) convinced me. I said to myself, okay, Iāll trust him. Letās give him a chance š
So, I have a PRD document with clear requirements.
Choosing a Development Environment (IDE)
Great, the plan is ready. Now I need an environment where I can āinputā this plan and get an actual mobile application out. As I mentioned in previous newsletters, for this we need an IDE (Integrated Development Environment) or a code editor that often comes with a built-in AI assistant nowadays.
The most popular options for working with AI:
- Cursor: Probably the easiest to get started with, AI models are already integrated.
- Windsurf: Similar to Cursor, simple and with integrated AI.
- VS Code + Cline (plugin): Flexible, but you need your own access to AI models (e.g., via OpenRouter).
- VS Code + Roo code (plugin): Similar to Cline, requires access to an AI model.
For an easier start, I recommend Cursor
or Windsurf
. Both have a free trial month, so you can see which one suits you better. And you are coverd for two months. The main advantage is that you donāt need additional setup for AI. Later, if youāre interested in cost optimization, I can show you how to set up access through VS Code.
Installation Instructions:
- Cursor: āhttps://docs.cursor.com/welcomeā
- Windsurf: āhttps://docs.windsurf.com/windsurf/getting-startedā
PS: If you get stuck, donāt forget about ChatGPT or YouTube guides ā theyāre always helpful!
Techniques for Working with AI Programmers
Once we have the tool (IDE with AI), we need a good workflow. How do we give tasks to the AI assistant to minimize errors and produce high-quality code?
There are several approaches, and I tried two that are interesting for higher quality programming with AI:
- Claude Task Master: A tool for breaking larger tasks into smaller subtasks. āhttps://github.com/eyaltoledano/claude-task-masterā
- Cursor Memory Bank: An approach for storing context, changes, and knowledge in files after each change. āhttps://github.com/vanzan01/cursor-memory-bankā
(By the way, Cline
and Roocode
have similar functionalities, like Boomerang Tasks, already built-in.)
Letās first look at Claude Task Master.
What is Claude Task Master?
The idea is that the system automatically creates all necessary tasks from requirements. If you wish, you can perform complexity analysis and for more difficult tasks, you can generate smaller, more manageable subtasks.
My Process with Task Master:
(If youāre not interested in technical details, you can jump straight to the results below. Let me tell you that things didnāt go as expected.)
-
Installing the tool (globally): ` npm install -g task-master-ai
`
-
Initializing in the project: ` task-master init
`
-
Configuration:
- Rename
.env.example
to.env
- Add your
ANTHROPIC_API_KEY
(for Claude model) - Add your
PERPLEXITY_API_KEY
(for research function - optional)
- Rename
-
Add PRD:
- I added my PRD document to the project folder.
-
PRD analysis and task creation: ` task-master parse-prd your_prd_filename.txt
`
-
List of basic tasks: ` task-master list
`
-
Complexity analysis (optional): ` task-master analyze-complexity task-master complexity-report
`
-
**Breaking tasks into subtasks (with research):**I used Perplexity to help define detailed steps for each task: `
Example for task with ID 5, I want 6 subtasks
task-master expand āid=5 ānum=6 āresearch āprompt=āBreak this task into detailed steps for implementation.ā
*(Of course, you replace*
āid*,*
ānum*and*
āprompt`with your values) -
Final list of tasks with subtasks:
task-master list with-subtasks
Results of My Task Master Experience
On paper it looks great, right? Detailed instructions for the AI assistant. But the result for me⦠wasnāt optimal.
Why?
To give the AI programmer a very clear goal, I thoroughly researched each task and divided it into micro-subtasks. Generally, the rule is: clearer instructions -> better results. But in my caseā¦
ā¦there was āover-engineeringā of the plan. Too much detailed planning.
The AI did follow the instructions, but the entire process became too rigid and slow. Instead of leveraging the AIās ability to understand broader context, I limited it to executing very small, specific steps. This took a lot of preparation time, and the end result wasnāt necessarily better than if I had given it slightly more general instructions.
Hereās an example of one task and how Task Master (with Perplexityās help) broke it down into detailed subtasks:
āEXAMPLE OF COMPLEX SUBTASKSā
I spent 34 cents on the Perplexity API to create subtasks.
For the final execution of all tasks (with all subtasks), 137 calls were made in Cursor using the Claude 3.7 Sonnet model.
Before start starting
At the end
262 files and 44k lines of code were created š«£
The experiment took approximately 6 hours.
Conclusion
The more code there is, the more possibilities for errors. Even if youāre running tests along the way.
Next time Iāll show you the other approach (Cursor Memory Bank), or how I took the best from each approach and simplified the process. With far fewer calls and better results. And results achieved in less than 1 hour.
To ātease you a bit,ā hereās the first result of four different tests, which Iāll describe next time:
First result of 4 different models/workflows
Interested in the final result? Letās stay in touch.
Talk to you soon, Primož