Cuando escribir código deja de ser el cuello de botella

Hay un patrón que aparece seguido en equipos que incorporan agentes de código al trabajo diario. La cantidad de código propuesto sube rápido, en semanas. La cantidad de código que efectivamente llega a producción sube mucho menos. Los pull requests se acumulan, las revisiones se atrasan, y la sensación general del equipo es que ahora hay más trabajo pendiente que antes.

No es un problema de la herramienta. Es que el cuello de botella se movió y la estructura del equipo siguió igual.

Durante veinte años organizamos equipos de desarrollo bajo un supuesto que casi nunca se discutía: lo escaso era la capacidad de escribir código. Todo lo demás se ordenaba alrededor de eso. El sprint existe para proteger a quien escribe de las interrupciones. La estimación existe porque escribir lleva un tiempo difícil de predecir. El tamaño del equipo se define por cuánto hay que construir. Incluso la forma de facturar, por hora o por persona asignada, asume que el tiempo humano dedicado a escribir es la unidad de valor.

Ese supuesto se está moviendo. No desapareció, pero dejó de ser el único. Y cuando el recurso escaso cambia, la estructura que se armó alrededor del recurso anterior empieza a producir resultados raros.

De ahí salen los pods. El nombre es genérico y cada empresa lo usa para algo distinto, así que conviene definirlo antes de discutirlo: un pod es una unidad de entrega chica, de dos a cuatro personas, dimensionada por su capacidad de revisar y decidir, no por su capacidad de producir. Los agentes hacen buena parte de la producción. Las personas definen qué se construye, revisan lo que se propone y responden por lo que se integra.

Es un cambio de unidad de medida, y como todo cambio de unidad de medida, tiene consecuencias que no son obvias.

Por qué el tamaño lo define la revisión

Si un equipo puede generar más código del que puede revisar con atención, el exceso no se pierde: se integra igual, con menos criterio. La deuda técnica no aparece porque se escriba mal. Aparece porque se aprueba rápido.

Esto tiene una implicancia incómoda para quien quiere escalar equipos. Agregar personas a un equipo que ya está saturado de revisión no aumenta la capacidad de entrega, porque cada persona nueva también genera código para revisar. El clásico de Brooks sobre el costo de coordinación sigue valiendo, y los agentes lo agravan: aumentan el volumen de artefactos que hay que coordinar sin reducir en nada el costo de coordinar entre humanos.

Un pod se dimensiona al revés. Se pregunta cuánto puede revisar con cuidado un grupo chico en una semana, y de ahí sale el alcance comprometido. No al revés. Es una restricción que incomoda al principio, porque parece que se está limitando la velocidad a propósito. Lo que se está limitando es la velocidad de acumular trabajo sin revisar.

La métrica que sirve para seguir a un pod no es el código producido, ni la cantidad de tickets cerrados. Es el trabajo integrado y el retrabajo posterior. Si el throughput sube y el retrabajo sube en la misma proporción, el pod no está entregando más. Está entregando lo mismo dos veces.

Qué cambia en el trabajo de las personas

Cuando la producción se abarata, el valor se concentra en tres momentos que antes ocupaban una fracción del día.

El primero es la especificación. Un agente ejecuta lo que se le define con una fidelidad razonable, incluso cuando la definición está mal. La ambigüedad en un requerimiento ya no se frena sola contra la resistencia de escribir el código; ahora se implementa completa y aparece recién en la revisión. Definir con precisión pasó de ser una buena práctica a ser el trabajo.

El segundo es la revisión. Revisar código que uno no escribió, todo el día, es una actividad distinta a programar. Requiere más contexto, más lectura y más disciplina para no aprobar por cansancio. Esto conviene decirlo en voz alta porque se discute poco: la revisión sostenida es agotadora de una manera diferente, y un equipo organizado alrededor de la revisión necesita rotación y pausas que un equipo tradicional no necesitaba. Ignorarlo no hace que el problema desaparezca, solo lo traslada a la calidad.

El tercero es la decisión de integrar. Cuando la autoría se vuelve difusa, la responsabilidad tiende a difuminarse con ella. Es la parte del modelo que más se subestima: alguien con nombre tiene que responder por cada cosa que entra. No porque escribió el código, sino porque decidió que estaba bien. Si esa persona no está definida, la responsabilidad queda repartida entre todos, que es otra forma de decir que no queda en nadie.

El modelo de facturación por hora se vuelve incoherente

Hay una consecuencia económica que vale explicitar, porque afecta a las dos partes de un contrato.

Si el tiempo humano dedicado a producir baja y el precio se cobra por hora, quien construye tiene un incentivo estructural en contra de su propia eficiencia. Cada mejora en el proceso reduce la facturación. Nadie lo dice así, pero el incentivo existe y actúa.

Facturar contra entregables o resultados acomoda ese desalineamiento, aunque introduce otro. Cerrar el precio contra un entregable significa que el riesgo de estimación se corre hacia quien construye, y para asumir ese riesgo hay que cerrar el alcance. Ese cierre le quita flexibilidad al cliente. Es un intercambio real, no una mejora neta: se gana previsibilidad de costo y se pierde capacidad de cambiar de opinión a mitad de camino.

Por eso el modelo no reemplaza a los demás. Conviven, y elegir entre ellos es la primera decisión del proyecto.

Para qué casos funciona

El modelo rinde cuando se cumplen, en general, estas condiciones:

El alcance está definido y es verificable. No alcanza con que esté escrito. Tiene que existir un criterio de aceptación contra el cual se pueda decir que algo está terminado. Si no hay forma de verificar, no hay forma de revisar a velocidad.

El código base tiene tests y CI. Los agentes amplifican la higiene existente, en las dos direcciones. Sobre un proyecto con buena cobertura de tests, la revisión se apoya en señales automáticas y el pod vuela. Sobre un proyecto sin tests, cada cambio hay que verificarlo a mano y el cuello de botella se cierra completo.

La fecha es real. Los pods sirven especialmente cuando hay una restricción temporal dura: un lanzamiento, una integración con un tercero, una obligación regulatoria con plazo. La estructura chica y la facturación contra entregables tienen sentido cuando el calendario es el problema principal.

El cliente puede decidir rápido. Un pod se bloquea antes que un equipo grande, porque tiene menos frentes de trabajo simultáneos donde refugiarse mientras espera una respuesta. Si las definiciones tardan dos semanas en volver, la ventaja de velocidad se pierde entera.

El trabajo es acotable. Módulos nuevos, integraciones, migraciones, automatizaciones sobre un dominio delimitado. Cuanto más nítido el borde, mejor funciona.

Para qué casos no

Esto es más importante que lo anterior, y suele contarse menos.

Descubrimiento abierto. Cuando el problema todavía no está entendido, acelerar es contraproducente. Un pod construye rápido en la dirección que se le dé, incluida la equivocada. Lo más caro de un proyecto no suele ser construirlo, sino haberlo construido hacia el lado que no era. Esa etapa pide conversación, prototipos descartables y tiempo de pensar, no capacidad de entrega.

Soporte y operación continua. El trabajo de soporte es interrupción, no entrega: prioridades que cambian todos los días, incidentes, disponibilidad. Comprometer entregables cerrados en ese contexto es forzar una estructura contra la naturaleza del trabajo. Para eso conviene un equipo integrado y disponible.

Cuando el cliente necesita retener el conocimiento internamente. Un pod concentra el contexto en pocas personas y en la configuración de sus herramientas. Eso es eficiente y es un riesgo de transferencia. Si el objetivo del proyecto incluye que el equipo interno quede capacitado para sostener el sistema, el modelo trabaja en contra y hay que compensarlo explícitamente.

Proyectos muy chicos. Montar un pod tiene un costo inicial real: definir criterios de aceptación, preparar el entorno, ajustar el flujo de revisión. En un trabajo de tres semanas ese costo no se amortiza nunca.

Falta uno, que es el que más veces aparece en la práctica y el único de la lista que se puede revertir con trabajo.

El legacy no es un impedimento, es una etapa previa

En sistemas donde el conocimiento crítico es tácito y vive en la cabeza de quienes los mantienen, un agente no tiene de dónde inferir las reglas que nadie escribió. Y sin tests no hay forma barata de verificar lo que propone, así que toda la carga de verificación vuelve a las personas, que es exactamente el cuello de botella que el modelo intentaba abrir.

La conclusión fácil sería que en legacy el modelo no sirve. La conclusión correcta es que hay trabajo previo, y que ese trabajo es bastante más acotado de lo que parece. Tiene tres partes.

Hacer explícito el contexto. Un agente infiere los patrones del código que tiene a la vista. Si el proyecto resuelve la misma cosa de tres maneras distintas, va a elegir cualquiera de las tres, y va a tener razón en las tres. Lo que falta escribir no es documentación en el sentido clásico: son las convenciones vigentes por módulo, las decisiones de arquitectura con su porqué, y tres o cuatro caminos canónicos sobre el código real que funcionen como referencia de “así se hace acá”. También las áreas donde conviene no intervenir. Ese material se versiona junto al código, porque envejece igual que el código.

Mover parte de la verificación al pipeline. Si la revisión humana es el recurso escaso, todo lo que pueda verificar una máquina tiene que hacerlo antes de llegar a una persona: build, tests, análisis estático, escaneo de secretos y dependencias, límite de tamaño de pull request. La revisión humana no desaparece; deja de gastarse en lo que no requiere criterio. Conviene arrancar con los controles en modo advertencia durante algunas semanas, para calibrar umbrales sin frenar la entrega.

Medir la cobertura sobre el diff, no sobre el total. Este es el punto que desatasca el problema. Exigir cobertura sobre todo el proyecto en un sistema legacy es pedir un proyecto de remediación de meses antes de poder empezar. Exigirla sobre el código nuevo o modificado significa que lo que se toca a partir de ahora viene con test, y lo viejo no bloquea. La deuda deja de crecer desde el día uno y se achica con el trabajo cotidiano, sobre todo porque el andamiaje de tests es uno de los primeros usos donde la asistencia rinde bien.

Ese enfoque tiene un límite que conviene decir: en los módulos que arrancan sin cobertura, los controles automáticos detectan menos, y ahí la revisión humana sigue siendo el control principal. No es una solución completa. Es lo que permite empezar sin haber terminado.

En un proyecto sobre el que estamos trabajando ahora, esa preparación se planteó como una etapa de cuatro semanas previa a cambiar la forma de entregar. Son cuatro semanas que no producen funcionalidad nueva, y esa es la parte que hay que decidir con los ojos abiertos: no se está comprando velocidad, se está comprando la posibilidad de trabajar distinto después. Si el proyecto no va a durar lo suficiente como para amortizarlo, no vale la pena.

La pregunta que está atrás

Nada de esto es específico de los pods. El modelo es una respuesta posible a un cambio que ya está ocurriendo en cualquier equipo que sumó agentes al trabajo diario: el volumen de código propuesto creció y la capacidad de decidir qué se integra no creció con él.

Se puede responder de otras maneras. Se puede reforzar la revisión dentro de la estructura actual, cambiar los criterios de aprobación, o resolverlo con tooling antes que con organización. Lo que no parece sostenible es dejar la estructura igual y asumir que el equipo absorbe la diferencia.

La pregunta previa a elegir un modelo, entonces, es más simple: si escribir código dejó de ser lo escaso en tu equipo, ¿qué es lo escaso ahora, y quién decide?