Vom Handwerk zur Orchestrierung: Wie die Ingenieurteams von Rokt lernten, mit KI zu bauen

Es gibt einen Moment, in dem jedes Entwicklungsteam zuschlägt, in dem KI aufhört, ein cooles Experiment zu sein, und beginnt, eine tragende Infrastruktur zu sein. Du planst es nicht. Eines Tages stellen Sie fest, dass sich Ihre Geschwindigkeitsannahmen geändert haben, Ihre Haltung zur Codeüberprüfung sich geändert hat und die Mitarbeiter in Ihrem Team andere Entscheidungen treffen als vor achtzehn Monaten.

Wir haben diesen Moment bei Rokt erreicht. Wir sind noch nicht fertig damit, es zu schlagen. Aber wir haben genug von der Reise hinter uns, sodass ich beschreiben kann, wie die Etappen tatsächlich von innen aussehen. Das unterscheidet sich von dem, wie sie in Blogbeiträgen und Konferenzvorträgen aussehen.

Stufe 1: Automatische Vervollständigung

Hier fängt fast jeder an, und eine überraschende Anzahl von Organisationen hört stillschweigend auf.

In dieser Phase ist KI ein Produktivitäts-Hack für Einzelpersonen. Tabulatorvervollständigung, die den Kontext versteht. Boilerplate-Generierung. Der gelegentliche Funktionskörper, der fast genau richtig herauskommt. Ingenieure, die Zeit investieren, um zu lernen, wie man präzise Eingabeaufforderungen durchführt, werden schneller. Ingenieure, die das nicht tun, tun es nicht.

Die Organisationsstruktur ändert sich nicht. Überprüfungsverfahren ändern sich nicht. Die Architektur ändert sich nicht. Sie erhalten individuelle Gewinne aus einem Tool, genauso wie ein schnellerer Laptop Ihnen individuelle Gewinne bringt.

Der Fehler, den die Teams hier machen, ist, das Transformation zu nennen. Das ist es nicht — es ist Effizienz. Das ist nicht dasselbe.

Stufe 2: Co-Pilot

Bei der Umstellung auf den Co-Piloten geht es weniger um die Ausrüstung als vielmehr um das Gespräch.

In dieser Phase nimmt KI an Designdiskussionen teil. Sie bitten es nicht nur, einen Funktionstext auszufüllen. Sie bitten das Unternehmen, Ihren Ansatz zu überprüfen, bevor Sie ihn entwickeln, Grenzfälle in Ihrer Spezifikation zu identifizieren und Ihre Architekturentscheidungen zurückzudrängen. Die Ingenieure, die darin gut werden, bewegen sich deutlich schneller als diejenigen, die das nicht tun.

Das sichtbare Signal ist eine wachsende Kluft zwischen Teammitgliedern, die KI als Gedankenpartner betrachten, und denen, die sie als Codegenerator behandeln. Beide Camps verwenden dieselben Tools. Der Unterschied ist das, wonach sie fragen.

Schnelles Handwerk wird hier zu einem echten Qualifikationsunterschied. „Schreib mir eine Funktion, die X ausführt“ ist eine Codegenerator-Eingabeaufforderung. „Hier ist mein aktueller Ansatz, hier ist die Einschränkung, unter der ich arbeite, hier ist, worüber ich mir nicht sicher bin: Was übersehe ich?“ ist eine Aufforderung des Copiloten. Die Ausgänge sind in verschiedenen Ligen.

Die Qualität Ihrer Spezifikationen wird ebenfalls immer wichtiger. Müll rein, Müll raus gilt in beide Richtungen. Die Ingenieure, die den klarsten Kontext schreiben, erhalten das nützlichste Ergebnis. Diejenigen, die wollen, dass KI die Anforderungen anhand vager Eingaben herausfindet, erhalten vagen Code zurück.

Stufe 3: Mitautor

Dies ist die Phase, in der der Identitätswandel stattfindet, und es ist die unangenehmste.

In der Koautorenphase sind KI-Agenten am gesamten Entwicklungszyklus beteiligt: Sie schlagen Testsuiten vor, implementieren sie, führen Testsuiten aus, wiederholen Fehler und generieren PRs. Die menschliche Rolle verlagert sich allmählich von der Konstruktion zur Rezension, vom Schreiben zur Regie.

Die meisten Ingenieurbüros geraten hier ins Stocken, nicht weil die Werkzeuge nicht funktionieren, sondern weil die Kultur nicht aufgeholt hat. Ingenieure, die ihre Karriere damit verbracht haben, handwerkliches Können zu schätzen (die elegante Funktion, die saubere Abstraktion, die gut gedrehte Schleife), stellen plötzlich fest, dass das, was evaluiert wird, nicht ihr Code ist. Es ist ihr Urteil über den Code, den jemand anderes geschrieben hat. Etwas anderes. Plötzlich sehen sie viel mehr wie Leads aus und viel weniger wie ihr mentales Modell eines einzelnen Mitwirkenden.

Die Organisationen, die diese Phase am schnellsten überstehen, sind diejenigen, die den Rollenwechsel ausdrücklich kulturell genehmigen. Bei Rokt bedeutete das, direkt mit unseren Teams umzugehen: Ihre Aufgabe ist es nicht mehr, Code zu schreiben. Es geht darum, die Absicht klar zum Ausdruck zu bringen, die Ergebnisse rigoros zu überprüfen und die Ergebnisse dessen, was passiert, zu kontrollieren. Der Code ist dem nachgelagert. Code wird zu nur einem Tool unter vielen anderen, um Ergebnisse für Kunden zu erzielen.

Die architektonischen Voraussetzungen erwiesen sich auch hier als enorm wichtig. Dienste, die unabhängig voneinander bereitgestellt werden, Eigentümer ihrer Daten sind und eher Verträge als interne Komponenten offenlegen, sind architektonisch sicher für die Entwicklung durch Agenten. Eng gekoppelte Systeme sind es nicht. Sie können Agenten nicht sicher in einer Codebasis arbeiten lassen, in der eine Änderung an einer Stelle unvorhersehbar in zehn andere übergreifen kann. Wir hatten bereits auf eine Verkapselung gesetzt, und diese Investition zahlte sich auf eine Weise aus, mit der wir bei der Umsetzung nicht vollständig gerechnet hatten.

Stufe 4: Supervisor

Hier konvergiert die Rolle des Entwicklers mit der Rolle des technischen Managers, und das verändert, wie ältere technische Talente tatsächlich aussehen.

In der Supervisor-Phase überprüfen Sie keine Codezeilen. Sie steuern eine Flotte von Agenten: Sie legen Absichten fest, überprüfen die Richtung, setzen Standards durch und achten auf Abweichungen. Die Fähigkeiten, auf die es ankommt, waren schon immer wichtig für ein gutes technisches Management. Klare Kommunikation darüber, wie gut aussieht. Urteil darüber, was akzeptiert und was zurückgeschickt werden soll. Bewusstsein für systemische Risiken.

Die Ingenieure, die sich hier auszeichnen, sind nicht unbedingt diejenigen, die den besten Code geschrieben haben. Sie sind diejenigen, die am präzisesten kommunizieren. Wer kann sich 400 Zeilen der generierten Ausgabe ansehen und schnell die drei Dinge identifizieren, die falsch sind. Wer versteht das System ganzheitlich genug, um eine technisch korrekte Lösung zu erkennen, die architektonisch falsch ist. Diejenigen, die zwei Agenten gegeneinander antreten lassen und schnell beurteilen können, wie erfolgreich sie sind.

Claire Southey, unsere Chief AI Officer, hat es kürzlich gut ausgedrückt:

Die entscheidende Fähigkeit zukünftiger Softwareteams wird nicht darin bestehen, wie viel Code sie schreiben, sondern wie klar sie ihre Absicht ausdrücken, von Ambiguität zu Klarheit übergehen und die Auswirkungen dessen, was sie entwickeln, steuern.

Das ist eine Stellenbeschreibung für einen Supervisor. Es beschreibt die Senior-ICs und führt unsere derzeit schnellsten Teams an. Unser Ziel bei diesem Übergang ist es, dafür zu sorgen, dass er für alle gilt, vom rauen Hochschulabsolventen bis hin zu unseren Führungskräften.

Was bringt die Transitions zum Kleben

Ein paar Dinge waren wichtiger als wir erwartet hatten.

Eine asphaltierte Straße. Zugelassene Tools mit guten Standardwerten verhindern Reibung und nehmen jedem Team die Entscheidung, welches Tool ich überhaupt verwenden sollte. Wir wollten nicht fünfzehn verschiedene KI-Codierungs-Setups im gesamten Ingenieurwesen. Wir haben den guten Weg zum einfachen Weg gemacht.

Gemeinsames Lernen. Die Ingenieure, die in jede Phase vordrangen, lernten zunächst Dinge, die der Rest der Organisation benötigte. Wir haben Mechanismen entwickelt, um diese Erkenntnisse schnell zu veröffentlichen, und zwar über asynchrone Kanäle und nicht vierteljährlich an externen Standorten, sodass die Leute in Echtzeit sehen konnten, was funktionierte.

Messung. Wir haben bei der internen Einführung von KI die gleiche Sorgfalt angewandt wie bei Produktentscheidungen: Instrumentierung, Kontrollgruppen, klare Erfolgskriterien. „Es fühlt sich schneller an“ ist keine Metrik. Wir haben die KI-gestützte Leistung (Zykluszeit, Überprüfungszyklen, Fehlerraten) gemessen, um zu sehen, ob wir uns tatsächlich verbessert haben oder ob wir uns nur so fühlten.

Die Übergänge zwischen den Stufen erfolgen nicht automatisch. Sie erfordern bewusste Entscheidungen darüber, wie die Arbeit strukturiert wird, für welche Fähigkeiten Sie Mitarbeiter einstellen und was Sie von Ingenieuren erwarten. Unternehmen, die den Übergang als passiv betrachten (die Tools kaufen, warten, bis die Kultur folgt), stecken zwischen den Phasen fest und fragen sich, warum sich der ROI nicht einstellt.

Die Tools sind in Ordnung und sie werden immer besser. Der Engpass sind fast immer die organisatorischen Entscheidungen, die sie umgeben. In dieser Phase entwickelt sich die Technologie schneller als die Kultur. Es ist meine Aufgabe als technische Führungskraft, dafür zu sorgen, dass die Kultur Schritt halten kann.

Bei Rokt hat es sich verschärft, diese Entscheidungen richtig zu treffen. Dieselbe technische Kultur, die die Agentenentwicklung realisierbar gemacht hat, ermöglicht es uns, genauso schnell voranzukommen wie auf der Produktseite: Versandmodelle, die mit jeder Transaktion intelligenter werden, Aufbau einer Personalisierungsinfrastruktur, die innerhalb von Millisekunden funktioniert, und die Dinge, die für unsere Kunden wichtig sind, wiederholen, ohne den Einfluss organisatorischer Trägheit. Die obigen Stufen sind nicht abstrakt. Darauf haben wir aufgebaut.

‍

Melissa Benua ist VP of Developer Experiences bei Rokt.

‍