Marc Andreessen soltó una frase esta semana que no debería pasar desapercibida: “No estoy seguro de que siquiera existirá un concepto relevante de lenguaje de programación en la forma en que lo entendemos hoy.”

Según Andreessen, los lenguajes de programación no van a declinar ni a evolucionar — van a dejar de existir como concepto. Los comparó con el arado: durante generaciones el 99% de la humanidad estaba detrás de uno, el mundo se pasó décadas preguntando qué haría la gente cuando la agricultura desapareciera, y la respuesta fue todo lo que vale la pena hacer. Para Andreessen, estamos ahí otra vez, solo que el arado esta vez es un teclado.

La visión tiene suficiente verdad para ser peligrosa si la tomas al pie de la letra. Antes de que reorganices tu equipo de ingeniería alrededor de esa idea, vale la pena escuchar qué le pasa a alguien que ya vive en ese futuro.

Simon Willison está agotado a las 11am

Simon Willison co-creó Django — el framework web que corre Instagram, Pinterest, Spotify y miles de plataformas más. Lleva 25 años construyendo software. Acuñó el término “prompt injection”. Tiene más de 100 proyectos open source. Si hay alguien que ha hecho la transición completa del modo antiguo al modo nuevo de construir software, es él.

En una entrevista con Lenny Rachitsky la semana pasada, Willison dijo esto: “Using coding agents well is taking every inch of my 25 years of experience as a software engineer, and it is mentally exhausting.” (Usar bien los agentes de codificación me exige cada centímetro de mis 25 años de experiencia como ingeniero de software, y es mentalmente agotador.)

El 95% del código que produce, no lo escribió él. Programa desde su teléfono caminando al perro por la playa. Suena a la utopía que nos prometieron. Excepto por el detalle que la utopía omite.

“I can fire up four agents in parallel and have them work on four different problems, and by 11am I am wiped out for the day.” (Puedo lanzar cuatro agentes en paralelo trabajando en cuatro problemas distintos, y a las 11am estoy agotado por el día.)

Estamos hablando de un ingeniero con 25 años de experiencia corriendo a máxima capacidad, agotado a las 11 de la mañana. Si le pasa a Willison, imagínate lo que le va a pasar a un equipo de ingeniería promedio cuando le pongas cuatro agentes a cada persona.

El efecto que nadie puso en la presentación

Se suponía que la IA nos daba más tiempo libre. Willison dice que los que más la usan están trabajando más duro que nunca. Conoce ingenieros que pierden sueño, que se despiertan a las 4 de la mañana para lanzar agentes antes de que empiece el día. Él mismo lo describe sin filtro: “There’s an element of sort of gambling and addiction to how we’re using some of these tools.” (Hay un elemento de juego de azar y adicción en cómo estamos usando algunas de estas herramientas.)

Lo más revelador es su resolución de Año Nuevo. Todos los años anteriores se proponía enfocarse más y tomar menos proyectos. Este año fue lo opuesto: “Take on more stuff and be more ambitious.” (Tomar más cosas y ser más ambicioso.) Le preguntaron cómo le va y dijo que se divierte, pero que el agotamiento cerebral ha sido “a really big surprise” (una sorpresa enorme). Puedes estar disfrutando un trabajo y al mismo tiempo estar destruyéndote con él. Cualquier CTO que haya pasado por un sprint de tres meses sabe de qué estoy hablando.

Esa tensión entre productividad y desgaste es lo que tu empresa va a enfrentar cuando despliegue agentes a escala. El equipo no va a escribir menos código — va a tener que dirigir más código. Dirigir tiene su propia carga cognitiva, y por lo que cuenta Willison, es más agotadora que la de escribir código a mano.

Dónde se movió el cuello de botella

Willison lo articula mejor que nadie: “We’ve taken the writing code bit and we’ve massively accelerated that. Now the bottlenecks are everywhere else.” (Aceleramos masivamente la parte de escribir código. Ahora los cuellos de botella están en todos los demás lados.)

Un spec que antes le dabas a tu equipo de ingeniería y tres semanas después, con suerte, tenías una implementación — ahora toma tres horas. Willison ya no necesita bloques de cuatro horas sin interrupciones para codificar. Necesita dos minutos cada cierto tiempo para darle instrucciones al agente. Es mucho más interrumpible que antes.

Pero el trabajo no desapareció — cambió de forma. Willison ahora prototipa tres versiones de cada feature porque el costo es casi cero. Después tiene que decidir cuál de las tres vale la pena. Tiene que mantener la arquitectura de contexto en su cabeza mientras cuatro agentes trabajan en paralelo. Y tiene que detectar cuándo un agente tomó un atajo que pasa las pruebas pero no resuelve el problema real.

“There is a limit on human cognition. Even if you’re not reviewing everything they’re doing, just how much you can hold in your head at one time.” (Hay un límite en la cognición humana. Aunque no estés revisando todo lo que hacen, solo cuánto puedes mantener en tu cabeza al mismo tiempo.)

Llevo más de 35 años en tecnología y algo que he visto repetirse en cada ola tecnológica es esto: la parte más visible del trabajo — en este caso escribir código — nunca fue la más difícil. Lo difícil siempre fue decidir qué construir y después verificar que sirve. Con la IA, esa segunda parte se volvió más importante, más frecuente, y más demandante. El código se abarató pero las decisiones sobre qué hacer con él se multiplicaron.

Los que están en el medio van a pagar el costo más alto

Hay un dato de ThoughtWorks que me parece más revelador que cualquier predicción de Andreessen.

ThoughtWorks — la consultora global de TI — reunió a un grupo de VPs de ingeniería de diferentes empresas para analizar esto, y lo publicó en su reporte Looking Glass 2026. La conclusión que sacaron es reveladora: la IA es excelente para ingenieros seniors y excelente para juniors. El problema son los que están en el medio.

Los seniors tienen 25 años de experiencia que amplificar. Pueden hablarle a un agente con lenguaje sofisticado de ingeniería y colaborar a un nivel alto. Pueden mirar un problema y saber que es un prompt de una oración. O saber que es un problema de tres semanas que el agente no va a resolver.

Los juniors se benefician del onboarding acelerado. Cloudflare y Shopify contrataron mil practicantes cada uno en 2025 porque el ramp-up que antes tomaba un mes ahora toma una semana con asistentes de IA.

¿Los de nivel medio? No tienen la experiencia para dirigir con criterio, y los beneficios de aceleración del onboarding ya los obtuvieron hace tiempo. Están en la zona donde la IA no amplifica lo suficiente y no acelera lo suficiente. Es la bifurcación que muchos equipos van a enfrentar este año.

El argumento estructural de Levie

Aaron Levie, CEO de Box, leyó la cita de Willison y agregó la perspectiva organizacional que faltaba.

Las empresas no tienen gerentes porque aman la ineficiencia. Los tienen porque eventualmente llegas al límite de cuánto contexto puede manejar una persona para producir trabajo útil. Entonces delegas. Y la persona que recibe la delegación maneja su sub-contexto.

Los agentes todavía no rompen esos límites cognitivos. Son tan efectivos como el contexto que les das, las herramientas a las que tienen acceso, y la capacidad del humano para mantenerlos en el camino correcto.

“This is also generally why the jobs arguments from those who think people go away will be wrong,” escribió Levie. (Por esto mismo, los argumentos de quienes creen que la gente va a desaparecer van a estar equivocados.) Dirigir agentes sigue siendo gestión — con otra forma, con otras herramientas, pero gestión al fin. Lo que cambió es qué tipo de esfuerzo mental requiere. Ya no estás haciendo el trabajo; estás decidiendo qué pedirle al agente, evaluando si lo que te devuelve sirve, y sosteniendo esa evaluación en paralelo para múltiples líneas de trabajo. Si alguna vez dirigiste un equipo de cuatro personas trabajando en cuatro cosas distintas al mismo tiempo, sabes lo agotador que es. Multiplicar eso por la velocidad de la IA no lo hace más fácil.

Lo que las empresas todavía no construyeron

Lo que me llama la atención es cómo estas tres perspectivas — Andreessen desde la visión, Willison desde la trinchera, Levie desde la organización — terminan apuntando al mismo lugar. Las empresas se apuraron a comprar la capacidad de ejecución sin preguntarse si tienen capacidad de dirección.

Hablo con CTOs que están poniendo agentes en producción y me encuentro con el mismo patrón: hay presupuesto para las licencias, hay entusiasmo por la velocidad, pero nadie se sentó a definir quién va a dirigir esos agentes, cuánta carga cognitiva implica esa dirección, ni qué pasa cuando esa persona se enferma o renuncia.

La brecha es organizacional. El rol de maestro de agentes debería ser algo con descripción de puesto, responsabilidades definidas y cobertura de respaldo — igual que cualquier otro rol crítico. Debería existir un marco para distribuir la supervisión entre varias personas, porque concentrarla en un solo ingeniero senior es una receta para burnout en tres meses. Y debería haber evaluaciones que midan la calidad del output, porque producir código con un agente es fácil; saber si ese código resuelve el problema correcto requiere criterio que la IA todavía no tiene.

Willison lo dice claro: “Using these tools effectively is not easy. That’s one of the great misconceptions in AI. It takes a lot of practice and it takes a lot of trying things that didn’t work.” (Usar estas herramientas de forma efectiva no es fácil. Ese es uno de los grandes malentendidos sobre la IA. Requiere mucha práctica y muchos intentos que no funcionan.)

La velocidad de construcción dejó de ser la ventaja competitiva. Lo que separa a las empresas que van a capturar valor de las que van a acumular deuda técnica es la capacidad de dirigir.

Lo concreto

Si eres CTO o director de tecnología, hay algo que puedes verificar esta semana sin necesidad de contratar a nadie: sienta a tu equipo y pregúntales quién entiende lo que hacen los agentes a nivel arquitectónico. La pregunta importa porque es distinta de “quién los usa más.” El que más usa un agente puede ser el que más output genera, pero la persona que te importa identificar es la que puede mirar ese output y decirte si resuelve el problema correcto. Esas personas son tu capacidad real de dirección. Y si están concentradas en una o dos personas, tienes un punto único de fallo que nadie está midiendo.

La otra cosa que vale la pena revisar: cuánto desgaste acumula tu equipo por semana de trabajo con agentes. Me refiero al desgaste cognitivo, no a las métricas de producción. Si el viernes tu gente llega con la mirada perdida después de cinco días dirigiendo agentes en paralelo, el cálculo de productividad que hiciste cuando compraste las licencias ya no cuadra.

Hay una métrica que me parece más útil que las líneas de código generadas: cuánto criterio humano necesita cada línea después de que el agente la produce. Cuando ese número baja, estás ganando. Cuando ese número es alto y lo compensas con más horas de tus ingenieros seniors, estás acumulando una deuda que se va a cobrar en rotación.

Si tu empresa usa agentes y no mapeaste quién los dirige, cuánta carga cognitiva implica, y qué pasa cuando esa persona no está — hay un riesgo que no estás viendo. Hacemos diagnósticos de capacidad de dirección de agentes — el foco está en si tu equipo puede sostener el ritmo de supervisión a mediano plazo, más allá de cuántos agentes tengas corriendo. Mándanos una descripción de tu setup actual a contacto y te mostramos dónde están los puntos ciegos.