Quien camina por San Francisco ya se acostumbró a ver autos sin nadie al volante. Se detienen en el semáforo, esperan a que cruce el peatón y esquivan obras en la calzada. Desde la acera, parece que el auto simplemente sabe conducir.
Lo que lo hace posible va más allá del modelo que decide cada maniobra. El auto opera dentro de un conjunto de piezas que trabajan juntas: un mapa detallado de las calles, sensores que se confirman entre sí, un área de operación delimitada, reglas que vetan maniobras peligrosas y un equipo remoto que se hace cargo de los casos difíciles. El modelo es una parte del sistema, y la confianza viene del conjunto.
La IA que escribe código tiene el mismo problema
Los agentes de IA ya redactan requisitos, proponen arquitecturas, escriben código y generan pruebas. La capacidad de los modelos crece con cada versión. Aun así, un agente suelto en un repositorio, sin el contexto del negocio y sin límites, produce un trabajo difícil de confiar. No sabe qué reglas sigue la empresa, qué decisiones ya se tomaron ni dónde no puede tocar.
Por eso, la pregunta más útil para quien lidera tecnología es en qué estructura va a trabajar el modelo: con qué contexto, dentro de qué límites y con quién revisando el resultado.
El harness, la estructura alrededor de la IA
En el Tog Method, esa estructura se llama harness. Es el conjunto de contexto, reglas, agentes, patrones de arquitectura y verificaciones que hace que la IA trabaje dentro de los estándares de la empresa. La IA genera, las verificaciones bloquean lo que se sale de la regla y un profesional de Tog Lab revisa antes de publicar.
Todo empieza por el contexto. Los modelos de IA aciertan más cuando reciben el contexto del negocio, por eso todo proyecto empieza con un Domain Context: la fuente única con las reglas, los riesgos y las decisiones que orientan cada etapa. En el auto, ese es el papel del mapa detallado de las calles.
Pieza por pieza
La correspondencia entre las dos estructuras es casi directa. Cada pieza que da seguridad al auto tiene un equivalente en el ciclo de desarrollo.
| En el auto sin conductor | En el Tog Method |
|---|---|
| Mapa detallado de cada calle | Domain Context |
| Cámaras, lidar y radar redundantes | Pruebas automatizadas y TDD |
| Área de operación delimitada | Alcance y permisos |
| Reglas que vetan maniobras peligrosas | Guardrails que bloquean acciones destructivas |
| Equipo remoto para casos difíciles | Revisión de un profesional de Tog Lab en el plan y en el pull request |
| Millones de kilómetros en simulación | Evals y pruebas de regresión antes del merge |
Los sensores del auto se confirman entre sí: si la cámara falla, el radar y el lidar siguen viendo la calle. En el software, las pruebas automatizadas cumplen esa función. Con TDD, la prueba se escribe antes del código, y el agente solo termina la tarea cuando la prueba pasa.
El área de operación delimitada se convierte en alcance y permisos. El agente recibe acceso solo a la parte del repositorio y a las herramientas que la tarea requiere. Las reglas que vetan maniobras peligrosas se convierten en guardrails: las acciones destructivas, como borrar datos o tocar producción, se bloquean por regla antes de ejecutarse.
El equipo remoto que se hace cargo de los casos difíciles corresponde a la revisión de un profesional de Tog Lab, que ocurre en dos momentos: en el plan, antes de que el agente empiece, y en el pull request, antes de que el código entre. Y los kilómetros recorridos en simulación se convierten en evals y pruebas de regresión, que verifican el comportamiento antes del merge.
Nada avanza a la etapa siguiente sin que una persona lea y apruebe el documento de la etapa actual.
Una persona aprueba cada etapa
En el AI-Accelerated, el modelo de desarrollo con IA de Tog Lab, el trabajo pasa por siete etapas: contexto, requisitos, arquitectura, especificación, prototipo, código y pruebas, e infraestructura. Cada una genera un documento que alguien lee y aprueba. Los agentes hacen el trabajo pesado entre una decisión y otra. Personas del equipo del cliente y de Tog Lab deciden qué entra y revisan todo el código antes de que llegue a producción.
El nivel de autonomía de la IA tiene un límite definido para cada tipo de tarea. Como en el auto, la autonomía crece a medida que la estructura demuestra que puede con ella. En una propuesta comercial, solo prometemos lo que ya se validó con clientes.
Dónde termina la analogía
Toda analogía tiene un límite. El auto decide en fracciones de segundo, en medio del tráfico, y un error tiene una consecuencia física inmediata. En el software, hay tiempo entre generar y publicar: el código pasa por pruebas, verificaciones y revisión antes del merge, y un cambio se puede revertir. Eso permite poner a la persona en los puntos de decisión del flujo, donde su aprobación tiene más efecto.
Hay otra diferencia importante. En el auto, la estructura pertenece al fabricante. En el AI-Accelerated, puede funcionar dentro de la cuenta de nube del cliente, con su propia clave de modelo y el modelo de IA que elija. Cambiar de modelo es un cambio de configuración: contexto, reglas, agentes y verificaciones siguen siendo los mismos, y no hace falta rehacer el proyecto.
Qué cambia para quien contrata
Para quien contrata desarrollo con IA, la estructura alrededor del modelo pesa tanto como el modelo. En la práctica, eso significa tres cosas.
- Sigues el proyecto a través de los documentos de cada etapa y apruebas antes de que empiece la siguiente.
- Repositorio, documentación y claves quedan a nombre de tu empresa desde el primer commit.
- La elección del modelo de IA es tuya, y cambiar de modelo no obliga a rehacer el proyecto.
Al evaluar a un proveedor, conviene preguntar cómo organiza esa estructura: dónde está el contexto del negocio, qué bloquean las verificaciones, quién revisa y qué queda registrado.