Cómo utilizar IA para mejorar revisiones de código en Angular

Resumen rápido (lectores con prisa)

La IA, correctamente alimentada con contexto y reglas, puede actuar como un Senior Angular bajo demanda. Usa herramientas distintas según alcance (Cursor para refactor, Claude/Gemini para auditorías, GPT‑4o para debates). Diseña un prompt system estricto, pide patches en formato unified diff y automatiza revisiones en PRs con métricas de calidad y coste.

Primero: la idea que cambia el juego

La IA no es solo un copiloto que escribe. Es un senior bajo demanda. Pero para eso hay que entrenarla con contexto, reglas y disciplina. Si le sueltas un archivo suelto, te devolverá consejo básico. Si le das repo, arquitectura, convenciones y tests, la IA te devuelve una revisión con criterio, riesgos, y cambios patchables.

Herramientas que debes conocer (y cuándo usarlas)

Cursor

si quieres revisiones que toquen múltiples archivos y entiendan el repo. Ideal para refactors globales.

Claude (3.5 Sonnet)

si buscas análisis profundo de flujos de datos y recomendaciones arquitectónicas.

Gemini (1.5 Pro)

auditorías a gran escala. Útil para detectar dependencias circulares o problemas de inyección.

ChatGPT (GPT‑4o)

explicación didáctica, debates de diseño y prompts interactivos en tiempo real.

Cómo orquestarlas: flujo recomendado

1) Prepara contexto mínimo (en el repo)

• README con convenciones del proyecto.
• ERD y diagrama de alto nivel si hay backend.
• Lista de dependencias críticas (librerías que no puedes romper).

2) Crea un prompt de “system” que actúe como tu senior

Define reglas: estándares Angular X, uso de Signals, OnPush, tests requeridos.

3) Alimenta a la IA con

• El archivo a revisar.
• Test unitario fallido (si lo hay).
• Metadata: ruta, package.json, versiones.

4) Pide

1) resumen ejecutivo, 2) lista priorizada de cambios, 3) patches o diffs, 4) riesgo de regresión.

5) Revisa manualmente, aplica cambios en una rama, corre CI, canary release.

Prompt maestro: transforma la IA en un Senior real

Usa esto como System + User. Pega exactamente:

System:
“Eres un Senior Angular Engineer con experiencia en Angular 19+. Tu objetivo: revisar el componente provisto, detectar anti‑patterns, proponer refactorizaciones concretas y producir parches listos para aplicar. Respeta las siguientes reglas: 1) Prioriza Signals y toSignal sobre suscripciones manuales; 2) Propón ChangeDetectionStrategy.OnPush donde aplique; 3) Evita inyecciones en constructor, usa inject(); 4) No rompas librerías incompatibles (si se listan); 5) Entrega: resumen, lista de issues (alta/media/baja), patches (diff) y tests sugeridos.”

User:
“Review this Angular component and suggest improvements following Angular 19 best practices, signals usage and performance optimization. Project constraints: [lista-de-paquetes-críticos]. File: [pega-el-código].”

Qué pedirle en la revisión (la checklist que marca diferencias)

• Arquitectura del componente: ¿es Smart/ Dumb? ¿Debe mover lógica a un servicio?
• Standalone? ¿Debe ser standalone o parte de módulo por compatibilidad?
• Signals vs Observables: ¿se puede usar toSignal? ¿Hay fugas de memoria?
• Change Detection: ¿OnPush es seguro? ¿Qué side effects existen?
• Template: ¿usar @if/@for mejora rendimiento? ¿trackBy en listas?
• Inyección: ¿usar inject() en lugar de constructor?
• Seguridad: ¿existen usos de innerHTML o riesgos XSS?
• Tests: ¿qué unit/e2e faltan?
• Complejidad ciclomática y sugerencias de simplificación.

Ejemplo práctico (caso real): input → output

Envías este componente legacy:

@Component({ selector: 'app-profile', template: `...` })
export class ProfileComponent implements OnInit, OnDestroy {
  user: any;
  sub: Subscription;
  constructor(private svc: UserService) {}
  ngOnInit(){ this.sub = this.svc.getUser().subscribe(u => this.user=u) }
  ngOnDestroy(){ this.sub?.unsubscribe() }
}

La IA, bien instruida, debe devolverte:

• Resumen: convertir Observable a Signal, usar inject(), añadir OnPush, eliminar ngOnDestroy.
• Issues: memory leak (alta), falta OnPush (media), falta test (media).
• Patch: el diff que transforma a standalone, agrega toSignal, cambia update flow.
• Test sugerido: mock para getUser() y asserción de render.

Automatización: reviews en PRs como si fuera otro reviewer

Integra un bot que llame a la IA en cada PR (acción GitHub). El bot añade comentario con: resumen, lista de riesgos, patch sugerido y tests a añadir.

Workflow ideal

• PR abierto → Bot corre revisión en background con contexto del PR.
• Si score de riesgo > X o cambios altos → asigna humano Senior.
• Si cambios menores y tests pasados → auto‑merge con etiqueta “AI‑reviewed”.

Cómo pedir diffs aplicables (para no recibir solo texto)

• Solicita explícitamente un diff en formato unified patch.
• Pide que el patch respete lint y formateo (prettier/eslint).
• Solicita que agregue tests y actualice package.json scripts si necesario.

Limitaciones reales (no seas ingenuo)

La IA no conoce efectos colaterales en el negocio. Puede proponer OnPush y romper integración con librería que dependa de Default. No confíes en la IA para decisiones legales, seguridad completa o en arquitecturas críticas sin revisión humana. Los modelos pueden ofrecer soluciones “no disponibles” en tu versión (verifica versiones Angular y librerías).

Buenas prácticas para prompts que devuelven código útil

• Incluye versiones: Angular 19, RxJS X, TypeScript Y.
• Proporciona lista de libs que son inmutables.
• Pide outputs estructurados: JSON con keys summary, issues[], patches[].
• Pide razones breves por cada cambio (1 línea). No te quedes con recetas, exige justificación.

Métricas que debes medir en tu pipeline AI‑Review

• Time to review (s): cuánto tarda la IA en devolver la revisión.
• % issues aceptados: cuántas recomendaciones se aplican.
• Regressions introduced: número de tests rotos después de aplicar patches.
• Cost per review: tokens/usd por review y ROI medido en bugs evitados.

Plantilla de reporte que debes exigir a la IA (copy/paste)

Executive summary (3 lines). Top 3 risks (with severity). Suggested changes (prioritized). Patch(es) (unified diff). Tests to add (unit + e2e). Why: one-line explanation per change. Confidence score (low/med/high).

Cultura del equipo: cómo integrar la IA sin que la gente se sienta reemplazada

• La IA como reviewer inicial, no como resolutor final.
• Todo patch sugerido por IA debe pasar por un PR con dueño humano.
• Promueve “AI apprenticeship”: juniors aplican patches, seniors validan.
• Mantén ownership: prompt versioning y changelog de prompts.

Cierre con acción (lo que tienes que hacer ahora)

Si no tienes pipeline de AI‑review funcionando:

• Paso 1: pick a tool (Cursor si quieres integración repo; Claude si buscas calidad en refactors).
• Paso 2: crea el System Prompt maestro y versionalo en repo.
• Paso 3: implementa GitHub Action que llame a la IA en cada PR.
• Paso 4: exige formato JSON y parséalo para crear checklist en PR.
• Paso 5: métricas y alertas: coste por review, ratio aceptado.

Si quieres el kit listo para pegar en tu repo, dime qué prefieres:
– “QUIERO LA ACTION”: GitHub Action + workflow que compare PR y añade comentario AI.
– “QUIERO EL PROMPT”: system + user prompts optimizados para Angular 19 (listos para usar).
– “QUIERO EL KIT COMPLETO”: Action + prompt + ejemplo de patch + tests e2e simulados.

Esto no acaba aquí. Si escalas sin revisiones de calidad, tu código se oxidará. Si usas la IA para auditar en serio, reduces bugs y aceleras calidad. ¿Cuál quieres primero — la Action que revise tus PRs o el prompt que convierta a la IA en tu Senior? Responde “ACTION”, “PROMPT” o “KIT” y te lo preparo para pegar y usar.

Dominicode Labs

Para quienes implementan pipelines de automatización y agentes para revisión de código, considera continuar con recursos y experimentos en Dominicode Labs. Es una extensión natural del flujo de trabajo descrito arriba y facilita pruebas de integración de bots y métricas.

FAQ

• ¿Qué ventaja tiene usar la IA para reviews en lugar de solo generación?
• ¿Qué herramientas debo elegir según mi objetivo?
• ¿Cómo evito que la IA proponga cambios incompatibles con librerías?
• ¿Qué formato debo exigir para los patches?
• ¿La IA puede sustituir a un reviewer humano?

¿Qué ventaja tiene usar la IA para reviews en lugar de solo generación?

La IA, con suficiente contexto y reglas, produce revisiones priorizadas, riesgos y parches aplicables que aceleran la corrección y mejoran la calidad en comparación con generación ad hoc.

¿Qué herramientas debo elegir según mi objetivo?

Cursor para refactors que tocan todo el repo; Claude para análisis en profundidad; Gemini para auditorías a gran escala; GPT‑4o para interacción y explicaciones en tiempo real.

¿Cómo evito que la IA proponga cambios incompatibles con librerías?

Incluye una lista de dependencias críticas en el contexto, define reglas en el system prompt que prohíban cambios en esas librerías y valida propuestas en CI antes de merge.

¿Qué formato debo exigir para los patches?

Unified diff (patch) que respete lint y formateo (prettier/eslint). Pide que los parches sean aplicables con git apply y que incluyan tests cuando correspondan.

¿La IA puede sustituir a un reviewer humano?

No. La IA acelera y propone cambios, pero todo patch debe pasar por un humano que entienda el dominio y valide riesgos antes del merge.