Agentisches Programmieren: Eine Diskussionsrunde mit Branchenführern

Hallo zusammen.

Sie haben diese Woche oder in den letzten zwei Tagen viel von Android-Googlern gehört.

Wir dachten, es wäre eine gute Idee, die Konferenz mit einigen Stimmen von außen, aus der Community, aus der Android-Entwickler-Community, abzuschließen.

Wir sprechen über agentisches Programmieren und die Auswirkungen, die es in der Praxis hat.

Wir stellen uns zuerst vor.

Ich heiße Ben und bin Android DevRel.

Sie haben mich schon einmal auf dieser Konferenz gehört, aber lassen Sie uns die Podiumsdiskussion durchgehen.

Hallo allerseits.

Mein Name ist Vinay und ich unterstütze die KI-Tooling-Bemühungen bei Databricks.

Ich freue mich, hier zu sein.

Hallo, ich bin Luis Artola.

Ich arbeite für Google Maps.

Ich leite Teams, die KI verwenden, um agentische Funktionen zu entwickeln und den Softwareentwicklungszyklus zu verbessern.

Hallo, ich bin Annyce Davis.

Ich arbeite bei Ford.

Ich leite einige Engineering-Teams, die unsere Abos und Treuepunkteprogramme entwickeln.

Hallo allerseits.

Ich bin Ty Smith.

Ich arbeite bei Uber und unterstütze unsere Entwickler.

Das ist schon sehr lange so.

In den letzten Jahren lag der Fokus auf der neuen, spannenden Zeit, in der wir uns mit KI-Tools befinden.

Hallo allerseits.

Ich bin Kaushik Gopal.

Ich arbeite als Principal Engineer bei Instacart und habe den Podcast „Fragmented“ zur Android-Entwicklung gestartet.

Wie Ty schon sagte, haben wir unsere Strategie etwas geändert und sprechen jetzt über KI-Entwicklung.

Okay.

Wir haben also 30 Minuten Zeit.

Ich denke, die Zeit wird wie im Flug vergehen, also fangen wir gleich mit den harten Fragen an.

Wir bei Android DevRel haben schon immer gesagt, dass wir die App-Entwicklung schneller und einfacher machen wollen.

Jetzt ist KI da und Sie haben uns hier oben sagen hören: „Ja, das ist es.

Wir sind der Meinung, dass sich Apps so schneller und einfacher entwickeln lassen.“

Aber ich möchte die Frage in den Raum stellen: Liefern wir Apps tatsächlich schneller aus oder generieren wir nur eine Menge Code, der nirgendwo hinführt?

Los gehts, Vinay.

Okay.

Ja, wir sehen uns alle an.

Beeindruckend.

Wenn man sich nur die Zahlen ansieht, ist die Ausgabe in Bezug auf PRs und Codezeilen definitiv massiv gestiegen. Dadurch stoßen wir auch auf Skalierungsprobleme, z. B. bei der Speicherung unseres Codes.

Diese Beschleunigung ist also sehr real.

Was nicht offensichtlich ist, ist, wie sich das auf die Ergebnisse auswirkt. Ich denke, die gesamte Branche versucht herauszufinden, was der richtige Messwert für die Ergebnisse ist und wie man herausfindet, wie sich das auf das Endergebnis auswirkt.

Aber ich sehe es definitiv in Aktion.

Ich glaube, wir haben in den letzten sechs Monaten mehr Code veröffentlicht als in einem sehr langen Zeitraum davor. Ich möchte hier nicht zu genau werden.

Und ich denke, dass sich dadurch auch unsere Strategie zur Messung der Produktivität geändert hat.

Es gibt verschiedene Möglichkeiten, darüber nachzudenken.

Wir versuchen herauszufinden, wie wir den Medianwert erhöhen können, richtig?

Wenn man sich die Ausreißer und den Median ansieht, gibt es einen Unterschied von 5x bis 10x zwischen diesen beiden Kategorien von Menschen. Unser Fokus liegt darauf, die Untergrenze und den Median anzuheben und diese Menschen so produktiv zu machen wie ihre Kollegen, die wir als produktiv wahrnehmen.

Wir sehen eine Kombination von Rollen.

Manche bewegen sich viel schneller.

Es gibt Leute, die täglich 100 PRs machen und einfach unglaubliche Arbeit leisten.

Aber das ist eine Art von Raum, in dem sie sich bewegen.

Das ist vielleicht eher ein Greenfield-Ansatz oder sie sind mit den Tools vertrauter.

Andere arbeiten eher im Brownfield-Bereich oder auf Plattformen und unterstützen eine andere Art von Arbeit, die vielleicht nicht so schnell voranschreitet, weil sie mehr Zeit mit menschlichen Entscheidungen verbringen müssen und dafür sorgen müssen, dass nichts kaputt geht.

Die Kombination dieser beiden Faktoren ist deutlich schneller als zuvor. Aber ich denke, das wirklich interessante Thema für uns ist, ob das Unternehmen tatsächlich mehr an die Endnutzer liefert, obwohl wir mehr liefern.

In diesen Bereich haben wir im letzten Jahr investiert, um wirklich zu verstehen, ob wir Funktionen schneller bereitstellen und nicht nur Code schneller ausliefern.

Erste Signale deuten darauf hin, dass wir das sind, aber es ist ein ganz anderer Ansatz als nur die reinen PRs.

Ich denke, was passiert ist, ist, dass die Leute ganz klar viel mehr liefern, also die Anzahl der PRs, die Anzahl der Pull Requests, ist gestiegen.

Aber ich glaube, dass viele auch jetzt noch denken: „Wie können wir KI und dieses Tool, das wir haben, nutzen, um bestehende Prozesse zu beschleunigen?“

Nicht wahr?

Früher haben wir Code so bereitgestellt, dass wir immer dachten, ein Mensch würde ihn bis zur Produktion begleiten.

Aber ich denke, wir sehen jetzt, dass das funktioniert.

Wir versenden mehr.

Aber wir stoßen auf jeden einzelnen Engpass, den wir früher nicht gesehen hätten, oder?

Früher hatten wir diese Probleme nicht, aber jetzt beschleunigen wir einen Teil eines mehrstufigen Zyklus und ich denke, das ist der Punkt, an dem es interessant wird: „Okay.

Wir liefern mehr, aber jetzt ist es wie ein Feuerwerk an Effekten.“

Wir stehen also vor anderen Herausforderungen.

Das ist ein sehr interessanter Punkt, denn wenn man darüber nachdenkt, gibt es viele verschiedene Schritte, aber aus einer übergeordneten Perspektive kann man sie in drei Phasen einteilen, oder?

Es gibt das Programmieren, das eindeutig beschleunigt wird.

Es gibt die Produktionsbereitschaft, die eine Reihe von Dingen wie rechtliche Aspekte, Datenschutz und Dinge umfasst, die es Ihnen ermöglichen, etwas auf den Markt zu bringen, und dann gibt es die Markteinführung, richtig?

Und dann bedeutet Versand je nach Standort etwas anderes, oder?

Wenn Sie ein rein serverseitiges Produkt haben, bedeutet die Bereitstellung wahrscheinlich einen optimierten Prozess. Wenn Sie jedoch etwas bereitstellen, das an den Verbraucher geht, ist die Bereitstellung in der Testphase nur die Mitte einer Reise, oder?

Sie müssen immer noch viel experimentieren und messen. Und da schließt sich der Kreis zu dem, was Sie gesagt haben: Es fühlt sich an, als wären Sie in einer Metropolregion auf einer Autobahn und hätten einen Engpass. Dann beschleunigen Sie und denken: „Ja, super.

Ich bin wirklich schnell“, aber dann stoßen Sie auf den nächsten Engpass.

Und was KI sehr deutlich macht, ist, dass man die Reibungspunkte klarer sieht, und einige davon haben nichts mit Programmierung oder Technologie zu tun.

Es geht um Prozesse und Menschen und darum, wie Sie diese mit KI optimieren können.

Das ist eine wirklich interessante Herausforderung, wie man den gesamten Prozess optimieren kann.

Eine interessante Frage, die wir uns stellen, ist: Wie viel Handlungsspielraum hat die Person oder das Team, um das Produkt vollständig auf den Markt zu bringen?

Wenn wir uns intern umsehen, gibt es viele Teams, die interne Tools oder Dinge entwickeln, die nicht an Kunden ausgeliefert werden.

Sie versenden viel schneller, oder?

Sie haben die volle Kontrolle darüber, wie sie diese Informationen sofort an ihre Kunden weitergeben.

Wenn Sie ein externes Produkt haben, das dann noch mit einem Nutzer getestet werden muss, oder wenn Sie die Roll-out-Zeiten im App Store berücksichtigen müssen oder mit Design und Produkt zusammenarbeiten, summieren sich all diese anderen Engpässe und die Personen, die den Code schreiben, haben viel weniger Möglichkeiten, schnell zu handeln.

Und so stoßen sie einfach auf die restlichen Engpässe im System.

Ich denke, dass die Aufteilung in diese beiden Bereiche wirklich zeigt, wo Ihre Geschäftsprozesse verbessert werden könnten.

Ja, ich stimme zu. Und ich denke, dass die Entwicklung nie der Engpass war.

Das sage ich schon seit Jahren.

Die Entwickler haben eine sehr strukturierte Arbeitsweise und die Frage des Unternehmens war immer: „Was ist das Problem?“

erhalten Sie zehn verschiedene Antworten.

Und dann: „Okay.

Sehen wir uns nun an, wie sich das auf Produktlösungen übertragen lässt.

Lassen wir das erst einmal sacken.

Oh, lass uns vielleicht ein bisschen mit dem Designteam sprechen.

Kick ihn rüber.“

Wenn es dann zur Entwicklung kommt, wissen wir mehr oder weniger, was wir tun müssen.

Dann versuchen wir einfach, Stack Overflow aufzurufen, kopieren ein paar Dinge und veröffentlichen das Ganze.

Mit KI sehe ich die größten Beschleunigungen bei der Compliance-Arbeit.

Dinge, die wir schon immer modernisieren wollten, oder die Spring Boot-Version, die wir schon immer schnell aktualisieren wollten.

Wir machen das so schnell.

Aber bei der tatsächlichen Bereitstellung von Funktionen habe ich keine nennenswerten Verbesserungen gesehen.

Sie haben alle erwähnt, dass sich der Engpass möglicherweise verschoben hat und Sie jetzt auf Prozesse stoßen, die früher nicht wirklich der Engpass waren, es aber jetzt sind.

Diese Prozesse sind aber wahrscheinlich das Ergebnis von harten Lektionen in der Vergangenheit, oder?

Spüren Sie also den Druck, diese zu ändern? Ich denke, das offensichtlichste Beispiel ist die Codeüberprüfung.

Wie sieht die Zukunft von Code Reviews aus?

Was tun wir aktuell?

Ich würde mich also über Feedback freuen.

Das geht auf den Punkt zurück, den ich vorhin angesprochen habe.

Ich glaube, viele dieser Engpässe entstehen, weil wir uns dachten: Wenn man einen Zauberstab hätte und die Softwareentwicklung neu erfinden könnte und heute KI hätte, würden wir dann viele der gleichen Dinge tun?

Zum Beispiel war die Codeüberprüfung notwendig, weil wir einen Menschen brauchten, der die Dinge absegnet, also die letzte Überprüfung vornimmt.

Ich denke, das ändert sich auch. Wir denken jetzt über Code Reviews nach und sollten vielleicht offen für die Idee sein, dass, wenn Sie den Namen refaktorieren oder Code refaktorieren möchten und wissen, dass Sie gute Tests haben, die natürlich jeder hat.

Wir haben die KI, die sie schreibt, also ist alles in Ordnung.

Nein, ich meine, ob Sie vielleicht einen viel besseren Job machen werden als dieser Agent.

Ich weiß nicht, vielleicht sollten Sie sich nicht die Zeit nehmen, das zu überprüfen.

Wenn Sie jedoch einen Fehler veröffentlichen und Ihr CEO Sie anruft und sagt: „Hey, das kostet uns X Dollar“, sollten Sie vielleicht Bereiche und Systeme identifizieren, die kritisch sind.

Das ist kein kritischer Bereich.“ und versuchen Sie dann, sich das Ganze neu vorzustellen.

So arbeiten wir heute nicht, oder?

Heute ist es eher so: „Hey, da ist ein PR.

Ich bin der Ingenieur.

Ich konzentriere mich auf diese Sache.

Es wird steigen.

Ich bitte Vinay mitten in der Nacht um eine Codeüberprüfung, weil ich das Ding einfach zusammenführen möchte.“

Oder sollten wir viele davon überdenken?

Ich stimme voll und ganz zu und betrachte Code Reviews als Verifizierungsproblem. Damit meine ich: Wenn ich volles Vertrauen in meine Fähigkeit hätte, etwas zu verifizieren, würde ich dann immer noch 100 % meiner PRs einem Code Review unterziehen?

Wahrscheinlich nicht, oder?

Code Reviews dienen also zwei Zwecken.

Zum einen müssen wir natürlich prüfen, ob wir das Richtige tun, und zum anderen müssen wir die Nutzer informieren, oder?

Zum Beispiel, dass die Menschen um dich herum wissen, was du vorhast, und ob sie mit dieser Entscheidung einverstanden sind oder nicht.

Es gibt also definitiv eine Kategorie von Arbeit, die wir beschleunigen und in den Code und sogar in Releases einfließen lassen sollten.

Das trifft vielleicht nicht auf 100 % der Fälle zu, aber ich denke, es ist eine sehr hohe, zweistellige Zahl, auf die es zutreffen sollte.

Ich denke, wir sind bereit, diese Änderungen vorzunehmen, und wir alle als Community müssen dafür sorgen, dass unsere Systeme darauf vorbereitet sind, denn es wird kommen.

Es war einfach

Der obere Bereich des Trichters ist so breit, dass Sie auf verschiedenen Oberflächen mehr PRs erstellen können.

Und Sie sind nur so schnell wie der langsamste Schritt im Prozess.

Für viele Teams sind das Code Reviews. Teams, die schneller vorankommen, haben diese Realität erkannt und akzeptiert.

Ja, und wenn wir ehrlich sind, sehen 70 % der PRs, die ich gesehen habe, gut aus.

Wenn wir alle Codebasen der Welt durchsuchen würden, wären die PR-Kommentare überall nur „looks good to me“, LGTM.

Als Ingenieure überschätzen wir uns manchmal selbst.

Wir denken wirklich, dass wir mittendrin sind.

„Haben sie das Befehlsmuster verwendet?“

Nein, wir sagen einfach: „Okay.

Ja, sieht gut aus.“

Warum kann das also nicht ein KI-Agent für mich erledigen?

Ich glaube, dass wir in Zukunft sehen werden, was für uns gut aussieht, welche Merkmale und Verhaltensweisen uns dieses Gefühl geben.

Und dann sorgen wir dafür, dass der Agent nach demselben sucht.

Oder versuchen Sie, sich verschiedene Möglichkeiten der Überprüfung zu überlegen.

Ich kenne Leute, die heute auf Twitter sind und Folgendes sagen:

Wenn Sie jetzt einen PR verifizieren, können Sie Ihre Agenten bitten, ihn auf eine andere Weise zu visualisieren, oder?

Hey, zeig mir ein Vorher-Bild.

Zeig mir ein Nachher-Bild.

Zeig mir die Tests, die du geschrieben hast, anstatt den Code Zeile für Zeile zu prüfen.

Aber es stellt eine Herausforderung dar. Wollten Sie etwas sagen, Luis?

Nein, ich finde, es regt zum Nachdenken an.

So kommen wir an einen Punkt, an dem Sie sich wirklich wohl dabei fühlen, CLs oder PRs ohne menschliches Eingreifen durchgehen zu lassen.

Ich möchte hier ein wenig den Advocatus Diaboli spielen und sagen, dass wir bei Reibung dazu neigen, sie als etwas Schlechtes zu betrachten. Es gibt jedoch gute und schlechte Reibung.

Ich denke, dass Rezensionen immer noch in die Kategorie der guten Reibung fallen.

Es geht darum, wie wir es für Entwickler weniger mühsam machen können, oder?

Und manchmal geht es nicht darum, wie wir diese Überprüfung zu diesem Zeitpunkt besser oder effizienter gestalten können.

Es geht darum, wie Sie die Entwicklung mit KI präziser gestalten können, oder?

Denn je nachdem, wie Sie KI verwenden, gilt: Gute Eingaben führen zu besseren Ausgaben, aber schlechte Eingaben führen zu wirklich schlechten Ergebnissen, oder?

Ich denke, um diesen ansprechenden Endzustand zu erreichen, muss der Prozess mit KI von Anfang an ganzheitlich verbessert werden. KI sollte verwendet werden, um die Architektur besser zu verstehen und wirklich solide Spezifikationen mit weniger Aufwand für Entwickler zu erstellen, damit der generierte Code von höherer Qualität ist.

Daher sind die Überprüfungen für Entwickler weniger aufwendig.

Ich denke, der Endzustand, der nicht so umstritten sein wird, ist, dass die meisten Leute sehen, dass der gesamte Code irgendwann ohne menschliche Überprüfung veröffentlicht wird.

In der Zwischenzeit befinden wir uns in einer sich entwickelnden Situation, in der die Modelle immer besser werden. Wir machen uns weniger Sorgen, dass sie einen technischen Fehler machen, sondern eher, dass sie einen geschäftlichen Fehler machen oder dass das Problem in der Beurteilung oder der Ideenfindung liegt, die in das Modell eingeflossen sind.

Das fließt also auch in das Signal ein, das Sie während der Überprüfungsphase herausfiltern möchten.

Sollten wir beispielsweise eine zeilenweise Überprüfung im PR durchführen oder die Absicht überprüfen, die sie verfolgen?

Wir denken darüber vielleicht auf verschiedene Arten nach.

Erstens: Wie können wir Nutzern relevantere Informationen zur Verfügung stellen, damit sie diese priorisieren können?

Und zweitens: In welchen Bereichen können wir sicherer experimentieren und in solchen Programmen schneller vorankommen?

Wie Kaushik schon sagte, erfordern nicht alle Bereiche denselben Aufwand.

Wir können das erkennen und einige schneller freigeben, das Risiko senken und gleichzeitig Bereiche, die stärker auf Compliance ausgerichtet oder sehr grundlegend sind, mit höherer Reibung beibehalten, bis wir wirklich an dem Punkt sind, an dem wir nicht nur den Modellen, sondern auch den Eingaben vertrauen, die in sie einfließen.

die richtigen Entscheidungen waren.

Zum Beispiel das Refaktorieren eines neuen Android-Moduls in der Uber App. Das ist vielleicht okay.

Android-Entwickler können kostenlos mitfahren. Sie sollten sich den Code aber vielleicht noch einmal ansehen.

Das muss ich mit unserem CEO besprechen.

Tut mir leid, Kaushik.

Aber ich denke auch, dass dieses Problem gelöst ist.

Wir haben bereits Funktions-Flags.

Wir haben bereits eine Blau/Grün-Bereitstellung.

Wir haben bereits viele der Teile.

Die Herausforderung ist, dass wir zu beschäftigt waren, um das wirklich zu tun.

Wir haben bereits Verhaltens-Tracking.

Wir haben all diese Daten, aber sie befinden sich in verschiedenen Systemen.

Wir verfolgen bereits Vorfälle.

Wir haben so viele Daten, aber sie alle in einem umfassenden Trace zusammenzuführen, ist das, was fehlt.

Sobald wir herausgefunden haben, wie ein solcher Engineering-Kontextdienst in all diesen verschiedenen Unternehmen aussieht, müssen wir uns keine Sorgen mehr machen, denn selbst wenn der PR einfach zusammengeführt wird, ist er sicher.

Denn wir wissen, dass wir das hinter einem Funktions-Flag haben.

Wir haben ein Blau/Grün-Deployment.

Wir haben alle Beobachtbarkeitsfunktionen eingerichtet.

Und dann können Sie ganz selbstbewusst sagen: „Oh, packen Sie es in die Pipeline.“

Wenn etwas Schlimmes passiert, haben wir all diese Wachen und Tore auf dem Weg.

Ich denke, die Geschwindigkeit, mit der man reagieren kann, ist auch sehr wichtig, oder?

Wenn Sie beispielsweise eine Änderung in Android veröffentlichen, die über den Google Play Store bereitgestellt und dann an Ihre Nutzer verteilt werden muss, ist Ihre Möglichkeit, diese sofort per Hotfix zu beheben, stark eingeschränkt. Wenn Sie dagegen etwas mit einer internen Bereitstellung mit interner Beobachtbarkeit und einem Agenten tun, der sofort darauf reagiert, haben Sie viel mehr Möglichkeiten, schneller zu handeln.

Eine meiner Fragen an Sie ist, dass es auch das Problem gibt, dass an diesen Apps gearbeitet werden muss, aber dann gibt es diese Greenfield-Apps, die einfacher sind, dann gibt es diese Brownfield-Apps, und dann gibt es diesen Moment, in dem Sie die Zeit brauchen, um viele dieser Prüfungen durchzuführen, damit Sie die Nutzung von KI ausweiten können.

Ich weiß, dass viele von Ihnen an riesigen Apps arbeiten, oder?

Ich bin neugierig, wie Sie darüber denken.

Sagen Sie dem CEO: „Geben Sie mir drei Monate, um die App KI-fähig zu machen“, oder fügen Sie jeden Tag etwas hinzu?

Ja.

Das machen sie sowieso nie.

Ich glaube nicht.

Die meisten Unternehmen werden diesen Luxus nie haben.

Ich denke, wir müssen dem Thema einfach genauso viel Zeit widmen wie früher der technischen Schuld. Also 20 % der Zeit dafür aufwenden, davon 5 % für die Verbesserung eines Prompts.

Und dann sogar verstehen, was der Prompt bewirkt, und den Kontext verbessern.

Wir haben ja schon darüber gesprochen, dass viele Entwickler noch nicht verstehen, wie es funktioniert.

Es fühlt sich immer noch sehr magisch und mystisch an, sodass sie es nicht so konfigurieren und optimieren, dass sie den besten Wert und die beste Effizienz daraus ziehen können.

Ich denke, dass Führungskräfte sich irgendwann fragen müssen: „Was müssen wir tun, um unser Team auf die nächste Stufe zu bringen, damit es versteht, wie das funktioniert, und wir dann mehr erreichen können?“

Es ist auch eine Fortsetzung davon.

Weil sich alles so schnell ändert, würden wir, wenn ich ein Team bitten würde, eine Woche lang die neuesten und besten Tools zu lernen und in die Praxis umzusetzen, und sie dann keine Zeit mehr hätten, weiter zu lernen oder zu experimentieren, und wir uns nächstes Jahr wiedersehen würden, deutlich hinter den neuen Möglichkeiten zurückbleiben.

Wir müssen also das Flugzeug bauen, während wir es fliegen. Wir müssen die Leitplanken setzen, lernen und uns anpassen, während die Dinge passieren. Und die Teams müssen auf dem Laufenden bleiben.

In großen Unternehmen gibt es Teams wie unseres, die versuchen, diese Informationen zu destillieren und sie ein wenig verständlicher und verdaulicher zu machen.

Aber es ist derzeit eine Herausforderung für alle in der Branche.

Ich würde gern etwas Abwechslung reinbringen.

Viele von Ihnen arbeiten in der Entwicklerinfrastruktur.

Tausende von PRs – schmelzen da nicht eure Testinfrastruktur und eure Server?

Und ich würde gerne ein paar Geschichten aus dem Kampf hören.

Ty?

Ja.

Sie sind super.

Mein CI weint mich jede Nacht in den Schlaf.

Fast alle unsere Teams für die Entwicklerinfrastruktur haben derzeit mit Skalierungsproblemen bei der Rechenleistung und Effizienzproblemen zu kämpfen.

Es gibt Code Reds.

Sie sehen diesen enormen Anstieg des Volumens.

Wir nehmen architektonische Änderungen an den Agenten vor.

Wir versuchen, Dinge wie die Remote-Build-Ausführung und das Caching mit Bazel so schnell wie möglich zu erweitern. Wir sehen uns an, wie der gesamte Hauptzweig jederzeit grün sein muss, oder ob wir mit Agents in bestimmten Bereichen mit der Vorwärtskorrektur beginnen können. Wir sehen uns das Volumen an, das von Entwicklern kommt, und versuchen, Dinge wie selbstheilende CI oder kürzere Feedback-Schleifen zu implementieren. Alle Teams investieren aktiv in all diese Bereiche, um mit dem Wachstum Schritt zu halten und gleichzeitig ein gewisses Maß an Effizienz zu wahren.

Aber es ist extrem schwierig.

Ja, ich stimme allem zu, was Ty gerade gesagt hat. Aber ich denke, es zwingt uns auch dazu, zu reflektieren und uns ehrlich zu fragen, ob wir bereit wären, wenn wir uns von diesem Punkt an verzehnfachen würden.

Für die meisten Menschen lautet die Antwort wahrscheinlich „Nein“.

Wenn wir also an die Zukunft denken, versuchen wir bewusst, unsere Ambitionen mit der Kapazität der Infrastruktur in Einklang zu bringen.

Und was… Eine Sache, die KI bewirkt hat, ist, dass wir alle ehrgeiziger geworden sind, weil wir bereits einen bedeutenden Sprung gesehen haben. Deshalb überdenken wir unsere Systeme.

Genau, wir überlegen, welches andere System ausfallen wird oder könnte, und was wir tun können, um dem zuvorzukommen, damit es keine Überraschung gibt.

In Wirklichkeit versuchen wir, Überraschungen zu vermeiden.

Richtig, solange wir das Gefühl haben, die Kontrolle zu haben, sind alle zufrieden.

Sobald wir auf eine Überraschung stoßen, weiß ich, dass das für alle schlechte Nachrichten sind.

Nicht wahr?

Das ist ein guter Zeitpunkt, um zurückzublicken, zu prüfen und herauszufinden, was als Nächstes kaputtgehen wird, denn das wird passieren.

Das ist unvermeidlich.

Wir möchten nur auf Nummer sicher gehen.

Ich habe ein interessantes Zitat vom CEO von Inflow gehört.

Sie beschrieb, dass Google etwa 20 Jahre gebraucht hat, um die Milliarden Zeilen Code zu erreichen, die es heute hat. Durch die Beschleunigung werden viele unserer Unternehmen in nur wenigen Jahren eine ähnliche Größenordnung erreichen, basierend auf der Beschleunigung der KI.

Und ich glaube nicht, dass alle Unternehmen bereit sind, eine Infrastruktur auf Google-Niveau für die Entwicklung zu haben.

Gibt es in Ihren Unternehmen eine Art Ausgabenlimit?

Wie gehen Sie damit um, dass manche Entwickler jetzt einfach Tokens für alles verbrauchen, also immer das bestmögliche Modell verwenden?

Gibt es Strategien, die du empfehlen kannst, oder ist es besser, sie einfach gewähren zu lassen, weil Experimentieren zu tollen Ergebnissen führt?

Ich würde sagen, das letzte Jahr war das Jahr des Experimentierens.

Alles erledigen.

Und vielleicht war die erste Hälfte dieses Jahres nur dazu da, sie vernünftig zu nutzen.

Seit September gibt es Tokenlimits.

Wir haben also Limits für Entwickler, was die Token-Nutzung angeht.

Und dann gibt es noch die Instrumentierung, mit der du sehen kannst, ob du gute, gesunde Trainingseinheiten hast.

Was bedeutet es, eine gesunde Sitzung zu haben?

Haben Sie so viele Runden pro Sitzung?

Was ist eine Unterhaltungsrunde?

Wir versuchen also, die Tools auch zur Weiterbildung von Entwicklern zu nutzen.

Das ist aber nur der erste Schritt.

Man muss wissen, dass man ein Problem hat, bevor man es beheben kann.

Und so sehen sie zumindest, dass das nicht kostenlos ist.

Früher hatte man das Gefühl, dass KI kostenlos ist.

Und die Leute haben es einfach genutzt.

Ich würde sagen: „Ändere meinen Branch.“ Und die Antwort wäre: „Kein Problem, Annyce, ich ändere den Branch für dich, kostet 5 $.“

An diesem Punkt denken Sie vielleicht: „Okay, ich könnte einfach die Befehlszeile aufrufen und das selbst machen, oder?“

Ich denke, dass wir damit beginnen werden, Ingenieure über die tatsächlichen Kosten aufzuklären.

Ich würde nicht einfach ECS-Instanzen einrichten und mich dann nicht mehr darum kümmern.

Als AWS auf den Markt kam, dachten wir vielleicht: „Ja, ich kann meine eigene Instanz erstellen.“

Und wir haben das Unternehmen so viel Geld gekostet.

Ich glaube, dasselbe passiert jetzt mit den Tokens.

Ich denke, dass praktische Einschränkungen auch wirklich interessante Möglichkeiten bieten, oder?

Denn wenn Sie daran denken, wie wir am Anfang LLMs verwendet haben, haben Sie ihnen alles Mögliche gegeben, oder?

Sie würden den Code analysieren, die Dinge herausfinden und für Sie zaubern, oder?

Das hatte jedoch seinen Preis.

Und die Branche erkennt das auch.

Das zwingt Entwickler und Unternehmen dazu, darüber nachzudenken, wie sie das optimieren können.

Ein konkretes Beispiel: Wenn Sie einen Generator haben, der Komponenten für die Benutzeroberfläche erstellt, die einer bestimmten Struktur entsprechen und Unit-Tests und ähnliche Anforderungen erfüllen müssen, warum sollten Sie die Modelle das on the fly generieren lassen, wenn Sie stattdessen ein deterministisches Tool generieren lassen können, das das für Sie erledigt?

Hier gibt es also viele Möglichkeiten, die Limits für Tokens und die Nutzung zu Ihrem Vorteil zu nutzen und tatsächlich effektiver zu werden.

Ja, und im Rahmen dieser Themen haben wir auf jeden Fall Limits eingeführt, zumindest bei Instacart.

Aber ich denke, das Ziel ist nicht unbedingt, die Nutzung von KI einzuschränken, sondern eine Art Hygiene oder, wie Sie sagen, Introspektion zu schaffen, oder?

Wann sollten Sie bestimmte Modelle im Vergleich zu anderen Modellen verwenden?

Sie brauchen wahrscheinlich weder Fable noch Astra, um die Uhrzeit zu erfahren oder einen Git-Branch zu ändern.

Nicht wahr?

Sie können wahrscheinlich etwas Zeit investieren, um ein Skript zu schreiben, das dann für immer kostenlos ist.

Hier werden keine Tokens verschwendet.

Nicht wahr?

Ich denke, dass die Einschränkung nicht unbedingt dazu dient, die Nutzung einzuschränken, sondern eher dazu, dass man nicht einfach alles auf einmal macht.

Nicht wahr?

Ich stimme dir zu. Letztes Jahr war das Jahr des Experimentierens.

Dieses Jahr geht es eher darum, wie wir diese Technologie effektiv nutzen können.

Ja.

Die Geschichten hier sprechen uns auch sehr an.

Vor allem, wenn man von mehr Experimenten zu einer ausgewogenen Mischung aus Effizienz und Verantwortlichkeit übergeht.

Das ist das Ergebnis verschiedener Investitionen.

Dazu gehören beispielsweise Schulungen für Entwickler und Sichtbarkeit.

Annyce hat ja schon über die Kosten und Informationen zu aktiven Sitzungen gesprochen.

Investitionen in sichere Standardeinstellungen, die unnötige Interaktionen vermeiden, und die Sicherstellung, dass die verwendeten Fähigkeiten effizient sind, um Regressionen und Ähnliches zu erkennen.

Und sie können die Kosten, die sie verursachen, besser nachvollziehen.

Wir haben also Tokenlimits.

Und wenn ein Entwickler diese erreicht, kann er mit einem Klick eine Begründung eingeben und sein Manager kann sie genehmigen.

Wenn also gute Arbeit geleistet wird, möchten wir, dass sie das durchlaufen.

Aber wenn sie vielleicht etwas Verschwenderischeres oder Experimentelleres tun, können sie ihrem Manager nicht erklären, warum sie dafür Geld ausgeben sollten. Das hilft ihnen also auch, das im Auge zu behalten.

Das führt nicht nur dazu, dass wir weniger Arbeit haben, sondern wir können uns auch fragen, ob das die richtige Modellwahl ist.

Ist das das richtige Gewicht dafür?

Die Kosten für diese Tokens sind aufgrund des Wettbewerbsdrucks gesunken.

Aber im Allgemeinen ist es meiner Meinung nach der richtige Ansatz, wenn unsere Entwickler darüber nachdenken, wie sie das Geld, das wir ihnen geben, am besten einsetzen.

Und langfristig, ihnen diese Entscheidung ganz abzunehmen.

Nicht wahr?

Sie möchten automatisches Modell-Routing und ähnliche Funktionen, damit sie sich darüber keine Gedanken machen müssen.

In der Zwischenzeit ist dies jedoch ein fehlerfreier Zustand.

Ja.

Wir haben uns stark auf Dinge wie den Modell-Router konzentriert, um Entwicklern diese Entscheidung abzunehmen und die Aufgabe dem richtigen Modell zuzuordnen.

Es geht aber auch darum, die richtigen Stolpersteine zu haben.

Wir betrachten Tokenlimits aus verschiedenen Blickwinkeln.

Wir möchten den Entwickler nicht blockieren.

Wir möchten aber sicherstellen, dass wir uns Zeit nehmen, um zu prüfen, ob das Geld in den richtigen Bereichen und auf die richtige Weise ausgegeben wird.

Es gibt zum Beispiel Tageslimits, die als Stolperstein dienen und die ein Entwickler selbst aufheben kann.

Sie müssen nur das Portal aufrufen, auf eine Schaltfläche klicken und sagen: „Hey, es ist nichts Überraschendes passiert.

Ich habe die Kontrolle.“

Nicht wahr?

Das ist nur ein einfacher Hebel, denn alle nutzen Schleifen, die über Nacht laufen können, und wir möchten nicht, dass dadurch Kosten entstehen.

Das ist also sehr vernünftig.

Andererseits möchten wir auch sicherstellen, dass unsere Entwickler die besten Modelle zur Verfügung haben.

Für diese Kategorie von Modellen haben wir jedoch ein Frontier-Budget erstellt.

Daher gibt es ein Monatsbudget.

Es ist hoch genug.

Sie sind nicht blockiert.

Wenn Sie die Blockierung aufheben lassen möchten, gibt es ein Ausnahmeverfahren.

Wird an deinen Manager gesendet.

In diesem Moment beschreiben Sie, was Sie tun.

Und wir als Plattformteam sind nicht die Entscheidungsträger, denn diese Entscheidungen sollten dort getroffen werden, wo die Arbeit stattfindet.

Auch bei der Nutzung des Frontier-Modells bieten wir Ihnen volle Flexibilität mit einer Obergrenze.

Der Grund dafür ist, dass der Prozess dadurch letztendlich vorhersehbar wird.

Nicht wahr?

Wir möchten sicherstellen, dass wir bei der Budgetierung unserer Token-Ausgaben – was für alle eine Herausforderung ist – unsere Pläne berücksichtigt haben. Diese Hebel ermöglichen uns das.

Weißt du, was ich an diesen Gesprächen faszinierend finde?

Ich denke, das liegt daran, dass wir alle in Unternehmen arbeiten.

Und so sind Unternehmen

Wir müssen also für jedes einzelne Token bezahlen.

Nicht wahr?

Aber es gibt auch einen ganzen Bereich des Internets, in dem Nutzer für Abos bezahlen.

Für sie ist das also eine ganz andere Rechnung.

Nicht wahr?

Aber ich denke, es ist nur eine Frage der Zeit, bis alle im selben Boot sitzen und über jedes einzelne Token nachdenken müssen.

Und dann wird es wahrscheinlich auch darum gehen, etwas verantwortungsbewusster zu sein, so wie wir es jetzt in Unternehmen tun müssen.

Oder Sie arbeiten in einem Frontier-Lab mit unbegrenztem Budget.

Und dann arbeiten Sie einfach weiter und erstellen viele dieser wirklich spannenden, KI-nativen Arbeitsweisen, die überall auf Twitter zu finden sind.

Alle unsere Unternehmen wollen das widerspiegeln, aber sie wollen nicht die Tokens ausgeben, die…

Wir haben hier Leute, die bei Google arbeiten.

Ich bin sehr neugierig.

Wie funktioniert das?

Wie hoch ist das Budget von Google?

Möchtest du das übernehmen, Luis?

Ich bin nicht die richtige Person, um über die wirtschaftlichen Aspekte zu sprechen.

Google ist ein sehr großes Unternehmen mit vielen verschiedenen Organisationen.

Das ist ein perfekter Abschluss, denn wir sind genau im Zeitplan.

Das war praktisch.

Gerade noch rechtzeitig.

Das ist Moderation vom Feinsten, Leute.

Die PR-Leute sind…

Vielen Dank an unsere Diskussionsteilnehmer und danke, dass Sie zu den ADS gekommen sind.