Cómo envolver a un genio impredecible

• En productos de IA donde incluso con la misma solicitud los resultados cambian, para reducir errores repetidos conviene controlar con código determinista que el modelo no pueda desobedecer, en lugar de simplemente aumentar las instrucciones
• La estructura de control se divide en cuatro capas: modelo, arnés, documentación y hooks; solo los hooks que operan de forma independiente bajo ciertas condiciones pueden imponer reglas
• Las tareas cuya exactitud puede evaluarse con código se pueden garantizar, pero las tareas que requieren criterio, como errores sutiles de análisis, vuelven a depender del modelo, por lo que el vacío de verificación no desaparece aunque el modelo mejore
• Los productos de IA necesitan ingeniería de arnés para separar qué partes se dejan al juicio del modelo y cuáles se garantizan con código; si el control es insuficiente, producen respuestas erróneas, y si es excesivo, se convierten en software común y costoso
• Si cualquiera puede alquilar el mismo modelo, la capa envolvente que acumula criterios, código, datos y entornos de integración propios de cada producto se convierte en una ventaja competitiva defendible, y el crecimiento de Cursor lo demuestra

---

Llevar las reglas del documento al código

• Aunque se prohíba cierto comportamiento en un archivo que Claude Code lee en cada sesión, a veces entiende el contenido, está de acuerdo y aun así repite la misma acción
• Cuando la regla se trasladó a código que bloquea el comando en cuanto se cumple una condición, la conducta prohibida se detuvo sin importar el juicio del modelo
• El costo de revisar salidas de IA que trata The Verification Tax puede reducirse no aumentando la revisión posterior, sino con ingeniería en etapas más tempranas
• Incluso una estructura mínima de control hecha por una sola persona con herramientas personales tiene la misma forma que los problemas que deben resolver los productos de IA a gran escala
• En una publicación aparte en X se pueden ver lineamientos prácticos que conectan tipos de fallas con tipos de hooks y ordenan qué puede medirse en cada capa

Las cuatro capas que componen el control

• La capacidad de control se compone de cuatro capas que se vuelven más fuertes de abajo hacia arriba
  • Modelo: por muy avanzado que sea, como Claude Opus 4.8 o GPT-5.5, puede dar respuestas distintas a la misma solicitud, y ninguna instrucción elimina por completo esa característica
  • Arnés: como Claude Code, Codex u OpenClaw, ejecuta el modelo y decide qué puede ver, pero solo puede orientar la dirección general
  • Documentación: CLAUDE.md y AGENTS.md contienen preferencias, contexto del proyecto, reglas y correcciones acumuladas, pero el modelo puede no seguirlas porque decide junto con otra información
  • Hook: código que vigila situaciones específicas y actúa de manera independiente, bloqueando comandos prohibidos sin importar si el modelo está de acuerdo o no
• De las cuatro capas, la única que no negocia es la superior: el hook
  • Las reglas trasladadas a hooks no pueden ser eludidas por el modelo, desaparecen los errores repetidos y también se reduce lo que las personas tienen que revisar

El ámbito del juicio que no puede garantizarse con código

• La superficie que debe controlarse se puede reducir, pero no cerrar por completo
  • La condición “no ejecutes este comando” puede verificarse con código
  • La condición “evita que el análisis derive sutilmente en una dirección equivocada” requiere juicio, y otro modelo que evalúe eso vuelve a tener imprevisibilidad
• Los sistemas que realmente pueden demostrar una salida comparan con código criterios y resultados escritos de antemano por personas, y solo funcionan en ámbitos donde la respuesta correcta puede definirse con precisión
• Aunque el modelo se actualice, los problemas de juicio no desaparecen, por lo que las capas de control que lo envuelven siguen siendo necesarias

• Garantías basadas en especificaciones formales

  • SEVerA puede garantizar que la salida de un agente cumpla un contrato formal, pero ese contrato debe escribirse de antemano en lógica formal, y solo aplica a dominios donde esa verificación es posible
  • VeriGuard añade seguridad verificada a agentes LLM, pero la verificación manual por parte del usuario sigue siendo necesaria
  • La etapa en la que el LLM traduce la intención del usuario a reglas formales es en sí misma impredecible
  • En la práctica, la garantía termina dependiendo de una verificación fija contra una especificación escrita por humanos
  • Los “agentes de auto-mejora” evalúan los resultados ocurridos para mejorar acciones posteriores, pero eso es distinto de demostrar que una salida específica es correcta

Envolver un motor probabilístico con software determinista

• Las pruebas de software tradicionales evolucionaron como un método para fijar una salida deseada y una única respuesta correcta, y luego comprobar código predecible
• Los productos nativos de IA ponen en el centro un motor probabilístico que puede dar resultados distintos incluso con el mismo prompt, por lo que se rompe la premisa de las pruebas tradicionales
• Como señala Hamel Husain, la disciplina de pruebas de software construida durante décadas presupone una única respuesta correcta, pero en la IA justamente esa respuesta desaparece
• Varios desarrolladores están convergiendo en mantener el motor impredecible, pero envolverlo con código determinista que opere igual cada vez
  • 12-factor agents de Dex Horthy define un buen agente como un sistema “compuesto principalmente de software”
  • building effective agents de Anthropic recomienda ejecutar tareas mediante “rutas de código predefinidas” y añadir “verificaciones programáticas”
• En Claude Code se puede elegir cómo verificar una condición
  • Si el código determina de manera independiente si pasa o falla, se obtiene una garantía
  • Si el modelo decide si la condición se cumplió, solo se obtiene un juicio

• Skills y /goal en Claude Code

  • Skills son procedimientos estructurados que el agente puede invocar, pero como el modelo decide si ejecutarlos y puede desviarse a mitad del proceso, pertenecen a la capa de documentación
  • /goal hace que la tarea continúe hasta cumplir condiciones explícitas, por lo que está más cerca de una capa de imposición
  • Aun así, un modelo pequeño y rápido evalúa después de cada turno si se cumplieron las condiciones, por lo que puede equivocarse igual que otros modelos
  • /goal es una función construida sobre un hook de Stop; en un hook de Stop escrito directamente, un script puede decidir por sí mismo si pasa o falla en lugar del modelo
  • La documentación de Claude Code distingue ambos enfoques: scripts para verificaciones deterministas y modelos para verificaciones que requieren juicio

Cuando la configuración personal escala al tamaño de una organización

• En un entorno personal, aunque un agente ignore una regla, el costo suele limitarse a unos minutos, y los casos importantes pueden bloquearse con hooks personales
• En una empresa de 200 personas que usa el mismo agente, no existe un hook personal para cada integrante y las reglas pueden quedar en un único archivo compartido
• Si una regla compartida se ignora una vez, el mismo problema puede aparecer en todos los lugares donde ese archivo se ejecute, y el nivel de protección de la organización queda determinado por la regla escrita de forma más laxa
• La estructura de control es la misma que en una configuración personal, pero al crecer la escala cambia el costo del error

Qué garantizar y qué dejar abierto

• La guía de arquitectura nativa de agentes de Every define una función no como código escrito, sino como “un resultado descrito que un agente logra operando dentro de un loop”
• Este enfoque deja que el modelo improvise y diseña el producto alrededor del resultado, pero en los puntos donde se necesita control vuelve al código
  • Recomienda mover al código los hot paths, es decir, rutas frecuentes o importantes
  • Reconoce que algunas tareas requieren verificaciones que no deben dejarse al juicio del agente
• El diseño de producto centrado en el modelo y la ingeniería centrada en el control parecen opuestos, pero en realidad abordan la misma arquitectura desde extremos distintos
• En el diseño real hay que decidir qué partes del producto se fijan en código y hasta qué grado
  • Si se fija demasiado poco, el modelo puede improvisar incluso en tareas que requieren garantías y entregar al cliente respuestas erróneas con aparente seguridad
  • Si se fija demasiado, termina siendo software común con todas las rutas escritas en código, y el modelo solo hace de forma lenta y costosa lo que antes ya hacía el código tradicional
• Lo que el equipo de OpenAI llama ingeniería de arnés consiste en dividir de forma intencional, en cada punto del producto, qué partes requieren el juicio del modelo y cuáles requieren garantías del código

La capa envolvente que se acumula más tiempo que el modelo

• Los modelos son la capa más difícil de defender porque cualquiera puede alquilar lo mismo, y las mejoras llegan al mismo tiempo a todos los usuarios según el calendario del laboratorio que los desarrolla
• Aunque un competidor pudiera leer todo el repositorio de código, no obtendría el juicio acumulado con el que se ha decidido, para una tarea específica, qué garantizar y qué dejar abierto
• Ese juicio se implementa en capas que el modelo no puede contrariar y sigue acumulándose junto con la estructura de control propia del producto
• La suma del código que rodea al modelo, los criterios, los datos y el entorno de integración con el trabajo forma una ventaja competitiva de largo plazo

La capa de control que ha acumulado Cursor

• Cursor, la herramienta de programación con IA, no crea su propio modelo generalista; enruta solicitudes entre Claude, GPT, Gemini y Grok, y trata los modelos como una mercancía que puede alquilarse
• Aunque Claude Code de Anthropic tenga acceso primero a mejores modelos, eso no reemplaza a Cursor
• Los ingresos de Cursor aumentaron de alrededor de 1,000 millones de dólares en noviembre del año pasado a unos 4,000 millones de dólares en junio
• SpaceX ejerció la semana pasada una opción obtenida en abril y acordó adquirir Cursor por 60,000 millones de dólares, la mayor compra de una startup respaldada por venture capital hasta la fecha
• Lo que Cursor ha acumulado no es un mejor modelo generalista, sino la capa que envuelve al producto
  • Un índice del codebase que sincroniza todo el repositorio y lo mantiene en estado consultable
  • Un modelo propio de autocompletado entrenado con cientos de millones de ediciones diarias para aprender qué sugerencias aceptan o rechazan los desarrolladores
  • Un entorno de integración empresarial presente en la mayoría de las empresas Fortune 500
• Aunque una empresa de modelos tenga un modelo mejor, no posee el editor, el índice ni los hábitos de uso de los desarrolladores

La pregunta que define la permanencia de los productos nativos de IA

• Casos como Cursor, que construyen una capa de control, son poco frecuentes; muchos de quienes usan IA en su trabajo no han creado esta capa envolvente o ni siquiera saben que existe
• A escala empresarial, cómo se construye esta capa es lo que distingue a un producto nativo de IA capaz de sostener el uso real de una demo impresionante montada sobre un modelo que cualquiera puede alquilar
• Incluso si los modelos base se vuelven gratuitos, la pregunta clave para distinguir el activo sostenible del producto es qué queda en pie