La IA en el flujo de trabajo del desarrollador: qué funciona de verdad (y qué es puro hype)

Voy a ser directo: la IA no va a reemplazar a los desarrolladores. Pero tampoco es un juguete. La verdad, como siempre, está en algún punto intermedio, y la mayor parte del discurso sobre la IA en el desarrollo es o bien hype desbordado o bien cinismo despectivo. Ambos se equivocan.

Llevo más de un año usando herramientas de IA a diario en mi flujo de trabajo. No como experimento. En trabajo de producción, liderando equipos y entregando sistemas reales. Esta es mi evaluación honesta y sin hype de qué funciona de verdad, qué no y en qué deberías estar pensando.

En qué es realmente buena la IA

Empecemos por los aciertos. Estas son las áreas en las que las herramientas de IA mejoraron mi flujo de trabajo de forma medible:

Boilerplate y código repetitivo

Aquí es donde la IA brilla más. Escribir DTOs, funciones de mapeo, endpoints CRUD, archivos de configuración, definiciones de tipos a partir de especificaciones de API: el tipo de código en el que el patrón está bien establecido y básicamente estás traduciendo una estructura conocida a sintaxis.

// "Genera un DTO para la respuesta de la orden con estos campos"
// La IA produce esto en segundos, frente a minutos de tipeo:
interface OrderResponseDto {
  id: string;
  status: OrderStatus;
  items: OrderItemDto[];
  total: number;
  currency: string;
  createdAt: string;
  shippingAddress: AddressDto;
  estimatedDelivery: string | null;
}

¿Es revolucionario? No. ¿Ahorra 20 minutos de tipeo tedioso varias veces al día? Totalmente. Y eso se acumula.

Andamiaje de pruebas

Probablemente sea mi caso de uso favorito. La IA es notablemente buena generando el andamiaje de las pruebas: los bloques describe, la configuración y los casos básicos de camino feliz y de error. Acierta con la estructura aproximadamente el 80 % de las veces.

// Describo qué hace la función y la IA genera el andamiaje:
describe('OrderService.calculateTotal', () => {
  let service: OrderService;
  let mockTaxCalculator: jest.Mocked<TaxCalculator>;

  beforeEach(() => {
    mockTaxCalculator = { calculate: jest.fn() };
    service = new OrderService(mockTaxCalculator);
  });

  it('should sum item prices correctly', () => { /* ... */ });
  it('should apply tax from calculator', () => { /* ... */ });
  it('should handle empty order', () => { /* ... */ });
  it('should throw on negative quantities', () => { /* ... */ });
  it('should round to 2 decimal places', () => { /* ... */ });
});

Las aserciones reales y los casos borde los sigo escribiendo yo. Pero tener el andamiaje, los mocks configurados y la organización de las pruebas listos ahorra muchísimo tiempo. Es como tener a alguien que te prepara el banco de trabajo antes de empezar a construir.

Explorar bases de código desconocidas

Cuando entro a un proyecto nuevo o necesito entender una librería que nunca usé, la IA es una excelente compañera de exploración. “Explica cómo funciona esta cadena de middlewares.” “¿Qué aprovisiona este módulo de Terraform?” “Guíame por el flujo de autenticación de este código.”

No siempre acierta. Pero es más rápido que leer la documentación desde cero y me da un punto de partida para mi propia investigación. La trato como a un colega que ya trabajó en ese código: su aporte es útil, pero verifico todo lo crítico.

Documentación y mensajes de commit

Escribir comentarios JSDoc, secciones de README, documentación de APIs e incluso mensajes de commit bien pensados. La IA lo hace sorprendentemente bien porque documentar consiste, en esencia, en describir algo que ya existe, y el código está ahí como contexto.

Sugerencias de refactorización

“Aquí tienes una función de 200 líneas. Sugiere cómo dividirla.” Las sugerencias no siempre están listas para producción, pero son un buen punto de partida para pensar la descomposición. La IA detecta oportunidades de extraer métodos más rápido de lo que yo leo una función larga.

En qué es pésima la IA

Ahora viene lo importante. Estas son las áreas en las que confiar en lo que genera la IA te va a costar caro:

Decisiones de arquitectura

La IA no puede tomar decisiones de arquitectura por tu sistema. No entiende las capacidades de tu equipo, tus restricciones de despliegue, los plazos del negocio, los requisitos regulatorios ni las dinámicas políticas que influyen en las decisiones técnicas.

He visto ingenieros preguntarle a la IA “¿uso microservicios o un monolito?” y tomar la respuesta como palabra santa. La respuesta va a ser coherente. Va a mencionar trade-offs. Va a sonar autorizada. Y va a ser un consejo genérico que ignora todo lo que realmente importa de tu situación concreta.

La arquitectura requiere un contexto que no entra en un prompt. Requiere entender la dinámica de la organización, las habilidades del equipo, la madurez operativa y el rumbo del negocio. La IA no tiene nada de eso.

Lógica de negocio

La lógica central que le da valor a tu sistema (los algoritmos de precios, las reglas de matching, los controles de cumplimiento, los cálculos propios del dominio) es exactamente donde la IA es más peligrosa.

¿Por qué? Porque genera código que parece correcto. Compila. Pasa las pruebas básicas. Pero codifica supuestos sobre tu dominio que pueden estar sutilmente equivocados. Y los bugs sutiles en la lógica de negocio son de los que cuestan dinero real y erosionan la confianza de los usuarios.

Tuve un caso en el que el código generado por IA para un cálculo de descuentos manejaba bien los descuentos porcentuales, pero los aplicaba en el orden equivocado cuando se combinaban con descuentos de monto fijo. El código se veía limpio. Las pruebas, que también generó la IA, pasaban. El bug llegó a staging y habría costado miles en órdenes con precios incorrectos.

Tu lógica de negocio es tu ventaja competitiva. Escríbela tú. Entiende cada línea.

Seguridad

No dejes que la IA escriba tus flujos de autenticación, tu lógica de autorización, tu validación de entradas ni nada relacionado con la seguridad. Los modelos de IA se entrenan con un corpus enorme de código, y una parte importante de ese código tiene vulnerabilidades.

La IA va a generar consultas SQL sin parametrizar. Va a crear validaciones de JWT que no revisan la expiración. Va a escribir manejadores de carga de archivos sin límite de tamaño ni validación de tipo. No siempre, pero sí con la frecuencia suficiente como para que no puedas confiar en ella.

La seguridad es un terreno en el que “funciona la mayoría de las veces” es completamente inaceptable.

La diferencia entre “asistido por IA” y “generado por IA”

Este es el marco que uso para pensar la IA en mi flujo de trabajo, y creo que es la distinción más importante de toda esta conversación.

Asistido por IA: yo manejo. Entiendo el problema, sé cómo debería verse la solución y uso la IA para acelerar las partes mecánicas de la implementación. Reviso cada línea, tomo las decisiones y la IA se encarga del tipeo.

Generado por IA: la IA maneja. Describo lo que quiero, la IA produce la solución y la entrego con una revisión mínima. En esencia, estoy tercerizando el entendimiento.

El primer enfoque te hace más rápido. El segundo te vuelve peligroso.

Mi regla es esta: si no puedes explicar cada línea del código generado por IA, no deberías entregarlo. No “entiendo más o menos lo que hace”: deberías poder explicar por qué se tomó cada decisión, cuáles son los casos borde y cómo falla.

Si no puedes hacerlo, no tienes una solución. Tienes un pasivo.

Cómo uso la IA en el día a día

Este es mi flujo de trabajo real:

Acelerar la revisión de código por la mañana: uso la IA para obtener un resumen rápido de los PRs grandes antes de hacer mi revisión detallada. “Resume los cambios de este PR y señala posibles problemas.” Eso me da un mapa antes de meterme en el terreno. Sigo revisando cada archivo, pero sé dónde concentrar la atención.

Generación de pruebas: cuando escribo un servicio nuevo, primero hago la implementación y después le pido a la IA el andamiaje de las pruebas. Las modifico mucho: agrego casos borde, corrijo aserciones y me aseguro de que las pruebas validen comportamiento y no implementación. Pero el andamiaje ahorra entre un 30 y un 40 % del tiempo.

Explorar librerías nuevas: antes de leer la documentación completa, le pido a la IA que me explique los conceptos centrales y los patrones comunes. Eso me da un modelo mental que hace la documentación más digerible. Siempre seguido de leer la documentación real.

Acelerar el boilerplate: DTOs, mappers, configuración, archivos de migración. Cualquier cosa en la que el patrón esté establecido y yo esté traduciendo una estructura conocida a código.

Para qué nunca uso la IA: decisiones de arquitectura, diseño de esquemas de base de datos, lógica de seguridad, caminos de código críticos para el rendimiento, implementación de reglas de negocio o cualquier código en el que equivocarse sutilmente tenga consecuencias importantes.

Por qué los fundamentos importan MÁS con IA, no menos

Esta es la postura que puede resultar polémica: la IA hace que los fundamentos de la ingeniería de software sean más importantes, no menos.

Si no entiendes los patrones de diseño, no puedes evaluar si el patrón que sugiere la IA es el adecuado. Si no entiendes los índices de base de datos, no vas a notar que la consulta que generó la IA va a hacer un escaneo completo sobre una tabla de un millón de filas. Si no entiendes la semántica de HTTP, no vas a detectar que la IA usó POST donde correspondía PUT.

La IA amplifica lo que ya sabes. Si entiendes el diseño de sistemas en profundidad, la IA te hace muchísimo más rápido. Si no entiendes los fundamentos, la IA te hace muchísimo más eficiente produciendo software roto.

Los desarrolladores a los que mejor les va con las herramientas de IA son los que ya tenían fundamentos sólidos. Usan la IA como una herramienta eléctrica, no como una muleta. Saben lo suficiente para:

• Evaluar críticamente lo que produce la IA
• Detectar errores sutiles que a primera vista parecen correctos
• Dirigir a la IA hacia la solución correcta haciendo mejores preguntas
• Saber cuándo NO usarla, que quizás sea la habilidad más importante de todas

El peligro de la zona de confort

Veo un patrón que me preocupa: desarrolladores que dejan de aprender porque la IA puede cubrir los huecos. No aprenden cómo funcionan las promesas porque la IA escribe su código asíncrono. No entienden los joins de SQL porque la IA genera sus consultas. No aprenden patrones de diseño porque la IA estructura su código.

Eso funciona hasta que deja de funcionar. Y cuando deja de funcionar (cuando estás depurando una condición de carrera a las 2 de la mañana, diseñando un sistema que tiene que soportar 10 veces el tráfico o intentando descubrir por qué el código generado por IA provoca una fuga de memoria) no hay atajos. O entiendes los fundamentos o no los entiendes.

La IA es una herramienta. El ingeniero eres tú. La herramienta no reemplaza la habilidad: la exige.

Reflexiones finales

La IA en el flujo de trabajo del desarrollador es realmente útil. Soy más productivo con ella que sin ella. Eso no es hype: es mi experiencia honesta después de un uso diario intensivo.

Pero las partes útiles son las mundanas. El boilerplate. El andamiaje. La exploración. La documentación. Lo que nunca fue la parte difícil de la ingeniería de software.

Las partes difíciles (entender los problemas a fondo, tomar decisiones de arquitectura con sus trade-offs, escribir lógica de negocio correcta, construir sistemas seguros, guiar a los equipos) siguen siendo habilidades completamente humanas. Y no veo que eso vaya a cambiar pronto.

Usa las herramientas de IA. Vuélvete más rápido en las partes mecánicas del desarrollo. Pero invierte todavía más tiempo en entender los fundamentos. Porque los desarrolladores a los que les va a ir bien en un mundo potenciado por la IA no son los que mejor escriben prompts. Son los que mejor piensan.

La IA es la herramienta eléctrica. El artesano sigues siendo tú. No olvides cuál de los dos importa más.