Project, Agent, Person: El Eje que Falta en Herramientas de Programación con IA

Introducción

Hace unos meses escribí sobre los niveles que faltan entre coordinar a mano tus agentes de codificación y construir tu propio orquestador. Ese artículo terminaba con una nota incómoda: en algún momento las herramientas se acaban, y te dicen que construyas el orquestador tú mismo.

Este artículo trata del porqué. Por qué, con decenas de herramientas de programación con IA bien financiadas saliendo cada mes, la que coordinaría tu trabajo entre todos tus proyectos, máquinas y bandejas de entrada sigue siendo la que tienes que montar a mano.

La razón tiene poco que ver con que el mercado vaya rezagado. Casi toda herramienta se construye en torno a algo que no eres tú: el proyecto, o la sesión, y rara vez la persona.

Agentes de IA Autónomos Frente a Asistidos: El Eje que Todos Miden

Casi todos los marcos para herramientas de programación con IA miden lo mismo: ¿cómo de autónoma es?

Los ocho niveles de Steve Yegge van desde nada de IA hasta un orquestador propio. Los cinco de Dan Shapiro van del spicy autocomplete a la Dark Factory. Sourcegraph y Swarmia tienen los suyos. Addy Osmani hace poco dividió la escala en dos ejes, pero, como veremos, ambos siguen tratando de autonomía.

No voy a volver a explicar la escala aquí. Mi artículo anterior intentó rellenar los peldaños que le faltan, y la escala en sí es real, útil y está bien cartografiada. Responde bien a una pregunta: ¿cuánto puedo confiar en que la herramienta trabaje por su cuenta?

Esa no es la única pregunta que merece la pena hacerse.

El Eje que Nadie Nombra: El Centro de Gravedad de una Herramienta

Aquí va una segunda pregunta que las escalas nunca hacen: ¿en torno a qué se construye la herramienta?

No cuánto de autónoma es, sino qué hay en el centro: eso a lo que, calladamente, sirve cada una de sus funciones. Lo pienso como el centro de gravedad de una herramienta, y una y otra vez aparecen tres respuestas. Ordenadas así, las herramientas de programación con IA se dividen en tres tipos: project-centric (centrado en el proyecto), agent-centric (centrado en el agente) y person-centric (centrado en la persona).

• Project-centric: la unidad es el repositorio y el issue. Le entregas una tarea y un agente trabaja de forma autónoma hacia un pull request.
• Agent-centric: la unidad es la sesión. Vives dentro de la cabina de una herramienta y manejas tus agentes desde ahí.
• Person-centric: la unidad eres tú. La herramienta coordina tu trabajo entre los repositorios, gestores de tareas y máquinas que llevan tu nombre.

Antes, dos aclaraciones.

Este "agent-centric" es distinto del que quizá hayas visto en otros sitios. No es el Agent-Centric Development Cycle de Sonar, un ciclo de gobernanza de la calidad del código, ni tampoco el diseño centrado en el usuario del mundo UX. Aquí significa una sola cosa: la herramienta se construye en torno a la sesión del agente como el lugar donde vives, y la cabina es el producto.

Y son centros de gravedad, no cajas. Las herramientas reales se solapan. El Copilot coding agent de GitHub es un caballo de batalla project-centric que además trae un panel personal; Cursor es una cabina agent-centric que además ejecuta tareas en segundo plano. Estoy nombrando hacia dónde se inclina cada herramienta, no metiéndolas en compartimentos estancos. Las clasificaciones que siguen son mi propia lente analítica, no cómo se describen estos fabricantes a sí mismos.

Un matiz sobre esa palabra, "falta": falta en cómo solemos hablar de estas herramientas, no en el mercado. La autonomía se lleva todos los marcos; el centro de gravedad, casi ninguno. Y no son la misma medida con otro nombre. Un bot de actualización de dependencias que solo abre un tipo de pull request pequeño y pre-aprobado es profundamente project-centric y apenas autónomo. La autonomía y el centro de gravedad suelen ir juntos, pero nada les obliga. Deja la autonomía a un lado y ordena las herramientas por su centro de gravedad, y el espacio adquiere una forma propia: tres mundos, uno junto a otro, con un rincón todavía claramente vacío.

Project-centric: La Unidad es el Repositorio

El rincón más concurrido y mejor financiado es el project-centric.

El patrón te resultará familiar: describes un cambio como un issue, un agente lo recoge en la nube, y aparece un pull request para que lo revises. Devin es el buque insignia. Cognition promociona flotas de ellos migrando repositorios en paralelo, y en 2025 compró el IDE Windsurf, un fabricante project-centric absorbiendo a uno agent-centric. Jules de Google, el agente en la nube Codex de OpenAI y el Copilot coding agent de GitHub juegan todos la misma baza, con los Droids de Factory y el OpenHands de código abierto completando el cuadro.

Este es el camino, construido por los fabricantes, hacia lo alto de la escala de autonomía, y es realmente bueno. Para trabajo acotado, bien especificado, de gran volumen y propiedad del equipo, hecho de actualizaciones de dependencias, parches de CVE y migraciones mecánicas, es la respuesta correcta; un humano en el bucle es fricción, no seguridad.

El impulso es tan real que lo veo dentro de mi propia empresa. fullsend es una exploración pública, en forma de documento de diseño, de ingeniería totalmente autónoma: triar, implementar, revisar y hacer merge, con un humano involucrado solo en los cambios arriesgados. Es un esfuerzo de ingenieros que conozco en Red Hat, donde yo también trabajo, una exploración independiente de código abierto, no un producto ni una hoja de ruta de Red Hat. Lo menciono porque esta dirección no es una apuesta marginal; es hacia donde apunta gente seria.

Hay quien sostiene que este es el único rincón que importará. Thibault Sottiaux, de OpenAI, dice que el andamiaje es "salir del paso, no escalar", y buena parte del dinero está detrás de esa apuesta. Es una apuesta, eso sí, no un resultado zanjado: en distintos equipos, el cuello de botella se ha desplazado a la verificación, y el contexto, la coordinación y la supervisión siguen condicionando lo que la autonomía pura entrega.

Agent-centric: La Unidad es la Sesión

Empecemos por lo que este rincón hace bien.

Una única cabina con criterio propio es el mejor entorno que tenemos para el trabajo concentrado. Claude Code en una terminal, Cursor en un editor, el Amp de Sourcegraph: metido de lleno en un cambio difícil, vivir dentro de una sola herramienta bien diseñada gana a saltar entre cinco. Los orquestadores locales construidos sobre esto, como Conductor, Claude Squad y Vibe Kanban, heredan la misma virtud. Cada agente recibe su propio git worktree, y los diriges a todos desde un solo lugar: la única máquina en la que corren. La señal delatora de la categoría es que la coordinación ocurre alrededor del agente.

Cursor es multimodelo (Claude, GPT, Gemini), así que el lock-in nunca fue realmente por el modelo. Fue por la cabina. La misma gravedad que hace grande a una cabina también la arrastra hacia un borde cerrado: cuanto más optimiza una herramienta la sesión en la que vives, más quiere ser la única sesión en la que vives. Visto de una manera, puedes ver cómo se endurece ese borde. Cuando el cliente de terceros opencode intentó usar credenciales de la suscripción de Claude, recibió This credential is only authorized for use with Claude Code and cannot be used for other API requests. Anthropic había restringido esas credenciales a su propia herramienta, empujando a los demás clientes hacia una clave de API con contador. Que Cognition comprara Windsurf es la misma física a mayor escala.

Nada de esto es maldad. Es lo que ocurre cuando la sesión es el centro de gravedad: la herramienta es el producto, y el producto te quiere dentro.

Person-centric: La Unidad Eres Tú

Esto nos lleva al rincón vacío. Seré claro: yo desarrollo una herramienta que vive en este rincón, así que si el argumento solo funciona porque favorece a mi propio proyecto, entonces no funciona. He intentado escribir la versión que sobrevive a borrarla.

Una herramienta de programación con IA person-centric te toma a ti como unidad de coordinación. No este repositorio, no aquella sesión, sino tú, y todo el abanico de trabajo que lleva tu nombre: repositorios repartidos en varias organizaciones, issues en dos gestores de tareas, una revisión esperando en Slack, agentes en un portátil y en una estación de trabajo. El centro es la persona, no el proyecto ni la plataforma. Actuar en tu nombre es un rasgo que se deriva de eso, no el eje en sí.

Dos propiedades la hacen categóricamente distinta. Es transversal a las superficies: va más allá de cualquier repo, IDE o plataforma concretos, hasta tu jornada de trabajo real. Y está enraizada en tu entorno: coordina los agentes que tú ejecutas, Claude Code o cualquier otro, dondequiera que los ejecutes, no solo los que un fabricante aloja dentro de sus muros. Es el rincón al que el bando del humano-como-operador no deja de apuntar, desde la "ingeniería agéntica" de Willison hasta la advertencia de Swarmia de que más autonomía no siempre es mejor, normalmente sin una herramienta de nivel profesional que señalar.

Así que, para plantearlo de forma que puedas rebatirlo: las herramientas de programación person-centric no están sin atender, pero sí gravemente infra-atendidas. Los asistentes de consumo ya actúan en nombre de una persona a través de sus apps de mensajería, y las herramientas de "jefe de gabinete con IA" lo hacen para el trabajo del conocimiento, pero ninguna toca código, repositorios ni CI. Lo más parecido en nuestro mundo es el Agent HQ de GitHub, cuyo mission control ya reúne agentes de varios fabricantes en un mismo panel. Pero solo orquesta los agentes que GitHub aloja, en las superficies del propio GitHub. No llega a las sesiones que ejecutas en tu propio hardware, ni al trabajo que se desborda hacia tu bandeja de entrada y tus otros gestores de tareas. Otros sienten el mismo tirón. Cursor reúne sus propios agentes en una sola ventana, y unas cuantas herramientas pequeñas y multi-marca enrutan las aprobaciones de los agentes a tu móvil; lo primero es el jardín de un solo fabricante, y lo segundo es una porción fina del trabajo. A fecha de julio de 2026 sigo sin encontrar una herramienta de nivel profesional que sea neutral respecto al fabricante, abarque tus proyectos y superficies, te mantenga a ti como operador, y coordine el trabajo real en lugar de una sola costura de él. Algunas de las herramientas que se acercan poco a poco a ese rincón no son mías, y de verdad me gustaría equivocarme aquí. Si conoces una que ya cumpla, indícamela y la añadiré.

Ese rincón vacío es la forma hacia la que construyo con ai-beacon: los agentes de todas tus máquinas en una vista web que puedes abrir desde cualquier sitio, Claude Code y opencode por igual. Nació del dashboard de agentes de codificación del que escribí a principios de año, y está en una fase temprana y es experimental. La categoría importa más que mi intento de construirla.

La fontanería de este rincón está a medio construir. Hay un estándar para cada costura: Model Context Protocol (MCP) entre agentes y herramientas, Agent Client Protocol (ACP) entre editores y agentes, A2A entre agentes, AG-UI entre agentes e interfaces. Lo que ninguno aporta por sí solo es la capa transversal al contexto que uniría tu trabajo por encima de todos ellos. Esa capa falta precisamente porque ningún fabricante tiene incentivos para centrarla en ti.

El enfoque person-centric tiene una debilidad propia. Vive a merced de las mismas fronteras que cruza. Una capa de control que se apoya sobre cada fabricante no hereda ninguna de sus protecciones: ni CI, ni controles de revisión. Y cualquier fabricante puede asfixiarla con una restricción de credenciales, el borde cerrado de antes. Eso no es razón para que la categoría no exista. Es la razón por la que es difícil.

Qué hay de Nuevo Aquí y Qué No

Déjame ser cuidadoso con lo que afirmo y lo que no, porque el trabajo previo merece reconocimiento. La distinción entre lo project-centric y lo agent-centric no es nueva; reetiqueta cosas que la gente ya dice. OpenHands ha escrito sobre el bucle interno frente al bucle externo, acelerar al individuo frente a gestionar tareas enteras por Slack y Jira, lo que encaja casi exactamente con agent-centric frente a project-centric, aunque OpenHands cabalga entre ambos. El modelo de dos ejes de Osmani divide la autonomía en agencia y orquestación, pero su segundo eje es cuántos agentes ejecutas, que sigue siendo una cuestión de autonomía.

Lo que sí es nuevo es pequeño pero estructural. Es elegir el centro de gravedad, en torno a qué se construye la herramienta, como eje, en lugar del grado de autonomía, y luego nombrar la categoría person-centric, a nivel profesional de desarrollo, como la que falta. Ni el eje de orquestación de Osmani ni el bucle externo de OpenHands dejan un asiento para la persona. Ese asiento es justo de lo que va todo esto.

Cómo Elegir Entre Herramientas Project-, Agent- y Person-centric

Nada de esto es una lucha a muerte. El futuro que espero es una composición, con una frontera clara entre las partes: una torre de control sobre una fábrica. La fábrica es project-centric: muchos agentes autónomos convirtiendo issues bien especificados en pull requests mientras duermes. La torre de control es person-centric: el panel único de una sola persona sobre todo ello, entre proyectos, superficies y máquinas. No son rivales; son altitudes distintas de la misma operación.

Eso deja una regla de decisión que puedo usar en el día a día.

• Cuando el trabajo es profundidad en un solo cambio, recurre a la cabina (agent-centric).
• Cuando es una unidad especificada que puedes delegar y dejar atrás, recurre a la fábrica (project-centric).
• Cuando abarca proyectos, superficies o máquinas y necesita tu criterio repartido entre todos ellos, recurre a la torre de control (person-centric).

La parte incómoda es que la tercera herramienta es la que el mercado tiene menos probabilidades de entregarte. Mi artículo anterior decía que probablemente tendrías que construir tu propio orquestador. Ahora creo que la razón de fondo es estructural. El centro de gravedad de cada fabricante es el proyecto o la plataforma, porque ahí está el negocio. En casi ninguno estás tú. Las herramientas de programación con IA se diferencian menos por cuánto de autónomas son que por aquello en torno a lo que se construyen, y el humano es el único centro para el que nadie ha llegado a construir del todo.

Si estás en algún punto de este mapa, me gustaría saber en qué rincón. Estoy recogiendo notas en las discusiones de ai-beacon, el mismo sitio que la última vez. Gracias, también, a mi colega Václav Vančura, cuyo trabajo en UX ayudó a afinar cómo veo todo esto. Cuantos más rincones comparemos, más nítido se vuelve el mapa.