Decidir qué construir

Hoy es habitual pedirle a una IA una aplicación entera. Describes lo que quieres, esperas unos minutos y tienes delante un formulario, una base de datos y hasta un diseño razonable. Hace cinco años eso llevaba semanas.

Entonces, ¿ya está todo hecho? No exactamente.

Dos tipos de complejidad

En 1986, Fred Brooks publicó un ensayo que se sigue citando casi cuarenta años después: No Silver Bullet. En él separaba la complejidad del software en dos clases. La accidental es la que nos creamos al construir: el lenguaje, las herramientas, la configuración. La esencial es la que trae el propio problema: qué tiene que hacer el sistema, para quién y en qué condiciones.

Cada gran avance desde entonces (lenguajes de alto nivel, frameworks, la nube) ha ido recortando la complejidad accidental. La IA es el mayor salto hasta ahora: escribir código ha pasado a ser casi gratis. La esencial, en cambio, sigue exactamente donde estaba. Brooks ya lo decía: la parte más difícil de construir un sistema es decidir con precisión qué construir.

Veamos tres lugares donde vive esa complejidad.

El contexto, lo que nadie escribe

G. K. Chesterton contaba la historia de una valla en mitad de un camino. Un reformista la ve y dice que no le encuentra utilidad, que habría que quitarla. Alguien más sabio le responde que, precisamente por eso, no debe tocarla: primero tiene que averiguar por qué se puso.

El software está lleno de vallas. Una validación extraña, un paso de más en un proceso, un campo que parece sobrar. Muchas veces son la cicatriz de un problema que ocurrió hace años y que nadie dejó por escrito.

El 1 de agosto de 2012, Knight Capital, uno de los mayores operadores de la bolsa estadounidense, desplegó código nuevo en su sistema de órdenes. Una función antigua, que llevaba años sin usarse pero seguía ahí, se activó por error. En 45 minutos envió más de 4 millones de órdenes y la empresa perdió más de 460 millones de dólares. Antes de la apertura, sus propios sistemas habían enviado 97 emails avisando del problema.

Una IA ve el código que le enseñas. La historia de cada valla hay que ir a buscarla.

Los casos límite, donde vive el riesgo

Un usuario pulsa «Pagar» y la conexión se corta justo después. ¿Se ha cobrado? La app no lo sabe, así que lo vuelve a intentar, y el cliente acaba pagando dos veces.

Los sistemas de pago resuelven esto con una idea preciosa: la idempotencia. Cada operación viaja con una clave única. Si llega dos veces, el servidor reconoce la segunda y devuelve el resultado de la primera, sin repetir el cobro. Stripe, por ejemplo, lo implementa con una cabecera llamada Idempotency-Key.

El camino feliz (el usuario rellena, pulsa y todo funciona) es justo lo que mejor genera una IA. Lo que separa un prototipo de un producto es todo lo demás: el doble clic, la red que se cae, el dato que llega a medias. Para pedirlo, primero hay que saber que existe.

Las decisiones sin vuelta atrás

En su carta a los accionistas de 2015, Jeff Bezos distinguía dos tipos de decisiones. Las de doble sentido son puertas que puedes cruzar y, si no te gusta lo que ves, volver. Las de un solo sentido no tienen vuelta atrás, y piden calma.

Elegir el color de un botón es una puerta de doble sentido. Decidir qué datos personales guardas, cómo proteges las contraseñas o qué parte de un proceso se automatiza sin revisión humana, no. Un dato que nunca guardaste no se puede filtrar; uno que ya se ha filtrado no se puede recuperar.

Para las primeras, la velocidad de la IA es un regalo. Para las segundas, conviene que alguien se pare a pensar.

Tres preguntas antes de generar

La IA es la mejor herramienta que ha tenido nunca quien construye software, y merece la pena usarla a fondo. Lo que cambia es dónde ponemos la atención: menos en escribir y más en entender.

Antes de pulsar «generar», tres preguntas ayudan mucho: ¿por qué está esto así?, ¿qué pasa si algo falla a mitad?, ¿esta decisión se puede deshacer? Quien sabe responderlas ya tiene hecha la parte más difícil del trabajo.