Mi recorrido de adopción de la IA

• Mitchell Hashimoto, quien salió de HashiCorp y está creando Ghostty, resume el proceso hasta integrar herramientas de IA en su trabajo real
• Lo divide en tres etapas: ineficiencia → adaptación → aumento de productividad, y registra en detalle los errores y aprendizajes de cada fase
• Tras reconocer los límites de la programación basada en chatbots, encontró valor de verdad al pasar a herramientas basadas en agentes
• Al entrenarse reproduciendo con agentes commits que antes completaba manualmente, internalizó que lo clave es la descomposición de tareas, separación entre planificación y ejecución, y verificación automática
• Aprovecha los últimos 30 minutos de la jornada para ejecutar trabajo automatizado nocturno y logra una mejora real de productividad delegando en agentes tareas simples y repetibles
• Actualmente siempre mantiene un agente ejecutándose y complementa eso con "ingeniería de harness" para maximizar la eficiencia de la colaboración entre IA y humanos

---

Contexto de adopción y enfoque

• Cada vez que se adopta una herramienta nueva, hay que pasar por tres etapas: ineficiencia → adecuación → innovación
  • Como ya existe familiaridad con el flujo de trabajo anterior, la adopción inicial resulta incómoda, pero a largo plazo lleva a una mejora de productividad
• En lugar de expectativas exageradas o críticas excesivas sobre las herramientas de IA, presenta una mirada equilibrada basada en experiencia de uso real

Paso 1: salir del chatbot

• Programar a través de interfaces de chatbot como ChatGPT o Gemini depende del entrenamiento previo, y como la corrección de errores depende de la retroalimentación repetida de la persona, termina siendo ineficiente
• Su primer “momento sorprendente” fue pegarle a Gemini una captura de pantalla de la paleta de comandos de Zed y recrearla en SwiftUI, lo que se convirtió en la base de la paleta de comandos de Ghostty para macOS
• Sin embargo, en el contexto de un proyecto brownfield (una base de código ya existente), los chatbots generaban con frecuencia malos resultados, y copiar y pegar código y salidas era más ineficiente que hacer el trabajo directamente
• Para obtener valor hay que usar necesariamente agentes; aquí, un agente es una herramienta en la que un LLM puede invocar de forma repetida acciones externas y que, como mínimo, necesita capacidad para leer archivos, ejecutar programas y hacer solicitudes HTTP

Paso 2: reproducir tu propio trabajo con un agente

• Cuando usó Claude Code por primera vez, no quedó satisfecho con los resultados, y corregirlos tomaba más tiempo que hacerlo él mismo
• En vez de rendirse, repitió el ejercicio de reproducir con un agente exactamente el mismo commit que había hecho manualmente
  • Era un proceso doloroso, porque implicaba hacer la misma tarea dos veces (manual + agente), pero la fricción al adoptar herramientas es algo natural
• En ese proceso descubrió por sí mismo tres principios clave:
  • Dividir la sesión en tareas unitarias claras y ejecutables
  • Si la petición es ambigua, separar la sesión de planificación y la sesión de ejecución
  • Si se le da al agente un medio para verificar el trabajo, puede corregir por sí mismo sus errores y evitar regresiones
• Identificar las áreas en las que el agente no funciona bien y saber cuándo no usarlo también fue un factor importante de mejora de eficiencia
• En esta etapa todavía no sentía una mejora neta de eficiencia, pero ya aceptaba al agente satisfactoriamente como herramienta

Paso 3: usar agentes al cierre del día

• Introdujo el patrón de dedicar los últimos 30 minutos de cada día a iniciar trabajo para agentes
  • La hipótesis era que, si el agente avanzaba mientras él no estaba trabajando, se podía obtener eficiencia
• Tres tipos de trabajo que le resultaron efectivos:
  • Sesiones de investigación profunda: investigar bibliotecas con cierta licencia en un lenguaje específico y generar resúmenes multipágina sobre ventajas, desventajas, actividad de desarrollo y reacción de la comunidad
  • Explorar ideas ambiguas con agentes en paralelo: no para lanzar algo, sino para descubrir variables desconocidas antes de trabajar al día siguiente
  • Clasificación y revisión de issues y PR: usando gh (GitHub CLI) para hacer triage de issues con agentes en paralelo; los agentes no respondían directamente, solo generaban un informe para revisar al día siguiente
• No dejaba a los agentes iterando toda la noche, y la mayoría de las veces terminaban en menos de 30 minutos
• Al convertir las horas de más cansancio al final del día en trabajo para agentes, consiguió el efecto de “arranque en caliente” a la mañana siguiente

Paso 4: delegación confiable de tareas

• Después de identificar tareas que el agente podía hacer casi con total seguridad, empezó a delegarlas a un agente en segundo plano mientras él se concentraba en otra cosa
• Cada mañana filtraba manualmente los resultados del triage de la noche anterior para seleccionar issues adecuados para el agente, y los ejecutaba de a uno
• Durante ese tiempo, en lugar de revisar redes sociales o videos, hacía él mismo trabajo de pensamiento profundo al estilo previo a la IA
• Desactivar las notificaciones de escritorio del agente fue clave: el costo del cambio de contexto es alto, así que es más eficiente que el agente no interrumpa a la persona y que ella revise el progreso en pausas naturales
• En respuesta al paper de Anthropic sobre formación de habilidades: acepta renunciar a la formación de habilidades en las tareas delegadas al agente, pero en las que sigue haciendo manualmente la formación de habilidades continúa de manera natural
• En esta etapa llegó a un nivel “del que ya no se puede volver”, y la mayor ventaja fue poder concentrarse en el trabajo que más le gusta

Paso 5: ingeniería de harness

• Los agentes son más eficientes cuando aciertan en el primer intento o cuando solo necesitan correcciones mínimas
• Cada vez que un agente se equivoca, ingenierizar una solución para que no vuelva a cometer el mismo error es la idea detrás de la “ingeniería de harness”
• Tiene dos formas:
  • Mejora de prompting implícito (AGENTS.md): si el agente ejecuta un comando incorrecto o encuentra una API equivocada, se registra en el archivo AGENTS.md para resolverlo; hay ejemplos reales en el repositorio de Ghostty
  • Herramientas programadas: escribir scripts para capturar pantallas, ejecutar pruebas filtradas, etc., y avisarle al agente en AGENTS.md que esas herramientas existen
• Actualmente está en esta etapa e invierte activamente en evitar comportamientos malos del agente y verificar los buenos

Paso 6: mantener siempre un agente en ejecución

• En paralelo con el Paso 5, se fijó como objetivo mantener siempre un agente ejecutándose en segundo plano
• Prefiere modelos lentos que tardan más de 30 minutos pero dan resultados de alta calidad, como el deep mode de Amp (basado en GPT-5.2-Codex)
• Actualmente no ejecuta múltiples agentes en paralelo, porque considera que el equilibrio adecuado está entre un agente y el trabajo manual
• En la práctica, solo alrededor del 10~20% del tiempo laboral tiene un agente en segundo plano funcionando, y sigue intentando mejorar esa proporción
• El objetivo no es ejecutar agentes por ejecutarlos, sino hacerlo solo cuando haya tareas realmente útiles, y crear flujos de trabajo delegables y de alta calidad sigue siendo importante independientemente de si se usa IA o no

Estado actual y perspectiva

• Está obteniendo resultados con herramientas de IA y las aborda desde una mirada equilibrada basada en la realidad
• No trabaja para empresas de IA, ni invierte en ellas, ni las asesora; su motivación central, exista o no la IA, es disfrutar construir cosas como artesano del software
• Le preocupa profundamente el problema de formación de habilidades en desarrolladores junior con bases débiles
• Como la velocidad de innovación de los modelos es alta, hay que revisar continuamente el juicio sobre las áreas en las que los agentes aún no funcionan bien
• Usar o no usar IA es una elección personal, y este texto busca compartir un caso personal sobre cómo explorar y aprovechar herramientas

[GN⁺]

Comentarios de Hacker News

• La clave es dividir la sesión en unidades de trabajo claras y accionables
  Si das instrucciones demasiado detalladas, no hay razón para usar un LLM, y si son demasiado amplias, como “haz una app tipo Facebook para perros”, solo sale un prototipo inútil
  Al final, usar LLM para código con éxito consiste en encontrar ese alcance adecuado

  • La parte que más disfruto al usar herramientas de IA es justamente formar esa intuición
    Entender qué tipo de tareas dan buenos resultados y ajustar el alcance en función de eso da una satisfacción parecida a modularizar al programar
  • Fracasé al hacer pedidos demasiado grandes, como en el ejemplo de “Facebook para perros”
    En Lovable daba la impresión de que el onboarding ya te empujaba al fracaso, pero con Claude Code, al dividir todo en partes pequeñas, me fue mucho mejor
  • Usar un LLM solo para buscar ejemplos de sintaxis de for es cómodo porque reduce el cambio de contexto
    Al principio lo usaba mucho como apoyo básico para escribir código
  • A medida que mejoran los modelos, da la impresión de que el límite superior de ese alcance adecuado sube cada 6 a 8 semanas
  • A veces le decía “imprime la salida” y de verdad respondía agregando solo print(output)
    Trabajar alternando entre lenguaje natural y código incluso se siente psicológicamente más cómodo

• 2025 fue el año en que las herramientas de IA para programar realmente entraron en una fase práctica
  Antes, modelos tempranos como GPT-3 solo mostraban posibilidades, y eso generó demasiado hype y escepticismo
  Pero ahora muchos desarrolladores ya están integrando IA en su flujo de trabajo real
  Si todavía eres escéptico, recomiendo leer el texto de Mitchell y probar Claude Code por tu cuenta

  • Pienso lo mismo. Me da curiosidad cuál momento se recordará dentro de 10 años como el punto de inflexión
    Hubo una época en que se hablaba mucho de los “límites de los datos”, pero con la salida de Claude Code, Sonnet 4.5 y Opus 4.5 el ambiente cambió por completo
  • Me pregunto si hay alguna razón para usar Claude Code en vez de Codex o Gemini
    Ambos modelos me parecían parecidos, pero todavía no lo he probado por los comentarios de que en Claude los límites de uso del plan se consumen muy rápido
  • Aun así, me sigue preocupando una estructura industrial centrada en el hype
    Me da miedo que la gerencia solo se enfoque en velocidad y volumen, y termine produciendo montones de código imposibles de mantener

• El enfoque de “Don’t draw the owl” también coincide con mi experiencia
  El problema era que el LLM cada vez se desviaba más de las restricciones del mundo real
  Por eso separé las cosas: el chat para discutir diseño, y el agente solo para trabajos de diff estrechos y verificables
  Cuando ese ciclo se estabilizó, dejó de ser un juguete y se volvió una palanca real, y pude desplegar varias veces funciones en proyectos reales

  • Me señalaron que el estilo del texto se parece al de un LLM
    Es interesante porque últimamente este tipo de estructura de frases estandarizada también está aumentando entre las personas
  • También da la impresión de que este enfoque en realidad no es tan distinto de cómo siempre debimos desarrollar software

• Como empezó a haber mucha discusión sobre Opus 4.5, lo probé por mi cuenta y sentí que el paradigma de agente de verdad ya se volvió útil
  Por ahora sigo usándolo sobre todo para tareas simples, pero me deja satisfecho

• Los LLM no son para mí
  La capacidad de pensar y la creatividad humanas son lo que nos distingue, y siento que entregárselas a una máquina termina debilitándonos
  Como desarrollador Rails probé Zed, Claude Sonnet 4.x y Opus, pero noté que cada vez se me daba peor escribir RSpec
  Al final volví a neovim y trabajo sin agentes
  La comodidad al final puede traer una atrofia del pensamiento
  Los LLM son la mejor herramienta de conveniencia que ha creado la humanidad, pero yo prefiero conservar mis habilidades y mi forma de pensar

• Este texto se siente mucho más práctico y menos exagerado que otros que han llegado a la portada

  • Por fin salió una guía paso a paso que incluso la gente escéptica puede intentar seguir
    En lugar de exageraciones tipo “hice un OS con vibe coding”, propone un enfoque realista

• Es interesante ver que todos están pasando por recorridos de adopción de IA parecidos
  Usan varios modelos en paralelo para distintas partes del codebase y hacen que los modelos se validen entre sí
  Sigo usando git reset con frecuencia, pero poco a poco estoy aprendiendo maneras más eficientes de evitarlo
  Se siente como vivir en la era del autocompletado del cerebro

• Alguien dijo que “un agente debe poder leer archivos, ejecutar programas y hacer solicitudes HTTP”,
  y eso está casi al mismo nivel que la ‘tríada letal’ de la que habla Simon Willison

  • Por eso yo jamás pienso correr algo así en mi máquina local

• Me fastidia tener que seguir diciéndole al agente qué debe mejorar
  Cada vez tengo que editar agent.md para darle retroalimentación, y ojalá pudiera aprender solo y mejorar

  • Pero la mejora para una persona puede ser un code smell para otra
    Agregar unas cuantas líneas a AGENTS.md tampoco es para tanto
    Si creas un comando /fix para que haga correcciones y documentación automáticamente, ahorra bastante tiempo
  • A mí, en cambio, sí me gusta dar retroalimentación
    Me da la sensación de que yo sigo teniendo el control de la ingeniería
    Sobre todo porque permite iterar rápido en investigación e implementación de funciones nuevas

• Si quieres ver cómo se ve este enfoque en la práctica,
  vale la pena revisar la entrada anterior del blog del OP, “Non-trivial Vibing”, y la discusión en HN sobre ella