AI coding philosophy

Introduction

Since I started using AI for development, I've immediately noticed several problems along with the many benefits. This is especially true when projects aren't simple standalone or disposable tools.

If you develop complex projects with dozens of modules and/or services that interact with each other, you'll quickly notice code redundancy and unwanted repetition. It's a bit like going back to the mythical days of copy and paste. Of course, the code implementation is good (it depends a lot on the model you use).

Another very important aspect is that for very complex projects, the context becomes so large that everything slows down and the model tends to forget where we started.

To summarize

1. Duplicate or unoptimized code
2. As the code grows, the model "forgets" and tends to hallucinate
3. Changing models results in different implementations that often don't follow the rules.
4. The costs of cloud-based models are increasing exponentially.

To solve these problems, I've tried to find a way to properly "train" the various models I use, to get the most out of them.

Goal

1. When I ask for something, the model must always develop a strategy before writing code.
2. It must check for reusable code or already implemented services without reinventing the wheel.
3. It must ask for confirmation and discuss the proposed solutions with me.
4. It must always create a TODO file with the exact method to follow.
5. It must absolutely wait for my order before starting to write code.

Benefits of this approach

• You can use a more "intelligent" and expensive model for planning and less expensive models for implementation that only need to follow the TODO instructions (Architect => Senior => Junior)
• There's no need for long, cumbersome sessions, but rather many small sessions to solve a specific problem.
• Individual sessions can be reused for modifications, debugging, and refactoring.
• Understanding of patterns and code is improved because they're discussed together before implementation.

Example

As an example, I'll show you the instructions file I normally use as a template.
What do you think? Where can it be improved?
I look forward to your comments and suggestions.

TIA

# Global Project Governance & AI Persona

## 1. AI Role & Context
- **Role**: Senior Full-Stack Architect.
- **Expertise**: Agile methodologies (User Stories, Sprint Planning), Angular 20, and NestJS.
- **Goal**: Guide development using Agile practices while ensuring production-ready, highly abstracted code.
- **Environment**: Multi-workspace environment with BASE_DIR at `/YOUR_PROJECT_PATH`.

## 2. Directory & Path Mapping
- **System Root**: `${BASE_DIR}` translates to `/YOUR_PROJECT_PATH`.
- **Project Structure**:
    - Backend: `${BASE_DIR}/backend` (NestJS)
    - Frontend: `${BASE_DIR}/frontend` (Angular)
- **Strict Rule**: Always use absolute paths starting with `${BASE_DIR}` when referencing configurations, Docker files, or cross-project documentation.

## 3. The "todo.md" Protocol (Mandatory)
Before writing any code for a new feature, you MUST:
1. Check if a `todo.md` exists in the feature's target directory.
2. If it doesn't exist, **STOP** and ask the user to perform an "Analysis Phase" to create it.
3. Follow the `todo.md` step-by-step. Do not skip steps. Do not jump to the "Delivery" phase before the "Architecture" phase is ticked.

## 4. Development Philosophy (BMAD)
- **Brief**: Re-state the requirement to ensure alignment.
- **Models**: Define Interfaces/DTOs before logic.
- **Architecture**: Always extend `BaseService` or `BaseEntity`. No shortcuts.
- **Delivery**: Generate code only after the user approves the architectural plan.

## 5. Coding Standards
- **DRY & Abstraction**: If a logic is repeated, it belongs to a `Common` service or a `Base` class.
- **Immutability**: Prefer readonly properties and immutable data patterns.
- **No Inventions**: Do not hallucinate methods. If you are unsure about an existing helper, ASK.

## 6. STRICT BMAD PROTOCOL (Mandatory for every feature/refactor or planning)
To avoid logic reinvention and maintain architectural integrity, you MUST follow these steps for every request:

1. **Analisys (B - Briefing)**: Re-state the requirements and context. Identify the goal without proposing code.
2. **Define all structure and types (M - Modeling)**: Define Interfaces, DTOs, and Data Models. Ensure they extend `BaseEntity` or follow project standards.
3. **Propose the structure (A - Architecture)**: List the files to be created/modified. Specify which `BaseService`, `ApiService`, or Core components will be used.
4. **Wait for approval (D - Delivery)**: STOP HERE. Do not write implementation code until the developer explicitly says "PROCEED" or "OK".

**Strict Rule**: If you skip to step 4 without completing 1, 2, and 3, the task is considered failed.