Manus mit Manus neu aufbauen: Was sich verändert hat, was kaputt ging und wie wir jetzt arbeiten
Von Tao Zhang, Mitgründer und Chief Product Officer, Manus
Ende September, während des Endspurts bei Manus 2.0, schickte ich einem unserer Ingenieure ein paar Feature-Anfragen und Bug-Reports über Slack. Später schaute ich vorbei, um zu sehen, wie er vorankam. Auf seinem Bildschirm war eine Reihe offener Agent-Sitzungen zu sehen, einige in Manus, einige in Codex. Ich klickte eine davon an. Der Prompt war meine Slack-Nachricht, Wort für Wort eingefügt.
Vor einem Jahr hätte er meine Nachricht gelesen, herausgefunden, was ich meinte, und dann den Code geschrieben. Jetzt liest ein Agent die Anfrage, findet den relevanten Code und schlägt eine Änderung vor. Die Aufgabe des Ingenieurs besteht darin, die Arbeit zu lenken, zu überprüfen und das Ergebnis zu verantworten. Die meiste Zeit, während eine Anfrage läuft, wartet sie nicht auf ihn. Heute ist es bei uns üblich, dass ein Ingenieur 10 bis 20 Anfragen gleichzeitig in Bewegung hat.
Ich bin stolz darauf, wie schnell sich unser Team angepasst hat. Ich bin auch beunruhigt. Ist dieses Tempo richtig? Was haben wir noch nicht bemerkt?
Wir bauen bei Manus Agents, also halten wir uns an zwei Regeln. Wir verwenden unser eigenes Produkt für echte Arbeit. Und wir suchen weiter nach den Stellen, an denen AI nicht mehr funktioniert.
Ich möchte dokumentieren, was in einem Unternehmen passiert, wenn Menschen und Agents standardmäßig Seite an Seite arbeiten. Dieser Beitrag behandelt drei Teams – Engineering, Produkt und Marketing – und schließt auch das ein, was nicht funktioniert hat. Es ist der Bericht über ein laufendes Experiment, keine Definition einer „AI-nativen Organisation".
Was wir bisher gelernt haben:
•Es gibt keinen halben Weg. AI zu alten Arbeitsweisen hinzuzufügen hat manchmal nur Rauschen erzeugt. Dinge änderten sich erst, als sich der Kreislauf schloss.
•Agents brauchen das Gesamtbild. Besserer Kontext hat uns mehr gebracht als bessere Prompts.
•Vertrauen entsteht durch Tests und Kontext, nicht allein durch Modellqualität.
•Autonomie braucht eine Ziellinie. Agents können nur dann eigenständig laufen, wenn sich der Erfolg überprüfen lässt. Überall sonst entscheidet ein Mensch.
•Der Engpass verschiebt sich. Als Engineering schneller wurde, wurde die Entscheidung, was gebaut werden soll, zum Engpass.
•Die Rolle der Menschen hat nicht abgenommen. Sie konzentriert sich stärker auf Dinge mit größerer Wirkung.
1. Es gibt keinen halben Weg
Vor 2026 taten wir das, was die meisten Unternehmen taten: Wir fügten AI zu unserer bestehenden Arbeitsweise hinzu. Das bedeutete, Support markierte Probleme mit einer AI-Zusammenfassung, Ingenieure nutzten Coding-Assistenten, und Bots posteten Analysen in Channels. Jedes Teilstück war für sich nützlich, aber nur wenige der Teile waren miteinander verbunden. Bis sich der Kreislauf tatsächlich schloss, arbeiteten wir im Grunde auf die alte Art weiter – nur mit viel AI, die sich gegenseitig ins Wort fiel.
Es gibt einen Satz, auf den wir oft zurückkommen: Softwareentwicklung ist Programmierung, integriert über die Zeit. Code zu schreiben ist leicht zu messen; ein komplexes Produkt über Jahre gesund zu halten, ist es nicht. Ein hoher Anteil an AI-geschriebenem Code kann echten Fortschritt bedeuten – oder er kann bedeuten, dass sich Schrott anhäuft, den später jemand aufräumen muss.
Der Test, der uns wichtig ist, ist härter. Manus ist ein komplexes Produkt, das seit mehr als einem Jahr live ist. Kann es sich unter neuen Arbeitsweisen weiter verbessern, ohne zusammenzubrechen, während jede Person mehr erledigt? Bisher lautet die Antwort ja.
2. Gib dem Agent das Gesamtbild
Wie die meisten Tech-Unternehmen verloren wir die meiste Zeit bei Übergaben. Ein Frontend- und ein Backend-Ingenieur interpretierten jeweils eine Anforderung, einigten sich auf eine Schnittstelle und verbrachten dann Tage damit, die Unstimmigkeiten zu beheben. Zwei Personen verstehen eine Anforderung selten auf dieselbe Weise.
Wenn AI Code über den gesamten Stack hinweg schreiben kann, könnte dann eine Person eine Anfrage von Anfang bis Ende verantworten? Das Hindernis war der Kontext. Unser Code lag in getrennten Repositories, sodass kein Agent das gesamte System auf einmal sehen konnte.
Unsere Antwort darauf begann mit einem internen Experiment. Wir wollten sehen, wie weit AI beim Aufbau eines Produkts mit möglichst wenig menschlichem Input und fast ohne handgeschriebenen Code gehen kann. Die Methode, die wir dabei entwickelt haben, wurde zum internen Tool, das wir heute Manus-mono oder Mono nennen.
Mono führt unsere Repositories nicht zusammen. Es ist ein einziger Einstiegspunkt plus ein für den Agent geschriebenes Handbuch: was jedes Repository tut, wie sie zusammenpassen und wie wir arbeiten. Der Agent zieht sich alles heran, was er braucht. Außerdem pflegen wir eine Bibliothek von Architektur-Entscheidungsprotokollen, sodass jede Agent-Sitzung mit der Begründung vergangener Entscheidungen beginnt, nicht nur mit dem Code. Wenn jemand mit einem Agent arbeitet, hat dieser Agent den Kontext aller, die vorher da waren.
Mono wuchs schrittweise, und jeder Schritt behob den Engpass, den der vorherige offenbart hatte:
1.Das gesamte System sehen. Wir haben den Geschäftskontext hinzugefügt, den kein einzelnes Repository enthält, und Git-Worktrees für parallele Arbeit verwendet.
2.Lokal verifizieren. Ein Push in die Testumgebung dauerte früher 5 bis 10 Minuten. Jetzt läuft der komplette Manus-Stack auf einem Laptop, und Prüfungen dauern Sekunden.
3.Produktionsprobleme debuggen. Mit eingegrenzten Berechtigungen kann Mono die Logs, Konfigurationen und Fehlerberichte lesen, die es benötigt, um Bugs in der Produktion zu diagnostizieren.
4.Releases durchgängig durchführen. Mono übernimmt jetzt die Release-Schritte, bei denen die Arbeit früher ins Stocken geriet. Freigabeentscheidungen treffen weiterhin Menschen.
5.Durchgängig testen. Als die Verifizierung zum langsamen Teil wurde, begann Mono, echte Benutzerabläufe mit Testkonten im Browser und in einem mobilen Simulator auszuführen.
(Wie Mono funktioniert und wie es sich entwickelt hat. Erstellt von einem Teamkollegen mit Manus.)
Manche fragen, ob Mono ein Code-Wiki sei. Dokumentation ist ein Teil davon, aber der Rest ist alles rund um den Code: wie wir testen, wie wir releasen, was wir entscheiden und warum, und was der Agent anfassen darf und was nicht.
Mit der Zeit ist Mono zu einer gemeinsamen Wissensbasis geworden, die besser wird, je mehr Leute dazu beitragen. Zum Beispiel hatte unser Ops-Ingenieur es satt, immer bei Releases um Hilfe gebeten zu werden, also schrieb er den Release-Prozess in Mono. Jetzt kann jeder einen Release durchführen, und auch der Agent kann es, aber die Freigabe liegt weiterhin bei Personen mit Release-Rechten. Ich liebe die Art, wie das Team arbeitet: Eine Person hat ihren eigenen Frust behoben, und dadurch wurde das ganze Unternehmen ein bisschen schneller.
Das Team geht jetzt davon aus, dass eine Person eine Anfrage auf jeder Plattform ausliefern kann. Unser Mobile-Team besteht die ganze Zeit über aus sieben Personen. Sie betreuen vier Apps über zwei Produkte hinweg und halten mit Web Schritt.
Mono hat sich im Unternehmen ohne Top-down-Vorgabe verbreitet. Ich glaube, die Kultur erklärt das genauso sehr wie das Tool. Die Grenzen von AI auszutesten ist Teil unserer Daseinsberechtigung, und unsere Organisation ist flach. Ein Tool kommt nur so weit, wie die Organisation es zulässt.
3. Den Kreis schließen: vom Fehlerbericht eines Nutzers bis zur verifizierten Behebung
Mono ermöglichte es jedem, an jedem Teil des Produkts zu arbeiten. Das war die eine Hälfte. Die andere Hälfte bestand darin, Agents dazu zu bringen, Probleme selbst zu finden.
Bei den meisten Internetunternehmen durchläuft der Fehlerbericht eines Nutzers Support, Produkt und Triage, bevor er einen Ingenieur erreicht, der ihn beheben kann.
Bei uns untersucht nun ein interner Agent den Bericht zuerst und verfolgt das Problem bis zu der Änderung zurück, die es verursacht hat. Dann postet er in Slack und markiert den Ingenieur, dem diese Änderung gehört. Der Ingenieur entscheidet, ob es seine Aufgabe ist, das Problem zu beheben, und übergibt es seinem eigenen Agent. Ein separater Agent prüft die Behebung, indem er die relevanten Tests und Abläufe durchführt.
Drei Agents, drei Rollen: einer triagiert, einer erledigt die Arbeit, einer prüft sie. Die Person in der Mitte trifft die Entscheidungen. Ein wachsender Anteil unserer Engineering-Arbeit beginnt jetzt auf diese Weise: Ein Agent bringt einer Person ein Problem.
Dieser Kreislauf hat klare Grenzen. Der Agent, der Nutzerberichte liest, kann keinen Code ändern. Er kann nur untersuchen und uns Bericht erstatten. Änderungen kommen vom eigenen Agent des Ingenieurs, nachdem der Ingenieur entschieden hat. Nichts wird ohne Freigabe einer Person mit Release-Rechten ausgeliefert.
4. Wie wir gelernt haben, Agent-geschriebenem Code zu vertrauen
Lange Zeit musste jede Änderung, die in unseren Hauptbranch einfloss, von einem von zwei Senior-Ingenieuren abgezeichnet werden. Wir vertrauten der AI nicht genug, um diesen Schritt zu überspringen. Als Agents mehr Code produzierten, wurde dieser Review-Schritt zum Engpass.
Was die reine Programmierfähigkeit angeht, waren die Modelle bereits stark. Wir erkannten, dass der Unterschied auf zwei Dinge zurückzuführen war. Erstens: Menschen wissen, wie sie ihre Arbeit testen. Zweitens: Menschen waren Teil der vorgelagerten und nachgelagerten Diskussionen und wissen daher, was „richtig" für das Geschäft bedeutet. Korrekter Code ist nicht dasselbe wie das korrekte Produkt.
Wir haben beides angegangen:
•Agents an der Diskussion teilnehmen lassen. Der Agent jedes Ingenieurs sitzt nun in den Slack-Threads, zu denen er hinzugefügt wurde, und folgt dem Kontext. Wenn jemand schließlich „Los" sagt, weiß der Agent bereits, was das Team entschieden hat und warum.
•Agents End-to-End testen lassen. In Zusammenarbeit mit unserem Backend-Team haben wir Agents die Möglichkeit gegeben, nach jeder Änderung echte Abläufe und Regressionstests in Manus auszuführen. Mit wachsender Testabdeckung wuchs auch unser Vertrauen.
Heute durchläuft jede Änderung diese Verifizierung und einen Code-Review-Bot, der das stärkste verfügbare Modell einsetzt, mit zusätzlichen Regeln für sensible Bereiche wie Zahlungen. Der Bot hat die Warteschlange ersetzt, nicht die menschliche Entscheidung. Ein Agent kann einen Pull Request öffnen, aber er kann ohne ausdrückliche Genehmigung einer Person nicht in unseren Hauptbranch mergen. Menschen entscheiden weiterhin, was gebaut wird und wer veröffentlichen darf.
5. Autonomie braucht ein Endziel
Vertrauen hat Grenzen, und das haben wir auf die harte Tour herausgefunden.
Zu einem bestimmten Zeitpunkt waren alle begeistert von vollständig autonomen Agent-Loops, also haben wir einen ausprobiert. Ein Agent sammelte Feedback aus unseren internen Feedback-Kanälen und startete für jeden Punkt ein Projekt. Ein Teamkollege ließ ihn über ein Wochenende laufen. Am Montagmorgen warteten mehr als 200 Punkte auf seine Entscheidung.
Warum nicht den Agent auch diese Entscheidungen treffen lassen? Autonome Loops funktionieren, wenn das System überprüfen kann, ob das Ziel erreicht wurde. Tests bestehen oder scheitern; eine Seite lädt oder nicht. Die meiste echte Arbeit hat keine solche Prüfung. Eine Person muss beurteilen, ob es erledigt ist und ob es überhaupt wert war, getan zu werden.
Wir haben aus diesem Wochenende zwei Lektionen gelernt. Erstens: Menschen können Entscheidungen nicht so schnell treffen, wie ein ungeprüfter Loop sie erzeugt. Zweitens: Wenn niemand entscheidet, ob etwas getan werden soll, ist niemand für das Ergebnis verantwortlich. Der Bugfixing-Loop in Abschnitt 3 funktioniert, weil Tests den Erfolg definieren. Produktentscheidungen haben keine Tests, daher beginnt jede Produktänderung bei Manus weiterhin damit, dass eine Person entscheidet, ob es sich lohnt, sie durchzuführen.
6. Als das Engineering schneller wurde, wurde das Produkt zum Engpass
Ein traditioneller Produktprozess hat viele Übergaben, und bei jeder davon verschieben sich die Prioritäten ein wenig. Als Coding-Agents die Ingenieure schneller machten, trat ein neues Problem auf: Es gab nicht genügend Product Manager, um gute Anforderungen zu schreiben. Zum ersten Mal war das Engineering nicht die Einschränkung.
Bei Manus bestand unsere erste Lösung darin, einige Ingenieure zu bitten, „Builder" zu werden, die ein Problem von der Entdeckung bis zum Launch verantworten. Nur wenige hatten sowohl das technische als auch das Produkturteilsvermögen. Als Nächstes ließen wir PMs Code ändern. Auch das stockte. Die Übergaben waren immer noch da, und ohne die Instinkte eines Ingenieurs konnten PMs Texte und Interaktionen ändern, aber nicht die zugrunde liegende Logik.
Mono hat beide Probleme gelöst, weil es die Regeln mitträgt:
•Jede Änderung, die Modellaufrufe oder Kosten betrifft, benötigt die Genehmigung des Verantwortlichen, bevor Code geschrieben wird.
•Jede Änderung durchläuft denselben Review- und Testprozess wie die Änderung eines Ingenieurs.
•Mono kann Anmeldung und Zahlung mit Testkonten durchlaufen und jeden Schritt aufzeichnen, sodass ein PM genau auf den Moment zeigen kann, in dem etwas kaputtgeht.
So sieht das in der Praxis aus. Eine PM, die an Speech-to-Text arbeitete, ließ Manus mehr als 10 Modelle benchmarken und wählte dann eines aus. Sie zog den Frontend-Code über Mono, baute einen Demo in unserem Design-System und ließ Manus jedes Nutzerszenario als Bild rendern, damit sie es überprüfen konnte. Sie verwandelte die Demo in ein Video. Der Plan war klar genug, dass sie das Feature selbst gebaut hat, einschließlich der Web- und Desktop-UI.
Menschen haben unterwegs drei Entscheidungen getroffen. Sie wählte das Modell. Produkt und Design prüften die Demo. Ein Ingenieur mit Release-Rechten überprüfte den Code. Vor einem Jahr wäre nichts davon möglich gewesen.
Wir beschreiben dies als Übergang von Human in the Loop zu Human on the Loop. Früher erledigte die KI 70–80 % einer Aufgabe und Menschen füllten den Rest aus. Jetzt legen Menschen die Regeln fest, beaufsichtigen mehrere Agents, prüfen Methoden und Ergebnisse an wichtigen Punkten, greifen bei Bedarf ein und tragen die Verantwortung für das Ergebnis.
Einige PMs übergeben jetzt ein kurzes Video statt einer schriftlichen Spezifikation oder Mockups. In wenigen Minuten zeigt es den Anwendungsfall, jeden Bildschirm, was jeder Klick bewirkt, wie Randfälle sich verhalten und wie alles im Hintergrund funktioniert. Für uns einigen sich Design, Engineering und QA schneller darauf, was "fertig" bedeutet, und der PM erklärt es nur einmal.
(Produktanforderungsvideo für Spracheingabe)
Heute veröffentlicht etwa die Hälfte unserer PMs Features eigenständig, und jeder PM hat Code committet. Auch Designer haben damit begonnen. Ein PM hat den Großteil der Manus Studio-Oberfläche in Manus 2.0 geschrieben. Ein anderer hat den Video Editor geschrieben. Hinter jedem von ihnen steht jemand, der monatelang über das hinausgegangen ist, was seine Rolle früher umfasste. Darauf bin ich am stolzesten.
Das heißt nicht, dass jeder ein Entwickler sein muss. Wenn jeder in einem Unternehmen bauen kann, können Dinge veröffentlicht werden, die es nicht geben sollte. Unser Produktteam stellt oft eine Frage: "Wenn das eine Sekunde dauern und nichts kosten würde, würdest du es veröffentlichen?" Manchmal lautet die Antwort nein. Wir brauchen weiterhin Modulverantwortliche, die entscheiden, was gebaut wird, was nicht und was Nutzer am Ende sehen. Wir brauchen auch Leute, die Infrastruktur wie Mono pflegen. Wenn das Bauen einfach wird, wird es wichtiger zu entscheiden, was gebaut werden soll.
7. Ein AI-Teamkollege im Marketing-Workflow
Eine Marketing-Partnerschaft durchläuft Skript-Review, Preisgestaltung, Verträge, Freigaben, Zahlung, Launch und Ergebnis-Review. Diese Schritte finden in E-Mails, Vertragstools, Freigabesystemen, Tabellenkalkulationen und Werbeplattformen statt. Ein Großteil der Arbeit bestand früher darin, Informationen zwischen ihnen zu verschieben, wodurch wenig Zeit für die kreative Arbeit blieb, die Urteilsvermögen erfordert.
Wir begannen mit einem kleinen Problem: Wenn Partner-Content oder eine Anzeige live ging, erfuhren wir oft spät davon. Also ließen wir die AI ein Skript schreiben, das erkennt, wann Content veröffentlicht wird. Dann wollten wir Performance-Daten. Dann einen Review vergangener Partnerschaften. Dann war der gesamte interne Workflow verbunden: Wenn ein Vertrag unterzeichnet oder eine Freigabe erteilt wird, aktualisiert der Agent den Status und benachrichtigt denjenigen, der für den nächsten Schritt verantwortlich ist.
Manus hat das alles in eine interne Website eingebaut. Für Menschen sind es Dashboards und ein Kalender. Für den Agent ist es eine Reihe von Tools. Der Agent, der diese Tools in unserem Workflow nutzt, ist das, was wir einen AI-Teamkollegen nennen. Er arbeitet nur in den Kanälen und Systemen, mit denen das Team ihn verbunden hat, mit auf diesen Workflow beschränktem Zugriff.
Hier ist, was er tut:
•Er verwaltet seine eigene Warteschlange. Viele Leute schreiben ihm gleichzeitig, also spricht er mit allen in einer "Empfangs"-Sitzung und übergibt Aufgaben an parallele Sitzungen. Er entscheidet, ob eine Nachricht für ihn relevant ist, und dann, ob er die aktuelle Arbeit unterbrechen oder warten soll. Er hat diese Regeln während der Entwicklung selbst vorgeschlagen, und wir haben sie überprüft, bevor wir sie beibehalten haben.
•Er lernt aus weitergeleitetem Kontext. Eine Strategieänderung bedeutete früher ein Meeting und ein schriftliches Briefing. Jetzt leitet unser Marketing-Lead die Diskussion weiter und sagt: "Lerne das."
•Er behält langfristige Ziele im Blick. Einmal konnten sich Teamkollegen in einem Slack-Thread, zu dem er hinzugefügt worden war, nicht erinnern, wo ein Projekt stand. Ohne markiert zu sein, antwortete er: "B ist noch im Test. Sollen wir auf die Ergebnisse von A warten, bevor wir uns B anschauen?"
•Er überprüft Fakten mit anderen Teams. Nachdem wir 3D-Modell-Rigging eingeführt hatten, fragte er das Produktteam, was unterstützt wird. Er erfuhr, dass Rigging sieben Kategorien abdeckt, darunter Fische, Schlangen und Vierbeiner, sodass unsere Beschreibungen korrekt blieben.
Teamkollegen beziehen ihn jetzt in Skript- und Preis-Reviews ein, weil er unsere früheren Partnerschaftsunterlagen gelesen hat. Die Menschen treffen weiterhin die Entscheidung.
Die interne Website kann sich auch durch ihre eigenen Nutzer verbessern, einschließlich des Agents. Wenn der Agent auf Reibung stößt, reicht er eine Anfrage über einen Feedback-Endpunkt ein. Das öffnet eine Entwicklungsaufgabe in Manus über Automations in Manus 2.0, und ein Ingenieur überprüft die Änderung, bevor sie veröffentlicht wird. Es läuft seit etwa einer Woche. Wir brauchen viele weitere Fälle, bevor wir uns darauf verlassen.
Was tun also die Menschen im Team? Drei Dinge bleiben bei ihnen. Sie treffen und tragen jede wichtige Entscheidung. Sie bearbeiten Fälle, die der Agent noch nicht gesehen hat, und bringen ihm bei, was zu tun ist oder wen er fragen soll. Und sie lenken ihn um, wann immer seine Analyse auf einen neuen Blickwinkel hinweist.
8. Sich gegenseitig weniger unterbrechen
In all diesen Teams müssen viele Fragen niemanden mehr unterbrechen.
Frag zuerst den Agent. Ein Teamkollege hat auf Mono einen Slack-Bot gebaut, der auf einem Cloud-Computer läuft und im Thread antwortet. Vor allem Nicht-Entwickler nutzen ihn. Wie funktioniert dieses Feature? Wo liegt dieser String? Ist das schon ausgeliefert? Sie müssen nicht mehr erst den Verantwortlichen finden.
Öffne die Session, statt nach einem Status-Update zu fragen. Der Fortschritt eines Entwicklers lag früher in seinen eigenen AI-Chats und war unsichtbar, sobald er sich abmeldete. Deshalb haben wir ein internes Feature gebaut, mit dem Mitglieder eines Projekts die Sessions der anderen sehen und um Beitritt bitten können. Ein Entwickler baut vielleicht den Großteil eines Features mit dem Agent, und dann steigt ein PM in dieselbe Session ein, um Abstände, Styles und Texte anzupassen. In einer fremden Session etwas zu posten, erfordert deren Zustimmung, und wir arbeiten noch an den Berechtigungen.
(Illustratives Beispiel: wie ein Entwickler, ein PM und ein Designer in einer Session arbeiten. Keine echte Preisänderung.)
Es geht nicht darum, weniger miteinander zu reden. Es geht darum, sich weniger gegenseitig zu unterbrechen.
Entscheide nur, was entschieden werden muss. Unser stärkster AI-Nutzer hält eine Haupt-Session mit einer einzigen Aufgabe offen: aufzulisten, was seine Entscheidung braucht, jeweils mit einer Empfehlung. Wenn es in Slack hektisch wird, hält er sich raus und fragt: „Was muss ich jetzt entscheiden?“
Ich mache etwas Ähnliches. Ich habe mehr als 20 To-dos am Tag und, wie ich öffentlich geteilt habe, ADHS. Anzufangen ist für mich das Schwierigste. Jetzt landet jedes To-do in einem speziellen Manus Project, das jedes einzelne in eine eigene Aufgabe verwandelt. Es startet, was es kann. Wenn es unsicher ist, fragt es mich nach Hintergrund und welcher PM dafür zuständig sein soll. Dann sammelt es mit dem Zugriff, den ich ihm auf mein eigenes Slack, Gmail und Notion gegeben habe, den Kontext und übergibt dem PM eine vollständige Anfrage statt einer Ein-Zeilen-Notiz. Für mich ist die Veränderung nicht nur eine Frage der Effizienz. Ich verbringe jetzt viel weniger Zeit am Tag damit, mir Sorgen zu machen, wo ich anfangen soll, was auf persönlicher Ebene riesig ist.
9. Lohnen sich die Kosten?
Wir geben viel für AI aus, und wir verfolgen diese Ausgaben genau. Wir nutzen das nicht, um die Leistung von jemandem zu beurteilen. Wir nutzen es, um die Ausgaben selbst zu beurteilen: Zahlt es sich jetzt aus oder bereitet es uns auf später vor?
Hier ist, was es uns unserer Meinung nach bringt und wohin wir die Kosten erwarten:
•Es kauft uns Zeit und Aufmerksamkeit. Wenn ein Team wächst, frisst Koordination die Aufmerksamkeit aller auf. AI schützt die Aufmerksamkeit jeder einzelnen Person und gibt ihnen volle Verantwortung für ihre Arbeit. Und wir stellen weiter ein.
•Die besten Modelle zu nutzen ist der Weg, wie wir herausfinden, wo die Grenzen von AI liegen. Das in Abschnitt 4 beschriebene Verifikations- und Code-Review-Setup läuft auf den stärksten Modellen, die wir bekommen können. Der Kollege, der die Developer-Produktivität leitet, nennt es unsere Ausgabe mit dem besten Preis-Leistungs-Verhältnis.
•Die Kosten sollten durch das Produkt sinken. Immer mehr unserer Entwicklung findet in Manus Studio statt, unserem eigenen Produkt, sodass unsere Nutzungsdaten uns zeigen, wo tokens verschwendet werden. Die Fixes fließen ins Produkt, sodass sie Manus auch für Nutzer effizienter machen sollten. Wir erwarten, dass die heutigen Kosten erheblich sinken, wenn Modelle günstiger werden und wir Verschwendung beseitigen. Das ist eine Überzeugung, kein Versprechen!
10. Was noch nicht funktioniert
Es gibt weniger Unterbrechungen, aber die Aufmerksamkeit ist stärker fragmentiert. Jemand, der früher vier oder fünf Dinge am Tag erledigt hat, treibt jetzt vielleicht 20 oder 30 gleichzeitig voran. Jeder Wechsel bedeutet, den Kontext neu zu laden. AI erweitert, was Menschen tun können, und drängt sie zugleich, mehr zu tun. Eine PM hat mir gesagt, dass sie jedes Mal, wenn eine Aufgabe läuft, nicht widerstehen kann, einen weiteren Agent zu starten. Mehr Dinge zu tun ist nicht das Ziel. Wir behandeln das als Problem, das gelöst werden muss, nicht als Tempo, das gefeiert werden sollte.
Informationen sind stärker verstreut. Unser Head of Product kannte früher jede Änderung und wusste, warum sie gemacht wurde. Jetzt macht er manchmal einen Screenshot von einem Problem und fragt Mono: „Wer hat das geändert?“ Das ist amüsant, aber die Frage ist real. Wenn jeder befähigt ist, das Produkt zu verändern, wer ist dann für das Ganze verantwortlich?
Die Freigabe-Berechtigungen brauchen ein Redesign. Wenn Arbeit geteilt und übergeben werden kann und Agents in mehr unserer Gespräche sitzen, müssen wir entscheiden, was offen ist und was eine Genehmigung erfordert.
Unsere Lösungen sind noch rudimentär. Momentan überwacht ein Agent die anderen und meldet nur, was feststeckt und was eine menschliche Entscheidung braucht. Wir wissen, dass das besser werden kann.
11. Was wir als Nächstes bauen
Diese Probleme deuten auf Produktarbeit hin, die wahrscheinlich auch andere Teams brauchen werden. Wir haben diese Funktionen nicht im Voraus geplant. Sie entstanden aus Problemen, auf die wir selbst immer wieder gestoßen sind.
•Sitzungen als gemeinsame Arbeitsbereiche. Eine Person bringt ein Problem auf, ein Designer schlägt eine Lösung vor, ein Ingenieur baut sie, und ein PM führt sie aus — alles am selben Ort.
•Arbeit, die sich über Geräte und Personen hinweg bewegt. Lokale und Cloud-Maschinen bleiben verbunden, sodass die Arbeit fortgesetzt werden kann, wenn Personen abwesend sind.
•Agents, die Optionen finden, an die Menschen nicht gedacht hatten. Ein Agent, der innerhalb der Systeme eines Unternehmens mit den richtigen Berechtigungen arbeitet, sollte in der Lage sein, Lösungen vorzuschlagen und nicht nur Anweisungen auszuführen.
Wir werden diese zuerst an uns selbst ausprobieren und sie dann den Nutzern zur Verfügung stellen.
12. Was Menschen jetzt tun
Der Ingenieur mit einer Reihe geöffneter Agent-Sitzungen ist nicht nur eine Geschichte über Effizienz. Es ist eine Veränderung dessen, worauf eine Organisation läuft. Unternehmen haben Informationen früher über Rollen und Hierarchien bewegt. Was eine Person tun konnte, hing davon ab, wie viele Menschen und Ressourcen sie einsetzen konnte. Jetzt verbringen wir ein wenig Zeit damit, AI Kontext und Werkzeuge zu geben, und mehr Zeit damit, Urteile zu fällen und Entscheidungen zu treffen. Immer öfter ist es ein Agent, der uns ein Problem bringt. Zu entscheiden, was damit zu tun ist, bleibt unsere Aufgabe.
Wir haben darüber gescherzt: Wenn Manus so viel kann, warum dann noch ins Büro kommen? Lass die Agents es ausarbeiten. Aber die wichtigen Fragen müssen immer noch von Menschen aufgeworfen, diskutiert und entschieden werden. Zum Beispiel: Was gilt als gutes Produkt? Oder, um etwas zu übertreiben: Ein großartiges Produkt mit echten Einnahmen bauen, das die Grenzen von AI weiter verschiebt, oder auf die Marge gehen? AI weiß nicht, was wir wollen. Wir wissen es. Kultur und Vertrauen entstehen, wenn man die Dinge Tag für Tag und in den entscheidenden Momenten gemeinsam durcharbeitet. Das ist das Fundament, auf dem die Arbeit in jeder Sitzung ruht.
Also, für den Moment, hier ist unsere Antwort. In unserem Experiment als AI-native Organisation hat sich die Rolle der Menschen nicht verringert. Sie ist stärker auf Bereiche fokussiert, in denen sie den größten Einfluss haben können: das Problem definieren, Qualität beurteilen, entscheiden, was es wert ist, getan zu werden, und das Ergebnis verantworten.
Deshalb stellen wir auch weiterhin ein. Die Fähigkeiten und das Urteilsvermögen der Menschen stehen im Mittelpunkt dieser Arbeitsweise — und das wird sich so schnell nicht ändern.
Während ich dies schreibe, bin ich neugierig, was dieser Beitrag in einem Jahr sagen würde. Jedes Unternehmen hat unterschiedliche Ziele, Strukturen und Kulturen, daher gibt es möglicherweise keine Standardantwort und keine endgültige Form. Aber für ein Unternehmen, das Agents baut, ist es keine Option, herauszufinden, wie Menschen und AI zusammenarbeiten. Es ist Teil des Jobs. Wir bleiben dran und werden weiterhin teilen, was wir lernen.
Eine Anmerkung zu den Zahlen. Die Zahlen in diesem Beitrag stammen aus internen Aufzeichnungen. Teamgrößen und PM-Shipping-Zahlen beziehen sich auf Ende Oktober. Einige Punkte sind Schätzungen oder die Erfahrung einer Person und keine Messungen.
