Wie Sie Ihre Organisation dazu bringen, Coding-Agenten zu nutzen (ohne Schrott zu liefern) — Eyal Blum, Figma
AAI Engineer
컴퓨터/소프트웨어경영/리더십
스크립트
00:00:00Eyal Blam: Guten Tag, mein Name ist Eyal Blam, ich bin Softwareingenieur bei Figma und
00:00:17in meinem heutigen Vortrag geht es darum, wie wir KI-Agenten in unseren
00:00:25Arbeitsablauf bei Figma angepasst haben oder anpassen und dabei eine hohe Qualität unserer Codebasis aufrecht
00:00:32erhalten. Wie Sie vielleicht wissen, ist Figma der browserbasierte Editor, in dem Design, Engineering und mittlerweile
00:00:40auch KI-Agenten zusammenarbeiten, um Code auszuliefern.
00:00:44Figma hat sich sehr stark von einem traditionellen Tool zu einem KI-zentrierten Tool gewandelt,
00:00:52aber in diesem Vortrag werde ich nicht über unser Produkt sprechen, sondern eher über unsere
00:00:55interne Organisation und wie unsere Engineering-Organisation KI-Agenten angepasst hat.
00:01:04Und was wir intern festgestellt haben: Sowohl in Unternehmen als auch bei Einzelpersonen gibt es gewissermaßen
00:01:11einen dreiaktigen Prozess der KI-Einführung.
00:01:16Man fängt damit an, etwas auszuprobieren – viele hier im Raum
00:01:21sind ja sehr KI-affin und nutzen KI schon länger –, haben etwas ausprobiert und
00:01:27einige einfache Dinge dazu gebracht, sehr gut und 10-mal schneller zu funktionieren.
00:01:30Dann fängt man an, dieselben Praktiken auf größere Probleme anzuwenden, und dabei versagt KI ziemlich stark, liefert schlechtes Zeug
00:01:40und viele Bugs.
00:01:41Das aufgebaute Vertrauen bricht ein, und ab diesem Punkt beginnt man, die echte Fähigkeit aufzubauen: nämlich
00:01:50zu lernen, wie man KI richtig einsetzt und die richtigen Leitplanken, das richtige Prompting
00:01:55und den richtigen Kontext nutzt, all das, worüber wir hier den ganzen Tag in allen Vorträgen gesprochen haben, um tatsächlich echte Kompetenz aufzubauen.
00:02:02Und was intern passiert, während Teams oder Einzelpersonen sie annehmen, ist, dass die Einführung ungleichmäßig verläuft.
00:02:12Wir haben Teams, die sehr KI-fortschrittlich sind und ihre gesamten Arbeitsabläufe bereits umgestellt haben, und dann haben wir Teams, die noch in der früheren Phase experimentieren und/oder das Vertrauen verloren haben, und sie alle müssen zusammenarbeiten, um unser Produkt auszuliefern.
00:02:28Sie müssen also in der Organisation koexistieren, und wir müssen einen Weg finden, sie zu unterstützen und gleichzeitig alle auf diese Reise mitzunehmen und alle in den dritten Akt der Geschichte zu führen.
00:02:44Abgesehen von diesem Hauptkonfliktpunkt haben wir auch andere Reibungspunkte bemerkt, die bei der Einführung von KI auftreten.
00:02:54Eine Sache, die wir oft von Entwicklern gehört haben und die Manager beobachten, ist, dass eine verringerte Autonomie der Entwickler dazu führt, dass Ingenieure etwas von ihrer Arbeitszufriedenheit verlieren.
00:03:04Viele Leute empfanden früher viel Stolz und Freude daran, Code zu schreiben und in den “Flow” zu kommen, und viele haben das Gefühl, dass dies verloren gegangen ist oder dass sie dieses Element größtenteils verlieren und stattdessen in einen Prompt-Zyklus geraten, in dem sie nur auf Ausgaben von KI warten und dann mit der KI sprechen – das macht nicht mehr so viel Spaß wie früher.
00:03:22Wir haben eine weitere interessante Sache bemerkt: Unsere besten Ingenieure wollen all ihren Kontext im Kopf behalten und werden schließlich mit dieser Last konfrontiert, und das führt dazu, dass sie wissen, wo all die Fallstricke liegen; sie halten mit ihrem mentalen Klebeband all die Stellen zusammen, an denen Agenten nicht gut funktionieren, und verhindern, dass all die wirklich schlimmen Dinge reinkommen, oder sie haben all den institutionellen Kontext, der niemals aufgeschrieben wurde, in ihrem Kopf
00:03:52und niemals aufgeschrieben wurde, und sie sind so stark belastet, dass sie zu Engpässen werden und wirklich frustriert sind, sodass sie letztendlich langsamer in der Einführung sind, weil sie alle Probleme aus erster Hand sehen.
00:04:04Das ist ein weiteres großes Problem, das wir gesehen haben, und dieses hier wird sicherlich bei jedem hier Anklang finden: Plötzlich sind alle Design-Dokumente, alle Slack-Nachrichten und alle E-Mails drei- oder viermal so lang geworden, und wir erhalten zwei- oder dreimal so viele E-Mails, und sie sagen im Grunde nicht viel mehr aus als zuvor.
00:04:28Die Kommunikation ist also ziemlich ineffizient geworden, und es ist eine Herausforderung geworden, sich in den Merkmalen von hoher Qualität und wichtigen Dingen im Vergleich zu weniger hoher Qualität zurechtzufinden.
00:04:40Deshalb werde ich die nächsten Minuten darauf verwenden, über einige der Lektionen zu sprechen, die wir gelernt haben und wie wir versucht haben, diese anzuwenden.
00:04:50Dies ist eine Reise, wir sind noch nicht am anderen Ende angekommen, aber wir haben einige wirklich interessante Fortschritte in vielen dieser Bereiche gesehen.
00:04:57Ich denke, viele der Redner hier haben dies angesprochen, aber die Investition in Verifizierung ist wahrscheinlich das Wertvollste, was wir in unserer Codebasis tun können.
00:05:11Wann immer wir in unserem Arbeitsablauf etwas nach links verschieben können – von einer Aufgabe, die ein Mensch erledigen muss, hin zu etwas, das ein Agent verifizieren kann.
00:05:19Wenn zum Beispiel Playwright MCP herauskommt, anstatt Menschen durch den Code navigieren zu lassen, kann jetzt der Agent den Code erkunden – das war ein großer Produktivitätsgewinn für viele unserer Teams.
00:05:33Das ist wirklich, das ist für uns immer ein großer Gewinn.
00:05:37Das andere ist, noch besser: Wenn Sie etwas finden, das der Agent als nützlich erachtet hat, nehmen Sie sich die Zeit, es zu nehmen und in einen deterministischen Ablauf zu kodieren.
00:05:51Ein deterministischer Ablauf, der leicht wiederholt werden kann, spart Token und Zeit, und außerdem wissen Sie dadurch, dass Sie das LLM nur dann nutzen, wenn es logisch schlussfolgern muss.
00:06:01Aber wenn Sie etwas haben, das bereits bekannt ist und im Grunde in einen Test kodiert werden kann, zahlt sich diese investierte Zeit fast immer aus.
00:06:11Und ein weiterer Tipp: Wenn Sie Ihren Skills oder Ihrem Agenten sagen, dass er den Code schreiben soll, den Sie schreiben, und zwar im TDD-Stil (Red to Green), liefert das fast immer bessere Ergebnisse.
00:06:26Weil Sie ein Ziel setzen und dem Agenten dann sagen, dass er auf dieses Ziel hinarbeiten soll.
00:06:30Das liefert fast immer bessere Ergebnisse beim Schreiben des Codes und anschließenden Schreiben des Tests, da der Test dann zum Code passt, anstatt den Code so anzupassen, dass er die Verifizierungskriterien erfüllt.
00:06:42Und dies ist die Testpyramide – die klassische Testpyramide aus dem Vorherigen, und wenn man an die Tests selbst denkt, hat man End-to-End-Tests, Integrationstests und Unit-Tests.
00:06:54Hier ist eine sehr ähnliche Verlagerung möglich: Verschieben Sie so viel wie möglich hin zur deterministischen Analyse, wie Linting, Compiler und die Unit-Tests selbst. Was auch immer leicht abgedeckt werden kann, dafür können Sie Agenten basierend auf Kriterien Reviews durchführen lassen.
00:07:12Und architektonische Standards, die...
00:07:15Und architektonische Standards, die leicht in die Codebasis kodiert wurden, können Sie an den Agenten übergeben.
00:07:19Und dann müssen Sie ganz oben nur noch eine Art menschliche Überprüfung haben, die sich normalerweise auf die Funktionalität bezieht und darauf, ob dies das Richtige zum Bauen ist – überlassen Sie den Menschen also nur das, worin Menschen tatsächlich involviert sein müssen.
00:07:31Und eine weitere wirklich wichtige Sache ist Planung im Vergleich zu Prompting; dies ist eng damit verbunden, Entwicklern die Autonomie zurückzugeben und einen Ersatz für das Handwerk des Programmierens zu finden.
00:07:50Viel Zeit in das Schreiben des Plans zu investieren und ihn dann im Wesentlichen als Implementierung, die automatisch durchgeführt werden kann, an den Agenten zu übergeben, ist etwas, von dem wir festgestellt haben, dass es die Freude am Entwickeln wieder in den Prozess zurückbringt.
00:08:07Daher ist es nicht ungewöhnlich, eine Woche damit zu verbringen, sehr detaillierte Pläne zu schreiben, alle Entscheidungen zu treffen, sie auszuarbeiten, zu iterieren und sie Teamkollegen zur Überprüfung zu schicken.
00:08:17Und erst wenn es bereit ist und Sie alle Entscheidungen getroffen haben, können Sie es an den Agenten senden, der es Ihnen nach der Implementierung zurückschickt.
00:08:26Und das war wirklich erfolgreich, sowohl was die Beschleunigung angeht als auch bei der Wiederherstellung eines Teils der Freude am Entwicklungsprozess.
00:08:36Was also macht einen guten Plan aus? Es ist wirklich wichtig, ganz oben mit dem “Warum” zu beginnen.
00:08:43Das hilft wirklich, ein Abweichen des Agenten (Agent Drift) zu verhindern, wenn Sie einen großen, fett gedruckten Abschnitt haben, ähnlich wie beim Schreiben eines Design-Dokuments.
00:08:49Sie möchten eine Zusammenfassung (Executive Summary) haben, fügen Sie diese für den Agenten ein, da er sonst mit der Zeit abdriftet, und stellen Sie sicher, dass der Agent nicht zurückgeht und das ändert, nur weil ihm danach ist.
00:08:58Wir beginnen also mit dem “Warum” und stellen sicher, dass der Plan in kleine Teile unterteilt werden kann, die jeweils unabhängig verifiziert werden können.
00:09:08Und meine persönliche Art herauszufinden, was eine gute Größe ist: Würde ich den Pull Request überprüfen wollen, der diesem Teil entspricht, falls er zu groß ist, um ihn in einer Sitzung zu lesen?
00:09:18Das ist etwa so wie der Test: „Ich muss mir erst eine Tasse Kaffee holen, bevor ich das lese.“
00:09:22Das bedeutet, es ist zu groß und ich möchte, dass es in kleinere Teile aufgeteilt wird.
00:09:26Und dann stelle ich sicher, dass jeder Teil unabhängig validiert werden kann, denn ich möchte nicht fünf Phasen haben, bei denen die erste geschrieben, aber nicht validiert wurde und dann alles andere auf falschen Annahmen aufgebaut wird.
00:09:41Ein Validierungstor oder Ausnahmekriterien für jede Phase zu haben, hilft wirklich dabei, den Plan widerstandsfähig gegen Abweichungen zu machen.
00:09:51Und es gibt allerlei technische Aspekte zur Verwaltung des Kontexts und zum Aufbau einer Softwarefabrik darüber.
00:09:58Aber sobald Sie den Plan haben, können Sie jede beliebige Schleife oder jeden beliebigen Arbeitsablauf nutzen, um ihn umzusetzen.
00:10:05Dies ist ein Screenshot eines zufällig ausgewählten Plans, aber so etwas suche ich normalerweise.
00:10:12Die Zusammenfassung oben.
00:10:14Die Phasen unterteilen ihn, und für jede einzelne gehe ich ins Detail, damit sie genau in einen Unteragenten passt.
00:10:20Und der Unteragent kann eigenständig daran arbeiten und muss sich keine Sorgen machen.
00:10:24Und es gibt andere Arbeitsabläufe, die funktionieren würden, oder andere Strukturen für den Plan.
00:10:29Ich finde, das Tolle an KI-Arbeitsabläufen ist, dass jeder das einrichten kann, was für ihn am besten funktioniert.
00:10:41Nein, danke.
00:10:43Jeder kann sehr leicht den Arbeitsablauf einrichten, der genau für ihn funktioniert.
00:10:47Es bringt also abnehmenden Ertrag, alle auf eine einzige Sache zentralisieren zu wollen.
00:10:51Solange es für ihren Workflow funktioniert und andere mit ihnen iterieren können, stelle ich fest, dass es im Allgemeinen sehr gut funktioniert.
00:10:58Und dies ist nur ein Beispiel – sozusagen zum Angeben –, wie ein Ergebnis aus einem Plan aussehen könnte.
00:11:04Und hier sind wahrscheinlich 20 PRs.
00:11:07Einige davon haben vielleicht 10 Zeilen und andere 100 Zeilen, aber wahrscheinlich nichts Größeres als das.
00:11:12Und das erlaubt uns – in der Vor-KI-Ära hätte man an diesem Plan wahrscheinlich eine Woche lang gearbeitet.
00:11:19Ich habe mich eine weitere Woche lang mit drei anderen Teams darauf abgestimmt und ihn dann einfach über Nacht von einem Agenten implementieren lassen.
00:11:26Und er kam zurück – das stammt wahrscheinlich aus zwei Plänen, nicht aus einem –, aber im Grunde sind das sechs Wochen Programmierarbeit in nur einer Woche.
00:11:36Daher kommt also die 5-fache Beschleunigung.
00:11:40Wenn man den Überprüfungszyklus am Ende einbezieht, an den man immer denken muss.
00:11:45Um von der Planung wieder zu dem Problem zu kommen, das wir mit den Skeptikern und den mit der meiste Arbeit belasteten Menschen hatten:
00:11:53Stellen Sie sicher, dass Sie sie einbinden und ihr Feedback sehr ernst nehmen.
00:11:59Sie sind skeptisch, weil sie sehen, wo Ihnen Validierung fehlt und wo Ihre Tools versagen.
00:12:05Ihr Feedback ist im Grunde der Fahrplan dafür, wie Sie Ihren Agenten und die Interaktion mit der Codebasis verbessern können.
00:12:12Binden Sie sie einfach ein, anstatt zu versuchen herauszufinden, wie man sie dazu bringt, KI zu nutzen.
00:12:19Übertragen Sie ihnen die Verantwortung für den Fahrplan, um KI in Ihrer Organisation sicher zu machen.
00:12:25Und sie werden mitziehen, sobald sie sehen, dass die Verbesserungen, die sie vornehmen, ihr Leben tatsächlich besser machen.
00:12:33Und wie Sie sehen werden, scheuen sie sich nicht, Ihnen zu sagen, was Sie reparieren müssen.
00:12:37Das ist weniger als eine Stunde im Kreis einer Gruppe von Leuten.
00:12:40Und das ist das Ergebnis von Brainstorms.
00:12:45Eine weitere Sache, die speziell für mein Team sehr hilfreich war – und wir arbeiten daran, dies auch in der breiteren Organisation zu übernehmen –,
00:12:53ist sicherzustellen, dass man eine aufmerksamkeitssensitive Kommunikation pflegt.
00:12:58Im Zeitalter der KI ist die menschliche Aufmerksamkeit eine knappe Ressource.
00:13:01Ich glaube, ich habe das in mehreren Vorträgen gehört, und viele Leute sind zu demselben Schluss gekommen.
00:13:06Man kann nicht mehr menschliche Aufmerksamkeit bekommen.
00:13:08Wo du also deine Zeit verbringst und was du liest, wird wirklich wichtig.
00:13:13Da es nun mal eine so knappe Ressource ist, ist es sehr hilfreich zu markieren, was von KI generiert und was von einem Menschen geschrieben wurde, um zu wissen, wie viel Zeit man für das Lesen aufwenden muss,
00:13:24und wie viel Steigung man in diesem Teil der Kommunikation erwarten kann.
00:13:31Und das baut sozusagen eine neue Kultur rund um diesen Kommunikationsstil auf.
00:13:35Das hilft wirklich sehr.
00:13:36Zum Beispiel hat das Team, mit dem ich arbeite, beschlossen: Jede PR-Beschreibung beginnt immer mit etwas in der Art.
00:13:45Etwas, das ich von Hand geschrieben habe, könnte sehr kurz beschreiben, was dies tut, und die KI-Beschreibung folgt dann danach.
00:13:54Es ist einfach – ich werde es wahrscheinlich lesen.
00:13:55Ich werde es wahrscheinlich bearbeiten, um einige falsche Dinge zu entfernen, aber sie haben hier nicht jede Zeile geschrieben.
00:14:00Sie sollten also misstrauischer sein und mehr darauf achten, was ich oben geschrieben habe, und es gegebenenfalls übersteuern.
00:14:05Solche Dinge in Slack, in E-Mails – man nutzt eben voll aus, dass jeder weiß, dass man KI für die Formulierung seiner Kommunikation verwendet,
00:14:15aber man scheut sich eben nicht zu sagen, was sie lesen sollten und worauf sie weniger achten müssen.
00:14:21Und ich erinnere mich noch gut daran, wie ich anfangs, vielleicht so zu Beginn dieses Jahres, versuchte... Ich hatte einige leitende Ingenieure in unserer Organisation, die ziemliche KI-Skeptiker waren,
00:14:35und ich versuchte, auf sie zuzugehen, um herauszufinden, wo das Problem lag, was los war, und sagte, ich habe versucht, eine Analyse einiger der von ihnen verfassten PR-Kommentare durchzuführen,
00:14:42und offensichtlich habe ich dafür KI genutzt.
00:14:45Und dann habe ich nicht sehr klar unterschieden, was ich geschrieben hatte und was die KI generiert hatte, und sie waren sehr verärgert.
00:14:54Sie meinten: Warum schickst du... Ich hätte von jemandem, den ich so sehr respektiere, nicht erwartet, mir etwas zu schicken, das offensichtlich so schlampig ist.
00:15:02Und da habe ich mich eben entschuldigt.
00:15:05Mir wurde klar, dass ich es hätte deutlich kennzeichnen und meine Absicht markieren sollen.
00:15:08So nach dem Motto: Das ist es, was ich geschrieben habe.
00:15:10Das hat die KI geschrieben, und ich brauche euer Feedback dazu, weil mir der Kontext fehlt, um zu wissen, ob es schlampig ist oder nicht.
00:15:15Und genau darum bitte ich euch.
00:15:17Solche Lektionen und die Veränderung der Kultur sind also genauso wichtig wie einige der technischen Herausforderungen, vor denen wir standen.
00:15:28Eine andere Sache, die bei der Einführung sehr hilfreich ist: Während man bei der Adaption voranschreitet, gibt es viele sehr ausgefallene Tools und Arbeitsabläufe, die wir implementiert haben.
00:15:41Aber eines der wirklich effektiven Dinge ist einfach, die Leute KI dort nutzen zu lassen, wo sie gerade stehen.
00:15:47Das hilft wirklich dabei, die Nutzung von KI für alltägliche Aufgaben zu normalisieren, und es baut Reibungsverluste ab.
00:15:54Und eines der mächtigsten Dinge ist tatsächlich die Möglichkeit, jemanden in einer Slack-Nachricht zusammen mit einem Agenten zu taggen und zu sagen: Kannst du das kurz für mich erledigen?
00:16:02Und die Agenten den Kreis im Thread schließen zu lassen?
00:16:07Solche Dinge sind wirklich wirkungsvoll.
00:16:09Und darauf aufbauend kann man dann das Ganze automatisieren und all diese ausgefallenen Dinge tun.
00:16:14Aber wenn man sich mit jemandem unterhält, der noch nicht voll überzeugt ist, kann man es auf eine nicht-passiv-aggressive Weise taggen und sagen: Lass es uns einfach mal ausprobieren und sehen, ob der Agent es diesmal hinbekommt.
00:16:26Und wenn sie den Kreis schließen und es eine gute Erfahrung ist, hilft das den Leuten wirklich dabei, es in anderen Fällen auch selbst auszuprobieren.
00:16:33Und unsere Reise geht weiter.
00:16:37Wir lernen immer noch dazu, obwohl wir KI bereits extern ausliefern – unsere KI-Adaption läuft, und wir experimentieren ständig mit so vielen Dingen, wobei unser Automatisierungsgrad noch nicht ganz dort ist, wo er sein soll.
00:16:50Wir versuchen immer noch herauszufinden, wann und wie wir Cloud Agent effektiv nutzen können, angesichts all der Abhängigkeiten, die wir für einige unserer Build-Systeme haben.
00:16:58Deshalb lernen wir kontinuierlich weiter.
00:17:01Es ist ein Wandel der Kultur.
00:17:02Es ist ein technologischer Wandel.
00:17:03Und ich weiß nicht, wie es bei dir ist, aber ich arbeite nun seit 15 Jahren im Silicon Valley, und das ist mit Abstand die größte Veränderung, die ich jemals in Bezug auf Kultur und Technologie erlebt habe.
00:17:16Wir stecken also alle gemeinsam hier drin und finden das zusammen heraus.
00:17:19Und genau darüber wollte ich heute mit euch sprechen.
00:17:22Vielen Dank.
00:17:28Vielen Dank.
커뮤니티 글
아직 글이 없습니다. 이 영상에 대한 첫 번째 글을 작성해 보세요!
이 영상에 대해 글쓰기