La escalera de la inteligencia

¿Cuánta inteligencia necesitamos de verdad?

Una escalera de inteligencia para el software y una alternativa a la economía de los agentes de programación.

Llevo un tiempo dándole vueltas a una pregunta sencilla:

¿Cuánta inteligencia hace falta de verdad para construir software?

No cuánta inteligencia hay disponible. No lo grande que es el último modelo. ¿Cuánta necesitamos para la cosa concreta que queremos construir?

Pensemos en una aplicación de chat.

Necesita una interfaz, un flujo de mensajes, canales, miembros y alguna forma de saber quién está conectado. Son piezas de software conocidas. Los ingenieros las han construido miles de veces.

Y aun así, si le pido a un agente de programación que construya la aplicación, a menudo recibo una estimación que es poco más que una conjetura.

El modelo se pone a trabajar. Escribe código, ejecuta pruebas, corrige errores y lo intenta de nuevo. A veces lo consigue. A veces se atasca. El coste depende de cuánto dure el bucle y de cuánta inteligencia necesite el modelo por el camino.

Es una forma extraña de comprar software.

Un constructor puede presupuestar una cocina. Una imprenta puede dar precio a cinco mil folletos. Pero con los agentes de programación se nos pide a menudo que empecemos una conversación y confiemos en que la factura tenga sentido al final.

Creo que hay otro camino.

La escalera de la inteligencia

Imagina que el software pudiera construirse a partir de una biblioteca de comportamientos existentes.

Un comportamiento puede ser un flujo de mensajes, una pantalla de inicio de sesión, un campo de búsqueda o un panel de control. Alguien ya lo ha construido, lo ha probado y lo ha hecho reutilizable.

Ahora imagina que pides una aplicación de chat.

El sistema mira la petición y se pregunta:

• ¿Qué partes existen ya?

• ¿Qué partes se pueden montar con piezas existentes?

• ¿Qué partes necesitan una pequeña adaptación?

• ¿Qué partes son realmente nuevas?

Aquí es donde entra la escalera de la inteligencia.

Piensa en ella como una escalera de esfuerzo. Abajo, el trabajo ya se conoce. Arriba, el sistema tiene que inventar algo.

Cuanto más abajo cae la petición en la escalera, menos inteligencia necesita.

Suena obvio. Lo hacemos en todas partes.

Una fábrica no rediseña una silla cada vez que alguien pide una. Usa los mismos componentes, las mismas máquinas y el mismo proceso. El trabajo se abarata porque el conocimiento está guardado en el proceso.

El software puede funcionar igual.

La pieza que falta es una forma de guardar y reutilizar el comportamiento de un programa.

Los comportamientos son los ladrillos

Llevo un año construyendo un sistema en torno a esta idea.

La unidad de trabajo es un comportamiento: una pieza reutilizable de un programa, con su estado, sus eventos y sus datos.

Un comportamiento puede describir cómo aparece un mensaje de chat, cómo se elige un canal o cómo se une un usuario a una conversación. Los comportamientos se combinan para formar comportamientos mayores, y los comportamientos mayores pueden formar una aplicación.

La distinción importante es que el comportamiento no es solo un trozo de texto o un fragmento de código. Es algo que el sistema sabe volver a construir.

Una vez que un comportamiento existe, no deberíamos necesitar un modelo potente para redescubrirlo cada vez que alguien pide lo mismo.

Ese es el fundamento de la escalera de la inteligencia.

Lo estoy construyendo en Almadar Studio, que ahora mismo está en beta y es gratuito.

Cuatro peldaños, de la repetición a la invención

La escalera tiene cuatro niveles.

1. Repetición

La aplicación exacta, o el plan exacto para construirla, ya existe.

El sistema la reconstruye a partir de sus comportamientos guardados.

No hace falta ninguna llamada a un modelo. El trabajo es determinista.

Es la forma más barata de crear software: el sistema ya sabe qué hacer.

2. Acierto completo

La aplicación pedida se parece mucho a algo de la biblioteca.

Quizá quieres una aplicación de chat con otras etiquetas, otra paleta de colores o unos pocos campos más.

Un modelo pequeño puede rellenar esas diferencias. El resto sale de comportamientos existentes.

La parte cara de crear software ya está hecha.

3. Acierto parcial

Algunas partes de la petición ya existen. Otras no.

El sistema reutiliza los comportamientos conocidos y envía solo las piezas que faltan a un modelo más potente.

Si la aplicación de chat necesita un flujo de mensajes conocido pero un nuevo tipo de política de conversación, no hay motivo para reinventar el flujo de mensajes.

Reutiliza lo que se conoce. Gasta inteligencia donde hace falta.

4. Fallo

Nada en la biblioteca se acerca lo suficiente.

Ahora el sistema tiene que escribir un comportamiento nuevo, validarlo y repararlo si es necesario.

Aquí es donde un modelo de programación potente se gana su sitio.

Y esto es lo importante: no todas las peticiones deberían llegar a este nivel.

Hoy los agentes de programación suelen tratar cada petición como si fuera un problema de programación nuevo. Aunque el trabajo sea conocido, se ponen a escribir.

La escalera le da la vuelta a eso.

Cómo se ve en la práctica

La biblioteca de Almadar contiene hoy algo más de mil comportamientos, entre componentes atómicos y componentes mayores compuestos a partir de ellos.

Una aplicación de chat en tiempo real, por ejemplo, se puede montar con comportamientos para:

• El flujo de mensajes.

• Los canales.

• Los miembros de un canal.

• Los usuarios conectados.

• Las políticas de conversación.

Estos usan componentes compartidos, como la estructura de la aplicación, las listas de exploración, los paneles de detalle, la búsqueda, los diálogos de confirmación y las notificaciones.

Ninguno de esos componentes hay que escribirlo específicamente para el chat.

Se construyeron una vez. Se pueden volver a usar.

Esa es la diferencia entre pedirle a un modelo que escriba una aplicación y pedirle a un sistema que la monte.

El primer enfoque empieza con una página en blanco.

El segundo empieza con una biblioteca.

El coste de la inteligencia

Lo he estado probando en local, en mi propia máquina, con distintos modelos de programación.

Los resultados son tempranos, pero muestran por qué esto importa.

Una aplicación nueva de comercio electrónico necesitó 62 llamadas al modelo, alrededor de 1,1 millones de tokens y 13 minutos en un modelo de programación de 30 000 millones de parámetros. El coste estimado fue de unos ocho centavos.

La misma petición en un modelo general de 27 000 millones de parámetros necesitó 127 llamadas, alrededor de 3 millones de tokens, y agotó el tiempo a los 41 minutos. No se produjo ninguna aplicación.

Un pequeño cambio en un panel de control existente necesitó 12 llamadas y unos cuatro minutos en ese mismo modelo general. En un modelo más pequeño, el cambio necesitó tres llamadas y 21 segundos.

No son pruebas de rendimiento de producción, y las cifras cambiarán a medida que el sistema mejore. Pero ilustran algo importante.

El coste del software no es solo el coste del modelo. Es el coste de cuánto trabajo tiene que redescubrir el modelo.

Cuando el sistema puede reutilizar comportamientos conocidos, la cantidad de inteligencia necesaria baja.

Y cuando baja la cantidad de inteligencia, el coste baja con ella.

La biblioteca se acumula

Esta es la parte que me parece más interesante.

Cada comportamiento nuevo que se añade a la biblioteca puede abaratar la construcción de las aplicaciones futuras.

Un flujo de mensajes construido para una aplicación puede servir en una docena más. Un componente de panel construido para una aplicación de empresa puede acabar formando parte de un sistema de gestión escolar. Una política de conversación puede reutilizarse en productos completamente distintos.

La biblioteca se convierte en una especie de memoria compartida del software.

Cuanto más contiene, menos veces tiene el sistema que empezar de cero.

Esto crea un modelo económico distinto para los agentes de programación.

En lugar de pagar a un modelo para que recree el mismo conocimiento una y otra vez, guardamos el conocimiento y lo reutilizamos.

En lugar de tratar cada aplicación como un proyecto de programación nuevo, la tratamos como una composición de comportamientos conocidos y una pequeña cantidad de trabajo nuevo.

La escalera de la inteligencia es la forma de medir esa diferencia.

Hacer software debería ser más barato

Detrás de todo esto hay una pregunta más grande.

¿Quién debería poder construir software?

Hoy, buena parte de la industria está organizada en torno al acceso a una inteligencia cara. El último modelo es mejor. El hardware es más caro. La suscripción es más alta. La aplicación se construye a lo largo de una conversación larga cuyo coste es difícil de prever.

Puede que sea un buen modelo de negocio para las empresas que venden la inteligencia.

Pero no es necesariamente un buen modelo para la gente que quiere construir cosas.

Preferiría ver que la creación de software va en la dirección contraria.

Más componentes compartidos. Más comportamientos reutilizables. Más ejecución local. Costes más previsibles. Menos dependencia de un modelo de vanguardia para cada tarea pequeña.

Una pequeña empresa no debería necesitar acceso al modelo más caro del mundo para construir una herramienta interna útil.

Un desarrollador no debería tener que pagar una larga serie de llamadas a un modelo para recrear un componente que ya existe.

Y una comunidad debería poder construir sobre el trabajo de otros sin tener que comprar otra vez la misma inteligencia.

Eso es lo que significa para mí convertir la tecnología en un bien común.

No hacer que la inteligencia valga menos.

Hacer innecesario gastar inteligencia cara en un trabajo que ya está hecho.

La alternativa al agente de programación

No creo que los agentes de programación vayan a desaparecer.

Son útiles. Pueden escribir código, explorar ideas y resolver problemas que de otro modo llevarían mucho tiempo.

Pero creo que hemos cometido un error al tratar al agente de programación como si fuera todo el proceso de desarrollo de software.

Un modelo sentado delante de un proyecto en blanco no es la única forma de construir software.

Podemos construir sistemas que saben lo que ya se ha construido.

Sistemas que pueden medir el trabajo antes de empezar.

Sistemas que usan modelos pequeños para las tareas conocidas y modelos potentes solo cuando hace falta algo realmente nuevo.

Sistemas que se abaratan a medida que crecen sus bibliotecas.

Esa es la dirección que estoy explorando con Almadar.

El objetivo no es construir un chatbot mejor que escriba más código.

Es construir un sistema en el que el conocimiento del software se pueda guardar, compartir y reutilizar.

En el que la siguiente aplicación no empiece con una página en blanco.

En el que la inteligencia necesaria para construir algo sea proporcional a lo nuevo que ese algo es de verdad.

Y en el que el coste de construir software se acerque al coste de montarlo.

Puede que el futuro de los agentes de programación no consista en hacer los modelos más inteligentes.

Puede que consista en hacer que necesiten menos inteligencia desde el principio.