Saltar al contenido

La lección amarga

Durante décadas hemos afinado patrones, arquitecturas y oficio para escribir mejor software. Pero si la lección amarga se aplica al desarrollo web, el salto de calidad puede venir menos de elegir el patrón perfecto y más de máquinas capaces de generar, probar y comparar muchas soluciones hasta encontrar la adecuada.

La lección amarga

La semana pasada leí "The Bitter Lesson", el ensayo que Rich Sutton publicó en 2019 sobre investigación en inteligencia artificial.

Su argumento es sencillo e incómodo: durante setenta años de IA, los enfoques que acabaron ganando no fueron los más ingeniosos ni los más cuidadosamente diseñados alrededor del conocimiento humano. Ganaron los métodos que podían aprovechar más cómputo. Ajedrez, Go, reconocimiento de voz, visión por computador: una y otra vez, la solución "elegante" basada en conocimiento experto perdió frente a sistemas que buscaban, probaban y aprendían a escala.

Creo que el desarrollo web es el siguiente territorio donde vamos a verlo.

El oficio no desaparece, pero cambia de sitio

Llevamos décadas refinando nuestro oficio. Patrones de diseño, principios de arquitectura, código limpio, guerras de frameworks, debates interminables sobre la forma correcta de modelar un dominio o estructurar una aplicación.

Nos enorgullece escribir soluciones elegantes. Y tiene sentido. Cuando los humanos escriben, revisan y mantienen cada línea, la claridad, la consistencia y el criterio arquitectónico no son un adorno: son lo que permite que el sistema siga vivo.

Pero una IA que escribe código no necesita comportarse como un artesano humano. No necesita intuir el patrón correcto a la primera. Puede generar docenas de implementaciones, ejecutar pruebas, comparar resultados, descartar variantes, medir costes y quedarse con la opción más adecuada.

No porque haya entendido el problema con la profundidad de un buen ingeniero, sino porque el cómputo es barato y cada vez lo será más.

La fuerza bruta vuelve a entrar por la puerta grande

Eso incomoda porque choca con una parte importante de nuestra identidad profesional. Hemos aprendido a desconfiar de la fuerza bruta. La asociamos con soluciones torpes, código duplicado, sistemas difíciles de mantener y decisiones tomadas sin criterio.

Pero la lección de Sutton no dice que la fuerza bruta sea bonita. Dice que, cuando puede escalar, gana.

En software, eso puede significar algo muy concreto: un modelo que no elige una solución porque le parezca elegante, sino porque ha probado varias y una funciona mejor bajo las restricciones disponibles. Pasa los tests. Respeta el estilo del proyecto. Tiene menos casos límite rotos. Encaja mejor con el código existente. Es más fácil de revisar.

La diferencia es que antes probar diez enfoques era caro. Requería tiempo humano. Hoy empieza a ser razonable pedirle a una máquina que explore el espacio de soluciones y traiga las mejores candidatas.

El valor pasa de escribir a juzgar

Esto no vuelve inútil la experiencia de un desarrollador. Pero sí desplaza su valor.

Si la máquina puede producir muchas versiones razonables de una funcionalidad, la pregunta importante deja de ser "quién escribe el código" y pasa a ser "quién define qué significa que este código sea adecuado".

Adecuado no es solo que compile. Adecuado significa que cumple la intención del producto, respeta permisos, cuida datos sensibles, no rompe flujos existentes, se entiende dentro de seis meses y encaja con las restricciones reales del negocio.

Ahí el criterio humano sigue siendo decisivo. Alguien tiene que formular el problema, decidir qué trade-offs importan, detectar una solución frágil aunque los tests pasen y reconocer cuándo una abstracción elegante está resolviendo el problema equivocado.

El oficio no desaparece. Se mueve hacia la definición del objetivo, las restricciones y la evaluación.

La próxima mejora de calidad puede venir de probarlo todo

Durante mucho tiempo hemos esperado que el siguiente salto en calidad de software viniera de mejores frameworks, arquitecturas más limpias o metodologías más disciplinadas. Todo eso seguirá importando.

Pero quizá la mejora más grande venga de otro sitio: de máquinas capaces de probar muchas más opciones de las que un equipo humano puede permitirse, quedarse con lo que funciona y repetir el proceso una y otra vez.

La lección amarga para quienes construimos software puede ser aceptar que el próximo salto no vendrá necesariamente de escribir la abstracción perfecta. Vendrá de sistemas que prueban, miden y eligen a escala.

Y nuestro trabajo será asegurarnos de que saben qué significa "mejor".