Cómo la IA nos hizo repensar la colaboración en equipo

Recientemente realizamos un experimento interno real.

El objetivo era el mismo producto: una herramienta de recuperación ante desastres a nivel de archivo. No era un proyecto de práctica — se construyó sobre la experiencia real acumulada en nuestros productos HyperBDR y otros de DR, reabstrayendo nuestra comprensión de los sistemas de recuperación en un nuevo objeto de recuperación. Contexto de negocio real. Complejidad de producto real.

Abordamos este requisito con dos estructuras organizativas completamente diferentes.

La primera fue el familiar modelo de desarrollo en equipo: un Lead dividió los requisitos en módulos (sincronización de archivos, gestión de versiones, estrategia de recuperación, programación de tareas, etc.), con dos ingenieros frontend y dos backend colaborando con asistencia de IA. El Lead también actuó como product manager, con la UI gestionada colaborativamente por el equipo.

La segunda fue exactamente lo contrario: un único compañero — alguien con larga experiencia en entrega a clientes y servicio de primera línea — utilizó la IA de forma independiente para ir desde el análisis de requisitos y el diseño de la solución hasta la implementación, sin descomposición de tareas, completando todo el producto de principio a fin.

Al final, no comparamos el tiempo de desarrollo ni las líneas de código. Solo miramos el producto en sí — qué tan usable era, cómo se veía, qué tan fluida era la experiencia.

El resultado sorprendió a todos.

El enfoque individual fue claramente superior en velocidad de entrega, coherencia general y experiencia de producto. Las diferencias fueron especialmente notables en la coherencia del flujo de recuperación, la consistencia del manejo de errores y la unidad lógica del producto en general.

¿Por qué una sola persona fue más eficiente?

La reacción inmediata es: ¿con asistencia de IA, puede una persona realmente reemplazar a un equipo pequeño?

Pero el problema puede no ser el número de personas — es el modelo de descomposición de tareas en sí.

La forma en que la ingeniería de software organiza el trabajo siempre ha estado cambiando. En los primeros tiempos, no había una distinción tan refinada entre frontend, backend, diseño, QA y producto. Una persona podía a menudo ser responsable de todo el ciclo, desde entender los requisitos hasta entregar funcionalidades. A medida que los sistemas se volvieron más complejos y las pilas tecnológicas más especializadas, la capacidad de ejecución individual se convirtió en el cuello de botella, y la división del trabajo fue emergiendo y solidificándose gradualmente.

Esta división del trabajo no surgió porque fuera “inherentemente más eficiente”. Era una compensación por los límites de capacidad individual bajo las condiciones de producción de su época.

La IA cambia esa premisa. Cuando la IA amplifica significativamente la capacidad de ejecución individual, los límites de tareas que fueron separados por la fuerza en el pasado vuelven a volverse inestables.

La premisa de la descomposición modular es que el acoplamiento entre módulos puede resolverse a través de interfaces y comunicación. Pero en productos reales, muchos problemas son intrínsecamente transversales — toma el “flujo de recuperación” como ejemplo: involucra simultáneamente la interacción frontend, las máquinas de estado del backend, la consistencia de datos, el manejo de errores y la experiencia general. Dividirlo entre diferentes personas inevitablemente requiere una enorme cantidad de alineación. Esa alineación en sí misma es el costo.

Mirando atrás al experimento, observamos una clara divergencia entre los dos grupos:

• El grupo de desarrollo tradicional operó en un modo clásico orientado al proceso: análisis de requisitos → diseño detallado → descomposición modular → implementación → pruebas de integración. Proceso completo, etapas claras.
• El compañero de entrega operó en un modo clásico orientado al resultado: sin énfasis en la integridad del proceso, sin enfoque en los pasos intermedios, con el entregable final como norte, usando continuamente la IA para corregir la desviación del objetivo.

Cuando la IA reduce el costo de ejecución, el valor del proceso en sí disminuye — y la capacidad de iterar hacia resultados se vuelve más importante. Esa brecha se amplificó aún más.

Repensando la Colaboración en Equipo

Este experimento me hizo revisar una pregunta más fundamental: ¿qué tipos de tareas pertenecen a una persona, y cuáles a muchas?

Una heurística bastante directa: si un trabajo requiere comunicación frecuente a nivel de negocio, probablemente sea más adecuado para una sola persona.

Porque esa comunicación en realidad no es colaboración — es sincronizar repetidamente sobre “qué es exactamente esta cosa”. Cuando la sincronización constante se convierte en la norma, la colaboración multipersona amplifica el costo de comprensión en lugar de reducirlo.

Por el contrario, si la colaboración es puramente basada en interfaces — límites claros, sin necesidad de explicar repetidamente el negocio en sí — entonces tiene sentido dividirlo entre múltiples personas.

En otras palabras, los criterios para la descomposición de tareas están experimentando un cambio fundamental:

De los límites funcionales, hacia el costo de comunicación cognitiva.

Para llevar esto más lejos: si alguien todavía necesita que otros le ayuden a entender el contexto del negocio mientras hace su trabajo, todavía está operando en el viejo modelo de colaboración. Cuando la IA puede manejar la mayor parte de la ejecución, la capacidad que realmente importa ya no es “¿puedes completar la tarea?” — es “¿puedes formar de forma independiente una comprensión completa y tomar decisiones?”

La IA Convirtió el Desarrollo de Preguntas Abiertas a Opción Múltiple

Hay otra observación que impactó profundamente durante este experimento.

La IA no hace el desarrollo de productos más fácil — simplemente hace que el primer 80% sea más rápido.

Prototipos, flujos básicos, estructuras de página, esquemas de API — con IA puedes construir todo esto rápidamente. Pero lo que realmente determina la calidad del producto es generalmente el último 20% del proceso de productización.

Las personas que avanzan rápido en el primer 80% no necesariamente piensan con claridad en el último 20%.

El primer 80% trata más sobre densidad de ejecución — en cierto sentido, la “diligencia” es suficiente. El último 20% exige juicio, compromisos y gusto — requiere “inteligencia”, o más precisamente, profundidad de pensamiento y sensibilidad estética.

En el pasado, escribir código era más como una pregunta de desarrollo: ¿podías resolver el problema?

Con la IA en escena, el desarrollo se siente cada vez más como opción múltiple y verdadero/falso: la IA te presenta opciones, código, interfaces y caminos. La parte difícil se convierte en — ¿puedes juzgar qué es correcto, qué simplemente “funciona”, y qué es realmente bueno?

En cuanto a las mejores prácticas para ese último 20%, honestamente todavía lo estamos descubriendo. Pero una cosa es clara: la IA ya ha convertido muchos problemas que antes dependían de la capacidad de ejecución en problemas de capacidad de juicio.

Conclusión

Si abstraemos este experimento, lo que vemos no es solo una historia de eficiencia — es un cambio organizacional.

El valor que la IA aporta no aparecerá solo en optimizaciones locales como “escribir código más rápido”. Gradualmente convergerá en una pregunta más práctica:

Dado el mismo objetivo, ¿utilizas menos personas para lograr el mismo resultado — o utilizas las mismas personas para multiplicar la producción por cinco o diez veces?

Este experimento simplemente hizo esa pregunta un poco más concreta.

Y lo que realmente separará a las personas en la era de la IA puede que ya no sea la capacidad de ejecución en el sentido tradicional. Puede reducirse a dos cosas:

Profundidad de pensamiento, y gusto.