El uso de la IA generativa para producir código es cada vez más popular en el mundo de los desarrolladores. Desde la creación de prototipos rápidos hasta el andamiaje de funciones completas, las herramientas de IA ya no son solo asistentes, sino que están empezando a formar parte de nuestro flujo de trabajo.

Con Angular v20.2, un nuevo comando CLI le permite generar un archivo de configuración específico para modelos de IA. Este archivo define directrices específicas del proyecto, lo que permite a la IA generativa aplicar las mejores prácticas, seguir patrones de codificación establecidos e implementar nuevas funcionalidades sin dejar de ser coherente con su código base.

Veamos cómo generar este archivo y exploremos el conjunto de reglas que contiene.

Generación de los archivos de configuración de IA

A partir de Angular CLI v20.2, al crear un nuevo proyecto, la CLI le pide que elija si desea incluir un archivo de configuración de IA:

ng new app

A continuación, se le pedirá que elija una o varias herramientas de IA para configurar:

? Which AI tools do you want to configure with Angular best practices? 
  See: https://angular.dev/ai/develop-with-ai

❯ ◉ None  
  ◯ Claude                 [ https://docs.anthropic.com/en/docs/claude-code/memory ]  
  ◯ Cursor                 [ https://docs.cursor.com/en/context/rules ]  
  ◯ Gemini                 [ https://ai.google.dev/gemini-api/docs ]  
  ◯ GitHub Copilot         [ https://code.visualstudio.com/docs/copilot/copilot-customization#_custom-instructions ]  
  ◯ JetBrains AI Assistant [ https://www.jetbrains.com/help/junie/customize-guidelines.html ]  
  ◯ Windsurf               [ https://docs.windsurf.com/windsurf/cascade/memories#rules ]

La CLI de Angular generará un archivo de configuración independiente para cada herramienta que selecciones, colocándolo en la ruta designada:

  • Gemini → .gemini/GEMINI.md
  • Copilot → .github/copilot-instructions.md
  • Claude → .claude/CLAUDE.md
  • Cursor → .cursor/rules/cursor.mdc
  • JetBrains → .junie/guidelines.md
  • Windsurf → .windsurf/rules/guidelines.md

Si ya sabe qué herramienta de IA desea configurar, puede omitir la solicitud y pasarla directamente como una opción:

ng new app --ai-config=gemini
ng new app --ai-config=copilot
ng new app --ai-config=claude
ng new app --ai-config=cursor
ng new app --ai-config=jetbrains
ng new app --ai-config=windsurf

Y si omite este paso, siempre puede añadir la configuración más tarde en un proyecto existente utilizando uno de los siguientes comandos:

# Start the prompt to choose which AI tool(s) to configure
ng generate ai-config

# Generate the AI configuration for a specific tool (Gemini in this example)
ng generate ai-config --tool=gemini

Analicemos el archivo de configuración

Los archivos generados tienen el mismo formato para cada herramienta de IA seleccionada.

Nota: el archivo Cursor también incluye algunos metadatos, nada de qué preocuparse

Contexto de IA para la generación de código

En la parte superior del archivo, se proporciona un contexto a la IA:

Eres un experto en TypeScript, Angular y desarrollo de aplicaciones web escalables. Escribes código mantenible, de alto rendimiento y accesible siguiendo las mejores prácticas de Angular y TypeScript.

Esto ayuda a guiar a la IA para que genere sugerencias y estructuras que se ajusten a las convenciones y mejores prácticas de tu proyecto Angular.

Secciones y reglas

El resto del archivo se divide en varias secciones, cada una de las cuales define más contexto y reglas para un área específica de desarrollo:

  • Mejores prácticas de TypeScript
  • Mejores prácticas de Angular
  • Componentes
  • Gestión de estados
  • Plantillas
  • Servicios

Aquí tienes el archivo de configuración completo con todas las secciones y reglas:

## TypeScript Best Practices

- Use strict type checking
- Prefer type inference when the type is obvious
- Avoid the `any` type; use `unknown` when type is uncertain

## Angular Best Practices

- Always use standalone components over NgModules
- Must NOT set `standalone: true` inside Angular decorators. It's the default.
- Use signals for state management
- Implement lazy loading for feature routes
- Do NOT use the `@HostBinding` and `@HostListener` decorators. Put host bindings inside the `host` object of the `@Component` or `@Directive` decorator instead
- Use `NgOptimizedImage` for all static images.
  - `NgOptimizedImage` does not work for inline base64 images.

## Components

- Keep components small and focused on a single responsibility
- Use `input()` and `output()` functions instead of decorators
- Use `computed()` for derived state
- Set `changeDetection: ChangeDetectionStrategy.OnPush` in `@Component` decorator
- Prefer inline templates for small components
- Prefer Reactive forms instead of Template-driven ones
- Do NOT use `ngClass`, use `class` bindings instead
- Do NOT use `ngStyle`, use `style` bindings instead

## State Management

- Use signals for local component state
- Use `computed()` for derived state
- Keep state transformations pure and predictable
- Do NOT use `mutate` on signals, use `update` or `set` instead

## Templates

- Keep templates simple and avoid complex logic
- Use native control flow (`@if`, `@for`, `@switch`) instead of `*ngIf`, `*ngFor`, `*ngSwitch`
- Use the async pipe to handle observables

## Services

- Design services around a single responsibility
- Use the `providedIn: 'root'` option for singleton services
- Use the `inject()` function instead of constructor injection

Como puede ver, cada sección contiene reglas objetivas y se centra casi exclusivamente en el uso de las nuevas API de Angular en lugar de las antiguas.

Por ejemplo, es preferible utilizar las nuevas directivas de flujo de control de Angular (@if, @for, @switch) en lugar de *ngIf, *ngFory *ngSwitch. Del mismo modo, utilice señales y las API input()/output() en lugar de sus alternativas más antiguas.

Añada sus propias reglas

Si lo desea, puede ampliar la configuración con sus propias reglas, como convenciones de nomenclatura, preferencias de ordenación o cualquier otra norma de codificación que se adapte mejor al flujo de trabajo de su equipo.

Puede añadir nuevas reglas a las secciones existentes o crear secciones completamente nuevas si es necesario.

Por ejemplo, una sección NgRx dedicada podría tener este aspecto:

## NgRx Best Practices

- Use feature-specific state slices rather than a single global state object.
- Always define action types using a `[Feature] Event` convention (e.g., `[Auth] Login Success`).
- Group effects logically per feature and keep side-effects outside of components.
- Avoid deeply nested state structures; normalize data when possible.

Este archivo debe tratarse como código, pero escrito en lenguaje natural. Estructurarlo cuidadosamente y mantenerlo limpio y organizado no es trivial y debe hacerse con cuidado, al igual que cualquier otro archivo de código.

Gracias por leer Código en Casa.