Cómo usar IA en Angular correctamente y evitar la deuda técnica

¿Sabes qué es peor que no usar IA en Angular? Usarla mal y creer que todo está bien.

Tiempo estimado de lectura: 6 min

Introducción

Poca gente lo dice en voz alta: la IA no es neutral. Los modelos devuelven lo más probable según lo que han visto… y lo que han visto es código antiguo, tutoriales desactualizados y montones de antipatrón. Resultado: miles de PRs que “funcionan” pero son bombas de deuda técnica con temporizador. Y tú, con suerte, te enteras cuando el bundle explota en producción.

Esto no es una bronca moral. Es una advertencia práctica.

La mayoría de desarrolladores Angular usan mal la IA (y ni siquiera lo saben). Lo hacen porque la IA les da lo que piden y ellos no piden con criterio. Piden “haz un componente” y reciben una reliquia: NgModules, BehaviorSubjects por todos lados, .subscribe() sin limpieza y cero Signals. Compilan. Rompen en escala.

Si eres Tech Lead, Senior o simplemente alguien que no quiere que su app sea un Frankenstein, esto es para ti. Voy a darte lo que nadie te dice en conferencias polidas: cómo usar la IA con Angular sin meter la pata, prompts que funcionan y políticas que evitan que el repo se convierta en un cementerio de buenas intenciones.

Resumen rápido (lectores con prisa)

La IA no es neutral: los modelos devuelven las soluciones más probables según su entrenamiento.

Mucho del código base de entrenamiento corresponde a Angular antiguas (8–12), antes de Standalone Components y Signals.

Pide arquitectura y restricciones (prompts versionados); exige explicación humana y tests para cualquier PR asistido por IA.

Mide PRs IA-assisted por rework, MTTR y memory leaks; si suben, la IA está degradando tu producto.

Primero: lo que realmente está pasando

La IA aprende de repositorios públicos. Mucho del código que alimenta estos modelos fue escrito para Angular 8–12.

Angular cambió. Standalone Components, Signals, Control Flow y takeUntilDestroyed son la nueva guardia.

Los LLMs siguen escribiendo código vintage. Te lo sirven envuelto y listo para mergear.

No es culpa del modelo. Es culpa de quien no lo contextualiza.

La diferencia entre “funciona” y “es mantenible”

La diferencia entre “funciona” y “es mantenible” son decisiones que la IA no puede tomar por sí sola. Tú sí puedes.

Tres antipatrones que detectas rápido (y que matan tu app lentamente)

1) Reactividad híbrida

Un PR mezcla BehaviorSubjects con Signals y subscribes por doquier. Resultado: re-renders inesperados, condiciones de carrera y debugging por mensajes de stack largos. Si lo ves, pide explicaciones claras: ¿por qué RxJS aquí y no Signals?

2) Suscripciones huérfanas

Código que usa .subscribe() sin takeUntilDestroyed o sin unsubscribe. Esto es memoria que se queda. A escala, tu cliente nota latencia y tú notas llamadas perdidas.

3) Módulos por costumbre

Componente “autónomo” que igual requiere NgModule. El bundle crece. El tree-shaking muere. La app se pone lenta en móviles. Y nadie recuerda por qué se introdujo ese módulo en primer lugar.

Cómo arreglarlo sin convertirte en un nazi del código

No se trata de prohibir la IA. Se trata de exigirle reglas de juego. Y versionarlas como si fueran tests.

Regla 1: No pidas código. Pide arquitectura.

Los prompts vagos generan código vagabundo. Los prompts específicos crean artefactos fiables.

Prompt base (cópialo y adáptalo):

“Eres un Staff Engineer especialista en Angular 17+. Refactoriza/crea [componente|servicio|PR] con estas restricciones: 1) Usa Standalone Components. 2) Aplica Signals para el estado local (signal/computed). 3) Limita RxJS exclusivamente a llamadas HTTP con operadores modernos. 4) Usa inject() en lugar de constructor(). 5) Incluye takeUntilDestroyed donde haya subscripciones. Devuélveme: 1) código, 2) tests que cubran casos límite, 3) checklist de riesgos y métricas a vigilar tras deploy.”

¿Ves la diferencia? No “haz un componente”, sino “hazlo según las reglas modernas y explícitas”.

Regla 2: La IA es tu linter arquitectónico, no tu desarrollador

No le pegues un ticket grande a la IA y mergees. Haz que la IA haga refactors y análisis. Pega un componente legacy y pídele migrarlo a Signals y Standalone. Pídele también un diff de riesgos.

Prompt para migración:

“Refactoriza este componente legacy (pego archivo). Reemplaza Observables derivados por computed() Signals. Asegura el mismo comportamiento. Indica: 1) supuestos que cambian, 2) pruebas adicionales necesarias, 3) riesgos operativos.”

Regla 3: Versiona prompts y publícalos en la wiki del equipo

Trátalos como infra. Cambia versión cuando el prompt mejore. Si algo rompe, tendrás historial para auditar: qué prompt produjo qué cambio.

Regla 4: Exige una “explicación humana” en cada PR generado o asistido por IA

Si tu app se rompe, quieres saber quién decidió. No aceptes merges sin:

• Un párrafo (2–4 líneas) que explique por qué la elección es correcta;
• Una lista de escenarios que prueban la decisión;
• Al menos 1 prueba que falla si la suposición es falsa.

Checklist rápido para revisar PRs (lo lees en 60 segundos)

• ¿Usa Standalone Components? Si no, ¿por qué?
• ¿State local con Signals o BehaviorSubjects? Preferir Signals salvo justificación.
• ¿Suscripciones con takeUntilDestroyed o patrón seguro?
• ¿Se agregaron tests para edge cases concurrentes?
• ¿Dependencias nuevas justificadas por RFC?
• ¿Quién será responsable del mantenimiento?

Prompts listos para usar (copiar y pegar)

1. Auditor de PR

   System: “Actúa como Senior Angular Architect.”
   User: “Analiza este diff y responde: 1) tres supuestos operativos que hace, 2) tres formas en que falla a escala y cómo detectarlo, 3) recomendación (aceptar/modificar/rechazar) con pasos concretos.”

2. Generador de Kata (para mentoring)

   System: “Actúa como instructor.”
   User: “Crea un kata en Angular con Signals que contenga un bug sutil de reactividad. Incluye 1) código base, 2) 3 pistas, 3) tests que inicialmente fallan.”

3. Migrador a Signals

   System: “Actúa como Staff Engineer pragmático.”
   User: “Refactoriza este componente a Signals. Mantén el comportamiento funcional. Proporciona diff, pruebas y checklist de rollback.”

Métricas que importan (no las obvias)

Olvida commits por día. Mide lo que realmente previene incendios.

• % de PRs etiquetados “IA-assisted” que requieren rework por problemas arquitectónicos.
• Tiempo medio hasta rollback (MTTR) tras deploys con cambios IA-assisted.
• Número de memory leaks detectados por semana en staging.
• Tamaño del bundle inicial tras merges (trend line).

Si esas métricas suben, tu IA está haciendo algo peor que inútil: está degradando tu producto.

Cultura y políticas (si no las pones, nadie las seguirá)

• Política “IA-assisted” obligatoria: todo PR generado/ayudado por IA debe llevar etiqueta y la explicación humana.
• Prompt Registry: versionado de prompts y ejemplos aprobados por el equipo.
• Pistas obligatorias: Katas que sirvan para evaluar si alguien sabe explicar lo que la IA generó. Si no puede explicarlo, vuelta atrás.
• Guardrails de dependencia: librerías nuevas requieren aprobación de Tech Lead y Security.

Errores reales que verás (y cómo atajarlos)

Error: “Funciona en local, perfecto”.

Realidad: pasó tests, pero explotó en mirror de tráfico. Solución: siempre despliegue con feature flags y monitorización explícita (p95, error budget).

Error: “El junior lo puso en prod con Copilot”.

Realidad: nadie entendía la implementación. Solución: defensa técnica obligatoria. Si quien mergea no lo puede explicar, revert.

Error: “Prompts mágicos de StackOverflow”.

Realidad: la IA copia snippets inseguros. Solución: validación de seguridad automática y revisión manual.

Metáfora que te pega: la excavadora y el plano

Piensa en la IA como una excavadora gigante. Mueve toneladas en minutos. Sin plano, destruye cimientos. El Tech Lead es el que marca dónde cavar, qué pilares dejar intactos y cómo rellenar después. Usar la excavadora sin plano es rapidez sin criterio. Y eso se paga caro.

Último truco: la regla de las tres preguntas

Antes de aceptar un PR asistido por IA, pregúntate:

• ¿Qué suposición técnica hace esta implementación?
• ¿Qué falla si esa suposición es falsa?
• ¿Cómo lo detecto y qué hago en 15 minutos si falla?

Si no puedes responder las tres, no lo merges.

Cierre con acción (porque esto no acaba aquí)

Si quieres dejar de encontrar sorpresas a medianoche, no hay excusas: necesitas prompts, plantillas y un kit de auditoría que funcione desde hoy.

Di “QUIERO EL KIT” y te mando:

• 10 prompts versionados (arquitectura, PR audit, migración a Signals, Katas).
• Plantilla PR con checklist obligatorio.
• Mini-RFC para tu política “IA-assisted”.
• 5 tests de estrés para staging que puedes pegar en CI.

Y si no quieres el kit, al menos copia esto en tu wiki y pásaselo al equipo. Pero no te quedes callado cuando el AI-generated pain llegue: será tarde.

Esto no acaba aquí. Tu repo habla. ¿Vas a escucharlo o seguirás fingiendo que todo está bien?

Dominicode Labs

Si gestionas automatización, IA aplicada, agentes o workflows como parte de tu stack, puede interesarte explorar recursos y experimentos prácticos. Sigue esta continuación lógica: Dominicode Labs.

FAQ

• ¿Por qué se dice que la IA no es neutral?
• ¿Qué son Standalone Components y por qué importan?
• ¿Cuándo debo preferir Signals sobre RxJS?
• ¿Qué debe incluir la explicación humana en un PR IA-assisted?
• ¿Qué métricas concretas debo añadir al dashboard?
• ¿Cómo versiono prompts de forma práctica?

¿Por qué se dice que la IA no es neutral?

Porque los modelos devuelven lo más probable según los datos con los que fueron entrenados. Si ese entrenamiento contiene código antiguo o antipatrón, los resultados reflejarán esas prácticas.

¿Qué son Standalone Components y por qué importan?

Standalone Components son una característica moderna de Angular que permite declarar componentes sin NgModules, reduciendo el bundle y mejorando el tree-shaking. Importan porque evitan módulos innecesarios que aumentan el tamaño y la complejidad.

¿Cuándo debo preferir Signals sobre RxJS?

Preferir Signals para estado local y recalculación reactiva simple; usar RxJS cuando se trabaja con flujos complejos o streams combinados, idealmente limitándolo a llamadas HTTP o casos donde sus operadores sean necesarios.

¿Qué debe incluir la explicación humana en un PR IA-assisted?

Un párrafo de 2–4 líneas justificando la elección técnica, una lista de escenarios que prueban la decisión y al menos una prueba que falle si la suposición es falsa.

¿Qué métricas concretas debo añadir al dashboard?

Por ejemplo: % de PRs IA-assisted que requieren rework por arquitectura, MTTR tras deploys IA-assisted, número de memory leaks detectados en staging y tamaño del bundle inicial por tendencias.

¿Cómo versiono prompts de forma práctica?

Guarda cada prompt en un repositorio o wiki con una versión semántica, ejemplos de entrada/salida y notas de cambios. Trata los prompts como infraestructura: cambia la versión cuando el prompt cambie y registra qué cambios produjo.