El oficio de la ingeniería de software se está reescribiendo.
La IA ya puede generar buena parte del código rutinario: boilerplate, flujos CRUD, scaffolding de interfaces, pruebas, migraciones y primeras versiones de la lógica de funcionalidades. Eso no vuelve obsoletos a los ingenieros. Desplaza el trabajo real hacia las etapas anteriores y posteriores: definir el sistema adecuado, establecer límites para la implementación, validar el resultado y asumir la responsabilidad por las consecuencias.
Los mejores ingenieros se parecen cada vez menos a mecanógrafos y más a diseñadores de sistemas. El plano importa más que los bytes.
Qué aprenderás
- Cómo el flujo de trabajo anterior a la IA moldeó los hábitos y las métricas de ingeniería
- Por qué el desarrollo asistido por IA hace que las especificaciones sean más importantes, no menos
- Los modos de falla más peligrosos del código generado
- Medidas prácticas que ayudan a los equipos a entregar rápido sin ahogarse en software frágil
El antiguo centro de gravedad: la implementación manual
Antes de que los modelos de lenguaje grandes llegaran al IDE, cada línea de código pasaba por una mente y un teclado humanos. Ya fuera que un equipo siguiera Waterfall, Scrum, Kanban o un ritmo de startup menos estructurado, el esquema era familiar:
Requirements -> Design -> Manual Implementation -> Manual Testing -> DeployLos ingenieros dedicaban buena parte de su tiempo a la implementación manual: escribir boilerplate, crear rutas, integrar frameworks, construir formularios, conectar capas de persistencia y traducir diseños a código. También se trabajaba en la arquitectura, pero gran parte del trabajo visible era la implementación en sí.
La calidad se garantizaba mediante revisión manual de código, pruebas unitarias y de integración, verificaciones de CI/CD y monitoreo en producción. Esos controles importaban, pero por lo general llegaban después de que la implementación ya existía.
Las métricas reflejaban ese mundo. Los equipos hablaban de velocidad, puntos de historia, cantidad de pull requests procesados y, a veces, lamentablemente, líneas de código. El valor de un ingeniero solía asociarse con su dominio de un stack específico, su velocidad de ejecución y su capacidad para depurar un sistema averiado bajo presión.
Ese modelo construyó internet. También significó que profesionales sénior dedicaran una cantidad sorprendente de tiempo a la mecánica de producir código, en lugar de enfocarse en la estructura, la seguridad y la vida útil del sistema.
El nuevo centro de gravedad: de la especificación a la validación
El desarrollo asistido por IA cambia el ritmo:
Detailed Specs -> AI Code Generation -> Automated Validation -> Human Review -> DeployEl cambio importante está al principio. La especificación se convierte en un contrato vivo: qué debe hacer el sistema, qué nunca debe hacer, qué casos límite importan, qué límites de seguridad existen, qué expectativas de rendimiento aplican y cómo se medirá el éxito.
La expresión «vibe coding» de Andrej Karpathy capturó el entusiasmo inicial de describir software en lenguaje natural y ver aparecer el código. Pero el patrón profesional más duradero no consiste en «dejar que el modelo haga lo que le parezca». Se trata de ingeniería disciplinada asistida por IA: las personas definen la intención, las restricciones y los criterios de aceptación; los agentes generan implementaciones candidatas; y las verificaciones automatizadas y el criterio humano deciden cuáles se conservan.
Esto significa que las habilidades de ingeniería más valiosas están cambiando:
- Redacción de especificaciones: Convertir una intención de producto difusa en comportamientos precisos y verificables.
- Diseño de sistemas: Entender cómo encajan los datos, los servicios, las interfaces y los modos de falla.
- Diseño de prompts y contexto: Darles a las herramientas de IA los límites, ejemplos y contexto del repositorio adecuados.
- Revisión de grandes volúmenes: Leer más código generado sin perder de vista defectos sutiles.
- Criterio de seguridad y cumplimiento: Detectar problemas que superan las pruebas del flujo ideal, pero no resisten el análisis en condiciones reales.
Las métricas también deberían cambiar. Un equipo que solo mide el volumen de producción recompensará la complejidad generada. Entre los indicadores más saludables están la tasa de defectos que llegan a producción, el tiempo medio de recuperación, la cantidad de código que se reescribe, la carga de revisión y la relación entre el código útil eliminado y el código nuevo agregado.
Por qué el código generado con IA parece rápido hasta que deja de serlo
El primer 70% de muchas tareas de software se ha vuelto muchísimo más barato. La IA es buena con patrones comunes, frameworks conocidos y flujos ideales. Puede crear una demo convincente más rápido de lo que la mayoría de las personas tarda en abrir todos los archivos necesarios.
La parte difícil es el último 30%: casos límite, integración en producción, accesibilidad, seguridad, observabilidad, seguridad de las migraciones, corrección de los datos y mantenibilidad a largo plazo. Addy Osmani lo describe como el «problema del 70%»: la IA puede llevarte rápidamente hasta muy cerca de la meta, pero el trabajo restante todavía requiere criterio de ingeniería experimentado.
Aquí es donde los equipos se meten en problemas. El código generado parece profesional. Puede que pase las pruebas básicas. La demo funciona. Pero el sistema no está listo.
Modos de falla del desarrollo asistido por IA
1. La trampa de la calidad de demo
La IA puede construir en minutos un prototipo impresionante para el flujo ideal. Los usuarios reales encuentran rápidamente los estados que faltan: solicitudes fallidas, pantallas vacías confusas, controles inaccesibles, dispositivos lentos, condiciones de carrera y rutas de recuperación poco claras.
El código con calidad de demo es útil cuando el objetivo es aprender. Es peligroso cuando se confunde con un sistema listo para producción.
2. El problema del 70%
La IA hace que las partes fáciles parezcan instantáneas y que las difíciles resulten más frustrantes que antes. La última etapa todavía incluye interpretar requisitos, resolver detalles de integración, tomar decisiones de seguridad y aplicar criterio de producto.
El cuello de botella nunca fue solo escribir código. Era comprender.
3. Código como castillo de naipes
El código generado puede unir patrones plausibles sin comprender los invariantes del sistema. Puede funcionar en condiciones simples y fallar bajo carga, concurrencia, entradas inusuales, interrupciones parciales o ante el comportamiento real de los usuarios.
Esto es especialmente riesgoso en bases de código maduras, donde pequeños cambios pueden cruzar límites ocultos.
4. El ciclo de dos pasos atrás
Un desarrollador le pide a una herramienta de IA que corrija un bug. El parche parece razonable, pero rompe otro comportamiento. La siguiente corrección generada introduce dos problemas más. El ciclo continúa hasta que la persona tiene que detenerse, leer el sistema y reconstruir manualmente su modelo mental.
En ese punto, la velocidad se ha convertido en retrabajo.
5. Fatiga de revisión
La IA aumenta el volumen de código. Los ingenieros sénior pueden terminar revisando pull requests más grandes y con mayor frecuencia, con más riesgos ocultos por línea. El cuello de botella de la revisión pasa de «¿podemos escribirlo?» a «¿podemos confiar en él?».
Cuando los equipos ignoran esto, la calidad de la revisión se deteriora justo cuando más necesita mejorar.
6. Puntos ciegos de seguridad
La investigación sobre la seguridad del código generado por IA sigue evolucionando, pero el patrón es lo bastante claro como para tomarlo en serio: el código generado puede incluir vulnerabilidades conocidas, como fallas de inyección, secretos codificados directamente, validación débil de entradas, acceso inseguro a objetos y configuraciones predeterminadas inseguras.
La lección práctica es simple: el resultado de la IA debe pasar por controles de seguridad más estrictos, no más débiles.
7. Atrofia de habilidades
Si los ingenieros junior solo aprenden a escribir prompts y pegar código, puede que nunca desarrollen los modelos mentales necesarios para depurar los sistemas que entregan. Esto crea una brecha peligrosa: las personas pueden producir código más rápido de lo que pueden comprenderlo.
Los equipos necesitan práctica deliberada, no nostalgia. Los profesionales junior deberían usar IA, pero también necesitan dedicar tiempo a las partes difíciles: rastrear bugs, escribir pruebas, comprender las concesiones y construir módulos críticos a mano.
8. Adopción desigual
Las ganancias de productividad con IA son desiguales. Algunos ingenieros aprenden a dirigir las herramientas con precisión; otros aceptan resultados de baja calidad o evitan las herramientas por completo. Sin estándares compartidos, el equipo trabaja de manera inconsistente.
La solución no es solo dar acceso a las herramientas. También hacen falta patrones compartidos, normas de revisión, ejemplos y capacitación.
9. El arte perdido de pulir los detalles
La IA suele producir software funcional antes que software pensado para las personas. Los buenos mensajes de error, las interacciones accesibles, los estados de carga que manejan bien los problemas, los textos cuidados y las configuraciones predeterminadas bien pensadas todavía necesitan criterio humano.
El oficio no desapareció. Se trasladó a los detalles que la IA tiende a simplificar.
Prácticas que evitan que la velocidad se convierta en deuda
Usa las especificaciones como límites
Documenta el comportamiento antes de pedirle a una herramienta de IA que lo implemente. Incluye restricciones de entrada, permisos, estados de error, expectativas de rendimiento, reglas de seguridad, requisitos de observabilidad y criterios de aceptación.
Una especificación útil no necesita ser aparatosa. Necesita ser lo bastante específica para que quien la revise pueda decir: «Esta implementación cumple el contrato» o «Falta este comportamiento».
Usa un ciclo de planificar, implementar y reflexionar
Un flujo de trabajo duradero asistido por IA tiene tres fases:
- Planificar: Documenta la intención de la funcionalidad, los riesgos, los criterios de aceptación y las tareas de implementación.
- Implementar: Usa IA para generar código candidato, pero intervén cuando se desvíe de la arquitectura del sistema.
- Reflexionar: Al terminar, registra las decisiones, las concesiones, las sorpresas y las tareas pendientes para que futuros agentes y personas hereden el contexto.
Esto convierte las sesiones con IA de chats desechables en artefactos de ingeniería.
Construye controles de calidad automatizados
Las pruebas importan más cuando producir código es más barato. El código generado debe pasar por linting, formateo, verificaciones de tipos, pruebas unitarias, pruebas de integración, análisis de seguridad, verificaciones de accesibilidad cuando corresponda y controles de CI que bloqueen las regresiones.
El desarrollo guiado por pruebas es un gran aliado de la implementación asistida por IA porque las pruebas diseñadas por personas delimitan el espacio de búsqueda del modelo. Si la herramienta no puede hacer que las pruebas pasen sin introducir problemas, es una señal de que hace falta intervención humana.
Reemplaza las métricas de vanidad
Las líneas de código y la cantidad bruta de PR son malos indicadores en un flujo de trabajo con un uso intensivo de IA. Pueden recompensar el ruido.
Entre las mejores métricas están:
- Tasa de defectos que llegan a producción: Con qué frecuencia los bugs llegan a producción.
- Tiempo medio de recuperación: Con qué rapidez el equipo resuelve problemas en producción.
- Código reescrito: Cuánto código recién generado se vuelve a escribir poco después del merge.
- Carga de revisión: Cuánto código generado deben inspeccionar los ingenieros sénior.
- Relación entre código nuevo y eliminado: Si la base de código está acumulando código o simplificándose.
El objetivo no es tener más código. Es ofrecer más capacidades correctas y mantenibles.
Establece límites según el riesgo
Usa IA de forma intensiva donde el alcance de un posible fallo sea bajo: prototipos, herramientas internas, migraciones respaldadas por pruebas sólidas, scaffolding, exploración de datos y flujos no críticos.
Aplica una disciplina más estricta a la autenticación, la autorización, los pagos, la criptografía, los datos de salud, los flujos financieros, los sistemas sujetos a requisitos estrictos de cumplimiento y la infraestructura compartida. En esas áreas, la IA todavía puede ayudar, pero el nivel exigido para la revisión humana debe ser mayor.
Aprende como equipo
La ingeniería asistida por IA debe convertirse en una práctica de equipo, no en un hábito individual. Organiza sesiones de revisión de código generado por IA. Comparte prompts efectivos y fallas graves. Documenta los límites de la arquitectura. Crea ejemplos de trabajo generado que sea aceptable.
Los equipos más sólidos no serán los que tengan más herramientas. Serán los que tengan los estándares más claros.
Preserva el dominio profundo del oficio
Los ingenieros todavía necesitan comprender los sistemas a fondo. Eso significa crear espacio para depurar, leer código fuente, escribir pruebas y tomar decisiones arquitectónicas sin delegar a un modelo cada razonamiento difícil.
El futuro no es «la IA escribe y las personas aprueban sin cuestionar». Es «la IA crea borradores y las personas diseñan, verifican y asumen la responsabilidad».
Conclusión
La ingeniería de software no ha abandonado la ingeniería. Lo que ha cambiado es el significado de hacer ingeniería.
Escribir cada línea a mano nunca fue la fuente más profunda de valor. Resolver problemas reales sí lo era. En la era de la programación con IA, los mejores ingenieros son quienes pueden expresar la intención con claridad, diseñar sistemas en los que el código generado pueda funcionar de forma segura y aplicar el criterio humano allí donde las máquinas suelen tropezar.
El plano importa más que los bytes.
Fuentes
- El problema del 70% - Addy Osmani
- El problema del 70% de la IA - Entrevista de Zed con Addy Osmani
- Documentación de GitHub Spec Kit - GitHub
- ¿Qué es el desarrollo guiado por especificaciones? - IBM
- Vulnerabilidades de seguridad en código generado por IA: un análisis a gran escala de repositorios públicos de GitHub - Schreiber y Tippe
- Vibe coding frente a programación agéntica: fundamentos e implicaciones prácticas de la IA agéntica - Roumeliotis y Karkee