El futuro de la programación es no programar en absoluto

En 2017, el CEO de GitHub dijo que la programación iba a desaparecer. Tenía razón en algo. Se equivocó en lo que importa.

---

"El futuro de la programación es no programar en absoluto." — Chris Wanstrath, ex-CEO de GitHub, 2017

Business Insider lo publicó en portada. El CEO de GitHub diciendo que la automatización acabaría con la programación tradicional.

En 2017 no existía ChatGPT. No existía Copilot. No existía nada de lo que hoy usamos a diario.

Y aun así, ya lo estaba diciendo.

¿Tenía razón?

Sí y no.

En lo que tenía razón

La forma de programar cambió. Eso es un hecho.

Hoy cualquier persona puede abrir una interfaz, escribir un prompt, y obtener un componente funcional en segundos. Código que hace cinco años habría requerido horas de trabajo aparece en la pantalla antes de que termines el café.

Sobre esto no hay debate. La barrera para generar código se desplomó.

En lo que se equivocó

Programar nunca fue solo escribir código.

Programar es pensar en sistemas. Es decidir qué construir y cómo. Es diseñar soluciones que funcionen hoy y que se puedan modificar mañana sin que todo explote. Es entender por qué una arquitectura aguanta la carga y otra no. Es saber cuándo una abstracción ayuda y cuándo está creando un problema que alguien va a sufrir en seis meses.

Eso no lo hace un prompt.

Un modelo de lenguaje genera código. No razona sobre el sistema. No conoce las restricciones reales del negocio. No tiene que mantener lo que produce ni responder cuando algo falla en producción a las dos de la mañana.

El criterio de ingeniería no se automatiza. Se aplica sobre la automatización.

La ventaja que nadie está viendo del todo

El programador que sabe diseñar software y además sabe usar herramientas de IA como un profesional tiene una ventaja que hoy todavía no está completamente valorada. Pero lo va a estar.

Y acá importa ser preciso, porque hay mucha confusión sobre qué significa "usar IA como profesional".

No hablo de pedirle a ChatGPT que te escriba un componente. Eso ya lo hace cualquiera. Eso es el piso, no el techo.

Hablo de otra cosa. De montar agentes que siguen tus reglas de arquitectura. De encadenar subagentes que manejan partes específicas de un flujo. De definir skills reutilizables y conectar herramientas externas vía MCP. De hacer que la IA trabaje para vos de forma estructurada, con criterio, con guardarraíles de ingeniería reales.

La diferencia entre generar código con un prompt y montar un sistema de IA que hace ingeniería de software es la misma diferencia que hay entre ejecutar un script y diseñar una arquitectura.

Dos caminos

Podés seguir haciendo vibe coding. Generar código, pegarlo, rezar para que funcione, repetir. Muchos lo hacen. El resultado es velocidad aparente y deuda técnica real.

O podés aprender a montar sistemas de IA que apliquen ingeniería de software de verdad. Que sigan principios de diseño. Que generen tests. Que respeten las convenciones del proyecto. Que escalen.

Wanstrath tenía razón en que escribir código manualmente iba a dejar de ser el centro del trabajo. Se equivocó en pensar que eso hacía irrelevante al programador. Lo que hace irrelevante al programador es no entender que su rol cambió.

El rol ahora es dirigir sistemas que producen software. Y para dirigirlos bien, necesitás saber exactamente qué es buen software.

El que no sabe eso, con o sin IA, sigue construyendo lo mismo de siempre.

Solo más rápido.