Microframeworks in der Admin-Konsole
Jede Asana-Bereitstellung verfügt über eine Admin-Konsole. Hier konfigurieren IT-Administratoren, wie ihr Unternehmen Asana nutzt, z. B. durch die Anpassung von Passwortanforderungen, Rollen und Berechtigungen, die Festlegung, ob Dateien aus Dropbox angehängt werden können, und die Bestimmung, wer ein neues Projekt standardmäßig sehen kann.
Im Zuge des Wachstums von Asana wurden in der Admin-Konsole über Jahre hinweg benutzerdefinierte Logiken und einmalige Anpassungen implementiert, was die Erstellung und Wartung von administrativen Steuerungselementen immer aufwendiger machte. Nehmen wir eine administrative Einstellung: die Standard-Sichtbarkeitseinstellung für neue Projekte. Ein Administrator wählt aus, ob ein neues Projekt für das gesamte Unternehmen, für sein Team oder nur für eingeladene Mitglieder sichtbar ist. Einfach zu beschreiben, aber dahinter verbirgt sich eine Menge Komplexität:
Ist diese Funktion im Paket des Kunden enthalten?
Hat der Kunde früher dafür bezahlt, dann damit aufgehört und ist nun an einer Einstellung hängengeblieben, die er nicht mehr ändern kann?
Handelt es sich um einen HIPAA- oder FedRAMP-Kunden, bei dem nur Benutzer mit erweiterten Berechtigungen die Einstellung bearbeiten können?
Wird eine Option durch eine andere Einstellung deaktiviert?
Soll ein Infobanner angezeigt werden, um die aktuellen Einschränkungen zu beschreiben?
Jedes Team, das eine Adminfunktion hinzufügen wollte, musste all das richtig machen. Die meisten kamen zu dem Schluss, dass es sich nicht lohnte, und im Laufe der Zeit wurde die Kluft zwischen dem, was Asana leisten konnte, und dem, was ein Administrator steuern konnte, immer größer. Dies zeigt sich daran, dass einige Einstellungen nur auf unternehmensweiter Ebene konfiguriert werden können, was es IT-Administratoren erschwert, die Einstellung nur auf eine Untergruppe ihrer Benutzer anzuwenden.
Hier ist ein Code-Snippet für das Dialogfeld mit den Datenschutzeinstellungen für Projekte, mit dem festgelegt wird, ob diese deaktiviert werden sollen und ob ein Banner angezeigt werden soll:
Hier gibt es eine Menge Logik zu analysieren – Funktionslizenzen, Datenverwaltung, Überschreibungen aufgrund der Bereitstellungsstruktur und Benutzerrollen, insbesondere für Prüfer. Um sorgfältig vorzugehen, müssten Sie die Testmatrix im Kopf rekonstruieren, um festzustellen, ob sie korrekt ist.
Und das ist nur das Dialogfenster. Ob die Zeile überhaupt auf der Einstellungsseite angezeigt wird, wurde an anderer Stelle entschieden, und zwar auch uneinheitlich:
Drei Zeilen, drei Mechanismen, und die Steuerung befindet sich nicht immer in derselben Datei. Um also die Frage „Welche Einstellungen sieht dieser Kunde tatsächlich?“ zu beantworten, mussten Sie nicht nur jede Zeile lesen, sondern auch jede Komponente durchgehen. Diese Frage stellt sich ziemlich oft: Der Kundensupport versucht zu erklären, warum eine Einstellung für einen Kunden verschwunden ist, ein Produktmanager möchte eine klare Antwort darauf, ob eine neue Steuerung eine schnelle Änderung oder eine Änderung ist, die zwei Wochen dauert, ein neuer Mitarbeiter versucht, die eine Stelle zu finden, an der entschieden wird, was ein bestimmter Benutzer sehen kann.
Im Großen und Ganzen gab es vier Gründe, warum die Arbeit in der Admin-Konsole aufwendig war:
Aufwendig zu überprüfen. Die Logik befand sich dort, wo der/die Autor(in) sie platziert hatte. Daher konnte ein PR ein spezielles Verhalten einführen, ohne dass es für eine prüfende Person offensichtlich war, und die Richtigkeit war nicht etwas, das man einfach durch Lesen überprüfen konnte.
Mangelnde Standardisierung verbarg Fehler. Wir hatten langjährige Bugs, die schwer zu erkennen waren. Viele davon waren auf Abweichungen zwischen der Produktspezifikation und der Implementierung zurückzuführen, die durch eine Vielzahl von maßgeschneiderten Implementierungen verursacht wurden. Die Teams trafen willkürliche Entscheidungen, was dazu führte, dass jedes Kontrollelement seine eigenen Eigenheiten hatte.
Änderungen waren kostspielig. Um eine Änderung für den Endnutzer vorzunehmen, musste man jede Stelle finden, an der eine Regel hinterlegt war, und es gab selten eine zentrale Stelle, an der die Regel definiert war.
Kostspielig zu testen. Die Einrichtung von Tests erforderte fundierte Kenntnisse der Backend-Zustände, und umfassende manuelle Tests der Endbereitstellungen waren aufgrund der Anzahl der interagierenden Dimensionen nicht durchführbar.
Einführung der Frameworks
Wir haben ein deklaratives Framework für administrative Kontrollen erstellt, das als zentrale Informationsquelle in der Codebasis dienen soll. Eine Kontrolle gibt nun an, was sie ist:
Jedes Feld hier wird einem Zweig aus dem obigen Dialog zugeordnet: requiredAdminRole ist die HIPAA-/Super-Admin-Prüfung, upsellBehavior sind die beiden Upselling-Zweige und churnBehavior ist der Fall des abgewanderten Kunden, der es ihm ermöglicht, den Standard und nichts anderes wiederherzustellen.
Im Rahmen dessen stellt das Framework Hooks bereit, mit denen Entwickler den berechneten Status des Steuerelements ableiten können. Sehen Sie sich an, wie dasselbe Dialogfeld für die Projekteinstellungen jetzt aussieht:
Die If-Kette des Banners wurde zu einer gemeinsamen Komponente zusammengefasst, die von einem zentralen Hook gesteuert wird. Das Framework übernimmt die kombinatorische Logik aller verschiedenen Szenarien, und die für die Pflege verantwortlichen Fachexpert:innen, die das Verwaltungsprodukt genau kennen, können mitnichten umfassende Änderungen vornehmen. Jetzt verwenden wir eine strikte Typisierung, um die Implementierer dabei zu unterstützen, die Pflichtangaben einzugeben, die erforderlich sind, damit ihre Einstellung in allen möglichen Szenarien korrekt dargestellt wird. Entscheidend ist, dass sie die Komplexität dieser Szenarien oder deren Wechselwirkungen nicht verstehen müssen.
Diese Einstellungen sind über Zeilen in der Benutzeroberfläche der Admin-Konsole zugänglich. Die Sichtbarkeit dieser Zeilen wurde auf die gleiche Weise behandelt, und hier kommt das zweite Framework ins Spiel. Eine Zeile in der Einstellungsregistrierung beschreibt nicht ihre eigenen Sichtbarkeitsregeln, sondern verknüpft sie mit den Steuerelementen, die sie repräsentieren:
Das Steuerelement-Array ist der Mehrwert. Es enthält dasselbe ProjectDefaultPrivacy-Objekt, das das Dialogfeld an useAdminConsoleControl übergibt, und die Registrierung führt es über dieselbe zentrale Informationsquelle aus, sodass die Seite und das Dialogfeld nicht voneinander abweichen können. Früher wurde es separat berechnet, sodass Abweichungen zu zwei Fehlerarten führen konnten: eine Zeile, die sichtbar ist, aber ein Dialogfeld öffnet, das nicht verwendet werden kann, und eine Einstellung, für die ein Kunde bezahlt, aber keine Zeile vorhanden ist, über die er darauf zugreifen kann. Durch die Zentralisierung wurde diese Kategorie von Fehlern beseitigt.
Tests, bei denen die zentralisierten Frameworks verwendet wurden, haben die Erfahrung der PR-Prüfer*innen erheblich verbessert. Nehmen wir zum Beispiel den Test der Zeilensichtbarkeit, der die Frage „Welche Einstellungen sieht dieser Kunde tatsächlich?“ beantwortet, Frage von vorhin beantwortet. Anstelle von Testcode besteht ein Szenario nur aus Daten: einer Persona, einem Domain-Status und den Seiten, auf denen es gerendert wird.
Und in einer Zeile wird lediglich aufgelistet, in welchen benannten Szenarien sie erscheinen muss:
Es muss weder ein Render-Aufruf noch eine Assertion geschrieben werden. Eine dynamische Testsuite liest den Katalog und überprüft jede Zeile anhand jedes Szenarios, in dem sie genannt wird. Der Katalog ist jetzt der einzige Ort, an dem festgehalten wird, was ein Kunde sieht, und der maschinell überprüft wird. Man muss sich nicht mehr darauf verlassen, dass ein gewissenhafter Code-Reviewer oder der Autor seine eigenen Testfälle richtig identifiziert und schreibt.
In der Welt der KI
Wir haben Ende 2025 mit dieser Arbeit begonnen, weil wir davon ausgingen, dass es notwendig sein würde, Entwickler ohne Fachwissen in die Lage zu versetzen, sicher in der Admin-Konsole zu arbeiten. Damals war es nicht das Ziel, die Leistung von LLMs zu optimieren, aber wie sich herausstellte, bewirkt die Standardisierung und Optimierung der Erfahrung für Entwickler dasselbe für KI-Agenten.
Bevor wir diese Frameworks entwickelt haben, haben wir KI auf dieses Migrationsproblem angewendet, was technisch funktioniert hat. Das Problem war, dass weder der Agent noch der Prüfer sagen konnten, ob die Tests tatsächlich korrekt waren, was zu falscher Sicherheit und versteckten Fehlern führte. KI behebt nicht den Mangel an Struktur, sondern erzeugt nur schneller mehr Code, und zwar zusätzlich zu der bereits vorhandenen Struktur. Google hat ein ähnliches Argument für das Typsystem von Go in der KI-gestützten Entwicklung vorgebracht: Statische Typen fungieren als automatisiertes Sicherheitsnetz, da LLMs dazu neigen, Eigenschaften zu halluzinieren und Typen über Dateien hinweg falsch zuzuordnen. TypeScript ist nicht so statisch streng wie Go, aber ein Framework kann die gleiche Garantie darauf aufbauen: Definieren Sie den Typ des Steuerelements einmal auf der Framework-Ebene, und jede Implementierung muss am Einsatzort dazu passen.
Sobald die Frameworks fertig waren, begannen wir mit den Vorbereitungen für die Delegierung und Parallelisierung. Ich habe unser neues spezifikationsgesteuertes Entwicklungstool [link placeholder: eng blog post on spec driven development: Asana Eng Blog – Spec-driven development: The Good Parts] verwendet, um eine Skill zu erstellen, die die Aufgabe von Anfang bis Ende erledigt. Es kodiert die gesamte Konvertierung: das Steuerelement definieren, den Hook aufrufen, die Banner ersetzen, die Fragmente aktualisieren, die neuen deklarativen Tests hinzufügen sowie eine sich selbst aktualisierende Checkliste und ein Protokoll der Sonderfälle aus früheren Konvertierungen. Bei allen rund 150 Migrationen mussten 91 % nach der Überprüfung nicht überarbeitet werden.
Es ist nicht besonders aufwendig, einen Agenten damit zu beauftragen, einen PR zu erstellen, und auch die Überprüfung dieses PRs ist nicht besonders aufwendig. Da alles auf vorhersehbare Weise deklariert wird, müssen die Prüfer keine Experten im Bereich Administration sein, um zu überprüfen, ob die Implementierung den Produktspezifikationen entspricht. Entscheidend ist, dass dadurch der Pool potenzieller Prüfer für eine viel größere Gruppe von Entwicklern zugänglich wird, was die Geschwindigkeit stärker erhöht als nur ein breiterer Trichter am Anfang des Prozesses, der Pull Requests erstellt. Wir sind nicht die Einzigen, die das Review-Verfahren für diese Zeit neu überdenken: GitHub hat den eigenen Review-Agenten von Copilot auf der Grundlage strukturierter PR-Nachweise neu gestaltet, um menschlichen Reviewern zu helfen, schneller zu den richtigen Fragen zu gelangen, wodurch ihre Review-Kosten um etwa 20 % gesenkt wurden.
Die ursprüngliche Migration von rund 150 Einträgen, die sich über mehrere Frameworks erstreckten, wurde von Anfang bis Ende als manuelle, einmalige Entwicklungsarbeit geplant. Indem wir zunächst die Frameworks erstellt und dann die Migration an Entwickler(innen) delegiert haben, die anschließend die Agenten überwacht haben, konnten wir das gesamte Vorhaben mehr als einen Monat früher abschließen, als es im ursprünglichen Plan vorgesehen war.
Was passiert als Nächstes?
Die Entwicklung dieser Frameworks war nie ein Projekt für sich. Es entstand aus der Notwendigkeit heraus, aus einer Roadmap, die parallelisiert und skaliert werden musste, mit begrenztem und wechselndem Personal im Laufe des Projekts und ohne die Voraussetzung, dass jeder Mitwirkende zunächst ein Fachexperte sein musste. Wir haben bereits gesehen, dass es auch über das Team hinaus funktioniert, das es entwickelt hat: 18 der 66 Kontrollen im heutigen Framework wurden von Entwicklerinnen und Entwicklern aus 8 verschiedenen Teams erstellt.
Jetzt suchen wir nach dem nächsten Bereich, in dem wir diese Art von Investition tätigen können. Wenn überhaupt, ist die Argumentation jetzt noch überzeugender als vor Beginn des Projekts: Ein gut durchdachtes, deklaratives Framework erleichtert nicht nur die Überprüfung, sondern entscheidet auch darüber, ob ein Agent etwas Verlässliches oder nur etwas Schnelles produziert. Es ist auch das, was eine autonome Überprüfung plausibel machen könnte: Cloudflare hat ein System entwickelt, bei dem ein KI-Prüfer sauberen Code genehmigt und echte Probleme selbstständig blockiert. Das funktioniert nur, weil die Inputs so strukturiert sind, dass der Prüfer ihnen vertrauen kann. Ob unsere Inputs ausreichend strukturiert sind, um dasselbe auszuprobieren, ist eine gute Frage für die Zukunft.
Über den Autor
Leo Zhang ist Softwareentwickler im Team Admin Foundations, das IT-Administratoren dabei unterstützt, ihre Unternehmen zu verwalten. Derzeit verbessert er die Entwicklungserfahrung anderer Produktentwickler in der Admin-Konsole, indem er in die technischen Frameworks investiert, die unser Produkt unterstützen.
Dank an das Team
Die Konzeption, Implementierung, das Testen und die Einführung dieser Änderungen waren eine enorme Teamleistung. Dies wurde durch die Beiträge anderer Entwickler im Admin-Foundations-Team ermöglicht: Yunus Rahbar, Maryam Booshehrian, Saverio Castelli, Bronwyn Damm, Cindy Yu, Calvin Norton und Jaxsun McCarthy Huggan. Walter Li vom Agent-Success-Tiger-Team hat maßgeblich dazu beigetragen, die richtigen KI-Tools für diese Migrationen einzurichten.
Referenzen
Lan Cheng, Emerson Murphy-Hill, Mark Canning, Ciera Jaspan, Collin Green, Andrea Knight, Nan Zhang und Elizabeth Kammer, „What Improves Developer Productivity at Google? Code Quality“, ESEC/FSE '22, November 2022. https://doi.org/10.1145/3540250.3558940
„Orchestrating AI Code Review at Scale“, Cloudflare-Blog, April 2026. https://blog.cloudflare.com/ai-code-review/
Napalys Klicius, „Better tools made Copilot code review worse. So haben wir sie tatsächlich verbessert“, The GitHub Blog, Juli 2026. https://github.blog/ai-and-ml/github-copilot/better-tools-made-copilot-code-review-worse-heres-how-we-actually-improved-it/
„Why Go is an Ideal Language for AI-Assisted Software Engineering“, Google Developers Blog, August 2026. https://developers.googleblog.com/why-go-is-an-ideal-language-for-ai-assisted-software-engineering/
