El equipo es la nueva ventana de contexto
La IA hace más rápido al developer individual, pero no necesariamente al equipo. Diez developers con las mismas herramientas terminan con diez formas distintas de trabajar, y esa fricción se paga a nivel de equipo. La respuesta no es uniformar a las personas, es una base común de reglas, skills y criterios de review.
Hace unos días un colega me contó algo que se me quedó dando vueltas. Bajó un proyecto en el que estaba trabajando otra persona y quiso usar sus propios modelos de IA, como hace siempre. Las skills prácticamente no existían, o no estaban pensadas para su forma de trabajar, y los agentes terminaron generando código que no seguía ninguno de los estándares que él maneja.
No fue el único caso que escuché esa semana. Me crucé con más de un colega atravesando algo parecido, y fue lo que me hizo sentarme a pensar esto.
Algo está pasando en la ingeniería de software. Los developers individuales nos volvimos considerablemente más rápidos. Ideas que antes tomaban horas hoy se exploran en minutos, prototipamos, validamos, descartamos y volvemos a intentar con un esfuerzo que antes no existía. Eso es bueno.
Tampoco veo la IA como una dependencia peligrosa. Ya vivimos algo parecido con Internet, los buscadores y los editores modernos. Las herramientas no eliminan la necesidad de criterio, cambian dónde hay que aplicarlo. La IA es una herramienta. Cuánto confías en lo que produce sigue dependiendo de tu propio criterio.
Pero hay un problema más interesante. La IA puede aumentar la productividad individual sin aumentar la productividad del equipo.
Diez developers, diez formas de trabajar
Dale las mismas herramientas a diez developers y vas a tener diez formas completamente distintas de trabajar. Uno tendrá reglas y skills cuidadosamente definidos; otro se va a quedar en los valores por defecto. Uno va a estar pendiente de la ventana de contexto y del consumo de tokens; otro ni se va a fijar. Algunos van a revisar casi cada línea que escribe un agente; otros van a mirar solo el diff final. Algunos van a usar un agente y otros varios.
Nada de esto es malo en sí mismo. La experimentación es parte de lo que hace tan potente a la IA. El problema aparece cuando todos esos sistemas individuales tienen que convivir dentro del mismo equipo.
El cuello de botella cambió de lugar
Un equipo de software no es una colección de developers independientes. Comparten arquitectura, código, documentación, decisiones y responsabilidades. Si cada persona trabaja distinto con la IA, la productividad que se gana individualmente empieza a generar fricción a nivel de equipo.
Antes nos preocupaba si los developers podían escribir código lo bastante rápido. Ya no es eso. El cuello de botella hoy es si la organización puede coordinar todo el código que la IA les permite producir.
Una base común, no un molde único
La solución no es controlar cómo cada developer usa la IA. Es establecer una base común, principios para trabajar con agentes, instrucciones de proyecto, skills reutilizables, criterios de contexto y code review, límites para las acciones autónomas, estándares de documentación y mecanismos para validar lo que el agente produce. El objetivo no es que todos usen la IA exactamente igual. Es que el sistema siga siendo coherente aunque las personas que lo usan sean distintas.
Eso es, en los hechos, lo que terminamos armando con .agents, un lugar único de reglas y skills que cualquier editor de IA puede leer, para que la fuente de verdad no dependa de qué herramienta eligió cada uno.
También hay que tener cuidado con lo que medimos. Tokens consumidos, prompts enviados o cantidad de código generado no son productividad. El objetivo no es maximizar el uso de la IA. Es maximizar los resultados útiles.
Creo que estamos entrando en una segunda etapa de adopción. La primera pregunta fue cómo usar la IA, probamos modelos, agentes, MCP servers, skills, ventanas de contexto y workflows cada vez más autónomos. La siguiente pregunta es cómo trabajamos con IA como equipo. Y esa pregunta es mucho más grande, involucra cultura, arquitectura, herramientas, documentación y diseño organizacional.
Las empresas que la resuelvan no van a ser las que tengan a los developers con los prompts más sofisticados. Van a ser las que logren convertir la capacidad individual de la IA en una capacidad compartida por toda la organización.
Cierre
La IA da apalancamiento individual. Los equipos construyen sistemas. Si cada developer se vuelve mucho más capaz pero el sistema que lo rodea sigue igual, ese sistema termina siendo el cuello de botella.
Quizás la próxima generación de prácticas de ingeniería no consista en enseñarle a cada developer a usar IA, sino en enseñarle al equipo a pensar con ella.
La ventana de contexto más importante de una organización nativa de IA no es la que está dentro del agente. Es la que comparte todo el equipo.