Seeing AGI (8): El renacer del rol humano
Hace poco asistí a Delight Spark en San Francisco, y una conversación se quedó conmigo mucho después de que terminara el evento. Trataba sobre las organizaciones de IA.
A lo largo de mis siete artículos anteriores de Seeing AGI, he escrito sobre la llegada de la AGI, el vibe working y los sistemas multiagente. Pero la pregunta a la que sigo volviendo es más simple: ¿qué le pasa al rol humano dentro de la empresa? Antes de que la IA reescriba el organigrama, reescribe a la persona.
Demasiadas empresas siguen tratando a la IA como una actualización de software para las mismas personas en los mismos puestos. Ese es el marco equivocado. La IA no solo está acelerando el trabajo. Está cambiando quién hace qué, quién es dueño del contexto y cómo se mueve el criterio.
Cada ola tecnológica cambia el rol humano
Cuando las personas se topan con una tecnología que rompe esquemas, suelen suponer que su trabajo seguirá siendo exactamente el mismo, solo que más rápido. La historia nos muestra que es una ilusión.
Lo primero que cambia rara vez es el organigrama sobre el papel. Lo primero que cambia es lo que los seres humanos hacen durante el día, de quién dependen, a quién le reportan y qué tipo de criterio premia realmente el sistema.
Así que si queremos entender la IA con claridad, no deberíamos preguntar solo qué pueden hacer los modelos. Deberíamos preguntar qué les hicieron las olas tecnológicas anteriores al trabajo en sí.
La electricidad no solo modernizó la fábrica. Cambió a las personas que estaban dentro.
La famosa lección de la electrificación no es solo que la electricidad fuera poderosa. Es que la primera ola de adopción se quedó corta porque las fábricas mantuvieron el mismo diseño anterior. Los dueños reemplazaron las máquinas de vapor por dinamos, pero conservaron la misma lógica de potencia centralizada, los mismos ejes de transmisión, las mismas correas y la misma geometría de producción.
El verdadero salto vino después, cuando las fábricas adoptaron el accionamiento individual: motores eléctricos por máquina. En ese momento, el edificio mismo pudo cambiar. Los diseños de una sola planta se volvieron más fáciles. Las máquinas ya no tenían que organizarse en torno a una columna mecánica. El flujo de trabajo podía rediseñarse alrededor de la velocidad, la seguridad y la especialización.
Y una vez que cambió la fábrica, los roles humanos cambiaron con ella. La vieja lógica de las salas de máquinas centrales, los diseños accionados por ejes y el mantenimiento construido alrededor de una sola fuente de energía empezó a desvanecerse. En su lugar surgió una nueva necesidad de electricistas, ingenieros eléctricos, planificadores de fábrica y un nuevo tipo de gestión de operaciones. Paul David escribió que la electrificación a gran escala requirió formar "un cuadro de arquitectos de fábrica e ingenieros eléctricos con experiencia". Ese es exactamente el punto. Una nueva fuente de energía no se limitó a hacer más rápidos a los viejos trabajadores. Creó nuevos especialistas, nuevas relaciones de reporte y una nueva lógica operativa.
Las computadoras no solo automatizaron las oficinas. Crearon roles de información completamente nuevos.
La era de la computadora hizo algo similar. Antes de la informatización, las grandes organizaciones dependían de capas de oficinistas, mecanógrafos, personal de archivo, contadores y operadores de máquinas para mover información a mano. Luego llegaron los departamentos de procesamiento de datos, los operadores de perforación de tarjetas, los programadores, los analistas de sistemas y, más tarde, los administradores de bases de datos y los gerentes de IT.
Algunos roles se redujeron. Otros aparecieron de la nada. Los operadores de perforación de tarjetas se convirtieron en una ocupación reconocible en la era de las tarjetas perforadas y luego desaparecieron gradualmente a medida que la computación directa se extendió. Al mismo tiempo, el analista de sistemas surgió como un nuevo rol puente: alguien capaz de entender el negocio, diseñar el sistema, preparar diagramas para los programadores y traducir las necesidades de la dirección en una estructura técnica. Ese rol solo tiene sentido en un mundo donde el software se vuelve parte de cómo piensa la empresa.
Esto también cambió las líneas de reporte. Una vez que los sistemas de información se volvieron centrales para las operaciones, las empresas construyeron organizaciones MIS y de IT, capas de gestión de proyectos, equipos de sistemas y, más tarde, funciones de software empresarial. La autoridad fluía cada vez más a través de la arquitectura de la información, no solo de las operaciones físicas.
El software creó la organización de producto moderna.
Después, la era del software añadió otra capa. A medida que la complejidad del software se disparó, la organización volvió a dividirse. La gestión de producto surgió para llenar el hueco entre el negocio, los usuarios y la ingeniería. En el software, no bastaba con comercializar un producto. Alguien tenía que decidir qué construir, traducir los escenarios de usuario y mantenerse cerca de la ingeniería durante todo el ciclo.
UX y el diseño de interacción maduraron a medida que la computación personal y luego la web hicieron que la usabilidad fuera económicamente ineludible. QA se convirtió en una función diferenciada porque las pruebas ya no podían quedarse en la cabeza del programador. Más tarde, Agile y DevOps empezaron a difuminar de nuevo esas líneas, llevando a los testers más temprano al ciclo y haciendo de la calidad una responsabilidad compartida.
Así que la estructura PM, Diseñador, Desarrollador y Tester no nos fue dada por la naturaleza. Pertenecía a la era anterior de la ingeniería de software. Era una respuesta racional a los límites de la comunicación humana, el conocimiento fragmentado, la programación manual y los ciclos de retroalimentación más lentos.
La vieja línea de ensamblaje fue construida para otro mundo
Una vez que ves esa historia con claridad, el organigrama actual del software parece mucho menos permanente de lo que la mayoría de la gente piensa. Es simplemente la última capa en una larga secuencia de reorganizaciones tecnológicas.
En el viejo mundo del software, un proyecto necesitaba una pila profunda de funciones especializadas antes de poder avanzar un centímetro. La lógica de reporte normalmente reflejaba el flujo de trabajo en sí: producto generaba los requisitos, diseño los traducía, ingeniería los implementaba, QA los validaba y la dirección coordinaba las entregas entre esos silos.
Piensa en lo que solía hacer un PM: pasaba semanas escribiendo enormes documentos de especificación de 20 páginas para lanzarlos por encima de un muro. Luego el Diseñador pasaba semanas empujando píxeles a mano para traducir esa especificación en mockups. El Desarrollador tomaba esos mockups y pasaba meses tecleando código repetitivo. Finalmente, el Tester pasaba semanas cazando desalineaciones y bugs.
Esa estructura tenía sentido cuando cada paso tenía que ser ejecutado por un especialista distinto usando herramientas distintas, con transiciones costosas entre ellos. Las entregas no eran solo burocracia. Eran la forma en que el sistema se protegía de la complejidad.
Pero cuando un agente de IA puede ayudar a generar el código, redactar la UI, crear casos de prueba y comprimir la iteración a minutos, la misma estructura empieza a trabajar contra sí misma. La entrega pasa de ser un mecanismo de seguridad a ser pura fricción.
La mayor parte de la "transformación con IA" hoy sigue atrapada aquí. Las empresas le dan una herramienta de escritura con IA al PM, una herramienta de diseño con IA al Diseñador y una herramienta de programación con IA al Desarrollador, pero conservan las mismas líneas de reporte y la misma división del trabajo. Es conectar una nueva fuente de energía a una máquina vieja.
Por eso creo que la primera parte de esta historia importa tanto. La IA no es la primera tecnología que reordena el trabajo. Pero puede ser la primera que lo hace a esta velocidad y, al mismo tiempo, colapsa tantos roles de conocimiento en el mismo momento de ejecución.
Lo que estoy viendo dentro de Genspark
Dentro de Genspark, ya puedo ver cómo se está escribiendo en tiempo real la siguiente capa de esa historia. Hoy somos una organización de unas 70 personas. Nuestra estructura es despiadadamente plana.
No dotamos los proyectos con departamentos enormes y multidisciplinarios. La gran mayoría de nuestros proyectos los ejecutan células ágiles de apenas 1 a 3 personas. Como el flujo de trabajo está comprimido, las personas operan muy cerca de toda la cadena de creación de valor.
Esto comienza desde el primer día. A los nuevos empleados no se los esconde en roles estrechos ni se los obliga a leer documentación durante un mes. Se los empuja inmediatamente al frente de batalla. Es habitual ver gente entregando funcionalidad real y compleja en su primera semana. Incluso integrantes del equipo que nunca habían escrito una sola línea de código antes de unirse están lanzando funciones.
En la era anterior, eso habría sonado temerario o imposible. En esta era, es la base. La gente ambiciosa prospera aquí porque ya no está atrapada en una sola caja.
Cómo están cambiando realmente los roles
Cuando el flujo de trabajo se comprime con tanta fuerza, los roles profesionales no desaparecen. Mutan. Se elevan.
El PM: de redactor de especificaciones a director del sistema
El PM ya no pasa semanas escribiendo documentos estáticos para que otra persona los interprete. Usa la IA para generar prototipos vivos al instante. Está dirigiendo el sistema, probando la lógica en tiempo real y haciéndose dueño del resultado final, en vez de solo de los requisitos.
El Diseñador: de traductor del front-end a juez final
Nuestro reciente lanzamiento de Genspark Design es el ejemplo perfecto. En el proceso anterior, el Diseñador era un traductor en la primera etapa. Tenía que dibujar las pantallas a mano antes de que cualquier otro pudiera construir. Hoy, el camino de una idea abstracta a un diseño completo y a un producto lanzado es continuo.
Como la IA puede generar decenas de prototipos funcionales de alta fidelidad en segundos, el rol del Diseñador se mueve al final del pipeline. Se convierte en el juez. Establece el listón de calidad. Protege el nivel de gusto. Aprueba la experiencia. Decide cuál de las iteraciones de la IA tiene el alma adecuada para la marca.
El Desarrollador: de tipista de código a arquitecto de sistemas
La primera semana de un desarrollador ya no se trata de configurar entornos locales y leer bases de código viejas. Se trata de entregar. Pasa menos tiempo tecleando código repetitivo y más tiempo arquitectando lógica, guiando agentes y resolviendo los problemas profundos y estructurales que la IA todavía no puede ver.
El Tester: de guardián manual a ingeniero de infraestructura para agentes
En el flujo de trabajo nativo de IA, todos se vuelven testers de su propia funcionalidad. La persona que construye la funcionalidad también genera casos, revisa condiciones límite, valida la experiencia y decide si está lista para salir. Las pruebas ya no se ubican al final de la cadena como un portón separado. Se vuelven parte de la propia autoría.
Eso no significa que el tester tradicional desaparezca. El rol sube un nivel. Se convierte en un rol de infraestructura. En lugar de revisar manualmente cada pantalla a posteriori, esta persona ayuda a asegurar que, una vez que las funciones se entregan en todo el equipo, el sistema se mantenga estable, observable y confiable en producción.
En ese sentido, el nuevo tester se parece más a un ingeniero de infraestructura para la calidad. Construye los frameworks, las barreras de protección, el monitoreo, los ciclos de evaluación y la lógica de release que hacen a toda la organización más confiable. También ayuda a crear infraestructura más amigable con los agentes, para que la IA pueda participar de manera más efectiva en pruebas, depuración y mejora continua.
En todas las disciplinas, la tendencia es exactamente la misma: el criterio se está volviendo mucho más importante que la entrega. La propiedad del contexto se está volviendo más valiosa que la especialización estrecha.
El CEO: de Chief Executive Officer a Chief Context Officer
Una vez que ves con qué profundidad la IA está recombinando roles, no puedes detenerte en los PM, los Diseñadores, los Desarrolladores y los Testers. El CEO también está siendo reescrito.
En el viejo modelo de empresa, la escala empujaba al CEO lejos del trabajo. La organización se volvía demasiado especializada, demasiado estratificada y demasiado lenta. El trabajo del CEO se convertía en gestionar la complejidad a través de otras personas.
Esa distancia no era un rasgo de personalidad. Era estructural. En muchas empresas, el CEO ya no podía tocar el producto directamente porque el trabajo había sido fragmentado en demasiadas funciones, reuniones y entregas.
La IA rompe ese modelo. Un CEO dispuesto a aprender puede volver a meterse en el trabajo. Puede explorar ideas de producto, revisar prototipos, probar flujos, cuestionar supuestos e incluso ayudar a impulsar la ejecución con IA. No porque el CEO deba volver a ser un microgerente, sino porque la pared entre el liderazgo y la creación se está volviendo más delgada.
Así que el trabajo cambia. El CEO de la era de la IA empieza a parecerse menos a un Chief Executive Officer y más a un Chief Context Officer. El rol consiste en marcar la dirección, clarificar el criterio, mover los derechos de decisión más cerca del borde y diseñar las interfaces que permiten a las pequeñas células moverse con verdadera propiedad.
En el viejo modelo, el poder venía de la distancia y el control. En el nuevo modelo, el poder viene del contexto, el gusto, la claridad y la capacidad de ayudar a la organización a pensar y moverse como un solo sistema. Y una vez que el CEO cambia, la organización no puede quedarse igual. La reescritura del rol se vuelve naturalmente reescritura de la organización.
La nueva organización no es solo más plana. Es estructuralmente diferente.
No creo que la descripción correcta para esta nueva empresa sea simplemente "plana". Plana solo significa menos capas. Lo que estamos viendo es un cambio más profundo que ese. La unidad básica de la organización ya no es la función. Es la célula.
En la vieja estructura, la empresa estaba construida alrededor de departamentos. Producto se sentaba en un lugar. Diseño en otro. Ingeniería en otro distinto. QA al final. El organigrama reflejaba la cadena de entregas.
En la nueva estructura, la empresa empieza a parecerse más a una red de pequeñas células de alto contexto. Una célula de 1 a 3 personas trabaja cerca del problema, cerca del usuario y cerca de la IA. Posee más cadena, de la idea al lanzamiento. Carga más contexto. Toma más decisiones. Espera menos.
En una empresa de miles, esto no puede significar un solo CEO tocando directamente cientos de células. Eso no escala. La versión escalable es una red de redes: células agrupadas en clusters de misión, sostenidas por contexto compartido, gusto compartido, claridad compartida y diseño de sistema compartido. Las capas de liderazgo siguen existiendo, pero su trabajo cambia. Ya no son cuellos de botella de aprobación. Se convierten en enrutadores de contexto, diseñadores de interfaces y multiplicadores de fuerza. En ese modelo, el CEO no gestiona cada célula. El CEO diseña la arquitectura que permite que muchas células se muevan con coherencia sin reconstruir la vieja burocracia. Así se ve la escala nativa de IA: no una pirámide más plana, sino un sistema diferente.
Una vez que eso sucede, la jerarquía deja de ser el principal mecanismo de coordinación. El contexto se vuelve el principal mecanismo de coordinación. La pregunta más importante ya no es "¿Quién le reporta a quién?". Pasa a ser "¿Quién tiene realmente el contexto y quién tiene el criterio para actuar sobre él?".
Eso también cambia para qué sirven las capas de liderazgo. En el viejo mundo, una buena parte de la gerencia media existía para traducir, resumir, coordinar y mover información a través de las fronteras funcionales. En el nuevo mundo, esos roles solo siguen siendo valiosos si evolucionan a constructores de sistemas, revisores de calidad, coaches de talento e integradores entre células. El gerente correa de transmisión irá perdiendo importancia de manera constante.
En una frase, la organización nativa de IA es esto: una red de pequeñas células con alta propiedad del contexto, apoyadas por agentes de IA, alineadas por un criterio compartido y conectadas por interfaces ligeras en lugar de jerarquía pesada.
La ventana para reescribir la empresa
Si la reescritura del rol lleva a la reescritura del CEO, y la reescritura del CEO lleva a la reescritura de la organización, entonces esto no es una actualización de herramientas. Es una reescritura de la empresa. Así que deja de mirar solo tu stack de IA. Mira a tu gente. Mira tu estructura.
Hazte las preguntas más difíciles. ¿Tu gente sigue atrapada en roles estrechos de traducción? ¿Tus mejores mentes siguen preparando entregas en lugar de emitir juicios? ¿Tu organigrama sigue construido para la vieja cadena PM-Diseñador-Desarrollador-Tester? ¿Los derechos de decisión siguen demasiado lejos de las personas que tienen el contexto real?
Comprar acceso a IA es fácil. La transformación real es más difícil. Significa rediseñar roles, empujar la propiedad hacia células pequeñas, reconstruir la infraestructura alrededor de los agentes y redefinir el propio liderazgo.
Los ganadores de esta era no usarán solo mejores modelos. Reconstruirán más rápido. Reemplazarán las cadenas de entrega con redes de células. Moverán el contexto al borde. Subirán el listón del criterio.
La IA no solo está reescribiendo tareas. Está reescribiendo la empresa. La ventana está abierta ahora. No se quedará abierta por mucho tiempo.