Unfortunately the no-code platforms and the AI builder platforms have made people believe in fractured approach to code development. Their suggestion to their customer is -

Just write the prompt, iterate into the fixes and trust the output.

This is not how the AI based development should be. In fact this approach would only make such platforms more rich for burning tokens as the users burn more of their efforts into the prompt and attempt to fix their broken apps.

If you invest your money into a platform where you prompt and create code while burning tokens then it helps to make use of variety of the AI out there for project documentations to build the code and then apps through it.

What documents should I use to build the project?

• Project requirement document

• Project directory structure

• Project Tech Stack

• Frontend Guidelines

• Backend Guidelines

• UI Guidelines

You can use plenty of LLM models out there to build these documents. However my approach always has been using the different LLM model than the one that builds my code.

For example, say Claude 4 builds my code, I won't use same AI in same tool to build my documentation. Instead my approach always has been using gpt models or deepseek or even mistral to write the docs.

I do this approach because I have found out each LLM to be offering different output and restrictions/boundaries for project. And when I try to use same model that builds code being used for docs, it often tries to justify it's action while cutting the corners and not following it's own docs and rules.

I have no idea why this is the behavior. However when I use Claude and Gemini as a code writers, I make sure to feed them with either deepseek docs/rules or the gpt based docs/rules to build the project code on.

Once I limit the code builders with the project documentations, a lot of useless code, unwanted features, extensive detailing over unimportant features get vanished.

So this is "write documentation with tests in mind" approach. You write the test and then build the docs with the "test in mind" for the features and the project development.

I even make sure for the LLM model to pay attention to small stats like these.

I am building multiple WordPress plugins where I use the audit.html file which has variety of the tests and suggestions based on the priority levels. I ask cursor to set "resolved" for features that are marked completed.

Take an example of me doing this with my recent Expo android app. I wrote the PRD and docs and then put the AI for development of app and then made sure cursor follows the project documentation and guidelines for development of an app.

Mahesh

@devnamipress

I used approach similar to taskmaster to reduce bugs and strictly force to get a better expo app output. Make sure you do the following:

- Write PRD
- Setup code-review after every stage
- Setup pending tasks page after update
- Always question AI if feature is dropped
- Each

2

10:04 PM • Jun 1, 2025

I always make sure to ask an AI if it is on the project and not straying out of it's path. This way I understand if it's not feeding the garbage to the development. Like Claude is known to write garbage document and things which don't even exist and it does this to satisfy the prompt requirement.

What about test later approach?

I start every project with the PRD and the prompt approach. And I let every project build with the documentation guidelines and after the project is completed I ask AI to write 2 documents.

• code-review.html

• pending-tasks.html

Code review document should take whole project overview and read entire codebase and find the faults in the project and reviews and audits like it is finding faults for the developer.

In case of pending tasks document I make sure to let the AI think of pending features, pending to do list and the tasks which needs fixing.

In short, as a developer you should write tests first then build documentation around these tests for project. Then finally build the project and at the end, test again to see if it has developed the project as asked.

More you ask LLM models to refine the quality the more you can bring quality product out in the world.

Test first, Test Later.

Happy Vibe coding!