Durante mucho tiempo, he estado construyendo un sistema de IA complejo.
Comenzó como un producto bastante específico. Con el tiempo, creció hasta incluir ejecución, herramientas, memoria, permisos, tareas de larga duración, capacidades externas y múltiples formas de producto. A medida que se hizo más grande, dediqué menos tiempo a preguntarme cómo añadir otra funcionalidad y más a plantearme una clase diferente de preguntas: ¿Dónde debería residir una capacidad? ¿Quién tiene la autoridad final para interpretarla? ¿Qué decisiones deberían dejarse al modelo y qué garantías deben provenir del software? ¿Se convertirá el mecanismo que nos ayuda a entregar hoy en una frontera de la que no podamos escapar mañana?
Estas preguntas parecen preguntas de arquitectura. En la práctica, cambiaron cómo pienso sobre el propio software.
El software tradicional se construye en torno a instrucciones. Un programador define la ruta de antemano y la máquina la sigue con precisión: si ocurre A, haz B; si la entrada es C, devuelve D. Gran parte del valor del software ha consistido en convertir el juicio humano en pasos estables y repetibles.
La IA cambia este arreglo. Por primera vez, las máquinas pueden decidir qué hacer a continuación en una variedad significativa de situaciones. Ya no necesitamos enumerar cada ruta. Podemos describir un objetivo, proporcionar un entorno y retroalimentación, y dejar que un modelo formule un plan, elija herramientas, observe el resultado y se ajuste.
Eso puede dar la impresión de que, a medida que los modelos se vuelven más capaces, el software se vuelve menos importante.
Mi experiencia me ha llevado a la conclusión opuesta. El software no está desapareciendo. Lo que está cambiando es el objeto de su responsabilidad.
Antes, el software le decía a la máquina qué hacer a continuación. Ahora un modelo puede elegir el siguiente paso, pero el software todavía tiene que responder a un conjunto diferente de preguntas: ¿Qué es verdad? ¿Qué está permitido? ¿Qué cuenta como completo? ¿Quién es responsable cuando algo sale mal? ¿Cómo se convierte una acción inteligente en un resultado en el que las personas puedan confiar?
He llegado a creer esto:
Los modelos generan posibilidades. El software convierte la posibilidad en orden.
El software ya no es meramente el conjunto de instrucciones en torno a la IA. Se está convirtiendo en la capa institucional del mundo que habita la IA.
Los principios siguientes surgieron gradualmente mientras construía, descartaba, reconstruía y verificaba diferentes partes de este sistema. No son una guía de arquitectura para un producto concreto, ni tampoco una metodología universal. Son simplemente las ideas que ahora considero dignas de llevar a lo que construya a continuación.
1. Define qué estás construyendo antes de que la interfaz de hoy defina el destino
La deriva más peligrosa en un proyecto de larga duración no es equivocarse en una funcionalidad. Es olvidar gradualmente qué te propusiste construir.
Los productos siempre comienzan a través de un punto de entrada concreto. Puede ser una interfaz de chat, una utilidad de escritorio, un editor, un navegador o un banco de trabajo. Debido a que estas cosas son visibles y utilizables, fácilmente comienzan a definir todo el proyecto a la inversa: el proyecto se convierte en lo que sean las pantallas que existen hoy, y su futuro se convierte en una expansión de la funcionalidad que esté actualmente más madura.
Pero el producto actual suele ser un vehículo para validar el destino, no el destino en sí.
Aprendí a separar deliberadamente tres cosas: lo que en última instancia quiero construir, la base común necesaria para apoyar ese objetivo y lo que los usuarios pueden usar genuinamente hoy.
Las tres deben conectarse, pero nunca deben hacerse pasar unas por otras.
Si hablas solo del destino, el proyecto se convierte en una visión sin entregable. Si hablas solo del presente, el proyecto queda atrapado por su interfaz actual y su implementación temporal. Si no hay una base común, cada nueva forma de producto tiene que reinventar la ejecución, el estado, los permisos y la memoria.
Esta distinción cambió muchas de mis decisiones. Dejé de decidir dónde pertenecía una funcionalidad preguntando únicamente dónde podía implementarse más rápido. Empecé a preguntarme si era una experiencia única del producto actual o una capacidad del sistema que los productos futuros también necesitarían. Una implementación temporal puede ser imperfecta, pero no debería permitírsele redefinir el objetivo a largo plazo.
Lo primero que necesita un sistema longevo no es una hoja de ruta. Es un sentido de las capas: cuál es la dirección, cuál es la base y qué es meramente la forma en que el sistema llega a los usuarios hoy.
2. Pregunta «¿Quién es el dueño de esto?» antes que «¿Cómo lo construimos?»
Gran parte de la complejidad del software no la causa demasiado código. La causa una responsabilidad que no tiene hogar.
Cuando un concepto no tiene un dueño claro, naturalmente comienza a replicarse. La interfaz guarda una versión del estado, el backend guarda otra y un archivo de configuración guarda una tercera. Ninguna es obviamente incorrecta, pero ninguna puede dar la respuesta final cuando discrepan.
Entonces el sistema empieza a acumular lógica de sincronización. Un cambio en un lugar tiene que notificar a los otros dos. Una notificación se pierde ocasionalmente, así que se añade recuperación. El orden de recuperación resulta inestable, así que se añade compensación. La compensación crea otro estado, así que se añade reconciliación. El código trabaja cada vez más duro mientras el sistema se vuelve más difícil de explicar.
Antes me sentía atraído de inmediato por la cuestión de cómo conectarlo todo. Ahora hago primero preguntas diferentes:
- ¿A quién pertenece realmente este concepto?
- ¿Quién lo crea, lo interpreta y lo termina?
- Si se desactiva, se migra o se elimina, ¿qué parte del sistema comprende el significado completo de ese cambio?
- ¿Otros componentes reciben la verdad, o meramente una vista proyectada desde ella?
Solo después de que esas preguntas tengan respuesta importa la estrategia de conexión.
«Propiedad» suena a un término de organización del código, pero creo que expresa un principio mucho más amplio: todo lo que persiste necesita una parte responsable de todo su ciclo de vida. De lo contrario, todos pueden cambiarlo, pero nadie lo comprende de verdad.
Esto también me ha dado una fuerte preferencia por un único intérprete final de cada hecho. Otros componentes pueden observar, almacenar en caché, presentar y usar ese hecho, pero no deberían inventar versiones igualmente autoritativas de él.
Los sistemas complejos no temen tener mucho estado. Temen tener demasiadas autoridades.
3. Consolida los mecanismos, no las experiencias de usuario
A medida que un sistema crece, crear un nuevo mecanismo para cada nuevo requisito es tanto la opción más natural como la más peligrosa.
Una capacidad es ligeramente diferente, así que recibe una nueva ruta de registro. Un caso de uso es algo inusual, así que recibe un nuevo modo. Una pieza de estado aún no tiene un hogar obvio, así que recibe un almacén separado. Una nueva ruta de ejecución es inconveniente de integrar, así que evita la ruta existente y crea otra.
Cada decisión parece razonable de forma aislada. Juntas, producen sistemas paralelos para el descubrimiento, los permisos, la carga, las actualizaciones, la desactivación y la recuperación. El costo real no son unas pocas clases extra. Es que cada capacidad futura tiene que responder las mismas preguntas de nuevo en todos esos mecanismos paralelos.
Aprendí gradualmente a distinguir entre dos tipos de diversidad: la diversidad que experimentan los usuarios y la diversidad que el sistema debe mantener internamente.
Los usuarios pueden y deben encontrar productos, puntos de entrada e interacciones muy diferentes. Contextos diferentes merecen su propio lenguaje y modelos mentales. Pero por debajo de esas experiencias, las capacidades pueden entrar en el sistema, recibir permisos y adquirir ciclos de vida a través de un pequeño número de mecanismos estables.
Consolida el mecanismo, no la experiencia.
La parte difícil de este principio es resistir la tentación de crear algo nuevo porque es más fácil de conectar. Antes de introducir otro mecanismo, ahora me pregunto si el actual realmente no puede expresar la necesidad, o si uno nuevo es simplemente más conveniente a corto plazo.
«Se ve un poco diferente» normalmente no es razón suficiente para crear un nuevo eje en el sistema.
Los mecanismos estables no están ahí para que los diagramas de arquitectura se vean más limpios. Reducen el costo cognitivo futuro: los modelos, los desarrolladores y los productos ya no tienen que adivinar entre varias formas casi equivalentes de hacer lo mismo.
4. El software debe restringir las consecuencias, no prescribir el proceso de pensamiento del modelo
Aquí es donde más cambió mi pensamiento.
Cuando el comportamiento del modelo es inconsistente, el impulso natural es codificar el flujo de trabajo ideal en el software. Exigir investigación antes de planificar, planificación antes de ejecutar y una etapa completada antes de que pueda comenzar la siguiente. Ejecutar verificación después de cada cambio. Añadir otra puerta de ejecución cada vez que el modelo parezca probable que tome el camino equivocado.
Estos sistemas suelen diseñarse con buenas intenciones. Pero a menudo se convierten en canalizaciones rígidas. Un modelo que podría adaptar su enfoque al tamaño y la forma de la tarea se ve obligado a completar cada etapa incluso para una solicitud simple. Múltiples barreras de protección también pueden interactuar y crear un bloqueo del que el modelo no tiene forma de escapar.
Comencé a usar una prueba más simple para decidir qué pertenece al software y qué debe permanecer con el modelo: ¿la regla restringe unmétodo o unaconsecuencia?
«Leer antes de editar», «presentar una propuesta antes de la implementación» y «recordar verificar al final» son métodos. Pertenecen a los prompts, las habilidades y el contexto, donde el modelo puede entenderlos y aplicarlos con flexibilidad.
«No acceder a datos sin autorización», «no causar pérdidas irreversibles sin confirmación» y «no eludir un permiso que el usuario deshabilitó explícitamente» son límites sobre consecuencias. No pueden depender de que el modelo los recuerde. El software debe hacerlos cumplir.
Las barreras mecánicas de protección contra la repetición, la inactividad y los bucles también deben usarse con moderación. Debe permitirse un primer intento. Cuando el sistema bloquea una acción, debe explicar por qué. Y debe proporcionar una vía clara de recuperación en lugar de atrapar al modelo detrás de la barrera de protección.
Esto cambió cómo entiendo la división del trabajo entre modelos y software:
Dar objetivos y métodos al modelo. Dar límites no negociables al software.
Si el software prescribe cada paso del proceso de razonamiento, simplemente hemos reconstruido un motor de flujo de trabajo con IA dentro de él. Si cada límite vive solo en un prompt, hemos entregado la responsabilidad real a la probabilidad.
Un buen sistema evita ambos extremos.
5. Mantener la realidad inequívoca en lugar de hacer que el modelo suene seguro
El razonamiento de un modelo puede permanecer abierto. Su lenguaje puede variar. Sus planes pueden revisarse. Pero una vez que comienza a actuar sobre el mundo real, algunos hechos no pueden ser ambiguos.
¿Realmente comenzó una tarea? ¿Realmente ocurrió un cambio? ¿Está habilitado un permiso? ¿Qué sesión es dueña de un resultado? La respuesta a estas preguntas no debería cambiar según qué pantalla las esté mirando.
Cada vez pienso más en el software como la capa de realidad de un sistema de IA. Un modelo puede ofrecer interpretaciones del mundo, pero el software registra lo que realmente ocurrió en él.
Eso significa que una interfaz puede expresar un estado pero no puede convertirse en el estado mismo. Los parámetros adjuntos a una solicitud pueden expresar intención pero no pueden anular temporalmente la autoridad duradera. Una caché puede mejorar el rendimiento pero no puede adquirir el mismo estatus que su fuente. Cuando el sistema no puede establecer un hecho, debe detenerse honestamente en lugar de adivinar la respuesta más conveniente para preservar una sensación de fluidez.
El software tradicional también necesita consistencia, pero la IA lo hace aún más importante. Los modelos son excepcionalmente buenos para continuar a partir de información incompleta y producir explicaciones que suenan plausibles. Cuando los hechos subyacentes ya han divergido, la inteligencia en la cima puede hacer que la contradicción se sienta más coherente y permitir que el problema permanezca oculto por más tiempo.
Mi principio es, por lo tanto, simple: permitir que el modelo sea incierto, pero no permitir que los hechos del sistema se vuelvan ambiguos.
Cuando el sistema no sabe, debe decir que no sabe. Cuando los datos autoritativos están dañados, debe negarse a actuar. Cuando dos fuentes entran en conflicto, debe exigir que se resuelva el conflicto en lugar de elegir silenciosamente el más fácil.
La inteligencia puede trabajar con ambigüedad. Las instituciones deben preservar la realidad.
6. La reversibilidad es un requisito previo para la autonomía
A menudo definimos la autonomía de la IA como hacer menos preguntas al usuario. Pero lo que determina si un usuario está dispuesto a soltar el control no es el número de diálogos de confirmación. Es si el sistema les permite ver, detener, corregir y recuperar.
Si cada paso requiere confirmación, la IA se convierte en una herramienta semiautomática que exige clics constantes. Si nada requiere confirmación y no hay registro ni camino de vuelta, la autonomía se convierte en una pérdida de control.
Comencé a prestar más atención a un conjunto diferente de cualidades: ¿Es visible el proceso? ¿Se puede interrumpir la acción? ¿Se pueden revisar los cambios? ¿Es rastreable el historial? Después de un fallo, ¿puede el sistema recuperarse a un estado cuyo significado sea claro?
La reversibilidad no es una capa extra de seguro para cuando algo sale mal. Es una condición previa para otorgar autoridad en primer lugar.
Cuando una acción es fácil de deshacer, el sistema puede dar al modelo más espacio para intentarlo. Cuando una acción es irreversible, el sistema debe endurecer los permisos y devolver la decisión al usuario. El grado de autonomía no debe determinarse por lo optimistas que nos sintamos respecto a un modelo. Debe determinarse por si las consecuencias pueden recuperarse.
Esto también cambió mi definición de «hecho». La finalización no es un estado verde en la interfaz. Significa que el sistema ha dejado claro el resultado, el riesgo restante y el camino hacia la recuperación. Cuando se interrumpe una tarea de larga duración, la animación no puede simplemente desaparecer. Cuando se rechaza un cambio, la mitad del estado de ejecución no puede quedar atrás. Cuando se deshabilita una capacidad, la lógica de recuperación no debe volver a activarla silenciosamente la próxima vez que se inicie la aplicación.
Cuanto más independientemente queremos que actúe la IA, con más cuidado debemos diseñar la forma en que se detiene y regresa.
7. No solo corrijas errores. Haz que cada fallo deje atrás un principio
Cualquier proyecto de larga duración encontrará muchos fallos. Lo que distingue a los proyectos no es si ocurren fallos, sino la forma en que permanecen después.
La respuesta más débil es hacer desaparecer el síntoma inmediato. Una mejor respuesta es identificar y corregir la causa raíz. La respuesta más valiosa va un paso más allá: ¿Qué clase de fallo fue este? ¿A través de qué otras rutas podría regresar el mismo fallo? ¿Le falta al sistema una regla, un único propietario o una estructura que pueda evitar que el problema vuelva a crecer?
Desarrollé el hábito de registrar más que el síntoma y la corrección. También registro la causa raíz, el propietario y la evidencia que evitaría una regresión. Un problema descrito solo por sus síntomas, sin un límite responsable y sin evidencia, aún no se ha convertido en conocimiento.
Un parche corrige un fallo. Un principio reduce toda una clase de fallos.
Si un error de sincronización se repara añadiendo una notificación más, puede regresar más tarde bajo un orden de eventos diferente. Si el fallo en cambio establece el principio de que cada pieza de estado tiene un único propietario, el diseño futuro contendrá naturalmente menos cadenas de sincronización. Si un antiguo punto de entrada crea ambigüedad de permisos, otro caso especial solo añadirá otra rama. Establecer que una intención tiene un único punto de entrada canónico da al sistema una regla de decisión duradera.
Creo que esto importa aún más ahora que la IA participa en el desarrollo de software. Se produce código más rápido y las correcciones locales se vuelven más baratas. Sin principios, un sistema puede acumular implementaciones duplicadas plausibles a una velocidad sin precedentes.
La IA puede ayudarnos a escribir parches más rápido. Los humanos todavía tienen que decidir qué debe enseñar cada fallo al sistema.
La verdadera acumulación de valor en un proyecto no es su volumen de código ni el número de tickets que ha cerrado. Es si el costo de los fallos pasados se ha convertido en principios que evitan que se vuelva a pagar el mismo costo.
8. No confundas la apariencia de finalización con evidencia
La IA es muy buena creando una sensación de completitud. Produce explicaciones bien estructuradas, código sintácticamente válido y resúmenes tranquilizadores. Pero las partes más difíciles de la ingeniería a menudo viven fuera de esa superficie.
Una interfaz que no muestra errores no prueba que nada siga ejecutándose en segundo plano. Una capacidad que funciona en un entorno de desarrollo no prueba que exista en el artefacto entregado a los usuarios. La validación en una plataforma no prueba un comportamiento idéntico en otra. El código que pasa un verificador de tipos no prueba que una antigua ruta autoritativa haya desaparecido del resto del sistema.
Con el tiempo, he preguntado menos «¿Está hecho?» y más «¿Qué evidencia sería suficiente para probar que está hecho?».
La evidencia no es un único indicador verde universal. Diferentes capas responden a diferentes preguntas. Las comprobaciones de código establecen la estructura local. La validación en tiempo de ejecución establece la ruta de ejecución real. La inspección de artefactos establece lo que los usuarios recibirán realmente. Las pruebas de recuperación establecen si el sistema preserva el significado en condiciones no ideales.
En la era de la IA, la validación no solo consiste en evitar que los modelos escriban código incorrecto. También contrarresta un riesgo más sutil: un resultado puede ser tan lógicamente convincente que todos estén dispuestos a creer que ya existe en la realidad.
Una de mis reglas más importantes es no inferir hechos subyacentes a partir del estado superficial, no inferir la corrección de todo el sistema a partir de una aprobación local, y no presentar un futuro no verificado como una capacidad entregada hoy.
Respetar la realidad a veces significa admitir: «Esto aún no está terminado». Esa honestidad no debilita un producto. Da al sistema un punto confiable desde el cual seguir evolucionando.
El software está pasando de ser instrucciones a ser instituciones
En retrospectiva, lo que me llevé de este trabajo no fue una arquitectura en particular. Fue una visión diferente del software de IA.
En el pasado, el software intentaba enumerar rutas. En el futuro, más de esas rutas serán generadas por modelos en el momento. El software ya no necesita prescribir cada acción para la inteligencia, pero sí necesita proporcionar un mundo estable: identidades y propiedad claras, límites que no puedan eludirse, un estado que preserve la realidad, formas de salir y recuperarse, y evidencia que establezca si un resultado es real.
Esto es similar a la relación entre las instituciones y los individuos.
Las instituciones no piensan en nombre de cada persona, ni deberían convertir cada acción en un procedimiento fijo. Definen la realidad compartida, los derechos, las responsabilidades y lo que sucede cuando algo sale mal. Las buenas instituciones dejan espacio para la acción a la vez que evitan que la libertad se produzca a costa del orden.
El software está empezando a desempeñar un papel similar en la era de la IA.
No es el cerebro del modelo, y no debería competir por el trabajo del modelo. Es la ley, el registro, el límite y la memoria del mundo que el modelo habita. Convierte una acción ingeniosa improvisada en el momento en una capacidad estable. Convierte un éxito accidental en un producto repetible. Permite a los usuarios confiar más trabajo importante a la IA sin cambiar la confianza ciega por la conveniencia.
No creo que la IA haga que el software sea menos importante. Al contrario, cuanto más capaces se vuelven los modelos, más debe el software responder a las preguntas que los modelos no deberían decidir por sí mismos.
¿Qué es verdad?
¿Qué está permitido?
¿A quién pertenece?
¿Cómo volvemos tras el fracaso?
¿Qué evidencia demuestra la finalización?
Los modelos exploran las respuestas. El software protege las preguntas.
Estamos pasando de una era en la que las personas escribían cada paso para las máquinas a otra en la que las personas establecen principios y las máquinas exploran caminos. El papel del software cambia con ello: de describir acciones a establecer orden.
Los modelos generan posibilidades.
El software hace que esas posibilidades merezcan confianza.