Reconstruir 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 impulso final de Manus 2.0, le 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 descifrado lo que 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 hacerse responsable 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 en marcha a la vez.
Estoy orgulloso de lo rápido que nuestro equipo se ha adaptado. También estoy inquieto. ¿Es correcto este ritmo? ¿Qué no hemos notado aún?
En Manus construimos agentes, así que nos regimos por 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 personas y agentes trabajan codo a codo de forma predeterminada. Esta publicación cubre tres equipos — ingeniería, producto y marketing — e incluye lo que no ha funcionado. Es un reporte de un experimento en curso, no una definición de una "organización AI-nativa".
Lo que hemos aprendido hasta ahora:
•No hay punto medio. Agregar AI a las viejas formas de trabajar a veces añadía ruido. Las cosas cambiaron solo cuando el ciclo se cerró.
•Los agentes necesitan el panorama completo. Un mejor contexto hizo más por nosotros que mejores prompts.
•La confianza proviene de las pruebas y del contexto, no solo de la calidad del modelo.
•La autonomía necesita una meta final. Los agentes pueden operar por su cuenta solo cuando el éxito puede ser verificado. En todos los demás casos, una persona decide.
•El cuello de botella se desplaza. Cuando la ingeniería se volvió más rápida, decidir qué construir se convirtió en la limitación.
•El rol de las personas no ha disminuido. Se ha vuelto más enfocado en cosas de mayor impacto.
1. No hay punto medio
Antes de 2026, hacíamos lo que hacían la mayoría de las empresas: añadíamos AI a la forma en que ya trabajábamos. Esto significaba que soporte marcaba 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 no muchas de las piezas estaban conectadas entre sí. Hasta que el ciclo realmente se cerró, simplemente estábamos trabajando de la misma manera de siempre pero con mucha AI hablando una sobre la otra.
Hay una frase a la que volvemos con frecuencia: la ingeniería de software es la programación integrada a lo largo del tiempo. Escribir código es fácil de medir; mantener un producto complejo saludable durante años no lo es. Un alto porcentaje de código escrito por AI puede significar un progreso real, o puede significar acumular desechos que alguien tendrá que limpiar más tarde.
La prueba que nos importa es más difícil. Manus es un producto complejo que ha estado en funcionamiento por más de un año. ¿Puede seguir mejorando bajo nuevas formas de trabajo sin colapsar, mientras cada persona logra hacer más? Hasta ahora, la respuesta es sí.
2. Dale al agente el panorama completo
Como la mayoría de las empresas de tecnología, perdíamos más tiempo en las transferencias. 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 a lo largo de todo el stack, ¿podría una sola persona hacerse cargo de una solicitud de principio a fin? El obstáculo era el contexto. Nuestro código vivía en repositorios separados, por lo 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 construyendo un producto con la menor intervención humana posible y casi sin código escrito a mano. El método que desarrollamos a lo largo del 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 incorpora lo que necesita. También mantenemos una biblioteca de registros de decisiones de arquitectura, para que cada sesión del Agent comience con el razonamiento detrás de 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 pasos, y cada paso resolvió el cuello de botella que expuso el anterior:
1.Ver el sistema completo. Añadimos el contexto de negocio que ningún repositorio por sí solo contiene, y usamos Git worktrees para el trabajo en paralelo.
2.Verificar localmente. Un push al entorno de pruebas antes tomaba de 5 a 10 minutos. Ahora el stack completo de Manus se ejecuta en una laptop, y las verificaciones toman segundos.
3.Depurar problemas en producción. Con permisos acotados, Mono puede leer los logs, la configuración y los reportes 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 personas siguen tomando las decisiones de aprobación.
5.Probar de principio a fin. Cuando la verificación se convirtió en la parte lenta, Mono comenzó a ejecutar flujos reales de usuarios 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 de él, 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 ops 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 el Agent también, pero la aprobación sigue estando en manos de personas con derechos de lanzamiento. Me encanta cómo trabaja el equipo: una persona resolvió su propia frustración, lo que llevó a que toda la empresa se volviera un poco más rápida.
El equipo ahora asume que una sola persona puede entregar una solicitud en cada plataforma. Nuestro equipo móvil ha sido de siete personas todo este tiempo. Mantienen cuatro apps en dos productos y van al mismo ritmo que 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 por qué existimos, y nuestra organización es horizontal. Una herramienta llega tan lejos como la organización le permita.
3. Cerrar el ciclo: desde el reporte de un bug de un usuario hasta una corrección verificada
Mono permitió que cualquiera trabajara en cualquier parte del producto. Esa era la mitad. La otra mitad era permitir 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 arreglarlo.
Para nosotros, un Agent interno ahora investiga el reporte primero 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 arreglarlo y se lo pasa 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 hace el trabajo, uno lo verifica. La persona en el medio toma las decisiones. Una proporción creciente de nuestro trabajo de ingeniería ahora comienza de esta manera, con un Agent llevándole un problema a una persona.
Este ciclo tiene límites claros. El Agent que lee los reportes de usuarios no puede cambiar código. Solo puede investigar y reportarnos. Los cambios vienen del propio Agent del ingeniero, después de que el ingeniero decide. Nada se despliega 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 omitir 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 programació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 sido parte de las discusiones aguas arriba y aguas abajo, por lo que saben qué significa "correcto" para el negocio. Código correcto no es lo mismo que producto correcto.
Abordamos ambos puntos:
•Dejar que los agentes participen en la discusión. El agente de cada ingeniero ahora está en los hilos de Slack a los que ha sido añadido, y sigue el contexto. Cuando alguien finalmente dice "Adelante", el agente ya sabe qué decidió el equipo y por qué.
•Dejar que los agentes prueben de extremo a extremo. Trabajando con nuestro equipo de backend, les 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 creció la cobertura de pruebas, creció nuestra confianza con ella.
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 fusionarlo en nuestra rama principal sin la aprobación explícita de una persona. Las personas siguen decidiendo qué se construye y quién puede lanzarlo.
5. La autonomía necesita una meta final
La confianza tiene límites, y lo aprendimos a la mala.
En un momento dado, todos estaban emocionados con los bucles de agentes totalmente autónomos, así que probamos uno. Un agente recopiló comentarios de nuestros canales internos de feedback y comenzó un proyecto para cada elemento. Un compañero lo dejó correr durante un fin de semana. El lunes por la mañana, más de 200 elementos estaban esperando su decisión.
¿Por qué no dejar que el agente también tome esas decisiones? Los bucles autónomos funcionan cuando el sistema puede verificar si se ha cumplido el objetivo. Las pruebas pasan o fallan; una página carga o no. La mayoría del trabajo real no tiene tal verificación. Una persona debe 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 genera. Segundo, si nadie decide si algo debería hacerse, nadie es dueño del resultado. El bucle de corrección de errores en 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 todavía 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 muchos traspasos, y las prioridades se desvían un poco en cada uno. 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 restricción.
En Manus, nuestra primera solución fue pedirle a algunos ingenieros que se convirtieran en "constructores" que son dueños de un problema desde el descubrimiento hasta el lanzamiento. Pocas personas tenían tanto el juicio técnico como el de producto. Luego dejamos que los PMs cambiaran el código. Eso también se estancó. Los traspasos seguían ahí, y sin los instintos de un ingeniero, los PMs 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 las llamadas al modelo o el costo necesita la aprobación del propietario 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, para que un PM pueda señalar el momento exacto en que algo falla.
Así se ve esto en la práctica. Una PM que trabajaba en speech-to-text hizo que Manus evaluara más de 10 modelos, luego eligió uno. Extrajo el código del frontend a través de Mono, construyó una demo en nuestro sistema de diseño, e hizo que Manus renderizara cada escenario de usuario como una imagen para revisarla. Convirtió la demo en un video. El plan estaba lo suficientemente claro como para que ella misma construyera la función, incluyendo la UI web y de escritorio.
Las personas tomaron tres decisiones en el 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. Antes, la AI hacía el 70-80 % de una tarea y las personas completaban el resto. Ahora las personas establecen las reglas, supervisan varios Agents, verifican métodos y resultados en puntos clave, intervienen cuando es necesario y asumen la responsabilidad del resultado.
Algunos PM 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 límite 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, aproximadamente la mitad de nuestros PM lanzan funciones por su cuenta, y todos los PM han contribuido con 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 estoy más orgulloso.
Esto no significa que todos tengan que ser constructores. Cuando cualquier persona en una empresa puede construir, es posible que se lancen cosas que no deberían existir. Nuestro equipo de producto suele hacer una pregunta: "Si esto tomara un segundo y no costara nada, ¿lo lanzarías?". A veces la respuesta es no. Todavía necesitamos responsables de módulos que decidan qué se construye, qué no y qué ven finalmente los usuarios. También necesitamos personas que mantengan infraestructuras 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 del guion, precios, contratos, aprobaciones, pago, lanzamiento y revisión de resultados. Esos pasos viven en correos electrónicos, herramientas de contratos, sistemas de aprobación, hojas de cálculo y plataformas publicitarias. Gran parte del trabajo solía consistir en mover información entre ellos, lo que dejaba poco tiempo para el trabajo creativo que requiere criterio.
Comenzamos con un pequeño problema: cuando se publicaba contenido de un socio o un anuncio, a menudo nos enterábamos tarde. Así que hicimos que la AI escribiera un script que detecta cuándo se publica contenido. Luego quisimos datos de rendimiento. Luego una revisión de colaboraciones pasadas. Luego todo el flujo de trabajo interno se conectó: cuando se firma un contrato o se aprueba algo, el Agent actualiza el estado y notifica a quien sea responsable del siguiente paso.
Manus construyó 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. Funciona solo 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 sesión de "recepción" y pasa las tareas a sesiones paralelas. Decide si un mensaje es relevante para él, y luego si interrumpe el trabajo actual o espera. Él mismo propuso estas reglas durante el desarrollo, y las revisamos antes de mantenerlas.
•Aprende del contexto que se le reenvía. Un cambio de estrategia solía implicar una reunión y un informe escrito. Ahora nuestro líder de marketing reenvía la discusión y dice: "Aprende esto".
•Mantiene a la vista los objetivos de largo plazo. En una ocasión, los compañeros en un hilo de Slack al que había sido añadido no recordaban en qué punto estaba un proyecto. Sin ser etiquetado, respondió: "B todavía está en pruebas. ¿Deberíamos esperar los resultados de A antes de mirar B?".
•Verifica hechos con otros equipos. Después de que lanzamos 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, por lo que nuestras descripciones se mantuvieron 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 gracias a 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 lance. Ha funcionado durante aproximadamente una semana. Necesitamos muchos más casos antes de depender de él.
Entonces, ¿qué hacen las personas del equipo? Tres cosas siguen en sus manos. Toman y son responsables de cada decisión importante. Manejan casos que el Agent no ha visto, y le enseñan qué hacer o a quién preguntar. Y lo redirigen cada vez que su análisis apunta hacia un nuevo ángulo.
8. Interrumpirse menos entre sí
En todos estos equipos, muchas preguntas ya no requieren interrumpir a alguien.
Pregúntale primero al agente. Un compañero construyó un bot de Slack en Mono que corre en una computadora en la nube y responde en el hilo. Los no ingenieros son quienes más lo usan. ¿Cómo funciona esta función? ¿Dónde está este string? ¿Esto 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. Así que construimos 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 todavía estamos resolviendo 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.
Decide solo lo que necesita decidirse. Nuestro mayor usuario de AI mantiene una sesión principal con un único trabajo: enumerar lo que necesita su decisión, con una recomendación para cada caso. Cuando Slack se pone intenso, él se mantiene al margen y pregunta: "¿Qué necesito decidir ahora mismo?"
Yo hago algo similar. Tengo más de 20 pendientes al día y, como he compartido públicamente, tengo TDAH. Empezar es la parte más difícil para mí. Ahora cada pendiente va a un Manus Project dedicado que convierte cada uno en su propia tarea. Comienza lo que puede. Cuando no está seguro, me pide contexto y 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 sobre eficiencia. Ahora paso mucho menos tiempo del día ansioso 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:
•Nos aporta 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 les da una propiedad más completa de su trabajo. Y seguimos contratando.
•Usar los mejores modelos es cómo 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 funciona con los modelos más potentes que podemos conseguir. El colega que lidera productividad de desarrolladores lo llama nuestro gasto con mejor relación valor-costo.
•El costo debería bajar a través del producto. Más de nuestro desarrollo ahora ocurre en Manus Studio, nuestro propio producto, por lo que nuestros datos de uso nos muestran dónde se desperdician tokens. Los arreglos entran al producto, así que también deberían hacer que Manus sea más eficiente para los usuarios. Esperamos que los costos de hoy caigan sustancialmente a medida que los modelos se abaraten y eliminemos el desperdicio. ¡Eso es una creencia, no una promesa!
10. Qué aún no funciona
Hay menos interrupciones, pero la atención está más fragmentada. Alguien que solía manejar cuatro o cinco cosas al día ahora puede estar impulsando 20 o 30 a la vez. Cada cambio implica recargar el contexto. La AI expande 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. Estamos tratando esto como un problema a resolver, no como un ritmo que celebrar.
La información está más dispersa. Nuestro director de producto solía conocer cada cambio y por qué se hizo. Ahora a veces toma 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 están empoderados para cambiar el producto, ¿quién es responsable del conjunto?
Los permisos para 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é es abierto y qué necesita aprobación.
Nuestras soluciones aún son básicas. Por ahora, un agente supervisa a los demás y solo reporta lo que está atascado y lo que necesita una decisión humana. Sabemos que esto puede mejorar.
11. Qué estamos construyendo a continuación
Estos problemas apuntan a trabajo de producto que otros equipos probablemente también necesitarán. No planificamos estas funciones de antemano. Surgieron de problemas con los que nosotros mismos nos topábamos constantemente.
•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 las personas se ausentan.
•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.
Primero las probaremos con nosotros mismos y luego las 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 aquello sobre lo que opera una organización. Las empresas solían mover 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 pudiera aprovechar. Ahora pasamos un poco de tiempo dándole contexto y herramientas al AI, y más tiempo haciendo juicios y tomando decisiones. Cada vez con más frecuencia, es un agent quien nos trae un problema. Decidir qué hacer al respecto sigue siendo nuestra tarea.
Hemos bromeado al respecto: si Manus puede hacer tanto, ¿para qué venir a la oficina? Que los agents lo resuelvan. Pero las preguntas importantes aún necesitan que las personas las planteen, las debatan y las 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 apostar por el margen? El AI no sabe cuál queremos. Nosotros sí. La cultura y la confianza surgen de resolver las cosas 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 las áreas donde pueden tener el mayor impacto: definir el problema, juzgar la calidad, decidir qué vale la pena hacer y ser responsables del resultado.
Por eso también seguimos contratando. Las habilidades y el juicio de las personas están en el centro de esta forma de trabajar, y eso no va a cambiar pronto.
Mientras escribo esto, tengo curiosidad por saber qué diría este post 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, descifrar cómo las personas y el AI trabajan juntos no es opcional. Es parte del trabajo. Seguiremos con ello y seguiremos compartiendo lo que aprendamos.
Una nota sobre las cifras. Las cifras de este post 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 en lugar de mediciones.
