Mi viaje adoptando agentes de IA: lecciones de Mitchell Hashimoto

Mitchell Hashimoto, fundador de HashiCorp y creador de herramientas como Vagrant y Terraform, comparte públicamente su experiencia adoptando agentes de IA: un viaje de seis meses desde la frustración inicial hasta ejecutar agentes en segundo plano durante el 10-20% de su jornada laboral.

No es teoría. No es marketing. Son lecciones prácticas de un ingeniero senior que pasó de rechazar chatbots ineficientes a integrar agentes de forma sistemática en su workflow diario, creando un concepto que llama “harness engineering” para hacer los agentes verdaderamente confiables.

En este artículo descubrirás su metodología paso a paso, qué son las “slam dunk tasks” que identificó como perfectas para agentes, y cómo aplicar estas lecciones a tu equipo sin caer en el hype. Las empresas que adoptan agentes con metodología clara reportan retornos promedio del 171%, con 74% alcanzando ROI en el primer año. Pero el éxito no está en la tecnología, sino en cómo la adoptas.

El viaje de 6 pasos de Mitchell Hashimoto

Paso 1: Abandona el chatbot

El primer descubrimiento de Mitchell fue contundente: los chatbots tradicionales (ChatGPT-style) son ineficientes para trabajo de desarrollo real. La interacción de copiar-pegar código, volver al editor, probar, volver al chat, ajustar el prompt, repetir… es demasiado fricción.

Su recomendación: usa agentes desde el principio. Los agentes no son chatbots glorificados. Son sistemas que pueden ejecutar acciones en bucle: leer archivos, ejecutar comandos, hacer peticiones HTTP, ver los resultados, y ajustar su siguiente acción basándose en lo que observan.

Herramientas como Claude Code, Cursor con modo agente, o GitHub Copilot con capacidades agénticas entran en esta categoría. La diferencia clave: el agente vive en tu entorno de desarrollo, no en una pestaña separada del navegador.

Paso 2: Reproduce tu propio trabajo

Esta fue la fase de mayor fricción para Mitchell. En lugar de abandonar cuando los resultados iniciales no cumplieron expectativas, se forzó a reproducir todos sus commits manuales usando agentes. Esto significó doblar el trabajo: hacer las cosas manualmente primero, luego intentar que el agente llegara al mismo resultado.

Suena ineficiente. Lo es. Pero reveló tres principios fundamentales que transformaron su uso de agentes:

1. Divide sesiones en tareas claras y separadas

Los agentes funcionan mejor con objetivos específicos. “Implementa autenticación” es vago. “Crea un middleware de Express que verifique JWT en el header Authorization y devuelva 401 si no es válido” es específico.

2. Separa planificación de ejecución

No pidas al agente que planifique y ejecute simultáneamente. Primero pídele un plan. Revísalo. Ajústalo si es necesario. Después pídele que ejecute ese plan específico. Dos fases distintas.

3. Proporciona mecanismos de verificación

El agente necesita formas de validar su propio trabajo. Tests automatizados. Scripts de verificación. Comandos que pueda ejecutar para confirmar que hizo lo correcto. Sin esto, el agente avanza sin saber si va por buen camino.

Paso 3: Agentes de fin de día

Mitchell comenzó a reservar 30 minutos al final de cada jornada para lanzar agentes en tareas de baja presión. Sin deadlines urgentes. Sin necesidad de que funcionara perfectamente. Espacio para experimentar y aprender.

Tres tipos de tareas funcionaron especialmente bien:

Investigación profunda de librerías y herramientas: “Investiga las 5 librerías más populares para manejo de WebSockets en Go, compara sus trade-offs, y dame ejemplos de código básico para cada una.”

Exploración paralela de ideas especulativas: “¿Cómo implementaríamos hot-reload en Ghostty sin reiniciar el proceso? Explora 3 enfoques diferentes y sus implicaciones.”

Triage de issues de GitHub con CLI tools: “Revisa los últimos 20 issues abiertos, clasifícalos por tipo (bug/feature/docs), identifica duplicados, y sugiere cuáles deberían priorizarse.”

El patrón común: tareas útiles pero no críticas. Si el agente falla, no hay consecuencias graves. Si tiene éxito, ganaste tiempo y conocimiento valioso.

Paso 4: Externaliza las “slam dunks”

Aquí es donde Mitchell empezó a ver eficiencia neta real. Una “slam dunk task” es una tarea de alta confianza donde el agente casi seguro tendrá éxito. No son obvias al principio. Las identificas por experiencia.

Ejemplos de sus slam dunks:

Actualizar documentación tras cambios en APIs
Implementar tests unitarios para funciones puras con especificaciones claras
Refactorizar código para seguir convenciones específicas del proyecto
Crear componentes UI basados en diseños existentes con ligeras variaciones

La clave: ejecuta estos agentes en segundo plano mientras tú trabajas en tareas creativas o de arquitectura. Y aquí viene un punto crítico que mucha gente ignora: desactiva las notificaciones.

Cuando el agente termina y te notifica, cambias de contexto. Revisas su trabajo. Te distrae de lo que estabas haciendo. El context-switching mata productividad. Mejor: deja que el agente trabaje, y revisa sus resultados en un momento que tú elijas, no cuando él termine.

Paso 5: Ingeniería del harness

Este es el concepto más importante del viaje de Mitchell. “Harness engineering” significa prevenir errores de agentes de forma sistemática, no solo reaccionar cuando fallan.

Cuando un agente comete un error, Mitchell no solo lo corrige y sigue adelante. Toma tiempo para ingenierizar una solución que evite que ese error vuelva a ocurrir. Dos mecanismos principales:

AGENTS.md files: Documentación que captura comportamientos malos descubiertos. Cada línea en este archivo está basada en un error real que el agente cometió.

Ejemplo del AGENTS.md de Ghostty (su proyecto de terminal macOS):

- NUNCA ejecutes `make test` sin filtros. Usa `make test FILTER=<pattern>` para tests específicos.
- Para screenshots, usa siempre el script `./scripts/screenshot.sh` que configuramos, no comandos manuales.
- El workflow de CI requiere que todos los tests pasen. Ejecuta `make check` antes de hacer commit.
- No modifices archivos en `vendor/` directamente. Usa `make vendor-update` en su lugar.

Herramientas programadas: Scripts custom que facilitan al agente hacer lo correcto. Si el agente fallaba tomando screenshots manualmente, Mitchell creó screenshot.sh que encapsula la forma correcta. Si necesitaba ejecutar tests filtrados, creó helpers que hacen obvio cómo hacerlo.

El resultado: según Mitchell, esto “resolvió casi completamente” los problemas recurrentes.

La filosofía detrás: “No quiero ejecutar agentes por el simple hecho de ejecutar agentes.” Los agentes deben aportar valor, no crear más trabajo de supervisión.

¿Quieres implementar agentes de IA en tu equipo sin el caos? En NERVICO te ayudamos con una auditoría gratuita de tus procesos para identificar tus “slam dunk tasks”.

Paso 6: Siempre ten un agente corriendo

El objetivo actual de Mitchell: mantener actividad constante de agentes en segundo plano. No múltiples agentes en paralelo (complejidad innecesaria), sino un solo agente trabajando de forma continua en la siguiente tarea de la cola.

Para esto usa modelos más lentos pero más pensantes, como el modo “deep” de Amp, que prioriza razonamiento sobre velocidad. El resultado: durante aproximadamente 10-20% de su jornada laboral normal, hay un agente activo ejecutando tareas.

Este no fue un “big bang” de adopción. Fue iterativo, gradual, basado en aprender de errores y construir confianza paso a paso.

Harness Engineering: hacer los agentes confiables

El concepto de harness engineering que Mitchell creó está ganando tracción en la industria. Anthropic publicó recientemente un artículo técnico sobre harnesses efectivos para agentes de larga duración. Philipp Schmid escribió sobre la importancia del agent harness en 2026. No es solo una idea de Mitchell, es una necesidad emergente.

Qué es un Agent Harness

Un agent harness es la infraestructura que envuelve un modelo de IA para gestionar tareas de larga duración. Piensa en él como el sistema operativo del agente. Sus responsabilidades incluyen:

Gestión de memoria y estado: El agente necesita recordar qué ha hecho, qué ha aprendido, qué ha fallado.
Integración controlada de herramientas: No darle acceso a todo, sino a las herramientas específicas que necesita con guardrails claros.
Ingeniería dinámica de contexto: Decidir qué información incluir en cada petición al modelo para maximizar efectividad sin explotar límites de tokens.
Guía de planificación y descomposición de tareas: Ayudar al agente a dividir problemas complejos en pasos manejables.
Verificación y restricciones de seguridad: Evitar que el agente haga cosas peligrosas o costosas sin supervisión.

Por qué los harnesses importan

Los benchmarks de modelos muestran diferencias pequeñas. Claude Opus 4.6 supera a GPT-5.3 en ciertos tests por 2-3%. Parece marginal. Pero estos benchmarks evalúan tareas cortas y aisladas.

En producción real, lo que importa es durabilidad: qué tan bien el modelo sigue instrucciones mientras ejecuta cientos de llamadas a herramientas durante horas. Una diferencia del 1% en un benchmark no detecta si el modelo se desvía del objetivo después de 50 pasos.

El harness es lo que mantiene al agente en el camino correcto. Como dice la comunidad de ingeniería de agentes: “Harness engineering se está volviendo tan importante como la selección de modelo.”

Harness Engineering vs Prompt Engineering

Prompt engineering optimiza inputs. Harness engineering construye sistemas de seguridad y recuperación alrededor del modelo.

La analogía: El harness es como un arnés de seguridad en escalada. No evita que intentes rutas difíciles. Evita que caigas cuando fallas. Te permite tomar riesgos calculados porque sabes que hay una red de protección.

En práctica, Mitchell actualiza su AGENTS.md cada vez que el agente comete un error. No es solo documentación pasiva, es un contrato de comportamiento activo que evoluciona con la experiencia del equipo.

”Slam Dunk Tasks”: dónde los agentes realmente brillan

No todas las tareas son iguales. Mitchell identifica “slam dunks” como tareas de alta confianza donde el agente casi seguro tendrá éxito. ¿Qué las caracteriza?

Características de slam dunk tasks

Alta repetibilidad: Has hecho esto o algo muy similar muchas veces antes.
Contexto bien definido: El agente tiene acceso a toda la información necesaria.
Criterios de éxito claros: Puedes verificar si funcionó sin ambigüedad.
Baja ambigüedad: No requiere juicio subjetivo o decisiones de trade-off complejas.
Verificación automática posible: Tests, linters, o scripts que confirman corrección.

Importante: estas tareas no son obvias al principio. Las descubres experimentando. Lo que es slam dunk para tu equipo puede no serlo para otro.

Ejemplos reales

De la experiencia de Mitchell:

Investigación profunda de librerías (recopilar info, comparar trade-offs)
Triage de GitHub issues (clasificar, identificar duplicados, etiquetar)
Recreación de componentes UI con especificaciones claras
Bug fixes de nivel junior/mid con contexto específico

Nota crítica de Mitchell: “Los cambios siempre necesitan revisión exhaustiva, follow-ups, y a veces ajustes manuales para llegar a calidad Senior.” Los agentes no son developers autónomos. Son multiplicadores de fuerza.

Dónde los agentes aún luchan

Mitchell es honesto sobre las limitaciones:

Requisitos ambiguos: “Haz que la UI se vea mejor” no funciona.
Problemas novedosos sin precedentes: Si nunca se ha hecho antes, el agente no tiene patrones de los que aprender.
Arquitectura de alto nivel: Decidir entre microservicios vs monolito requiere contexto de negocio que el agente no tiene.
Decisiones de negocio con trade-offs complejos: Velocidad vs seguridad, coste vs features, etc.
Creatividad genuina: Los agentes combinan patrones existentes excepcionalmente bien, pero crear algo verdaderamente nuevo sigue siendo humano.

Esta honestidad es refrescante. Contrasta con el hype de “los agentes reemplazarán developers” que vemos en marketing.

Los datos de industria confirman el enfoque pragmático: Gartner proyecta que en 2026, el 40% de aplicaciones empresariales incluirán agentes específicos para tareas. Específicos. No generales. El énfasis está en tareas prácticas de alta confianza con ROI claro, no en ambiciones de AGI.

Cómo llevar esto a tu equipo (sin el caos)

El viaje de Mitchell fue individual. ¿Cómo lo traduces a un equipo de desarrollo? Aquí hay un roadmap adaptado de su experiencia combinado con datos de adopción empresarial:

Semanas 1-2: Adopción individual

Objetivo: Familiarización sin presión.

Cada desarrollador experimenta con asistentes de código: Cursor, GitHub Copilot, Claude Code. Sin expectativas de productividad. Solo exploración.

Resultado esperado: Identificar early adopters. Siempre hay 2-3 personas en cada equipo que abrazan nuevas herramientas rápido. Déjalos liderar por ejemplo, no por imposición.

Semanas 3-4: Documentación de equipo

Objetivo: Valor tangible sin riesgo.

Usa agentes para actualizar docs técnicas, READMEs, guías de onboarding. Estas son tareas de baja criticidad pero alta utilidad. Si el agente se equivoca, es fácil de corregir. Si tiene éxito, ahorraste horas de trabajo tedioso.

Resultado esperado: Primera victoria compartida. El equipo ve valor concreto.

Mes 2-3: Automatización de workflow

Objetivo: Identificar y automatizar slam dunks del equipo.

Empieza harness engineering colectivo. Crea un AGENTS.md de equipo. Documenta comportamientos malos descubiertos. Construye herramientas compartidas.

Tareas candidatas: code reviews automatizados preliminares, triage de bugs, testing básico de regresión, actualización de dependencias con validación.

Resultado esperado: 10-15% de tareas rutinarias delegadas a agentes.

Mes 4+: Optimización continua

Objetivo: Refinar y expandir.

Mide lo que funciona. Descarta lo que no. Expande a nuevas tareas gradualmente. No por presión de adopción, sino por evidencia de ROI.

Resultado esperado: 20-30% de tareas rutinarias automatizadas, permitiendo al equipo enfocarse en problemas complejos y creativos.

Métricas de éxito reales

No confíes solo en sensaciones. Mide. Las empresas que adoptan agentes de IA con disciplina están viendo resultados cuantificables:

ROI promedio: 171%, con empresas US alcanzando 192%
Time to ROI: 74% logra retorno en el primer año
Productividad: 39% de ejecutivos reportan productividad al menos duplicada
Content creation: 46% más rápido en equipos de marketing
Customer service: Reducción del 52% en tiempo de casos complejos (caso ServiceNow)
Productividad general: Ganancias del 15-30% en áreas como customer service

El factor crítico según análisis de Oracle: “Las organizaciones exitosas no son las que tienen mejor infraestructura de IA, sino las que activan agentes rápidamente, miden resultados tangibles, e iteran con disciplina.”

Gestionar la resistencia

Adoptar agentes genera miedos legítimos:

“¿Me volveré obsoleto?”

Reframe: Los agentes son multiplicadores, no reemplazos. Eliminan trabajo tedioso para que te enfoques en problemas interesantes. Los developers que usan agentes efectivamente tienen ventaja sobre los que no.

“¿Los juniors aprenderán los fundamentos?”

Mitchell menciona esto explícitamente. Su recomendación: Juniors deben aprender fundamentos sin agentes primero. Entender por qué el código funciona, no solo cómo hacer que un agente lo genere. Después, los agentes son herramientas poderosas.

“¿Perderemos control de calidad?”

Solo si no implementas harness engineering. La revisión sigue siendo necesaria. Los agentes proponen, los humanos deciden.

Transparencia ayuda. Comparte wins y fails. Muestra el AGENTS.md creciendo con el aprendizaje del equipo. Haz visible el proceso, no solo los resultados.

Lo que Mitchell aprendió (para que tú no tengas que repetirlo)

Lecciones clave

1. Saber cuándo NO usar agentes es tan valioso como saber cuándo usarlos

No uses agentes por usar agentes. Mitchell insiste en esto: “I don’t want to run agents for the sake of running agents.” Ten criterio. A veces hacer algo manualmente es más rápido y efectivo.

2. La eficiencia neta llegó solo en el paso 4

Los primeros tres pasos fueron inversión, no ganancia. Hubo más fricción, más trabajo, más frustración. Requiere paciencia y compromiso con el proceso. La mayoría de la gente abandona demasiado pronto.

3. Notificaciones desactivadas son críticas

Context-switching es el enemigo silencioso de la productividad. Cuando un agente te notifica que terminó, interrumpe tu flujo. Deja que los agentes trabajen en background. Revisa sus resultados cuando tú elijas.

4. Single agent > Multiple agents paralelos

Mitchell ejecuta un solo agente a la vez. Menos complejidad. Más control. Menos costes de API. Resultados más predecibles. La orquestación de múltiples agentes es tentadora en teoría, caótica en práctica.

Errores comunes

1. Abandonar en la fase de ineficiencia

La curva de adopción tiene un valle. Al principio eres menos productivo con agentes que sin ellos. Es temporal. Mitchell se forzó a través de esta fricción. La mayoría no lo hace.

2. No documentar los errores

Sin harness engineering, repites los mismos problemas. El agente comete error X. Lo corriges. Semana después, comete error X otra vez. AGENTS.md es tu memoria organizacional. Úsalo.

3. Expectativas irreales

Los agentes no son developers senior autónomos. Necesitan revisión. Necesitan contexto. Necesitan guía. Son junior-to-mid level en el mejor caso. Si esperas más, te decepcionarás.

4. Escalar sin validar

No evangelices agentes a toda la empresa porque funcionaron en tu equipo. Valida con slam dunks específicos. Mide resultados. Entonces expande. Datos antes que entusiasmo.

El disclaimer de Mitchell

Mitchell termina su artículo con un párrafo que vale citar completo:

“Este post fue escrito completamente a mano, con mis propias palabras. No tengo participaciones financieras en compañías de IA. Respeto las elecciones individuales sobre adopción de IA. Soy un artesano del software que solo quiere construir cosas por amor al oficio.”

Por qué importa: Incluso los early adopters mantienen perspectiva crítica. No es evangelismo. Es pragmatismo. Mitchell reconoce que en meses, sus opiniones actuales pueden parecer ingenuas dado lo rápido que evoluciona el campo. Humildad intelectual.

Tu plan de acción para las próximas 2 semanas

Suficiente teoría. ¿Cómo empiezas mañana?

Week 1: Experimento personal

Día 1-2: Elige una herramienta. Claude Code, Cursor, o GitHub Copilot. Configura el entorno. Lee la documentación básica. No esperes productividad aún.

Día 3-4: Reproduce un commit manual con el agente. Elige algo que ya hiciste. Intenta que el agente llegue al mismo resultado. Documenta qué funcionó y qué no.

Día 5: Reserva 30 minutos de “end-of-day agent time”. Lanza el agente en tareas de baja criticidad: research, exploración, documentación. Sin presión.

Week 2: Primeros slam dunks

Día 1-2: Identifica 3 tareas candidatas a slam dunk en tu workflow. Criterios: repetitivas, bien definidas, bajo riesgo si fallan. Escríbelas específicamente.

Día 3-4: Ejecuta agente en background en una de esas tareas. Notificaciones desactivadas. Trabaja en algo más. Revisa resultado después.

Día 5: Evalúa honestamente. ¿Funcionó? Si sí, añádela a tu lista de slam dunks. Si no, actualiza tu AGENTS.md personal con lo aprendido. Qué falló. Por qué. Cómo prevenirlo.

Repite este ciclo. Gradualmente tu lista de slam dunks crece. Tu AGENTS.md se vuelve más rico. Tu confianza en los agentes aumenta basada en evidencia, no en hype.

Recursos para profundizar

Fuentes primarias:

Recursos técnicos:

Datos de industria:

Conclusión

Mitchell Hashimoto no comenzó creyendo en los agentes de IA. Pasó por frustración, ineficiencia, y muchos errores antes de alcanzar el 10-20% de su jornada laboral con agentes activos en background. Su viaje revela que la adopción exitosa no es sobre tecnología, es sobre metodología.

Harness engineering, slam dunk tasks, y paciencia para atravesar las fases iniciales de fricción. Estas son las claves. No el modelo más nuevo. No la herramienta más hype. Proceso disciplinado y aprendizaje iterativo.

Las empresas que adoptan agentes con esta disciplina (medición, iteración, ROI claro) están viendo retornos del 171%. Las que lo hacen por hype están desperdiciando recursos. La diferencia no es la tecnología, es el enfoque.

No necesitas revolución. Necesitas evolución. Empieza mañana con un experimento personal de 2 semanas. Documenta lo que aprendes. Construye tu harness. Identifica tus slam dunks. En tres meses, tendrás resultados medibles.

Como dice Mitchell: “Soy un artesano del software que solo quiere construir cosas por amor al oficio.” Los agentes de IA son herramientas. Buenas herramientas, si se usan bien. No magia. No reemplazos. Multiplicadores de capacidad en manos de profesionales que saben qué están haciendo.

¿Listo para empezar? Descubre cómo implementamos equipos técnicos con agentes de IA usando nuestro framework APEX, o solicita una auditoría gratuita para identificar oportunidades en tu workflow actual.