Por qué seguir programando en 2026 — la respuesta de 540 comentarios en HN que los agentes de IA no quieren que leas

Mientras lees esto, hay agentes de IA generando millones de líneas de código en servidores de todo el mundo. Empresas enteras están reemplazando equipos de desarrollo por asistentes de Claude Code, Cursor y GPT-5.6. Y un ingeniero de GitHub advirtió que en 12 meses ya no va a saber qué significa "escribir código".

Pero entonces, ¿por qué un post en Hacker News titulado "Why Write Code in 2026" acumuló 540 comentarios en horas y un ratio de discusión de 3.17 — el más alto del día?

Porque la pregunta correcta no es "¿puede la IA reemplazar a los programadores?".
La pregunta es: ¿qué pierdes cuando delegas completamente tu pensamiento a una máquina?

El argumento que nadie se atreve a hacer

Doug Turnbull, el autor del post, no es un tecnófobo que escribe a máquina desde una cabaña en el bosque. Es un ingeniero de software que admite abiertamente que la gran mayoría de su código hoy es generado por IA.

Pero dice algo que incomoda: "Los agentes de IA no son compiladores. Son pasantes recién contratados que leen código parcial — posiblemente slop — y reciben una descripción imprecisa del cambio que deben generar."

Y ahí está el núcleo del debate. Tratar a los coding agents como si fueran compiladores — una caja negra que transforma especificaciones en código perfecto — es un error que ya estamos pagando.

La fábrica de software tiene un problema de atención

Imaginá una línea de ensamblaje de autos. Los agentes de IA son los robots que ponen tornillos y soldan piezas. Rápidos, eficientes, incansables. Pero cada tanto alguien tiene que desarmar la línea de ensamblaje para entender por qué un lote de frenos falla en campo.

Ese alguien no puede ser un pasante. Necesita entender el motor de combustión interna — la arquitectura del sistema — y conectar los detalles minúsculos con el panorama completo.

Turnbull lo plantea así: "Para mantener mi atención, debo ir más allá de 'leer código' como un observador pasivo de agentes desde lejos. Para conectar realmente con la arquitectura del sistema, ayuda sumergirse en el código."

Traducción: no podés mantener la calidad de un sistema si nunca ensuciaste tus manos con él.

El slop que nadie ve hasta que es demasiado tarde

Hay un fenómeno que los defensores del "todo IA" evitan mencionar: los agentes amplifican las malas decisiones.

Turnbull cuenta una experiencia reveladora: "Una mañana, mi cerebro humano — sin cafeína todavía — decidió usar el localStorage del navegador para manejar estado aleatorio. Todo lo demás iba a una base de datos. Cuando miré el código que los agentes generaron para preservar esa idiotez humana, la cantidad de wrappers e indirección para mantener esa decisión estúpida probablemente triplicó las líneas de código."

El problema no es que la IA genere mal código. Es que genera código conservador que preserva tus peores decisiones en lugar de desafiarlas. Un pasante no te dice "jefe, esto que hiciste está mal". Un pasante ejecuta. Y si el pasante es un agente de IA, ejecuta a escala industrial.

El inglés no es un lenguaje de programación

Uno de los argumentos más sólidos del post: "El inglés es un lenguaje poco especificado. No es una forma precisa de expresar cómputo."

Cuando le pedís a un agente: "hacé que esto sea más rápido", el agente puede interpretar 50 cosas distintas. Cuando vos mismo escribís el bucle optimizado, sabés exactamente qué está pasando. Sabés dónde están las compensaciones. Sabés qué asunciones hiciste.

Hay un tipo de pensamiento que solo ocurre cuando estás escribiendo código — cuando estás explorando el espacio de diseño en el medio de ejecución, no a través de una proxy de lenguaje natural. Ese pensamiento no se puede delegar.

La regla del Boy Scout que los agentes nunca siguen

¿Viste alguna vez a un agente de IA dejar el código mejor de lo que lo encontró?
¿Siguiendo la regla del Boy Scout?

Los agentes están sesgados a hacer el cambio más seguro posible. Su función de pérdida optimiza por "no romper nada". Pero la deuda técnica se acumula precisamente porque nadie presta atención a los detalles — nadie está dispuesto a pasar un día entero observando pruebas de frenos para encontrar por qué un problema en campo no se detecta temprano.

Escribir código — de verdad, con las manos en el teclado — es el mecanismo más efectivo que tenemos para conectar los detalles minúsculos con la imagen grande. Borrar código muerto. Refactorizar una abstracción que ya no sirve. Documentar un principio arquitectónico consistente.

Los agentes de IA pueden escribir código más rápido que cualquier humano. Pero no pueden querer cuidar el código. Y ese cuidado — esa obsesión por los detalles — es lo que separa un sistema que evoluciona de uno que se pudre.

No se trata de productivity. Se trata de ownership.

Turnbull lo resume con una frase que debería estar en la pared de todo equipo de ingeniería: "Cuando leo y apruebo código, observo que no tengo el mismo sentido de ownership. El slop vuela bajo el radar. Es más difícil hacer microajustes."

Si toda tu contribución a un sistema es aprobar PRs generados por IA, eventualmente dejás de ser ingeniero y te convertís en un manager de robots. Y los robots no tienen criterio. No tienen gusto. No tienen la capacidad de decir: "esto no está bien aunque pase todos los tests".

Escribir código en 2026 no es un acto de nostalgia. Es una decisión estratégica. Porque los detalles importan. Porque las decisiones de arquitectura no se pueden proxy a través de inglés. Porque alguien tiene que querer el sistema lo suficiente como para ensuciarse las manos.

¿Vas a dejar que un pasante construya tu fábrica de software mientras mirás desde lejos?

Compartí esto con alguien que cree que programar ya no es necesario. El debate recién empieza.