Los primeros tres meses que usé Copilot, acepté demasiadas sugerencias. Era un desarrollador senior con cerca de una década en front-end en ese momento, trabajando en Angular desde 2017, y aun así integré bugs sutiles porque el código generado parecía plausible. Una cadena RxJS que usaba switchMap donde necesitaba exhaustMap. Una actualización de signal que evitaba el contrato de inmutabilidad. Un componente con una suscripción que nunca se limpiaba. El código compilaba. Los tests pasaban porque fueron generados por la misma herramienta y testeaban el mismo comportamiento incorrecto. Empecé a ser más selectivo después de eso.
Los dos no compiten tanto en funcionalidades como en el lugar que ocupan. Copilot vive en el editor y completa lo que estoy escribiendo. Claude Code vive en la terminal y trabaja sobre el repositorio: lee archivos que no abrí, hace un cambio repartido en varios de ellos, corre la suite de tests y reacciona a lo que falló. La otra diferencia es dónde vive la política. Copilot Business responde al admin de una organización, que es por lo que era el que usaba en el trabajo. En mis propios proyectos nadie fija esa política más que yo.
Para Qué Son Realmente Buenas las Herramientas de IA
Las ganancias son reales en las categorías correctas. Cualquier tarea que es estructural y repetitiva, donde la forma del output está bien definida y yo solo estaría rellenando un patrón que ya conozco, la IA es más rápida que yo. Cualquier tarea que requiere juicio sobre arquitectura, reglas de negocio o corrección conductual sutil, la IA es una distracción.
- Scaffolding de nuevos componentes y servicios que siguen patrones ya existentes en el codebase
- Escribir test cases de Jest para un componente una vez que la implementación existe
- Generar interfaces TypeScript a partir de formas de respuesta de API o ejemplos JSON
- Drafting de patrones regex y funciones de formateo de fechas
- Refactorizar bloques de código repetitivos en utilidades compartidas
- Sugerir operadores RxJS cuando describes el comportamiento que quieres en lenguaje natural
La ganancia de scaffolding en un servicio Angular típico se nota fácilmente. En un codebase Angular actual, escribir un nuevo servicio con signals, manejo de errores y patrones takeUntilDestroyed, siguiendo las convenciones del codebase, es un trabajo lento y cuidadoso sin IA. Con Copilot referenciando un servicio existente como plantilla, se convierte en una pasada corta con una ronda de correcciones. Eso es tiempo real ahorrado, y se acumula con cada servicio que un equipo agrega.
El Problema de Versión de Angular
Angular ha cambiado más entre v14 y v19 que en cualquier otro punto de su historia. Componentes standalone, signals, la nueva sintaxis de control flow, inject() reemplazando inyección por constructor en la mayoría de patrones, guards funcionales, y del lado de NgRx, el Signal Store. Las herramientas de IA entrenadas con código pre-v16 generarán con confianza los patrones antiguos. Se ven correctos. Compilan. Simplemente no son cómo se escribe Angular hoy.
- Declaraciones de componentes basadas en NgModule en lugar de standalone: true
- Inyección por constructor en lugar de inject()
- Teardown con Subject en ngOnDestroy en lugar de takeUntilDestroyed
- ngIf y ngFor en lugar de @if y @for control flow
- Patrones antiguos de NgRx en lugar de Signal Store para estado de feature
- Inyección por constructor de ActivatedRoute en lugar del nuevo enfoque de input binding
Reviso cada fragmento de Angular generado por IA para estos antes de aceptarlo. Toma unos 15 segundos. Si la herramienta genera un constructor con dependencias inyectadas, lo convierto. Esto no es culpa de la IA. Es un problema de fecha de corte de conocimiento y datos de entrenamiento. La solución es conocer los patrones actuales lo suficientemente bien como para detectar las brechas.
Cómo Uso Claude Code en Mis Propios Proyectos
En mis propios proyectos, o sea mi SaaS y el proyecto paralelo que esté vivo en ese momento, lo que quiero es código que coincida con el proyecto, no código que coincida con la documentación del framework. Así que mantengo un archivo de instrucciones del proyecto en el repositorio describiendo las convenciones, y apunto a los archivos específicos a los que quiero que se parezca una pieza nueva. El prompt de abajo es la forma que funciona: nombrar el archivo de referencia, nombrar los patrones, nombrar los servicios compartidos.
// Prompt approach that produces consistent results
// (illustrative; paths and names are generic):
// "Generate a JobApplicationService following the same patterns as
// src/app/features/inbox/services/inbox.service.ts
// Use inject() for dependencies, expose state via signals,
// handle errors with the ErrorHandlerService already in core,
// and include takeUntilDestroyed where needed."
// The output follows the project's conventions rather than
// the generic Angular answer, which is what you want
// in a codebase that already has standards.
@Injectable({ providedIn: 'root' })
export class JobApplicationService {
private http = inject(HttpClient);
private errorHandler = inject(ErrorHandlerService);
private _applications = signal<JobApplication[]>([]);
private _saving = signal(false);
readonly applications = this._applications.asReadonly();
readonly saving = this._saving.asReadonly();
track(postingId: string, stage: ApplicationStage): Observable<JobApplication> {
this._saving.set(true);
return this.http
.post<JobApplication>('/api/applications', { postingId, stage })
.pipe(
tap(application => {
this._applications.update(list => [...list, application]);
this._saving.set(false);
}),
catchError(err => {
this._saving.set(false);
return this.errorHandler.handle(err);
})
);
}
}Usando IA en un Banco: Cuáles Son las Reglas
En un banco, la conversación sobre herramientas de IA no es opcional. Los bancos fijan políticas sobre qué código puede enviarse a servicios externos de IA, y la versión corta suele ser la misma: nada de lógica de negocio propietaria, nada de datos de clientes, nada de contratos de APIs internas. En BMO, el asistente del equipo era GitHub Copilot Business, que tiene las garantías de privacidad de datos empresariales. No usaba la interfaz de chat para pegar código de servicios internos o modelos de datos.
En la práctica esto significaba que la IA me ayudaba con patrones de Angular y mecánicas de TypeScript, no con la lógica de dominio de préstamos. No le pedía que me ayudara a implementar un algoritmo de decisión crediticia o una verificación de cumplimiento regulatorio. Esos requieren juicio humano y revisión, y enviarlos a una IA de terceros es un riesgo de gobernanza de datos incluso con tiers empresariales.
- Usa suscripciones de grado empresarial con acuerdos de procesamiento de datos
- Nunca pegues credenciales, strings de conexión, secretos JWT o PII en ninguna interfaz de IA
- Nunca pegues lógica de negocio propietaria o schemas de API internas en chat público de IA
- Revisa el código generado de la misma manera que revisas el PR de un desarrollador junior: asume errores, lee cuidadosamente
Los Guardrails, y Cuál Bloquea Realmente un Merge
Los guardrails vienen en capas y no son intercambiables. La capa de instrucciones va primero: un archivo de instrucciones en el repositorio que le dice al asistente qué es el codebase y qué nunca debe sugerir, y en Copilot Business, la exclusión de contenido, que mantiene rutas enteras fuera del contexto del modelo desde el principio. Esa capa moldea lo que se genera, y es la que detallé en el post sobre guardrails de IA en un entorno bancario. No decide qué se mergea. Eso lo decide el pipeline. ESLint con reglas de angular-eslint, Jest con un umbral de cobertura, quality gates de SonarQube, todo eso en cada pull request. Si la IA genera un patrón deprecado, el lint falla y el merge se bloquea. Fíjate en lo que no pasa automáticamente: si te entrega un método de servicio sin rama de error, nada lo atrapa a menos que alguien haya escrito antes la regla de lint o el test. Las dos capas son complementarias, y el orden es el punto. Las instrucciones son un pedido que un modelo es libre de ignorar. Una quality gate en rojo no es negociable. Si solo puedes construir una de las dos este trimestre, construye el pipeline.
// eslint.config.js
// angular-eslint ships flat config from v18, and a v19 workspace
// generates this file instead of .eslintrc.json. These are the rules
// that catch what an AI assistant gets wrong most often in Angular.
// @ts-check
const eslint = require('@eslint/js');
const tseslint = require('typescript-eslint');
const angular = require('angular-eslint');
module.exports = tseslint.config({
files: ['**/*.ts'],
extends: [
eslint.configs.recommended,
...tseslint.configs.recommended,
...angular.configs.tsRecommended,
],
processor: angular.processInlineTemplates,
rules: {
'@angular-eslint/prefer-standalone': 'error',
'@angular-eslint/no-lifecycle-call': 'error',
'@angular-eslint/use-injectable-provided-in': 'error',
'@typescript-eslint/no-explicit-any': 'warn',
'@typescript-eslint/explicit-function-return-type': 'warn',
'no-console': ['error', { allow: ['warn', 'error'] }],
},
});Las herramientas de IA dan apalancamiento al desarrollador que ya conoce el framework. Dan falsa confianza al desarrollador que no.
Mi evaluación general después de dos años de uso diario: Copilot es el que tengo abierto mientras escribo, y Claude Code es al que le entrego una tarea completa cuando el trabajo abarca varios archivos y necesita correr los tests. Las ganancias de velocidad en trabajo estructural repetitivo son reales y se componen a lo largo de un trimestre. La clave es tratar cada sugerencia como un punto de partida, no como una solución. La revisión toma segundos. Saltársela toma minutos en arreglar después, si es que lo detectas.
Referencias
- Acerca de GitHub Copilot. https://docs.github.com/en/copilot/get-started/about-github-copilot
- Angular Signals. https://angular.dev/guide/signals
- angular-eslint flat config. https://github.com/angular-eslint/angular-eslint
- Documentación de Claude Code. https://docs.claude.com/en/docs/claude-code/overview