La Nueva Forma de Escribir Código de Mitchell Hashimoto

Cómo Mitchell Hashimoto Mantiene un Agente Ejecutándose en Todo Momento

Mitchell Hashimoto — cofundador de HashiCorp, creador de Terraform, y actualmente construyendo Ghostty — se une a Gergely Orosz en The Pragmatic Engineer para compartir una metodología profundamente considerada para el desarrollo asistido por IA. Esto no es hype ni opiniones pasajeras. Es un profesional con 20 años de experiencia describiendo cómo ha reestructurado fundamentalmente su flujo de trabajo diario alrededor de agentes de IA.

La disciplina central: “I endeavor to always have an agent doing something at all times. I want an agent if I’m coding, I want an agent planning. If they’re coding, I want to be reviewing. There should always be an agent doing something.” (“Me esfuerzo por siempre tener un agente haciendo algo en todo momento. Quiero un agente si estoy codificando, quiero un agente planificando. Si ellos están codificando, yo quiero estar revisando. Siempre debe haber un agente haciendo algo.”)

Antes de cada transición — salir de casa, conducir a algún lugar, parar al final del día — Mitchell dedica 30 minutos preguntándose: “¿Qué es algo lento que mi agente podría hacer a continuación?” Asigna a los agentes tareas de investigación, evaluaciones de librerías y análisis de casos extremos que no necesitan atención en tiempo real. Críticamente, desactiva todas las notificaciones del agente: “Yo elijo cuándo interrumpir al agente. Él no puede interrumpirme.”

Sobre lo que IA realmente te da: “It’s really allowed me to choose what I want to actually think about. I always felt limited — I’m going to have to spend the next two hours doing this boilerplate. But now I don’t have to learn about it.” (“Realmente me ha permitido elegir en qué quiero pensar. Siempre me sentí limitado — voy a tener que pasar las próximas dos horas haciendo este código repetitivo. Pero ahora no tengo que aprender sobre eso.”) Esto no se trata de producir más código. Se trata de redirigir la energía cognitiva al trabajo que importa.

Ingeniería de Mecanismos: La Estrategia de Calidad Compuesta

La contribución más original de Mitchell al discurso de codificación con IA es la ingeniería de mecanismos — su término para construir herramientas que los agentes pueden invocar para prevenir errores repetidos.

El patrón: Cuando un agente comete un error, en lugar de solo corregirlo, construye un test harness, script de validación, o regla de linting que el agente pueda invocar para auto-verificarse. Añade la regla a tu archivo CLAUDE.md o agents.md. El agente nunca comete ese error específico nuevamente.

Esto se compone con el tiempo. Cada sesión mejora el mecanismo. Cada mejora del mecanismo hace que sesiones posteriores del agente sean más confiables. Mitchell llama a esto uno de sus objetivos clave para 2026 y lo considera la inversión crítica en infraestructura para equipos que usan agentes de IA.

El requisito de prueba expandido: IA es “orientada a objetivos” — romperá cosas fuera del alcance de su tarea actual para lograr su objetivo inmediato. Esto significa que la cobertura de pruebas necesita ser mucho más expansiva de lo que era suficiente para desarrollo solo con humanos. Cada error de IA debería resultar en una mejora del mecanismo, no solo una corrección.

Calidad Dependiente del Contexto: De Cero Revisiones a Cada Línea

Mitchell aplica estándares de calidad completamente diferentes dependiendo del proyecto:

• Ghostty (terminal de código abierto, de larga duración): Revisa cada línea de código generado por IA. El rendimiento a 9 microsegundos por fotograma importa.
• Proyectos desechables (sitio web de boda familiar): Cero revisión de código. “¿Se renderizó bien en tres navegadores? Publicarlo. Solo estará en línea durante 2 meses.”

Este pragmatismo se extiende a ejecuciones de agentes competitivos. Para tareas difíciles donde la confianza es baja, ejecuta dos agentes en paralelo — Claude Code vs. Codex — y elige el mejor resultado. Se describe a sí mismo como “el alcalde” gestionando como máximo dos agentes a la vez.

Por Qué Git Podría No Sobrevivir la Era Agéntica

La predicción más provocadora: “This is the first time in like 12 to 15 years that anyone is even asking that question — will Git be around? — without laughing.” (“Esta es la primera vez en aproximadamente 12 a 15 años que alguien está incluso haciendo esa pregunta — ¿Git seguirá existiendo? — sin reírse.”)

Mitchell argumenta que Git y los repositorios de GitHub “no funcionan con infraestructura agéntica hoy.” Cuando la rotación de agentes es 10-100 veces la rotación humana, las colas de fusión se hacen imposibles, el espacio en disco explota, y los revisores humanos no pueden mantener el ritmo. Aconseja a una compañía stealth que trabaja específicamente en este problema.

Su visión para el futuro del control de versiones: mantener muchas más ramas, experimentos fallidos e historial — nunca eliminar. Este es el “momento Gmail para control de versiones.” Pero requiere herramientas fundamentalmente mejores para encontrar contexto relevante en repositorios masivos.

Las Contribuciones de Código Abierto Generadas por IA Están Destruyendo la Señal

Ghostty recibe 2-3 PRs de baja calidad generadas por IA diariamente. Mitchell ahora las cierra sin leer si carecen de un número de problema asociado. “AI makes it trivial to create plausible looking but incorrect and low-quality contributions. Open source has always been a system of trust. Before we had default trust. Now it’s default deny.” (“IA hace trivial crear contribuciones que se ven plausibles pero son incorrectas y de baja calidad. El código abierto siempre ha sido un sistema de confianza. Antes teníamos confianza por defecto. Ahora es negación por defecto.”)

Desearía que las herramientas agénticas “pausaran en abrir PRs” — la fricción que causan para los mantenedores supera la conveniencia para los contribuyentes. Incluso identifica la firma de Claude: abrir un PR en borrador sin cuerpo, editar el cuerpo, luego reabrirlo — un patrón que ningún humano sigue.

6 Principios del Flujo de Trabajo de IA de Mitchell Hashimoto

• Siempre tener un agente ejecutándose — Usa transiciones (conducir, descansos, fin del día) para encolar tareas lentas del agente. Los agentes nunca deben estar inactivos durante las horas de trabajo
• Separar la planificación de la ejecución — Un paso de planificación dedicado antes de la codificación del agente mejora dramáticamente la calidad de salida
• Construir mecanismos, no solo correcciones — Cada error del agente debería producir herramientas que prevengan recurrencia, no solo una corrección
• Elegir en qué pensar — El valor de IA no es más código por hora sino redirigir la cognición a arquitectura, diseño, y necesidades del usuario
• Rigor de revisión dependiente del contexto — Código de producción obtiene revisión de cada línea; prototipos desechables obtienen cero revisión. Acopla el esfuerzo a lo que está en juego
• Invertir en la curva de aprendizaje — “Es como si alguien intentara Git por una hora y decidiera que no era productivo. Toma esfuerzo sostenido convertirse en competente”

Lo Que Esto Significa para Organizaciones de Ingeniería

Mitchell enmarca el valor de IA no como ganancias de productividad bruta sino como capacidad expandida para experimentar. Pruebas de concepto que tomaban una semana ahora pueden hacerse en un día. Pero es notablemente cauteloso: “I hesitate to say more productive. There’s an expectation they could do more. You should be able to build a full demo, design, everything — you don’t need a team to do that anymore.” (“Dudo en decir más productivo. Hay una expectativa de que podrían hacer más. Deberías ser capaz de construir una demo completa, diseño, todo — ya no necesitas un equipo para hacer eso.”)

Para organizaciones, las implicaciones son concretas: requerir competencia en herramientas de IA en la contratación, tratar archivos de configuración de agentes (CLAUDE.md) como infraestructura de primera clase, invertir en ingeniería de mecanismos, y aceptar que pipelines de CI/CD necesitan repensar fundamental para manejar las pruebas expandidas que el código generado por IA demanda. Todo en infraestructura de ingeniería — editores, repositorios, CI/CD, pruebas, observabilidad, sandboxing — está en la mesa para cambio a la vez. Como lo dice Mitchell: “Esta es la primera vez en mi carrera profesional de 20 años que tanto está en la mesa para cambio a la vez.”