Capítulo 3 — El viaje de adopción de Mitchell Hashimoto
Capítulo 3 — El viaje de adopción de Mitchell Hashimoto
Basado en My AI Adoption Journey de Mitchell Hashimoto, creador de Terraform y Vagrant, publicado en febrero de 2026.
Por qué este capítulo cierra el tutorial
Los dos capítulos anteriores entregaron herramientas distintas:
- El capítulo 1 dio una receta concreta: feature list, progress file, init.sh.
- El capítulo 2 dio el marco conceptual: feedforward, feedback, harnessability, ley de Ashby.
Falta una pregunta práctica que ningún marco contesta: ¿cómo se llega a usar todo esto en serio?
No empezás un lunes diciendo “hoy implemento harness engineering”. Empezás frustrado con un chatbot, después probás algo, falla, probás otra cosa, y meses después te das cuenta de que armaste — sin planearlo — la infraestructura que los otros dos capítulos describen.
Mitchell Hashimoto documenta exactamente ese trayecto. Su artículo no es teoría: son seis fases de adopción, cada una con un fracaso específico que lo empujó a la siguiente. Es el mejor caso de estudio público sobre cómo el harness engineering aparece naturalmente en una práctica seria.
Quién es y por qué importa el caso
Mitchell Hashimoto creó Terraform y Vagrant. Es un ingeniero que vive de construir cosas, no de vender hype sobre IA. Aclara explícitamente que no invierte en empresas de IA, que su objetivo es entregar software como artesano, y que llegó a estas conclusiones empujado por la realidad del trabajo, no por entusiasmo.
Eso vuelve su narrativa especialmente útil: cada fase es una respuesta a un problema concreto, no a una visión.
flowchart LR
F1[1. Abandonar\nchatbots] --> F2[2. Reproducir\ntrabajo manual]
F2 --> F3[3. Agentes de\nfinal de jornada]
F3 --> F4[4. Delegar\nslam dunks]
F4 --> F5[5. Ingeniería\ndel harness]
F5 --> F6[6. Agentes\nsiempre activos]
style F5 fill:#bfdbfe,stroke:#1e40af
style F6 fill:#dcfce7,stroke:#166534Fase 1 — Abandonar los chatbots
El detonante
Hashimoto reconoce valor en ChatGPT, Gemini y similares para tareas puntuales. Su experiencia exitosa inicial fue reproducir la paleta de comandos de Zed usando SwiftUI con Gemini. Funcionó.
Pero al intentar escalar la misma forma de trabajo a proyectos reales, chocó con un techo. Los chatbots exigen corrección humana constante: copiar código, pegar errores, explicar contexto, copiar de vuelta. La fricción mata el flujo.
El cambio de marco
Migra de “chatbot” a agente, definido como:
Un LLM que conversa e invoca comportamientos externos en bucle.
Las capacidades mínimas que un agente necesita para que valga la pena adoptarlo:
- Leer archivos
- Ejecutar programas
- Hacer solicitudes HTTP
Esa lista es más profunda de lo que parece. Un chatbot sin estas tres cosas siempre va a tener al humano como cuello de botella. Un agente con las tres puede cerrar el loop por su cuenta.
Lectura desde el marco
En vocabulario del capítulo 2: un chatbot es un sistema con feedback humano obligatorio en cada iteración. Un agente es un sistema con feedback computacional automático — y eso cambia todo lo que se puede construir encima.
Fase 2 — Reproducir el trabajo manual
El experimento
Hashimoto adopta Claude Code y los primeros intentos no salen bien. En vez de abandonar, hace algo metodológicamente valioso: realiza la misma tarea dos veces, una manualmente y otra con el agente, y compara.
Los descubrimientos
El experimento no produce una respuesta tipo “sirve / no sirve”. Produce tres descubrimientos que se vuelven principios:
- Desglosar la sesión en tareas claras y accionables. Una instrucción vaga falla. Una tarea atómica con criterio de éxito explícito tiene chance.
- Separar planeación de ejecución. El mismo agente no es bueno haciendo las dos cosas en el mismo turno. La planeación pide divergencia; la ejecución pide convergencia.
- Dotar al agente de capacidades de verificación automática. Tests, builds, linters. Sin ellos, “terminó” significa “creyó que terminó”.
El aprendizaje meta
Saber cuándo no usar agentes previene más desperdicio que automatizar tareas con éxito marginal.
Esta línea sola justifica el experimento. La métrica útil no es “qué porcentaje de tareas puede hacer el agente”. Es “qué tareas son rentables delegarle”. Las dos preguntas tienen respuestas muy distintas.
Fase 3 — Agentes de final de jornada
La hipótesis
Las últimas dos horas del día son cognitivamente las menos productivas. Hashimoto bloquea 30 minutos al final para lanzar agentes en paralelo sobre tareas que pueden trabajar mientras él descansa.
Los tres tipos de tarea que funcionan
Investigación profunda: agentes encuestando librerías por lenguaje, licencia y sentimiento de la comunidad. Resultado al día siguiente: una nota lista para decidir.
Exploración de ideas vagas: distintas posibles soluciones a problemas que no tiene tiempo de atacar. El agente devuelve opciones; el humano elige.
Triaje de GitHub: scripts con gh para revisar issues, sin contestar todavía. Devuelve resúmenes priorizados.
El beneficio no obvio
flowchart LR
PM[Final de jornada\n5pm] -->|"30 min lanzando\nagentes"| N[Noche]
N -->|"trabajan solos"| AM[Mañana siguiente]
AM -->|"arranque en caliente"| W[Trabajo profundo\ncon contexto pre-cargado]
style PM fill:#fef3c7,stroke:#92400e
style W fill:#dcfce7,stroke:#166534El humano abre la mañana con material ya procesado. La parte costosa del día — la primera hora de “calentar motor” — se reemplaza por leer un informe que ya está listo.
Fase 4 — Delegar los “slam dunks”
La definición
Un slam dunk es una tarea donde el agente tiene probabilidad alta de éxito en el primer intento. No cualquier tarea. No las que requieren juicio fino. Las que son tediosas pero estructuradas.
El workflow diario
- Triaje manual de issues de la noche anterior — el humano filtra.
- Marca los slam dunks y los lanza al agente, secuencialmente (no en paralelo).
- Mientras el agente trabaja, el humano hace deep work en otro lado.
La práctica crítica
Desactivar notificaciones del agente.
El cambio de contexto cuesta más que esperar. El humano decide cuándo mirar el resultado, no el agente cuándo interrumpirlo. Esta inversión de control es la diferencia entre un asistente útil y una notificación más en una vida ya saturada.
La objeción honesta
¿No erosiona habilidades? Hashimoto contesta: delego tareas sin aprendizaje y mantengo desarrollo manual en las que sí lo tienen. La pregunta no es “agente sí o agente no” sino “qué tareas en mi calendario tienen valor educativo y cuáles son puro overhead”.
Fase 5 — Ingeniería del harness
Acá la narrativa se enchufa directamente con los dos capítulos anteriores.
El principio operativo
Cada error recurrente del agente genera una intervención que previene su recurrencia.
Es exactamente el steering loop del capítulo 2: observar problema repetido → diseñar control → integrar al harness.
Las dos formas que adopta
Prompting implícito vía AGENTS.md
Archivo de instrucciones específicas del proyecto. Hashimoto cita su propio repo de Ghostty como ejemplo: tiene un AGENTS.md que documenta comportamientos defectuosos del agente y los neutraliza. Resultado público: bugs recurrentes “casi completamente resueltos”.
Herramientas programadas
Scripts pequeños que el agente puede invocar:
- Capturar screenshots
- Correr tests filtrados a un subconjunto
- Validar formatos
- Verificar runtime
Combinados con AGENTS.md que le indica al agente cuándo usarlos.
flowchart TD
E[Error recurrente\ndetectado] --> D{Tipo de error}
D -->|"no sabía\nqué hacer"| F1[Agregar instrucción\nen AGENTS.md]
D -->|"no detectó\nque falló"| F2[Agregar script\nde verificación]
F1 --> R[Agente futuro\nno lo repite]
F2 --> R
style E fill:#fee2e2,stroke:#991b1b
style R fill:#dcfce7,stroke:#166534Por qué esto cierra los capítulos anteriores
| Lo que muestra Hashimoto | Concepto del marco |
|---|---|
AGENTS.md con instrucciones | Feedforward (capítulo 2) |
| Scripts de verificación | Feedback computacional (capítulo 2) |
| Iterar el archivo cuando falla | Steering loop (capítulo 2) |
| Solo bugs recurrentes generan reglas | Variety reduction / ley de Ashby |
AGENTS.md específico del proyecto | Plantilla de harness por topología |
Hashimoto no construyó nada que no esté nombrado en el capítulo 2. La diferencia es el orden: él descubrió las piezas resolviendo problemas reales, no leyendo un marco conceptual.
Fase 6 — Agentes siempre activos
La meta actual
Mantener un agente ejecutando algo de forma continua durante el día laboral. Particularmente efectivo con modelos lentos y reflexivos: menciona el “deep mode” de Amp con un modelo en la línea de GPT-5.2-Codex que tarda 30 minutos por cambio chico, pero produce resultados de calidad superior a los modelos rápidos.
Las limitaciones que admite
- No paraleliza múltiples agentes. Es un solo agente activo en un momento, no una flota.
- Logra ~10–20% de la jornada con agente activo. No es todo el día. Es una fracción.
- No deja agentes corriendo sin propósito. La meta es siempre tener una tarea delegable lista, no inflar la métrica.
El cambio de mentalidad
Pasa de “¿cuándo uso un agente?” a “¿qué del trabajo del día puede ir mientras yo hago lo que solo yo puedo hacer?”. Es la pregunta correcta — la que asume que el agente es una herramienta de fondo, no un evento.
Las tres fases universales detrás de las seis
Hashimoto cierra con un patrón general que aplica a la adopción de cualquier herramienta nueva:
flowchart LR
I[1. Ineficiencia\ninicial] --> A[2. Adecuación\nbásica]
A --> T[3. Descubrimiento\ntransformador]
style I fill:#fee2e2,stroke:#991b1b
style T fill:#dcfce7,stroke:#166534| Fase | Sensación | Riesgo |
|---|---|---|
| 1. Ineficiencia inicial | ”Esto es más lento que hacerlo a mano” | Abandonar antes de tiempo |
| 2. Adecuación | ”Empieza a servir para tareas puntuales” | Frenar y no descubrir más usos |
| 3. Transformación | ”Cambió cómo trabajo” | Sobre-aplicar a tareas donde no rinde |
La fricción de la fase 1 es esperable. Exige atravesarla antes de poder evaluar la herramienta con honestidad. Esto explica por qué tantas adopciones tempranas fallan: la gente evalúa en la fase 1 y nunca llega a la fase 3.
Reservas honestas que vale la pena no esquivar
Hashimoto explicita preocupaciones que el discurso del hype suele ocultar:
Formación de juniors
Si el agente hace las tareas que tradicionalmente formaban a un desarrollador junior — leer código mediocre, pelearse con un build roto, googlear cuatro errores hasta entender el quinto — ¿qué pasa con la formación?
No tiene una respuesta. La señala como riesgo real. La industria entera tendrá que resolverlo en los próximos años.
El equilibrio que evita la trampa
Una de las cosas que más me gustaron fue concentrarme en tareas que disfrutaba mientras delegaba el trabajo desagradable.
La frase es importante. La trampa opuesta sería delegar lo disfrutable y quedarse con lo desagradable, o delegar todo y perder oficio. El equilibrio personal — qué delegás y qué te reservás — es una decisión activa, no algo que el agente decide por vos.
Aplicación al lector
Si tu equipo recién está adoptando agentes, este es el plan que la narrativa de Hashimoto sugiere:
- Saltá los chatbots para trabajo serio. Adoptá una herramienta tipo agente desde el día uno (Claude Code, Cursor con agent mode, Aider).
- Hacé el experimento dual una semana. Misma tarea, dos veces. Documentá qué falló cada vez.
- Identificá tu primer slam dunk. Una tarea repetitiva, estructurada, con criterio de éxito claro. Delegala.
- Empezá tu
AGENTS.md. No de cero — solo cuando un agente meta la pata por segunda vez del mismo modo. La regla nace del fallo. - Sumá scripts de verificación cuando duelan. Cada bug que el agente no detectó solo es un script nuevo en tu carpeta de tooling.
- Resistí la tentación de paralelizar antes de tiempo. Un agente bien dirigido vale más que cinco agentes mediocres.
flowchart TD
S[Semana 1\nExperimento dual] --> A[Semana 2-3\nPrimer slam dunk]
A --> B[Mes 2\nAGENTS.md naciente]
B --> C[Mes 3+\nScripts de verificación]
C --> D[Mes 6+\nAgentes en background]Cierre del tutorial
Tres lentes sobre el mismo problema:
- Anthropic / Justin Young te dio el harness como artefacto concreto: archivos, scripts, convenciones. La receta.
- Birgitta Böckeler / Thoughtworks te dio el harness como disciplina de ingeniería: vocabulario, principios, decisiones de diseño. El marco.
- Mitchell Hashimoto te da el harness como trayecto personal: cómo se llega ahí desde el primer día de frustración con un chatbot. La práctica vivida.
Las tres convergen en lo mismo: un agente útil no aparece — se construye. Lo que cambia entre las tres fuentes es desde dónde lo mirás.
Construir software con agentes no es una ruptura con la ingeniería tradicional: es ingeniería tradicional con un actor más en el equipo, uno que necesita exactamente las mismas afordances que un humano nuevo — instrucciones claras, herramientas accesibles, feedback rápido — y un par de afordances extra porque carece de memoria y de responsabilidad social.
El harness es lo que cubre esa diferencia. Y cómo lo construís — desde la receta, desde el marco o desde la experiencia — depende de por dónde te toque empezar.
Fuente: My AI Adoption Journey — Mitchell Hashimoto, mitchellh.com, febrero 2026.