TTKIA genera código. Por qué confío en ello.
En el vídeo, TTKIA lee por su cuenta la documentación de una API pública que nadie le había presentado (PeeringDB, el registro de interconexión de Internet), desarrolla un programa de más de quinientas líneas y me lo entrega ya comprobado. Lo ejecuto en mi portátil sin modificar ni una coma: aparecen dieciocho puntos neutros de España, con sus redes y su capacidad, representados sobre un mapa.
No hay agentes ni plantillas de por medio. Cada consulta sigue siempre el mismo recorrido: planificar, buscar evidencia, evaluar y redactar. Al final interviene Craft con la respuesta ya elaborada. El modelo no construye el entregable directamente: escribe un script que lo genera usando un kit cerrado, y ese script corre en un entorno aislado. Luego, un verificador examina el paquete sin ejecutar nada: que compile, que el bash supere la comprobación de sintaxis, que no haya rutas fuera del paquete ni credenciales escritas a fuego. Cada error regresa al modelo con su fichero y su línea, hasta en tres rondas. En la grabación aparece un «reintento 2» que no estaba preparado.
La contención es arquitectura, no buena voluntad del modelo:
1. Un contenedor por trabajo, desechable: solo lectura, usuario sin privilegios, sin capacidades del núcleo, un gigabyte, una CPU, dos minutos.
2. Red separada: no accede al backend, ni a las bases de datos, ni a los servidores que se comunican con los equipos. El host le bloquea los metadatos de la máquina y las redes privadas.
3. Aduana para el script del modelo: fuera subprocess, requests, socket, eval y similares.
4. Credenciales siempre por variable de entorno, con su .env.example; el verificador localiza las que se cuelen.
5. Todo lo que modifica algo arranca en modo de prueba.
6. Y la decisión más deliberada de todas: el programa no se ejecuta dentro de TTKIA.
Código escrito por un modelo, con salida a Internet y lanzado desde la plataforma, hace a la plataforma responsable de sus consecuencias. Lo ejecuta una persona, en su propia máquina, después de haberlo leído.
Límites, sin rodeos: el verificador revisa la forma, no el comportamiento real contra el sistema. Faltan analizadores como ruff o ansible-lint, que se irán incorporando, y ejecutar cálculos con salida a dominios concretos para devolverlos como evidencia. Está pensado; aún no está hecho.
El caso sencillo es una API pública. El que realmente importa es el script que nace de una consulta a la red de verdad. La máquina escribe el código. Las puertas las pusimos nosotros. Y el Enter, por ahora, lo sigo pulsando yo, después de leer.
TTKIA genera código verificado para consultar PeeringDB y renderizar puntos neutros sobre mapa: arquitectura de contención sin agentes
Resumen técnico
El sistema lee documentación de PeeringDB API sin instrucciones previas y genera un script de más de 500 líneas que ejecuta sin modificaciones. El flujo sigue cuatro fases: planificar, buscar evidencia, evaluar y redactar. Un verificador estático analiza el paquete sin ejecutarlo: comprueba compilación, sintaxis bash, rutas relativas y ausencia de credenciales hardcodeadas. Los fallos retornan al modelo con fichero y línea exacta, con un máximo de 3 reintentos. Resultado: 18 puntos neutros de España con sus redes y capacidad visualizados sobre mapa. Sin plantillas. Sin agentes.
Análisis de implicaciones
El verificador actúa como linter de seguridad, no como sandbox de ejecución: detecta forma, no comportamiento real. El modelo no accede directamente a Internet desde el entorno de generación; el script se ejecuta en local por el usuario. Las variables de entorno se gestionan mediante .env.example, y el verificador detecta credenciales que se filtren al código. El modelo genera el entregable indirectamente: escribe el script que lo fabrica, no el artefacto final. Esto desplaza la responsabilidad de ejecución fuera de la plataforma, con implicaciones legales y de auditoría deliberadas.
Aplicación práctica
El caso documentado consulta PeeringDB para extraer infraestructura de interconexión pública. El script generado corre aislado en un contenedor con límites duros: 1 GB RAM, 1 CPU, 2 minutos de ejecución, usuario sin privilegios, red separada del backend. Módulos como subprocess, requests, socket y eval están bloqueados en el entorno del modelo. Las credenciales entran exclusivamente por variable de entorno. Los procesos con escritura arrancan en modo de prueba. El usuario pulsa Enter después de revisar el código entregado.
Contexto del sector
La generación de código por LLMs sin contención arquitectónica es el vector de riesgo principal en automatización con IA en 2024-2025. Soluciones como GitHub Copilot o Cursor no ejecutan en sandbox aislado ni verifican credenciales automáticamente. El enfoque descrito combina aislamiento por contenedor, red segregada y verificación estática en una cadena reproducible. Faltan aún analizadores como ruff o ansible-lint y ejecución con salida a dominios controlados como capa de evidencia. La dirección es correcta; la implementación, incompleta por diseño explícito.
