Huntley, el ingeniero que cambia AGENTS.md por hooks

Un hook de pre-commit en lugar de un AGENTS.md

"Si el agente no está usando mi librería de diagnósticos, podría introspeccionar y actualizar el AGENTS.md, pero sigue habiendo un delta, y va a derivar. En lugar de eso, escribo un hook de pre-commit que revisa el git diff en busca de llamadas directas a módulos de observabilidad que saltean mi módulo de diagnósticos. Boom: falla el commit, inyecto un prompt que le dice al agente que use la librería de diagnósticos. De golpe es diez de diez."

La cita es de Geoffrey Huntley y la recogió Simon Willison el 13 de octubre de 2026. Viene de un post de Huntley titulado nobody should type code by hand anymore. here's what's left, donde resume una conversación de hora y media con Josh Wulf en el podcast Agentic Engineering.

El fragmento parece un detalle de implementación. En realidad es una tesis completa sobre cómo se gobierna un agente de código: dejar de pedirle al modelo que se porte bien y empezar a construir barreras que no le permitan portarse mal.

Leíste lo que hace la IA. ¿Y en tu negocio?

En CAR, dueños de empresa arman en 7 días su primer sistema funcionando: que ningún cliente se les escape, o que el informe del lunes salga solo. Con otros emprendedores al lado.

👥 Probar 7 días

¿Quién es Geoffrey Huntley y por qué importa su postura?

Huntley no es un divulgador de IA que descubre el tema este año. En su propio post se describe como veterano de developer tooling: fue tech lead en Canva, empleado temprano de Gitpod y hoy trabaja en Antithesis, una empresa que construye un computador determinista para inyectar fallas en software existente.

Su argumento central es que la profesión ya cambió. "No hay lugar en el mundo hoy para un ingeniero de software que escribe código a mano", escribe. Y agrega que el cuello de botella se movió: ya no es escribir código, es revisarlo y verificarlo.

Ese es el problema que su hook resuelve. Cuando un agente genera cientos de cambios por día, la revisión humana línea por línea deja de ser viable. Huntley lo dice sin vueltas: si revisar código a ojo fuera suficiente para evitar bugs, nunca habríamos tenido defectos, y menos va a funcionar a mil veces la velocidad humana.

¿Por qué los AGENTS.md y los skill packs no alcanzan?

Acá está la parte incómoda del post. Huntley dedica una sección entera a lo que llama skill packs are astrology for software engineers: astrología para ingenieros de software.

Su razonamiento: los skill packs, los AGENTS.md y los MCPs son probabilísticos. No hay garantía de que hagan algo. Un humano los lee y piensa "sí, esto se ve bien", pero que se vea bien no significa que funcione. Es un horóscopo: reconforta, no obliga.

La prueba que propone es brutalmente simple y la atribuye a Wulf: ¿lo probaste sin el skill? ¿Cómo sabes que el skill hace algo, o que lo hace bien? Su recomendación es incómoda: borra tus skills y tu AGENTS.md cada dos meses. Los modelos mejoran, y si no mediste con evals sobre tus propios traces, no sabes si estás avanzando o retrocediendo.

La conclusión de Wulf, que Huntley cita como resumen de todo el debate, cabe en cuatro palabras: agency, not AGENTS.md.

La verificación determinista: el patrón que sí escala

El hook de Huntley funciona porque no le pide nada al modelo: le pone un límite al repositorio. Si el diff introduce una llamada directa a un módulo de observabilidad que saltea su librería de diagnósticos, el commit falla. Y el propio fallo inyecta la instrucción correcta en el contexto del agente.

Es la misma lógica de Danger Systems, la herramienta que hace años automatizaba chequeos en CI del tipo "el dominio REST no puede acoplarse al dominio SQL". Nadie gastaba ciclos de revisión en eso porque una máquina lo verificaba. Huntley solo movió esa pieza adentro del loop del agente.

El contexto del sector acompaña. Andrew Ng, fundador de DeepLearning.AI, describió en 2026 el loop engineering como el diseño de ciclos repetibles donde el agente construye, testea y corrige, y Addy Osmani, de Google Cloud, lo resumió así: "Loop engineering es reemplazarte a ti mismo como la persona que hace el prompt. Diseñas el sistema que lo hace en tu lugar". Pero Osmani también dejó la advertencia que valida la postura de Huntley: "un loop corriendo sin supervisión es también un loop cometiendo errores sin supervisión".

La urgencia es real. Según Help Net Security, el 90% de los desarrolladores usa agentes de código en el trabajo al menos una vez por semana. Ese volumen de cambios generados por máquinas no se sostiene con revisión manual.

¿Qué significa esto para tu startup?

Si tu equipo ya usa Claude Code, Cursor o Codex, el problema de Huntley ya es tuyo, aunque todavía no lo hayas notado. La diferencia entre un equipo que escala con agentes y uno que acumula deuda técnica está en dónde pone el control.

1. Convierte tus convenciones en checks ejecutables. Elegí las tres o cuatro reglas arquitectónicas que hoy dependen de que alguien las recuerde en un code review —que las capas no se crucen, que los logs pasen por tu módulo de observabilidad, que no se salteen la capa de autenticación— y escribí un script que las verifique sobre el diff. Un hook de pre-commit o un job de CI alcanza. La regla deja de ser una sugerencia y pasa a ser una condición de merge.

2. Haz que el error le hable al agente. El detalle más valioso de la cita no es que el commit falle, es que el fallo inyecta el prompt correcto. Un mensaje de error que dice "usá la librería de diagnósticos en lugar de llamar al módulo de observabilidad directamente" le da al agente la instrucción exacta para corregirse solo. Un error genérico lo deja dando vueltas.

3. Mide antes de confiar. Antes de sumar un skill pack o un AGENTS.md nuevo, corré la misma tarea sin él y compará. Si no hay diferencia medible, estás agregando superficie de mantenimiento sin retorno. Y si el agente ignora una convención tres veces, no la reescribas en el prompt: automatizala.

El punto de fondo: menos prompt, más ingeniería

Huntley no está diciendo que los agentes sean malos. Está diciendo que tratarlos como cajas mágicas que responden a instrucciones bien redactadas es una apuesta, y que la ingeniería de software siempre resolvió esto de otra forma: con barreras que no dependen de la buena voluntad de nadie.

Para un founder, la lectura práctica es tranquilizadora. No necesitas contratar un experto en prompts ni comprar el curso de moda. Necesitas hacer lo que ya sabes hacer: escribir tests, definir contratos, automatizar lo que se repite. La novedad es que ahora esos checks también le hablan a un agente.

Como resume Huntley, la implementación se volvió una caja negra —sea un equipo de contratistas que nunca ves o silicio— y los humanos quedaron en dos puntos: la visión y la verificación. El hook de pre-commit es, literalmente, la verificación puesta en el lugar donde nadie puede saltearla.

Fuentes

Leíste lo que hace la IA. ¿Y en tu negocio?

En CAR, dueños de empresa arman en 7 días su primer sistema funcionando: que ningún cliente se les escape, o que el informe del lunes salga solo. Con otros emprendedores al lado.

👥 Probar 7 días

Daily Shot: Tu ventaja táctica

Lo que pasó en las últimas 24 horas, resumido para que tú no tengas que filtrarlo.

Suscríbete para recibir cada mañana la curaduría definitiva del ecosistema startup e inversionista. Sin ruido ni rodeos, solo la información estratégica que necesitas para avanzar:

  • Venture Capital & Inversiones: Rondas, fondos y movimientos de capital.
  • IA & Tecnología: Tendencias, Web3 y herramientas de automatización.
  • Modelos de Negocio: Actualidad en SaaS, Fintech y Cripto.
  • Propósito: Erradicar el estancamiento informativo dándote claridad desde tu primer café.

📡 El Daily Shot Startupero

Noticias del ecosistema startup en 2 minutos. Gratis, todos los días.

Share to...