Reconstruyendo Manus con Manus: qué cambió, qué se rompió y cómo trabajamos ahora
Por Tao Zhang, cofundador y director de producto, Manus
A finales de septiembre, durante el empujón final de Manus 2.0, envié a uno de nuestros ingenieros algunas solicitudes de funciones y reportes de errores por Slack. Más tarde fui a ver cómo le iba. En su pantalla había una fila de sesiones de agentes abiertas, algunas en Manus y otras en Codex. Hice clic en una. El prompt era mi mensaje de Slack, pegado palabra por palabra.
Hace un año, él habría leído mi mensaje, habría deducido lo que yo quería decir y luego habría escrito el código. Ahora un agente lee la solicitud, encuentra el código relevante y propone un cambio. El trabajo del ingeniero es dirigir la labor, revisarla y responsabilizarse del resultado. La mayor parte del tiempo una solicitud está ejecutándose, no esperándolo a él. Hoy, es común aquí que un ingeniero tenga de 10 a 20 solicitudes avanzando a la vez.
Estoy orgulloso de lo rápido que se ha adaptado nuestro equipo. También estoy inquieto. ¿Es correcto este ritmo? ¿Qué no hemos notado todavía?
En Manus construimos agentes, así que nos atenemos a dos reglas. Usamos nuestro propio producto para trabajo real. Y seguimos buscando los lugares donde la AI deja de funcionar.
Me gustaría documentar lo que ocurre dentro de una empresa cuando, por defecto, personas y agentes trabajan codo con codo. Esta publicación cubre tres equipos — ingeniería, producto y marketing — e incluye lo que no ha funcionado. Es un informe de un experimento en curso, no una definición de una "organización AI-native".
Lo que hemos aprendido hasta ahora:
•No hay término medio. Añadir AI a las viejas formas de trabajar a veces añadía ruido. Las cosas cambiaron solo cuando el bucle se cerró.
•Los agentes necesitan el panorama completo. Un mejor contexto nos aportó más que mejores prompts.
•La confianza viene de las pruebas y el contexto, no solo de la calidad del modelo.
•La autonomía necesita una meta. Los agentes pueden funcionar por su cuenta solo cuando el éxito puede comprobarse. En todo lo demás, decide una persona.
•El cuello de botella se mueve. Cuando la ingeniería se aceleró, decidir qué construir se convirtió en la restricción.
•El papel de las personas no ha disminuido. Se ha vuelto más centrado en cosas de mayor impacto.
1. No hay término medio
Antes de 2026, hacíamos lo que hacían la mayoría de las empresas: añadir AI a la forma en que ya trabajábamos. Esto significaba que soporte señalaba problemas con un resumen de AI, los ingenieros usaban asistentes de codificación y los bots publicaban análisis en los canales. Cada pieza era útil por sí sola, pero pocas estaban conectadas entre sí. Hasta que el bucle realmente se cerró, simplemente estábamos trabajando como siempre pero con mucha AI hablando por encima unas de otras.
Hay una frase a la que volvemos a menudo: la ingeniería de software es programación integrada en el tiempo. Escribir código es fácil de medir; mantener un producto complejo sano durante años no lo es. Un alto porcentaje de código escrito por AI puede significar un progreso real, o puede significar acumular basura que alguien tendrá que limpiar más tarde.
La prueba que nos importa es más difícil. Manus es un producto complejo que lleva en producción más de un año. ¿Puede seguir mejorando bajo nuevas formas de trabajar sin colapsar, al tiempo que cada persona hace más? Hasta ahora la respuesta es sí.
2. Dale al agente el panorama completo
Como en la mayoría de las empresas tecnológicas, perdíamos la mayor parte del tiempo en los traspasos. Un ingeniero de frontend y uno de backend interpretaban cada uno una solicitud, acordaban una interfaz y luego pasaban días arreglando los desajustes. Dos personas rara vez entienden un requisito de la misma manera.
Si la AI puede escribir código en toda la pila, ¿podría una sola persona encargarse de una solicitud de principio a fin? El obstáculo era el contexto. Nuestro código vivía en repositorios separados, así que ningún agente podía ver todo el sistema a la vez.
Nuestra respuesta a eso comenzó con un experimento interno. Queríamos ver hasta dónde podía llegar la AI al construir un producto con la menor intervención humana posible y prácticamente sin código escrito a mano. El método que desarrollamos en el camino se convirtió en la herramienta interna que ahora llamamos Manus-mono, o Mono.
Mono no fusiona nuestros repositorios. Es un único punto de entrada más un manual escrito para el Agent: qué hace cada repositorio, cómo encajan entre sí y cómo trabajamos. El Agent toma lo que necesita. También mantenemos una biblioteca de registros de decisiones de arquitectura, de modo que cada sesión del Agent comienza con el razonamiento detrás de las decisiones pasadas, no solo con el código. Cuando alguien trabaja con un Agent, ese Agent tiene el contexto de todos los que vinieron antes.
Mono creció por etapas, y cada etapa resolvió el cuello de botella que la anterior había expuesto:
1.Ver todo el sistema. Añadimos el contexto de negocio que ningún repositorio por sí solo contiene, y usamos worktrees de Git para el trabajo en paralelo.
2.Verificar localmente. Un push al entorno de pruebas solía tardar de 5 a 10 minutos. Ahora la pila completa de Manus se ejecuta en una laptop y las comprobaciones toman segundos.
3.Depurar problemas en producción. Con permisos acotados, Mono puede leer los logs, la configuración y los informes de errores que necesita para diagnosticar bugs en producción.
4.Ejecutar lanzamientos de principio a fin. Mono ahora maneja los pasos de lanzamiento donde el trabajo solía estancarse. Las decisiones de aprobación siguen siendo de las personas.
5.Probar de principio a fin. Cuando la verificación se convirtió en la parte lenta, Mono comenzó a ejecutar flujos reales de usuario con cuentas de prueba, en un navegador y en un simulador móvil.
(Cómo funciona Mono y cómo evolucionó. Hecho por un compañero de equipo con Manus.)
A veces nos preguntan si Mono es una wiki de código. La documentación es una parte, pero el resto es todo lo que rodea al código: cómo probamos, cómo lanzamos, qué decidimos y por qué, y qué puede y qué no puede tocar el Agent.
Con el tiempo, Mono se ha convertido en una base de conocimiento compartida que mejora a medida que las personas aportan a ella. Por ejemplo, nuestro ingeniero de operaciones se cansó de que le pidieran ayuda con los lanzamientos, así que escribió el proceso de lanzamiento en Mono. Ahora cualquiera puede ejecutar un lanzamiento, y también el Agent, pero la aprobación sigue recayendo en personas con derechos de lanzamiento. Me encanta cómo trabaja el equipo: una persona resolvió su propia frustración, lo que hizo que toda la empresa fuera un poco más rápida.
El equipo ahora asume que una sola persona puede entregar una solicitud en cada plataforma. Nuestro equipo de móvil ha sido de siete personas todo este tiempo. Mantienen cuatro apps en dos productos y siguen el ritmo de la web.
Mono se extendió por toda la empresa sin un mandato de arriba hacia abajo. Creo que la cultura lo explica tanto como la herramienta. Probar los límites de la AI es parte de nuestra razón de ser, y nuestra organización es plana. Una herramienta llega hasta donde la organización le permita.
3. Cerrar el ciclo: del reporte de bug de un usuario a una corrección verificada
Mono permitió que cualquiera trabajara en cualquier parte del producto. Esa era una mitad. La otra mitad era dejar que los Agents encontraran problemas por sí mismos.
En la mayoría de las empresas de internet, el reporte de bug de un usuario pasa por soporte, producto y triaje antes de llegar a un ingeniero que pueda corregirlo.
Para nosotros, un Agent interno ahora investiga primero el reporte y rastrea el problema hasta el cambio que lo causó. Luego publica en Slack y etiqueta al ingeniero responsable de ese cambio. El ingeniero decide si le corresponde corregirlo y se lo entrega a su propio Agent. Un Agent separado verifica la corrección ejecutando las pruebas y flujos que importan.
Tres Agents, tres roles: uno hace el triaje, uno realiza el trabajo, uno lo verifica. La persona en medio toma las decisiones. Una proporción creciente de nuestro trabajo de ingeniería ahora comienza así, con un Agent llevando un problema a una persona.
Este ciclo tiene límites claros. El Agent que lee los reportes de usuarios no puede modificar código. Solo puede investigar e informarnos. Los cambios provienen del Agent propio del ingeniero, después de que el ingeniero decida. Nada se lanza sin la aprobación de una persona con derechos de lanzamiento.
4. Cómo aprendimos a confiar en el código escrito por agentes
Durante mucho tiempo, cada cambio que entraba en nuestra rama principal necesitaba la aprobación de uno de dos ingenieros senior. No confiábamos lo suficiente en la AI como para saltarnos ese paso. A medida que los agentes producían más código, ese paso de revisión se convirtió en el cuello de botella.
En cuanto a capacidad pura de codificación, los modelos ya eran sólidos. Reconocimos que la diferencia se reducía a dos cosas. Primero, las personas saben cómo probar su trabajo. Segundo, las personas han formado parte de las discusiones previas y posteriores, por lo que saben lo que "correcto" significa para el negocio. Código correcto no es lo mismo que producto correcto.
Abordamos ambos aspectos:
•Dejar que los agentes participen en la discusión. El agente de cada ingeniero ahora está presente en los hilos de Slack a los que se le ha añadido, y sigue el contexto. Cuando alguien finalmente dice "Adelante", el agente ya sabe lo que el equipo decidió y por qué.
•Dejar que los agentes prueben de principio a fin. Trabajando con nuestro equipo de backend, dimos a los agentes la capacidad de ejecutar flujos reales y pruebas de regresión en Manus después de cada cambio. A medida que crecía la cobertura de pruebas, crecía nuestra confianza.
Hoy, cada cambio pasa por esa verificación y por un bot de revisión de código que ejecuta el modelo más potente disponible, con reglas adicionales para áreas sensibles como los pagos. El bot reemplazó la cola, no la decisión humana. Un agente puede abrir un pull request, pero no puede fusionar en nuestra rama principal sin la aprobación explícita de una persona. Las personas siguen decidiendo qué se construye y quién puede publicar.
5. La autonomía necesita un objetivo final
La confianza tiene límites, y lo descubrimos por las malas.
En un momento dado, todos estaban entusiasmados con los bucles de agentes completamente autónomos, así que probamos uno. Un agente recopiló comentarios de nuestros canales internos de feedback e inició un proyecto para cada elemento. Un compañero lo dejó ejecutarse durante un fin de semana. El lunes por la mañana, más de 200 elementos esperaban su decisión.
¿Por qué no dejar que el agente también tome esas decisiones? Los bucles autónomos funcionan cuando el sistema puede comprobar si se ha alcanzado el objetivo. Las pruebas pasan o fallan; una página carga o no. La mayoría del trabajo real no tiene tal comprobación. Una persona tiene que juzgar si está hecho, y si valió la pena hacerlo en absoluto.
Sacamos dos lecciones de ese fin de semana. Primero, las personas no pueden tomar decisiones tan rápido como un bucle sin control las crea. Segundo, si nadie decide si algo debe hacerse, nadie es dueño del resultado. El bucle de corrección de errores de la sección 3 funciona porque las pruebas definen el éxito. Las decisiones de producto no tienen pruebas, por lo que cada cambio de producto en Manus aún comienza con una persona decidiendo si vale la pena hacerlo.
6. Cuando la ingeniería se aceleró, el producto se convirtió en el cuello de botella
Un proceso de producto tradicional tiene muchas transferencias, y las prioridades se desvían un poco en cada una. A medida que los agentes de codificación hacían más rápidos a los ingenieros, apareció un nuevo problema: no había suficientes product managers para escribir buenos requisitos. Por primera vez, la ingeniería no era la limitación.
En Manus, nuestra primera solución fue pedir a algunos ingenieros que se convirtieran en "builders" que son dueños de un problema desde el descubrimiento hasta el lanzamiento. Pocas personas tenían tanto el criterio técnico como el de producto. Luego dejamos que los PM cambiaran el código. Eso también se estancó. Las transferencias seguían ahí, y sin los instintos de un ingeniero, los PM podían cambiar textos e interacciones pero no la lógica subyacente.
Mono resolvió ambos problemas porque lleva las reglas consigo:
•Cualquier cambio que afecte a las llamadas al modelo o al coste necesita la aprobación del responsable antes de escribir el código.
•Cada cambio pasa por la misma revisión y pruebas que el cambio de un ingeniero.
•Mono puede recorrer el registro y el pago con cuentas de prueba y grabar cada paso, de modo que un PM pueda señalar el momento exacto en que algo falla.
Así se ve en la práctica. Una PM que trabajaba en voz a texto hizo que Manus comparara más de 10 modelos y luego eligió uno. Extrajo el código del frontend a través de Mono, construyó una demo en nuestro sistema de diseño y le pidió a Manus que renderizara cada escenario de usuario como una imagen para que ella lo revisara. Convirtió la demo en un video. El plan era lo suficientemente claro como para que ella misma construyera la función, incluyendo la UI web y de escritorio.
Las personas tomaron tres decisiones a lo largo del camino. Ella eligió el modelo. Producto y diseño revisaron la demo. Un ingeniero con permisos de publicación revisó el código. Hace un año, nada de esto habría sido posible.
Describimos esto como pasar de human in the loop a human on the loop. La AI solía hacer el 70-80% de una tarea y las personas completaban el resto. Ahora las personas establecen las reglas, supervisan varios agentes, verifican métodos y resultados en puntos clave, intervienen cuando es necesario y asumen la responsabilidad del resultado.
Algunos PMs ahora entregan un video corto en lugar de una especificación escrita o maquetas. En unos minutos, muestra el caso de uso, cada pantalla, qué hace cada clic, cómo se comportan los casos extremos y cómo funciona todo por debajo. Para nosotros, diseño, ingeniería y QA se ponen de acuerdo más rápido sobre lo que significa "terminado", y el PM lo explica una sola vez.
(Video de requisitos de producto para entrada de voz)
Hoy en día, aproximadamente la mitad de nuestros PMs lanzan funcionalidades por su cuenta, y cada PM ha enviado código. Los diseñadores también han comenzado. Un PM escribió la mayor parte de la interfaz de Manus Studio en Manus 2.0. Otro escribió el Editor de Video. Detrás de cada uno de ellos hay alguien que pasó meses superando lo que su rol solía abarcar. Eso es de lo que más orgulloso me siento.
Esto no significa que todos tengan que ser constructores. Cuando cualquiera en una empresa puede construir, las personas pueden lanzar cosas que no deberían existir. Nuestro equipo de producto a menudo hace una pregunta: "Si esto llevara un segundo y no costara nada, ¿lo lanzarías?" A veces la respuesta es no. Todavía necesitamos propietarios de módulos que decidan qué se construye, qué no, y qué ven finalmente los usuarios. También necesitamos personas que mantengan la infraestructura como Mono. Cuando construir se vuelve fácil, decidir qué construir importa más.
7. Un compañero de equipo AI dentro del flujo de trabajo de marketing
Una colaboración de marketing pasa por revisión de guion, precios, contratos, aprobaciones, pago, lanzamiento y revisión de resultados. Esos pasos se desarrollan en correo electrónico, herramientas de contratos, sistemas de aprobación, hojas de cálculo y plataformas publicitarias. Gran parte del trabajo solía ser mover información entre ellos, lo que dejaba poco tiempo para el trabajo creativo que requiere criterio.
Empezamos con un pequeño problema: cuando el contenido de un socio o un anuncio se publicaba, a menudo nos enterábamos tarde. Así que hicimos que la AI escribiera un script que detecta cuándo se publica el contenido. Luego quisimos datos de rendimiento. Después una revisión de colaboraciones pasadas. Luego todo el flujo de trabajo interno quedó conectado: cuando se firma un contrato o se aprueba algo, el agent actualiza el estado y notifica a quien tenga a su cargo el siguiente paso.
Manus integró todo esto en un sitio interno. Para las personas, son paneles y un calendario. Para el agent, es un conjunto de herramientas. El agent que usa esas herramientas dentro de nuestro flujo de trabajo es lo que llamamos un compañero de equipo AI. Trabaja únicamente en los canales y sistemas a los que el equipo lo ha conectado, con acceso limitado a este flujo de trabajo.
Esto es lo que hace:
•Gestiona su propia cola. Muchas personas le envían mensajes a la vez, por lo que habla con todos en una sola sesión de "recepción" y entrega tareas a sesiones paralelas. Decide si un mensaje es relevante para él, luego si interrumpir el trabajo actual o esperar. Propuso estas reglas por sí mismo durante el desarrollo, y las revisamos antes de conservarlas.
•Aprende del contexto reenviado. Un cambio de estrategia solía significar una reunión y un informe escrito. Ahora nuestro líder de marketing reenvía la conversación y dice: "Aprende esto".
•Mantiene a la vista los objetivos de largo plazo. En una ocasión, los compañeros de equipo en un hilo de Slack al que había sido añadido no podían recordar en qué estado estaba un proyecto. Sin ser etiquetado, respondió: "B todavía está en pruebas. ¿Deberíamos esperar los resultados de A antes de revisar B?"
•Verifica datos con otros equipos. Después de lanzar el rigging de modelos 3D, le preguntó al equipo de producto qué estaba soportado. Aprendió que el rigging cubre siete categorías, incluyendo peces, serpientes y cuadrúpedos, para que nuestras descripciones se mantuvieran precisas.
Los compañeros de equipo ahora lo incluyen en las revisiones de guion y precios, porque ha leído nuestros registros de colaboraciones pasadas. Las personas siguen tomando la decisión.
El sitio interno también puede mejorar a partir de sus propios usuarios, incluido el agent. Cuando el agent encuentra fricción, presenta una solicitud a través de un endpoint de retroalimentación. Eso abre una tarea de desarrollo en Manus mediante Automatizaciones en Manus 2.0, y un ingeniero revisa el cambio antes de que se publique. Ha estado funcionando aproximadamente una semana. Necesitamos muchos más casos antes de poder confiar en él.
Entonces, ¿qué hacen las personas del equipo? Tres cosas siguen siendo suyas. Toman y asumen la responsabilidad de cada decisión importante. Manejan los casos que el agent no ha visto, y le enseñan qué hacer o a quién preguntar. Y lo reorientan siempre que su análisis apunte a un nuevo enfoque.
8. Interrumpirse menos unos a otros
En todos estos equipos, muchas preguntas ya no requieren interrumpir a alguien.
Pregunta primero al agente. Un compañero construyó un bot de Slack sobre Mono que se ejecuta en una computadora en la nube y responde en el hilo. Quienes más lo usan son los no ingenieros. ¿Cómo funciona esta función? ¿Dónde está esta cadena? ¿Ya se lanzó? Ya no necesitan encontrar primero al responsable.
Abre la sesión en lugar de pedir una actualización de estado. El progreso de un ingeniero solía vivir en sus propios chats de AI, invisible una vez que cerraba sesión. Por eso creamos una función interna que permite a los miembros de un proyecto ver las sesiones de los demás y pedir unirse. Un ingeniero puede construir la mayor parte de una función con el agente, y luego un PM se une a la misma sesión para ajustar el espaciado, los estilos y el texto. Publicar en la sesión de otra persona requiere su aprobación, y aún estamos definiendo los permisos.
(Ejemplo ilustrativo: cómo un ingeniero, un PM y un diseñador trabajan en una sola sesión. No es un cambio real de precios.)
El objetivo no es hablar menos entre nosotros. Es interrumpirnos menos entre nosotros.
Decide solo lo que hay que decidir. Nuestro mayor usuario de AI mantiene una sesión principal con una única tarea: enumerar lo que requiere su decisión, con una recomendación para cada caso. Cuando Slack se vuelve ajetreado, se mantiene al margen y pregunta: "¿Qué necesito decidir ahora mismo?"
Yo hago algo parecido. Tengo más de 20 tareas pendientes al día y, como he compartido públicamente, tengo TDAH. Empezar es la parte más difícil para mí. Ahora cada tarea pendiente va a un proyecto dedicado de Manus que convierte cada una en su propia tarea. Comienza lo que puede. Cuando tiene dudas, me pide contexto y me pregunta qué PM debería hacerse cargo. Luego, usando el acceso que le he dado a mi propio Slack, Gmail y Notion, reúne el contexto y le entrega al PM una solicitud completa en lugar de una nota de una línea. Para mí, el cambio no es solo de eficiencia. Ahora paso mucho menos tiempo al día angustiado por dónde empezar, lo cual es enorme a nivel personal.
9. ¿Vale la pena el costo?
Gastamos mucho en AI y seguimos ese gasto de cerca. No lo usamos para juzgar el desempeño de nadie. Lo usamos para juzgar el gasto en sí: ¿está dando frutos ahora o nos está preparando para después?
Esto es lo que creemos que nos aporta, y hacia dónde esperamos que vaya el costo:
•Compra tiempo y atención. A medida que un equipo crece, la coordinación consume la atención de todos. La AI protege la atención de cada persona y le da una propiedad más plena sobre su trabajo. Y seguimos contratando.
•Usar los mejores modelos es como aprendemos dónde están los límites de la AI. La configuración de verificación y revisión de código descrita en la sección 4 se ejecuta sobre los modelos más potentes que podemos conseguir. El colega que lidera la productividad de desarrolladores lo llama nuestro gasto con mejor relación valor-precio.
•El costo debería bajar a través del producto. Cada vez más de nuestro desarrollo ocurre en Manus Studio, nuestro propio producto, por lo que nuestros datos de uso nos muestran dónde se desperdician tokens. Las correcciones van al producto, así que también deberían hacer a Manus más eficiente para los usuarios. Esperamos que los costos actuales caigan sustancialmente a medida que los modelos se abaraten y eliminemos desperdicios. ¡Esa es una creencia, no una promesa!
10. Lo que aún no funciona
Hay menos interrupciones, pero la atención está más fragmentada. Alguien que antes manejaba cuatro o cinco cosas al día ahora puede impulsar 20 o 30 a la vez. Cada cambio implica recargar contexto. La AI amplía lo que las personas pueden hacer, y también las empuja a hacer más. Una PM me dijo que cada vez que una tarea está en ejecución, no puede resistirse a iniciar otro agente. Hacer más cosas no es el objetivo. Lo tratamos como un problema a resolver, no como un ritmo que celebrar.
La información está más dispersa. Nuestro responsable de producto solía conocer cada cambio y por qué se hizo. Ahora a veces hace una captura de pantalla de un problema y le pregunta a Mono: "¿Quién cambió esto?" Es gracioso, pero la pregunta es real. Cuando todos tienen el poder de cambiar el producto, ¿quién es responsable del conjunto?
Los permisos de compartir necesitan un rediseño. Cuando el trabajo puede compartirse y traspasarse, y los agentes participan en más de nuestras conversaciones, tenemos que decidir qué queda abierto y qué requiere aprobación.
Nuestras soluciones aún son básicas. Por ahora, un agente supervisa a los demás e informa solo lo que está atascado y lo que necesita una decisión humana. Sabemos que esto puede mejorar.
11. Lo que estamos construyendo a continuación
Estos problemas apuntan a trabajo de producto que probablemente otros equipos también necesitarán. No planeamos estas funciones de antemano. Surgieron de problemas con los que nosotros mismos nos topábamos una y otra vez.
•Sesiones como espacios de trabajo compartidos. Una persona plantea un problema, un diseñador propone una solución, un ingeniero la construye y un PM la ejecuta, todo en el mismo lugar.
•Trabajo que se mueve entre dispositivos y personas. Las máquinas locales y en la nube permanecen conectadas, para que el trabajo pueda continuar cuando la gente se ausente.
•Agents que encuentran opciones que la gente no había considerado. Un Agent que trabaja dentro de los sistemas de una empresa, con los permisos adecuados, debería poder sugerir soluciones, no solo ejecutar instrucciones.
Probaremos esto primero en nosotros mismos, y luego lo llevaremos a los usuarios.
12. Lo que la gente hace ahora
El ingeniero con una fila de sesiones de Agent abiertas no es solo una historia sobre eficiencia. Es un cambio en lo que mueve a una organización. Las empresas solían hacer circular la información a través de roles y jerarquías. Lo que una persona podía hacer dependía de cuántas personas y recursos podía aprovechar. Ahora dedicamos un poco de tiempo a dar contexto y herramientas al AI, y más tiempo a emitir juicios y tomar decisiones. Cada vez con más frecuencia, es un Agent quien nos trae un problema. Decidir qué hacer al respecto sigue siendo nuestro trabajo.
Hemos bromeado al respecto: si Manus puede hacer tanto, ¿para qué venir a la oficina? Que los Agents lo resuelvan. Pero las preguntas importantes todavía necesitan que las personas las planteen, las discutan y decidan. Por ejemplo, ¿qué cuenta como un buen producto? O, exagerando un poco: ¿construir un gran producto con ingresos reales que siga empujando los límites del AI, o ir por el margen? El AI no sabe cuál queremos. Nosotros sí. La cultura y la confianza se construyen trabajando juntos, día tras día y en los momentos que importan. Esa es la base sobre la que descansa el trabajo en cada sesión.
Así que, por ahora, esta es nuestra respuesta. En nuestro experimento como organización nativa de AI, el papel de las personas no ha disminuido. Se ha vuelto más enfocado en áreas donde pueden tener el mayor impacto: definir el problema, juzgar la calidad, decidir qué vale la pena hacer, apropiarse del resultado.
Esa es también la razón por la que seguimos contratando. Las habilidades y el juicio de las personas están en el centro de esta forma de trabajar, y eso no cambiará en el corto plazo.
Mientras escribo esto, tengo curiosidad por saber qué diría esta publicación dentro de un año. Cada empresa tiene objetivos, estructuras y culturas diferentes, por lo que puede que no haya una respuesta estándar ni una forma definitiva. Pero para una empresa que construye Agents, descubrir cómo trabajan juntos las personas y el AI no es opcional. Es parte del trabajo. Seguiremos en ello, y seguiremos compartiendo lo que aprendamos.
Una nota sobre las cifras. Las cifras de esta publicación provienen de registros internos. Los tamaños de los equipos y las cifras de entregas de los PM son a finales de octubre. Algunos puntos son estimaciones o la experiencia de una sola persona, más que mediciones.
