La programación no está resuelta

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

Las afirmaciones de que los grandes modelos de lenguaje han “resuelto” la programación reciben una fuerte réplica de ingenieros que señalan que escribir fragmentos o portar código es muy distinto de diseñar, verificar y mantener sistemas complejos. Los comentaristas describen la IA como un acelerador extremadamente potente para boilerplate, refactors y detección de bugs, pero dicen que la programación agentic suele producir bases de código frágiles, hinchadas u opacas que aún requieren humanos con experiencia para la arquitectura, la estrategia de pruebas y la responsabilidad. El consenso emergente es que la IA ha cambiado radicalmente cómo se produce el código, especialmente en tareas rutinarias, pero no ha eliminado las partes difíciles de la ingeniería de software ni la necesidad de juicio humano.

¿Está “la programación” resuelta? Posiciones divergentes

  • Un bando afirma que “la programación está resuelta hoy”: los LLM de frontera pueden escribir, leer, portar y optimizar código en la mayoría de los lenguajes a un nivel igual o superior al humano típico, especialmente para CRUD, algoritmos y refactors.
  • Otros sostienen que esto está sobrevalorado: el código de los LLM sigue siendo peor que el buen código humano, sobre todo en arquitectura, mantenibilidad a largo plazo y requisitos no funcionales (NFR).
  • Varios distinguen entre “programar en pequeño” (funciones, endpoints, ports) como algo en gran medida resuelto, frente a la “ingeniería de software” (requisitos, diseño, tradeoffs, ciclo de vida) como muy lejos de estar resuelta.

Capacidades vs. límites de los modelos actuales

  • Historias de éxito: grandes ports (p. ej., cientos de miles de LOC TypeScript→Rust), flujos de trabajo agentic intensivos, implementaciones de juegos de mesa, mejoras importantes de productividad (se afirman 10×+).
  • Los críticos señalan que a menudo se trata de problemas acotados con oráculos sólidos (comportamiento existente, suites de tests) y no demuestran que el diseño de sistemas greenfield de extremo a extremo esté resuelto.
  • La planificación a largo plazo, la arquitectura global y el diseño de API/tipos a prueba del futuro se citan repetidamente como puntos débiles.

Calidad, slop y code review a escala

  • Muchos informan que la IA permite a desarrolladores débiles producir cantidades mucho mayores de código mal entendido, saturando la revisión humana (de decenas a cientos de miles de LOC por semana).
  • Los revisores de código con IA suelen ponerse quisquillosos con el estilo mientras pasan por alto fallos profundos de diseño; “IA revisando IA” se considera peligroso sin una supervisión humana fuerte.
  • Algunas organizaciones ya tratan los PR generados por IA como básicamente sin revisar, lo que lleva a regresiones, pérdida de observabilidad y problemas sutiles de corrección/rendimiento.

Pruebas, determinismo y “comprensión”

  • Postura pro-IA: si tienes especificaciones sólidas y enormes pruebas automatizadas, importa menos quién o qué escribió el código; los tests y fuzzers también pueden generarse con IA.
  • Postura escéptica: aún necesitas humanos para definir qué probar, interpretar los requisitos y notar comportamientos que no fueron especificados; de lo contrario, los agentes optimizan solo lo que está en los tests y dejan que todo lo demás se degrade.
  • Debate sobre la “no determinación”: algunos dicen que la estocasticidad de los LLM no es peor que el error humano; otros subrayan que una generación opaca y no repetible no es análoga a compiladores o bibliotecas probadas.

Responsabilidad, riesgo y dominios

  • Amplio acuerdo en que la responsabilidad sigue siendo humana/organizacional; la IA no puede ser castigada ni considerada legalmente responsable.
  • Algunos argumentan que la mayor parte del software empresarial es de bajo riesgo y que el slop de IA es “suficientemente bueno”; otros señalan que incluso sistemas mundanos (pagos, logística, administración sanitaria) pueden causar daños reales cuando fallan.

Impacto en roles y habilidades

  • Nueva “habilidad”: orquestar agentes, escribir AGENTS.md y documentación de arquitectura, diseñar especificaciones y pruebas, y bloquear merges en lugar de programar a mano.
  • Preocupaciones sobre “sobredosis de IA” y deshabilitación de habilidades: los juniors quizá nunca desarrollen capacidad profunda de resolución de problemas; los seniors sienten que décadas de experiencia codificando se devalúan.
  • Muchos prevén menos roles de “code monkey” pero una demanda continua de personas que puedan razonar sobre sistemas, requisitos y tradeoffs.