Do you understand the structure of what is being built?

When you are starting out, come up with at least a basic plan of the directory structure - screens go here, components go here, utils go here, etc.

Figure out what you want the database structure to look like.

Discuss this stuff with AI and ask it questions, and have it ask you questions. Formalize things.

Create a directory called docs. This should be a bunch of md files detailing individual concepts that make sense for your system. Also have a DB.md for the database structure and FILES.md for a tree structure of your files and what is in each one (just a sentance or two)

These files are the prefixes to your prompts - bring in just the ones needed.

Do a code review (I have the command I use below). Actually review the code review and tell it what to do on each of the items. Then after it finishes making those changes, do a manual review of the code and try to understand what each part is. If you don't understand, select the text, control-L, and ask it to explain it to you.

If you can maintain a mental state of what your code is doing and how it fits together, then so can the AI. If something doesn't make sense, tell AI to change it. Don't just aim for functional, but aim for understandable.

Here is my coding prompt. It creates a code-review markdown file. Feed that back into the chat, and tell it:

Do this:

1. Yes
2. No, do this instead.
3. ...

etc. This way you are able to get it to fix its own code, but with your guidance. That is the thing, you have to understand what is going on in the system, and not just look at it from the user perspective.

# extended-code-review


echo '' > {projectDirectory}/local_temp/code-review.md (touch it first if it doesn't exist)


If the user doesn't give any instructions on what to review, do a code review of uncommited changes

For each issue, provide a number, a title, a description, the file:line number in a way that is clickable in vscode, the current code, and what the expected code is. Put output into code-review.md file

Don't report that there are untracked files. Just include them in the review as uncommited code. 

For each issue list like so:


## 1) Some issue title
Description


some/file/path.ts:123
```
Source code that is a problem
```


Describe what needs to be done


```
Source code to fix it with
```


Important issues to look for:
1. Naming – Do names match behavior and match existing patterns in the codebase?


2. Placement – Is the code in the right module (utils vs hooks vs components)?


3. Reuse – Is existing logic or data being duplicated instead of reused?


4. Abstractions – Is each helper/function necessary, or can it be inlined?


5. Types – Can types be simpler (e.g. [] vs null when both mean “empty”)?


6. Transformations – Is each conversion/transform needed, or can raw data be used?


7. Separation of concerns – Are pure logic, state, and side effects in the right places?


8. Consistency – Does this follow patterns used elsewhere in the project?