La pregunta que más me repiten últimamente es qué va a pasar con el trabajo de los programadores. Yo creo que antes hay que responder otra que nadie se hace: ¿cuánta pizza comen los agentes?

Aunque no lo creáis, es la cuestión más importante si queremos entender el futuro del desarrollo de software y cómo nos va a afectar tanto a los profesionales como a las empresas.

Me explico. Jeff Bezos popularizó el término two-pizza team. Básicamente, afirma que el tamaño óptimo de un equipo es aquel que le permita alimentarse con un máximo de dos pizzas (grandes, que programar cansa).

Otra forma de verlo es la relación directa entre el tamaño del equipo y lo compleja que se hace la comunicación y coordinación: cada persona nueva en el equipo hace crecer los canales mucho más rápido: con cinco personas hay 10 conversaciones posibles, con ocho se llega a 28 y con doce alcanzamos las 66.

A esa energía que gastamos en coordinarnos y en hacer nuestro trabajo la llamaremos carga cognitiva. Nuestra capacidad es limitada y, por eso, los equipos tienen un tamaño óptimo.

Algo parecido al número de Dunbar, el máximo de relaciones personales estables que puedes mantener, pero en el ámbito profesional.

¿Pero cómo se calcula esa carga cognitiva en una realidad en la que no solo interactúas con personas sino también con agentes IA?
 

El día a día de un ingeniero agéntico

Si ya has comenzado a usar agentes para crear software, puede que hayas vivido algo similar a esto:

8:00 Comienza el día, contestas correos y slacks.

8:10 Tienes 5 PRs mirándote en GitHub que tus agentes han hecho por la noche. Dos de ellas están listas para mergear. De la tercera tienes dudas… decides lanzar un entorno de desarrollo, que un agente haga QA y luego revisarlo a mano. El último agente se ha inventado la mitad de las cosas así que decides empezar de cero de nuevo.

8:40 Estás prompteando a Claude para arreglar la PR maldita y María te escribe: tiene dudas sobre el pair programming de ayer. Lanzas el prompt sin que la especificación esté perfecta, pero confías en que sea suficiente para sacarlo adelante.

8:45 Llamada con María. A mitad te llega la notificación del agente que hacía QA: ha encontrado tres errores.

9:00 Miras los errores detectados por el QA. Es cierto, está mal. Se los mandas a otro agente para que arregle la PR. Antes de acabar el prompt te llega la notificación del Claude con la PR maldita.

9:05 Revisas la PR maldita. Bastante bien… Unos últimos retoques y queda lista.

9:10 Te llega un aviso del agente que monitoriza otro proyecto: un error en producción con su fix para que lo revises. Llamas a Carlos, que es quien controla esto, para que te ayude.

Los últimos commits son tuyos, pero los hiciste tan rápido con Claude que no tienes muy claro qué hay en ellos. Carlos no te lo dice, pero le has interrumpido mientras hacía las especificaciones con ChatGPT de una nueva funcionalidad. Aun así, responde a tu mensaje y entráis en una llamada…

Suenan teclados de fondo… unos 20 Claudes y 12 ChatGPTs están tirando líneas mientras habláis… Tu vaso de agua comienza a temblar y no sabes por qué.

La programación con agentes es muy exigente mentalmente. Simon Willison lo resumió muy bien: «the productivity boost these things can provide is exhausting».

El trabajo se ha vuelto más intenso y los cambios de contexto mucho más frecuentes. Eso provoca un agotamiento tan común que ya tiene nombre: burnout de coordinación u orquestación.

No puedes hacer un x10 y que todo siga igual. Geoffrey B. West cuenta muy bien que, cuando un sistema crece no basta con hacerlo más grande, tiene que cambiar su estructura para no colapsar.

Ya nos pasó con CI/CD y DevOps: desplegar diez veces al día no era desplegar más rápido, era otra forma de trabajar. Ahora toca otra vez.

En ingeniería siempre soñamos con dejar de «tirar líneas» y diseñar a alto nivel: cajitas y flechas. Queríamos hacer arquitecturas que hicieran llorar de alegría al mismísimo Uncle Bob de «Clean Code» (que ahora mismo usa la IA sin parar). Sistemas cloud tan perfectos que Jeff Bezos te los subvencionaría. Arquitecturas tan hexagonales que acaban siendo octogonales. Aplicaciones con más tests que usuarios.

Tienes 100 % de cobertura, pero tu cerebro está frito, al 0 %.
Ya lo dice el refrán: ten cuidado con lo que deseas.
 

Entonces ¿cuánta pizza come un agente?

La heurística de las dos pizzas habla de nuestra capacidad cognitiva: tenemos un máximo de dos pizzas mentales a repartir.

Si un compañero se come una porción de mis pizzas, ¿cuántas se come un agente? No está claro aún, pero se calcula entre 1:2 y 1:3. Es decir, un agente consume tanta pizza como dos o tres compañeros.

Miguel Carranza cuenta que en RevenueCat han dividido en dos los equipos. Si necesitáis que alguien con corbata os lo diga para que vuestro jefe os crea, McKinsey también lo menciona: de 8-12 personas a 3-4 por equipo.

¿Por qué unos tanto y otros tan poco?

Si partes tus equipos por la mitad, de repente tienes el doble de equipos con la misma plantilla. Las matemáticas no perdonan: saldrán mejor paradas las empresas elásticas, las que tarden poco en convertir esa nueva capacidad de trabajo en valor.

El reto ya no es ni técnico ni de arquitectura, sino comercial (a quién puedes vender este nuevo paradigma) y gestión (qué paralelizas del backlog).

Esa elasticidad explica muchas dicotomías que observamos:

Puede ser la época dorada de pequeñas agencias y consultoras: duplicas el ancho de banda y no es complicado encontrar en el mercado más clientes en esa escala. Si antes sacabas 3 proyectos al trimestre, ahora 6.

Pero cuando gestionas una estructura tan grande que tiene su propia inercia, ese cambio de dirección tarda mucho más en producirse. Y, cuando finalmente lo haces, está por ver que tu fuerza de ventas sea capaz de facturar todo ese nuevo ancho de banda. No lo digo yo, lo dice el mercado.

Esa dicotomía, también se traslada a las compañías de producto.

Si desarrollas una aplicación relativamente nueva y que aún se está expandiendo, es fácil encontrar nuevas características que desarrollar en paralelo.

En cambio, un producto maduro con clientes enterprise no puede ensanchar tan rápido. No existe el backlog infinito y añadir demasiadas cosas puede generar feature creep y el rechazo de los usuarios, incapaces de absorber tanta «innovación».

Esto explica —en parte— por qué en Twitter tienes fans de la IA que hacen x10 y escépticos que solo ven mejoras ligeras. No todo el mundo disfruta de la misma elasticidad y esto depende de tu mercado y producto, no de tu habilidad con la IA. Así que, no te sientas mal si no eres de los elegidos.

Los buenos pizzeros lo saben: la mejor masa es elástica y no se rompe. De la misma manera, en la era de la IA, los empresarios y ejecutivos tienen que hacer sus compañías más elásticas, no romperlas.

No necesitamos empresas más pequeñas, sino equipos más pequeños. Tanto como para que puedan seguir alimentándose con solo dos pizzas, teniendo en cuenta que los agentes son auténticos tragaldabas.

¿Quieres ayudarme a difundir este texto?