Si la IA se vendiera de forma honesta

—¿Es determinista? —No. —¿Reproducible? —Tampoco. —¿Explicable? —Menos. —¿Y qué vendes entonces? —Velocidad. Un diálogo satírico sobre qué pasaría si la IA se vendiera de forma honesta.

La mayoría de los argumentos para vender IA aplicada a la programación suenan parecido: “ingenieros 10x”, “entrega más rápida”, “tu equipo, supervitaminado”. Imaginemos, por un momento, que diéramos con un consultor honesto.

En un universo paralelo, nuestro protagonista llegaría a ACME Inc. para vender a su equipo de ingeniería un producto revolucionario: un modelo de lenguaje especializado en código. En la sala, ingenieros sénior. Los que llevan años creando y manteniendo el sistema.

La conversación podría ser algo parecido a esto:

—Hoy os presento una nueva forma de programar. Describís lo que queréis en lenguaje natural y un modelo estadístico genera el código que, muy probablemente, hará lo que le habéis pedido. Luego, solo lo verificáis.

Alguien en el fondo levanta la mano.

—Verificarlo, ¿cómo?

—Leyéndolo. O ejecutándolo. O escribiendo tests. Lo que sea que hacéis cuando un júnior os entrega código.

—Entonces, ¿todavía tenemos que entender el código?

—Sí.

—¿Qué ahorramos, pues?

—Escribirlo.

La sala se queda muda. El consultor prosigue.

—El modelo no es determinista. Una misma entrada puede dar salidas diferentes. No podéis reproducir una sesión. El código puede invocar APIs o métodos que no existen, pero que parecen existir. Las llamamos alucinaciones. Suena mejor que “errores”. Y no son bugs que podamos arreglar: forma parte del diseño.

—Disculpa, ¿con qué frecuencia alucinan los modelos?

—Poco. Aunque recomendamos verificar cada línea antes de subirla a producción.

—¿Y eso no es más lento que escribirlo directamente?

—Para séniors en su dominio, sí. Es útil cuando no sabes lo que haces. En prototipos de usar y tirar. En tareas mecánicas, como refactorizar.

—Vale. ¿Y los modos de fallo?

—Opacos. El modelo no sabe explicar por qué ha generado lo que ha generado. Usa el mismo tono cuando acierta que cuando se equivoca estrepitosamente. La mejor señal de que se ha equivocado es que tu código no funcione. Con suerte, fuera del horario de guardias.

—¿Y dónde corren estos modelos?

—El servicio depende de nuestra infraestructura. Si los servidores se caen, dejáis de trabajar. A veces ajustamos el rendimiento del modelo para ahorrar costes: lo que funcionaba ayer deja de funcionar hoy. Subimos precios sin previo aviso. Retiramos modelos viejos con regularidad: si habíais construido sobre ellos, toca readaptar.

Un par de ingenieros se miran. Uno empieza a tomar notas.

—¿Y qué pasa con el código que os enviamos? Algunos repositorios contienen secretos, lógica de negocio, datos de clientes.

—Buena pregunta. Vuestros prompts pasan por nuestra infraestructura. Aplicamos las garantías establecidas en nuestros términos de servicio, que actualizamos de vez en cuando. Históricamente, hemos usado conversaciones para mejorar el producto. Si queréis prevenirlo, existe un plan empresarial. Cuesta más.

—¿Y qué nos puedes decir sobre los datos de entrenamiento?

—Son lo mejor de lo mejor. Hemos rastreado internet e incorporado todo el código abierto que pudimos. Muchas veces, sin respetar la licencia, por lo que la legalidad del código que genera es cuestionable. También hemos peinado Stack Overflow e incorporado algunas respuestas con votos negativos. No demasiadas.

—¿Y qué ganamos con todo esto?

—Velocidad.

—Velocidad, ¿medida cómo?

—En líneas de código generadas. ¿Os he dicho que cobramos por cada línea que generamos? Estamos incentivados a producir mucho código, quizás demasiado. Pero más código entregado, más pull requests, más tickets cerrados por sprint.

—¿Y la calidad?

—No podemos garantizar que el código sea correcto, solo que lo parezca. Pero sí garantizamos que un ingeniero con nuestro modelo cierra el doble de tickets. Habrá más bugs, claro. Pero la degradación es lenta. Tardará en aparecer en vuestros dashboards y, mientras tanto, los puntos por sprint suben hoy.

Silencio incómodo. Un ingeniero júnior recién llegado a la empresa se levanta.

—Disculpa. Dijiste que venías a enseñarnos una nueva forma de programar. Pero esto no parece una nueva forma de programar. Parece una herramienta útil para algunas tareas repetitivas, pero con un coste de verificación cada vez mayor. ¿Me equivoco?

—No te equivocas. Pero si lo contase así sería mucho más difícil de vender.