Por qué la IA no ha reemplazado a los ingenieros de software, y no lo hará

Artículo original ↗ Discusión en Hacker News ↗

Capacidades y límites de la programación con LLM

  • Los LLM ahora pueden montar aplicaciones completas (web, móvil, infraestructura como código) y encargarse de tareas no triviales (ingeniería inversa de firmware, scripts de seguridad, Terraform/Ansible, Frida, etc.).
  • Destacan en el código repetitivo, el cableado y los problemas de backend “con forma de texto”; son mucho más débiles en UX matizada, gusto visual y casos límite.
  • Los modelos siguen cometiendo errores lógicos básicos (por ejemplo, ordenar fechas como cadenas) y perseguirán con seguridad rutas incorrectas sin darse cuenta.
  • Un uso eficaz requiere una fuerte guía humana, pruebas y revisión; el “vibecoding” sin guía produce grandes volúmenes de código frágil y de baja calidad.

Greenfield vs mantenimiento y complejidad

  • Para desarrolladores individuales y equipos muy pequeños, los LLM hacen viables proyectos de 50–100k líneas de código que antes eran imposibles; el tiempo pasa de teclear a planificar, leer y hacer QA.
  • En sistemas más grandes (muchos ingenieros, cientos de funciones), la complejidad, el acoplamiento y las restricciones invisibles dominan. Los LLM aún no gestionan bien esto.
  • Los prototipos greenfield son en gran medida automatizables; el mantenimiento a largo plazo, la integración con sistemas heredados y la seguridad siguen siendo difíciles y muy intensivos en trabajo humano.

Reemplazo vs aumento

  • Algunos informan de un reemplazo concreto de “varios desarrolladores” en pequeñas startups y proyectos personales; otros sostienen que se trata de proyectos completamente nuevos que nunca habrían contratado ingenieros.
  • Muchos ven la IA como un multiplicador de fuerza: un buen ingeniero + agentes pueden reemplazar a un equipo mucho más grande y mediocre, especialmente en proyectos nuevos.
  • Consenso: los desarrolladores débiles o “movedores de tickets” son los más expuestos; los ingenieros fuertes que pueden especificar, revisar, depurar y diseñar alrededor de agentes ganan apalancamiento.

Decisión, conocimiento de dominio y responsabilidad

  • El valor central se desplaza hacia:
    • Decidir qué construir (pensamiento de producto, conocimiento de dominio).
    • Verificar y ser responsable de lo que se entrega (pruebas, seguridad, cumplimiento).
    • Entender el código y el contexto del negocio lo bastante a fondo como para navegar los trade-offs.
  • El personal no técnico ya está construyendo herramientas internas con IA, pero rápidamente topa con muros de complejidad y se convierte, de facto, en desarrolladores insuficientemente formados.
  • Las organizaciones siguen necesitando un “chivo expiatorio” humano y aún no pueden descargar en la IA la responsabilidad legal/operativa; los proveedores no ofrecen garantías de responsabilidad.

Efectos económicos y en el mercado laboral

  • Algunos esperan un momento “impresora 3D/CNC”: muchas más herramientas pequeñas y a medida, menos puestos tradicionales de desarrollo, menor salario medio, mayor salario para los mejores.
  • Otros señalan patrones históricos: la automatización tiende a expandir la demanda total de software, no a reducirla, aunque cambian roles y títulos concretos.
  • Preocupa que la IA mercantilice la programación, vacíe los roles de nivel medio y concentre las recompensas en un conjunto más pequeño de “pastores de IA” de alta cualificación.