Llevo toda la semana trasteando con Claude Code. Empecé a escribir una aplicación, pero con los días he invertido más tiempo en diseñar sistemas de trabajo.

Precisamente en el trabajo, estoy creando uno que me permita hacer pairing con Claude en alguna de las iniciativas que tenemos en marcha. Básicamente, le digo lo que quiero, reviso la respuesta, le indico las correcciones que observo e iteramos hasta que tenemos algo lo suficientemente bueno. Cuando eso sucede, le digo que lo suba directamente a Jira. Y oye, lo hace.

En casa, mientras tanto, he estado creando un sistema que me ayude a escribir estas entradas. Mi propósito es aprender a trabajar con agentes en paralelo. Podría hacer esto con mi aplicación, pero la realidad es que me queda grande poder entender el código que generan. Al hacerlo con un artículo, espero comprender mejor los mecanismos detrás de la máquina.

Voy a ver dónde me lleva este camino, pero mentiría si dijese que no creo que mi forma de trabajar va a cambiar significativamente. Anticipo un escenario probable: en mi trabajo, Claude Code (o cualquier marco agéntico futuro) será el autor del 99% de mis documentos.

En cierto modo, los Product Managers ya estamos acostumbrados a hacer a través de otros. Pasamos PRDs a diseñadores e ingenieros e iteramos con ellos para encontrar la mejor solución posible. Pasar a incorporar a Claude Code, y tantos agentes especializados como necesitemos, es una extensión natural de lo que veníamos haciendo. El trabajo ya no es tanto hacer, como gestionar que un agente lo haga por ti.

El fin del contribuidor individual

Esta semana me topé (vía Kent Beck) con un artículo de Philip Su que captura perfectamente este cambio:

“Los días dorados del contribuidor individual han terminado. No porque la IA programe mejor que tú, sino porque maximizar tu productividad requiere que enfoques tu tiempo en todas esas cosas que, al final del día, son tareas de mánager.”

Un contribuidor individual (IC) es alguien que hace cosas directamente: escribe código, diseña interfaces, redacta documentos. No gestiona equipos ni coordina personas. Ejecuta.

Su sostiene que ese rol tenderá a desaparecer. No porque las IAs hagan mejor el trabajo, sino porque la forma más eficiente de trabajar será gestionar agentes que lo hagan por ti.

Y eso se parece mucho a lo que he vivido estos días. Pienso que mis días de escribir largos documentos de especificaciones serán sustituidos por largas sesiones de colaboración con sistemas agénticos, revisando y corrigiendo respuestas hasta llegar al resultado deseado.

¿Qué hace en realidad un mánager?

Si el rol del contribuidor individual desaparece, ¿seremos todos mánagers? Si nos atenemos a la definición del trabajo de un mánager de Su, sin duda:

“El trabajo de los mánagers es metatrabajo: no es construir la cosa, es pensar y ajustar la máquina que construye la cosa.”

Eso es exactamente lo que he estado haciendo estos días: metatrabajo. En vez de escribir documentos, estoy creando los sistemas que me facilitarán crearlos. Y aunque Su escribe desde la perspectiva de un ingeniero de software, lo que describe aplica a cualquiera que trabaje con información.

¿Qué pasa si no quieres ser mánager?

Hay una razón por la que existe la distinción entre contribuidores individuales y mánagers: no todo el mundo quiere ser mánager.

Conozco ingenieros brillantes que aman programar y diseñadores excepcionales que aman diseñar. Ninguno quiere alejarse de lo que le apasiona. Sin embargo, para Su, esa opción ya no existirá. Las presiones del mercado los forzarán a convertirse en mánagers de IAs que harán el trabajo a bajo nivel por ellos.

La experiencia de ser un mánager es cualitativamente muy diferente de la de ser un contribuidor individual. El trabajo directo no es necesariamente mejor ni peor que el metatrabajo. Pero es importante reconocer que hemos superado un horizonte de sucesos en el que ya no existe la opción de escoger entre ambos.

Conclusión

Tal vez Su y yo nos equivoquemos. Quizás siempre quede espacio para que artesanos del software o del diseño puedan trabajar sin intermediarios. Pero reconozco que cada día que paso trabajando más codo a codo con Claude Code, más me cuesta imaginármelo.

El problema no es que la IA pueda hacer mejor el trabajo, sino que gestionarla para que lo haga será más eficiente. Y en el mercado, la eficiencia tiende a imponerse a la artesanía.

Si esto es cierto, las implicaciones son inmediatas. Deberíamos dejar de optimizar para ser mejores ejecutores y empezar a optimizar para ser mejores orquestadores. Deberíamos aprender a escribir mejores prompts, a diseñar mejores sistemas de agentes, a iterar más rápido en ciclos de interacción con la IA.

Por mi parte, voy a seguir con el experimento. Seguiré construyendo estos sistemas, seguiré iterando con Claude Code, y seguiré documentando lo que aprenda en el camino. Puede que dentro de seis meses descubra que esto tiene un techo, o puede que mi forma de trabajar sea irreconocible comparada con la de hoy.

Lo que termine siendo, aquí lo contaré.