01
Arquitectura
Qué agente, qué contexto, qué datos y dónde empieza y termina su autoridad.
Diseño la arquitectura y el control que hacen falta para llevar un agente a producción.
Soy Alex. Llevo 10 años construyendo software. Los últimos 4 los he dedicado a los agentes: cómo darles contexto, cómo medirlos y cómo evitar que un output convincente se confunda con uno correcto.
Ahora
Durante el último año he estado impulsando la transición hacia IA dentro de mi empresa.
No solo probando herramientas: buscando dónde aportan valor, definiendo cómo usarlas y ayudando a equipos a incorporarlas sin perder control sobre lo que producen.
Trabajo dentro del código real, en lo que se va a producción. No desde fuera con una presentación.
akrcontext , open source, con un cliente ejecutándolo en producción.
Benchmarks y experimentos publicados aquí, con el código y con los fallos incluidos.
01
Qué agente, qué contexto, qué datos y dónde empieza y termina su autoridad.
02
Cómo compruebas que lo que produce es correcto. Que un agente revise su propio trabajo no es una garantía.
03
Cuánto se puede delegar, con qué garantías y qué tiene que existir para que eso no salga caro más tarde.
Enfrenté un juez y un atacante sobre el mismo código generado por IA —mismo modelo, mismo spec. El atacante encontró bugs que el juez aprobó explícitamente como correctos. Por qué el feedback adversarial vence a la evaluación en coding agents.
Comparé tres paradigmas —vanilla, agente con terminal y RLM— sobre un codebase de 1.13M tokens. RLM ayuda a modelos pequeños, pero un agente con terminal empató a 3x menos coste.
Construí cuatro demos de prompt injection y las probé contra Claude Code, Codex, Gemini CLI y Copilot. Los resultados no son lo que esperas: los modelos modernos detectan los ataques obvios. El que no detectan es el más peligroso.