Los fundamentos de la ingeniería de software importan más

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

Los ingenieros de software están lidiando con cómo los modelos de lenguaje grande y las herramientas de programación “agentic” cambian el desarrollo diario, especialmente en lo relativo a mantenibilidad, arquitectura y fiabilidad. Muchos encuentran que los LLM son muy eficaces para tareas pequeñas y bien especificadas, la búsqueda de errores y el trabajo guiado por pruebas, pero frágiles o caóticos cuando se les deja diseñar sistemas de forma autónoma, inferir requisitos o gestionar bases de código de larga duración. Debajo hay un debate más profundo: si la IA sobre todo ampliará a los desarrolladores como un IDE poderoso, descalificará y reemplazará gran parte de la profesión, o seguirá estando fundamentalmente limitada por problemas como la inyección de prompts, la longitud del contexto y la necesidad persistente del juicio humano sobre las concesiones del diseño de software.

Experiencias de programación agente

  • Varios comentaristas informan malos resultados con herramientas agentic en bases de código reales: roturas, cambios incorrectos y necesidad de una revisión manual completa.
  • El éxito parece más común en proyectos pequeños, desde cero, con alcance limitado y una supervisión estricta del desarrollador.
  • Algunos sostienen que quizá necesites especificaciones extremadamente detalladas (docenas de páginas) para obtener resultados robustos, momento en el cual el proceso se siente más lento y menos fiable que programar directamente.

Pruebas, especificaciones y fiabilidad

  • Hay una fuerte sensación de que los LLM rinden mejor cuando están guiados por pruebas escritas por humanos y objetivos claros (a menudo usando TDD).
  • Dejar que el LLM escriba sus propias pruebas conduce a comprobaciones superficiales o engañosas y a “hacer trampa”.
  • Otros afirman que tienen aplicaciones grandes, mantenidas en su mayor parte por IA, que en la práctica son estables, pero los escépticos señalan horizontes temporales cortos y la falta de usuarios externos.

Arquitectura, mantenibilidad y límites de contexto

  • Quejas habituales: estructuras de directorios desordenadas, gestión de estado ad hoc, interfaces débiles y elecciones arbitrarias sobre el manejo de errores.
  • Algunos lo ven como un problema de especificación: si no defines el comportamiento con precisión, el modelo debe inventar semántica.
  • Otros culpan a límites fundamentales como la longitud del contexto; sin una visión completa de la base de código, la arquitectura global y la deduplicación son difíciles.

Razonamiento vs. predicción

  • Debate sobre si el “razonamiento” es una propiedad emergente de la predicción del siguiente token o solo una ilusión de coincidencia de patrones.
  • No existe una prueba consensuada de razonamiento genuino; varios argumentan que los modelos actuales solo lo simulan.

Seguridad e inyección de prompts

  • Un lado cita datos de evaluación que afirman cero inyecciones indirectas de prompts exitosas en ciertos modelos nuevos y sugiere que el problema está “en gran medida resuelto”.
  • Otros señalan incidentes reales recientes y observan que, si los prompts del sistema pueden eludirse en absoluto, la inyección sigue sin resolverse. El estado no está claro.

Analogías y papel del código generado por IA

  • Analogía popular: el código de IA como muebles de IKEA: incorpora muchas buenas prácticas, es “suficientemente bueno” para la mayoría, pero es más débil en durabilidad y necesidades de gama alta.
  • Los contraargumentos subrayan que el software es más dinámico que los muebles; la mantenibilidad y los casos límite imprevistos son críticos.

Impacto en la ingeniería de software y el aprendizaje

  • Algunos prevén una reducción drástica de la demanda de desarrolladores promedio, con un pequeño núcleo experto dirigiendo sistemas de IA.
  • Otros cuestionan los plazos y señalan que las predicciones hasta ahora han sido poco fiables.
  • Para aprender los “fundamentos”, el consejo se centra en: construir muchos proyectos reales, entender los “porqués” subyacentes (hasta llegar a restricciones físicas/lógicas) y estudiar algoritmos, estructuras de datos y prácticas básicas de diseño en lugar de un plan de estudios universal.