Volver al Blog
AI & Development5 de mayo de 202610 min de lectura

Programación Asistida por IA: Qué Delego y Qué No

DR

Doug Ribeiro

10 min de lectura

Hace un año empecé a llevar un registro de cada tarea en la que usé asistencia de IA para programar y la calidad del resultado. No fue un estudio formal, sino una nota personal en mi gestor de tareas con una evaluación de una línea: qué pedí, qué obtuve, si era usable, y si delegaría esa categoría de nuevo. Después de 12 meses de entradas, el patrón es lo suficientemente claro como para escribir sobre él.

La versión corta: la IA es un ingeniero junior altamente capaz que ha leído todos los tutoriales y páginas de documentación jamás publicados, pero nunca ha trabajado en un codebase de producción bajo presión de plazos. Conoce los patrones extremadamente bien. No conoce tu sistema, tus restricciones, la historia de tu equipo, ni por qué ese servicio específico fue diseñado de esa manera. Delega en consecuencia.

Lo Que Delego Sin Dudar

Boilerplate y Scaffolding

Generar un nuevo standalone component de Angular con change detection OnPush, un archivo spec correspondiente, una interface para sus inputs, y la estructura SCSS básica me toma bastante menos de un minuto con un asistente de IA. A mano me toma varios minutos. A lo largo de un día con múltiples componentes, esto se acumula. El resultado es confiable, consistente con los patrones que tengo configurados en el archivo de instrucciones personalizadas del proyecto, y requiere revisión mínima.

typescript
// Prompt I use for scaffolding:
// "Create a standalone Angular component called UserProfileCard.
// It should accept a User input (use the existing User interface from core/models).
// OnPush change detection. Include a loading skeleton state.
// SCSS using design tokens. Spec file with a basic render test."

// Output quality: usable on the first pass, small adjustments for project-specific patterns
// Time saved: most of the typing per component
// Review required: light scan for any deviances from the project rules

Tests Unitarios para Funciones Puras

Aquí es donde veo la mayor calidad de resultado de forma consistente. Dada una función pura con entradas y salidas claras, la IA genera tests unitarios completos incluyendo casos límite que yo podría haber pasado por alto. Proporciono la firma de la función y una descripción del comportamiento esperado, y el suite de tests regresa con happy path, condiciones límite, manejo de null/undefined y tests de validación de tipos.

typescript
// Function I provide:
export function formatCurrency(
  amount: number,
  currency: string,
  locale: string
): string {
  if (amount < 0) throw new Error('Amount must be non-negative');
  return new Intl.NumberFormat(locale, {
    style: 'currency',
    currency,
    minimumFractionDigits: 2
  }).format(amount);
}

// AI-generated tests cover:
// - Standard formatting for CAD/USD/EUR
// - Zero amount
// - Large amounts with thousands separators
// - Locale differences (en-CA vs fr-CA)
// - Negative amount throws error
// - Invalid currency code behavior
// Output quality: the most reliable category in my log, week after week
// Time saved: most of the test-writing time per function

Regex y Manipulación de Strings

Ya no escribo expresiones regulares desde cero. Describo el patrón que necesito en lenguaje natural, pido la regex, pido casos de prueba, y verifico contra ellos. El resultado de regex de la IA es más legible que lo que yo solía producir bajo presión de tiempo, y los casos de prueba que genera a menudo revelan casos límite que no había considerado. Regex de validación para códigos postales canadienses, chequeos de formato de SIN, normalización de números de teléfono: todo delegado. Nota la división: la regla de formato es genérica y se puede entregar sin riesgo, mientras que lo que el código hace después con el valor, enmascararlo, registrarlo, guardarlo, no lo es, y esa parte la escribo yo.

Refactorización de Patrones Conocidos

Convertir un componente declarado en un NgModule a un standalone component, migrar formularios reactivos sin tipar a la API de typed forms, actualizar código RxJS antiguo a patrones más nuevos de RxJS, extraer un bloque repetido en un componente compartido: estas son transformaciones mecánicas donde las reglas son conocidas y la IA las ejecuta con precisión. Sigo revisando el resultado, pero la revisión es confirmación, no reconstrucción.

Mecánicas de CSS y SCSS

Layouts CSS complejos, keyframes de animación, hojas de estilo específicas para impresión, áreas de CSS grid template: estas son áreas donde la IA produce resultados correctos que me tomarían significativamente más tiempo escribir manualmente. Describo el comportamiento de layout que necesito y reviso el resultado para cumplimiento de tokens y compatibilidad de navegadores.

Documentación y JSDoc

Le doy a la IA una función o servicio y le pido que genere comentarios JSDoc. Produce documentación precisa y bien estructurada que luego reviso y ajusto por matices. Esta solía ser la tarea más procrastinada en cualquier proyecto; ahora es un prompt de 30 segundos.

Donde la IA Falla: Lo Que Nunca Delego

Delegar a la IABoilerplate (componentes, servi…Andamiaje de tests unitarios y …Layout CSS/SCSS y reglas respon…Patrones regex y manipulación d…Transformación de datos y funci…Documentación y comentarios JSD…Hacerlo tú mismoDecisiones de arquitectura y es…Lógica de negocio con restricci…Código sensible a seguridad (au…Algoritmos críticos para el ren…Diseño de contratos de API y br…Revisión del código generado po…VS

Decisiones de Arquitectura

¿Debería esta funcionalidad vivir en una librería compartida o en la aplicación host? ¿Deberíamos usar un patrón facade o exponer el store directamente? ¿Estos datos deberían obtenerse de forma eager o lazy? Estas decisiones requieren entender la historia del codebase, las capacidades del equipo, el modelo de despliegue, el presupuesto de rendimiento y la hoja de ruta a largo plazo. La IA te dará una respuesta. La respuesta será plausible y bien razonada. Estará basada en la información que proporcionaste en el prompt, que nunca es el panorama completo.

La IA va a recomendar dividir un servicio en tres microservicios sin saber si tu pipeline de despliegue puede desplegar servicios de forma independiente. Va a recomendar una implementación NgRx para un estado que tu equipo ya planea mover a otro patrón. Las decisiones de arquitectura requieren contexto que vive fuera del codebase.

Lógica de Negocio Específica del Dominio

La lógica de negocio regulada es específica y está moldeada por décadas de evolución del producto. Toma los reclamos de seguros como ejemplo neutral: qué términos de la póliza aplican en la fecha del siniestro, qué le hace el deducible al monto pagado, cuándo un expediente debe escalarse a un ajustador. La IA no tiene conocimiento de las reglas de una aseguradora concreta y generará con confianza código de apariencia plausible que es incorrecto para el dominio, e incorrecto de una forma que se lee como correcta en la revisión. No le doy prompts a la IA con estas tareas en absoluto. Las escribo yo mismo con la especificación del product owner abierta al lado del editor.

Código Sensible a la Seguridad

Flujos de autenticación, verificaciones de autorización, utilidades de cifrado, validación de tokens, verificación de consentimiento: los escribo manualmente, exijo una revisión antes del merge, y no itero sobre ellos con IA. El riesgo de una sugerencia sutilmente incorrecta en esta categoría es demasiado alto, y el esfuerzo de revisión necesario para confiar en el resultado hace que no sea más rápido que escribirlo yo mismo.

Rutas Críticas de Rendimiento

Cuando estoy optimizando un componente crítico para el renderizado, un pipeline RxJS complejo que maneja eventos de alta frecuencia, o una implementación de virtual scrolling, escribo y perfilo manualmente. El código generado por IA es correcto en términos de comportamiento pero raramente óptimo en términos de rendimiento. No conoce tu estrategia de change detection, tu presupuesto de tamaño de bundle, ni qué llamadas están ocurriendo en la ruta crítica de renderizado.

Cómo Ha Evolucionado Mi Delegación

Cuando empecé el registro, la IA ya era parte de mi trabajo diario. Lo que no tenía era un mapa. Delegaba de forma amplia y juzgaba cada resultado por separado, así que seguía entregando categorías que volvían necesitando una reescritura, y seguía haciendo a mano trabajo que la herramienta maneja bien. Los primeros tres meses de entradas sirvieron sobre todo para ordenar esas dos listas.

Para el mes seis, el registro me había dado un conjunto de patrones de prompting específicos para mi flujo de trabajo: firmas de funciones antes de implementaciones, tests antes de código, y restricciones enunciadas explícitamente ('esto se ejecuta en contexto OnPush', 'esto no debe disparar el change detection de zone.js'). Los patrones en sí son simples. Aplicarlos a cada prompt, y no solo cuando me acordaba, es lo que movió la calidad del resultado.

Para el mes doce, mi flujo de trabajo se había estabilizado. La IA maneja una parte grande de mis teclas en un día cualquiera, principalmente en archivos de test, SCSS y boilerplate. El resto es arquitectura, lógica de negocio, revisión y cualquier cosa que requiera conocimiento de cómo funciona nuestro sistema específico. Esa parte es genuinamente valiosa porque es la que encontraba menos interesante y más consumidora de tiempo.

  • Delegación de alta confianza: tests unitarios, boilerplate, regex, SCSS, refactorización, JSDoc
  • Delegación de confianza media: scaffolding de tests de integración, pipelines RxJS complejos (con revisión), utilidades de transformación de datos
  • Delegación de baja confianza: effects de NgRx con efectos secundarios, estrategias de manejo de errores, cualquier cosa que toque autenticación
  • Nunca delegar: decisiones de arquitectura, lógica de negocio del dominio, código sensible a la seguridad, rutas críticas de rendimiento

La Evaluación Honesta

Las herramientas de programación con IA me han hecho significativamente más rápido en las tareas que manejan bien. No me han convertido en mejor arquitecto, mejor experto de dominio, ni mejor revisor. Los ingenieros que conozco que obtienen más valor de estas herramientas son los que tienen clara la distinción: usan la IA para acelerar la ejecución y reservan su propio juicio para las decisiones que lo requieren.

El mejor uso de la IA en desarrollo no es reemplazar el pensamiento. Es eliminar el trabajo que no lo requiere, para que tengas más tiempo y energía para el trabajo que sí.

Registra tus delegaciones durante un mes. No formalmente, solo una nota mental de qué le pediste a la IA y si el resultado fue usable sin revisión significativa. Rápidamente construirás un mapa personal de dónde la herramienta se gana tu confianza y dónde te hace perder el tiempo. Ese mapa es más valioso que cualquier guía genérica de prompting de IA, porque está calibrado para tu dominio específico, tu codebase y tu estilo de trabajo.

Referencias

AIAngularDeveloper ToolsProductivity