Verificado al 11 de julio de 2026. Este análisis realiza un seguimiento de los cambios en los flujos de trabajo de los desarrolladores, los debates sobre la codificación basada en agentes y las prácticas de verificación de software.
- La chispa viral: ‘¿Cómo mides el éxito?’
- La IA como bloc de notas desechable: El flujo de trabajo real
- Los límites de la optimización automática: La advertencia de la ‘psicosis de los agentes’
- El espectro de la lectura de código: Tres arquetipos de desarrolladores
- La falacia de la comparación con el compilador
- FAQ
- Fuentes
Puntos Clave
- El origen: Cuando se le preguntó en X sobre cómo valida y mide el éxito del uso de IA en sus proyectos, el creador de Ghostty, Mitchell Hashimoto, respondió: “Yo leo el código”.
- El flujo de trabajo real: En lugar de confiar en complejos flujos de trabajo automáticos para producción, Hashimoto utiliza LLM para escribir demos desechables y probar direcciones, y luego reescribe el código a mano desde cero.
- La advertencia de la psicosis: Hashimoto advirtió contra confiar ciegamente en la optimización de agentes después de que uno redujera el tiempo de renderizado de 88 ms a 2 ms y las asignaciones de ~150K a 500. Lo reescribió en Go para verificar el resultado.
- El debate: El intercambio resalta el cambio de rol del ingeniero de software, de escritor de código a editor que debe verificar salidas probabilísticas generadas por máquinas.
La comunidad de ingeniería de software está experimentando una división sobre cómo integrar la inteligencia artificial en los flujos de trabajo diarios. Mientras algunos defensores promueven agentes completamente autónomos que escriben y envían código sin supervisión humana, un intercambio viral ha devuelto la atención a la necesidad de la revisión manual.
La chispa viral: ‘¿Cómo mides el éxito?’
La discusión comenzó en X cuando Mitchell Hashimoto, creador del emulador de terminal Ghostty y cofundador de HashiCorp, respondió a preguntas sobre su uso de modelos de lenguaje grande en el desarrollo de software. Cuando un usuario le preguntó qué métricas utilizaba para medir el éxito del uso de modelos de IA y detectar errores, Hashimoto respondió con una simple declaración:
“Yo leo el código”.
Esta respuesta de dos palabras generó una amplia discusión en Hacker News, Reddit y X. Para muchos ingenieros, sirvió como un recordatorio de que independientemente de lo avanzados que sean los modelos de generación, la verificación final sigue siendo una responsabilidad humana.
Este escepticismo se alinea con el trabajo anterior de Hashimoto al denunciar las prácticas de envío automatizado de código, como se detalla en el análisis de cómo Mitchell Hashimoto expuso el oleoducto de código basura de IA en el código abierto.
La IA como bloc de notas desechable: El flujo de trabajo real
Aunque algunas narrativas en línea han presentado a Hashimoto como alguien que utiliza flujos de trabajo complejos y multimodelo para escribir código de producción, su enfoque real es mucho más pragmático. En una entrevista reciente, Hashimoto describió su uso de la IA no como un flujo de producción estructurado, sino como un método para el prototipado rápido y desechable.
Hashimoto explicó que utiliza LLM para construir rápidamente demostraciones informales donde el código generado es basura. El objetivo no es enviar este resultado a producción, sino verificar rápidamente si una característica específica o una dirección arquitectónica es útil.
Si el prototipo resulta exitoso, Hashimoto descarta el código generado por IA por completo y reescribe la implementación a mano con el cuidado que merece. Este enfoque trata a la IA como un bloc de notas digital en lugar de una fábrica automatizada, manteniendo las bases de código de producción limpias y completamente comprendidas por sus mantenedores humanos.
Los límites de la optimización automática: La advertencia de la ‘psicosis de los agentes’
Para ilustrar los peligros de confiar acríticamente en el código generado por máquinas, Hashimoto compartió un experimento de optimización que involucraba un renderizador de software. Ejecutó un agente de codificación automatizado en un bucle para optimizar su base de código.
El agente reportó métricas espectaculares, reduciendo los tiempos de cuadro de 88 ms a 2 ms (una reducción de aproximadamente 44 veces) y disminuyendo las asignaciones de aproximadamente 150.000 a solo 500. Sin embargo, en lugar de celebrar las métricas, Hashimoto reaccionó con un escepticismo explícito, llamando al fenómeno “psicosis del agente”.
Su publicación sirvió como una advertencia sobre confiar en métricas sospechosamente buenas reportadas por agentes sin comprender profundamente lo que realmente sucedió bajo el capó. Para verificar el trabajo del agente, reescribió manualmente el renderizador en Go bajo las mismas restricciones, asegurándose de que la lógica fuera sólida y correcta en lugar de aceptar ciegamente la telemetría de la máquina.
Este experimento resalta una limitación crítica de los asistentes de codificación de IA actuales. Aunque son aceleradores de escritura altamente efectivos que pueden aplicar rápidamente patrones de optimización estándar, carecen del razonamiento profundo desde los primeros principios necesario para diseñar arquitecturas de alto rendimiento sin producir errores silenciosos o diseños lógicamente incompletos.
El espectro de la lectura de código: Tres arquetipos de desarrolladores
La respuesta de la comunidad de desarrolladores al debate de “yo leo el código” resalta que la verificación de código no es un simple binario. En su lugar, los flujos de trabajo de ingeniería se están organizando en torno a tres arquetipos distintos:
1. La exploración del ‘Vibe Coding’
Para el prototipado temprano, productos mínimos viables (MVP) y scripts de utilidad internos, a menudo no es necesario leer el código. Los desarrolladores que practican el vibe coding priorizan la velocidad y la retroalimentación inmediata del usuario. Esto se alinea con el concepto de Hashimoto de la demo informal (usar IA para probar ideas rápidamente con la intención explícita de desechar el código).
2. Verificación manual de cada línea
Para sistemas centrales, emuladores de terminal y software crítico para la seguridad, los ingenieros eligen inspeccionar cada línea. En entornos sensibles al rendimiento, introducir código generado por máquinas sin verificar introduce un comportamiento impredecible que es difícil de depurar más adelante. Para estos sistemas, el control humano sobre la asignación de memoria y el flujo de ejecución es innegociable.
3. El término medio basado en arneses
Un número creciente de desarrolladores está adoptando un enfoque híbrido: diseñar software a nivel de interfaz, tipo y API. El ingeniero humano define la estructura y la lógica de integración (el arnés), mientras que el agente de IA genera los cuerpos de las funciones individuales.
Este flujo de trabajo es compatible con una estrategia multimodelo, aprovechando modelos premium para la planificación y modelos más baratos y rápidos para escribir código, similar a cómo los desarrolladores estadounidenses adoptan modelos de IA chinos para optimizar sus presupuestos de tokens.
La falacia de la comparación con el compilador
Un argumento común en defensa de no leer el código generado por IA es compararlo con los compiladores. Los defensores argumentan que los desarrolladores no leen el código ensamblador o de máquina generado por un compilador, por lo que no deberían necesitar leer el código generado por un LLM.
Sin embargo, los profesionales de software señalan que esta comparación es técnicamente defectuosa. Un compilador es una herramienta de traducción determinista: toma código estructurado y lo traduce según reglas estrictas. Si el código fuente es correcto, el resultado del compilador está garantizado de ser semánticamente idéntico.
En cambio, un LLM es un motor probabilístico. Predice el siguiente token más probable basándose en patrones de sus datos de entrenamiento. Debido a que los LLM son propensos a alucinaciones y pueden generar código incorrecto que parece correcto, tratarlos como compiladores introduce riesgos operativos y de seguridad significativos. A medida que los proveedores de EE. UU. reestructuran sus precios (como el reciente cambio en los precios de Claude Fable 5 a solo créditos), los desarrolladores deben evaluar si las ganancias de velocidad de la generación de IA sin verificar justifican los costos de mantenimiento a largo plazo.
FAQ
¿Qué es el debate de “yo leo el código”?
Es una discusión de la industria sobre la necesidad de que los ingenieros humanos revisen y verifiquen manualmente el código generado por IA en lugar de desplegarlo automáticamente.
¿Utiliza Mitchell Hashimoto la IA para escribir código de producción?
No. Hashimoto utiliza la IA para escribir prototipos temporales y desechables (demos informales) para probar ideas, y luego reescribe el código de producción final a mano.
¿Por qué es incorrecto comparar la IA con un compilador?
Los compiladores son herramientas deterministas que traducen código según reglas fijas, mientras que los LLM son motores probabilísticos que pueden generar lógica incorrecta o alucinada.
¿Qué fue la advertencia de ‘psicosis del agente’ de Mitchell Hashimoto?
Fue una advertencia contra confiar ciegamente en la optimización de agentes después de que uno reportara reducir los tiempos de cuadro de un renderizador de 88 ms a 2 ms. Hashimoto reescribió manualmente el renderizador en Go para verificar el resultado.
Sobre el autor
Ether Exter es un entusiasta de la IA con 5 años de experiencia probando y experimentando con modelos de IA, analizando qué funciona realmente. Síguelo en X: @EtherExperiment.
Fuentes
- Entrevista sobre flujo de trabajo: Mitchell Hashimoto Programming Q&A
- Estadísticas de modelos y OpenRouter: OpenRouter API Statistics
- Evaluación de herramientas de codificación de IA: Hunk Review and Refactoring Portal
- Discusión de la comunidad de desarrolladores: Hacker News AI Code Quality Threads
Acerca del autor
Ether Exter es un entusiasta de la IA con 5 años de experiencia probando y experimentando con modelos de IA, analizando lo que realmente funciona. Sígalo en X: @EtherExperiment.
