Ich rede nicht gerne mit Robotern

Ich habe ein Android-Handy, aber ich habe die Sprachbefehle deaktiviert. Ich hatte noch nie einen Alexa. Ich bin mir nicht sicher, was Siri genau macht, weil ich ohne sie, die mir eine Playlist findet, durchs Leben gekommen bin. Also, als KI-Coding-Tools schwer zu ignorieren wurden, kam ich langsam dazu. Eine Zeit lang habe ich das gemacht, was manche 'Ein-Schuss-Methode' nennen: Ich arbeitete, wie ich es immer getan hatte, delegierte gelegentlich einen Teil der Arbeit an die KI und wartete dann ab, was zurückkam. Das ist ein wirklich cooler Ansatz für Leute, die gerne Glücksspiele mögen.

Für mich war ein Teil der Reibung die Chat-Oberfläche selbst. Die Vorstellung, ein Gespräch mit dem Modell zu führen, kam mir albern vor. Ich baue Dinge. Ich handle nicht mit Textfeldern aus.

Aber Spezifikationsgetriebene Entwicklung funktioniert nicht so. Man definiert das Problem präzise, teilt dem Modell mit, welche Dateien zu berücksichtigen sind, beschreibt das gewünschte Ergebnis, bespricht den Plan im Chat, bevor KI eine Codezeile generiert. Heutige KI-Modelle sind schnell im Codieren, aber immer noch gefährlich inkonsistent bei Strategische Entscheidungsfindung. Wenn man mit KI arbeitet, besteht die Aufgabe darin, Design-Urteilsvermögen in eine Schriftliche Spezifikation umzuwandeln, sodass man der KI eine Liste von Einfache Arbeitsschritte geben kann, die dem entsprechen, was man tun würde, wenn man den Code selbst eingeben würde. Um diese Spezifikation richtig hinzubekommen, muss man Abstimmen.

Ich habe das in den letzten sechs Monaten gelernt. Und ich bin ziemlich gut darin geworden. Ich schreibe selten/nie Code von Hand, doch ich liefere mehr Funktionen als je zuvor. Und da ich den Softwareentwurf nicht dem Modell überlasse, setze ich die gleichen Qualitätsstandards durch, die ich in meiner 25-jährigen Karriere beim Bau von digitalen Produkten zu wahren gelernt habe.

Was ich nicht erwartet hatte, war, wie schwer es zu lehren wäre.

Bin ich schon Picasso?

Es gibt die Vorstellung (bei der oberen Führungsebene?), dass LLM-Werkzeuge die Produktivität aller Ingenieure steigern werden. In der Praxis habe ich das nicht gesehen. Was ich sehe, ist, dass anpassungsfähige, erfahrene Ingenieure ein Vielfaches von dem erreichen, was sie früher produziert haben, während andere das Gleiche oder weniger produzieren.

Das ist keine gute Situation für Anfänger. KI-Codierungswerkzeuge erscheinen einfach, weil ihre Benutzeroberflächen nur Textboxen sind. Aber man wird nicht Picasso, indem man willkürlich Farbe auf eine leere Leinwand schmiert.

Parallel-Implementierungs-Syndrom

Ich schätze Junior-Ingenieure aus vielen Gründen, nicht zuletzt, weil sie meine Lieblingsmenschen sind, mit denen ich zusammenarbeite! Ihre Aufgeschlossenheit ist noch nicht verkümmert, und sie helfen mir, Dinge anders zu sehen. Kürzlich machte ich eine KI-Lernreise mit einem jungen Ingenieur, der intelligent ist, begeistert von KI-Werkzeugen, bereit, sich einzubringen, und überhaupt nicht zögerlich, mit der KI zu sprechen.

Und doch funktionierte es irgendwie nicht.

Das erste Anzeichen war das Authentifizierungssystem. Sie musste OAuth zu einem bestehenden Dienst hinzufügen, und sie forderte das Modell auf, den gesamten Authentifizierungsablauf in einer riesigen Spezifikation zu erstellen. Login, Token-Aktualisierung, Sitzungsverwaltung, rollenbasierter Zugriff und der Abmeldeablauf. Alles. Das Modell erfüllte die Aufgabe gerne. Es produzierte mehrere hundert Codezeilen, die komplett aussahen, mit 100% Code-Abdeckung und bestehenden Tests.

Aber als ich es überprüfte, waren die Probleme strukturell. Das Modell hatte einen neuen Sitzungsspeicher erstellt, anstatt den zu verwenden, den wir bereits hatten. Es führte ein Token-Aktualisierungsmuster ein, das mit unserem API-Gateway in Konflikt stand. Die rollenbasierte Zugriffslogik duplizierte Geschäftsregeln, die bereits in einer gemeinsamen Middleware existierten. Technisch gesehen war nichts davon falsch—es funktionierte. Architektonisch war alles davon falsch.

Ich setzte mich zu ihr und stellte eine einfache Frage: „Bevor du das eingegeben hast, wusstest du, wie wir heute mit Sitzungen umgehen?“ Sie zögerte. „Nicht genau.“ Das war die Lücke. Sie hatte das Gebiet nicht kartiert, bevor sie das Modell bat, darauf aufzubauen.

Der nächste Versuch verlief anders, aber nicht ausreichend. Sie bat das Modell, den Anmeldeablauf zu ändern, um einen neuen Anbieter zu unterstützen. Dieses Mal wählte sie einen kleineren Umfang, was gut war. Aber sie beschrieb die Änderung in Bezug auf das, was die Benutzeroberfläche tun sollte, und nicht in Bezug auf das, was der vorhandene Code bereits handhabte. Das Modell, das keinen Grund hatte, über unsere bestehende Anbieterabstraktion Bescheid zu wissen, schrieb eine parallele Implementierung von Grund auf. Gleiches Ergebnis: funktionierender Code, falsche Architektur.

Wir besprachen, was geschehen war. Ich riet ihr, das Modell wie einen neuen externen Mitarbeiter im Team zu betrachten. Talentierte, schnelle, aber ohne Erfahrung mit unserer Codebasis. Man würde einem externen Mitarbeiter nicht einfach das Projekt übergeben und sich verabschieden. Stattdessen würde man erklären: Hier ist unser Sitzungsspeicher, hier die Middleware, und hier das Muster zur Integration eines neuen Anbieters. Passen Sie Ihre Arbeit entsprechend an.

Sie verstand das Konzept. Aber die nächsten paar Runden zeigten mir, dass das Konzept der einfache Teil war. Sie bekam einen einzigen Plan vom Modell und gab grünes Licht, ohne nach Alternativen zu drängen. Sie sah die Bereitschaft des Modells, umfangreiche Codeänderungen vorzunehmen, als gründlich; ich sah es als unnötiges Risiko. Sie hatte noch nicht den Instinkt zu sagen: 'Nein, das ist zu viel Angriffsfläche für diese Änderung.'

Eine erfahrene Ingenieurin hätte dieselbe OAuth-Aufgabe in sechs oder sieben fokussierten Runden bewältigt, jede auf einen Teil des Systems begrenzt, den sie bereits verstand.

Soziale Kompetenzen sind die neuen Fachkompetenzen.

Das mag nach Aufwand klingen, der die Produktivitätsgewinne durch KI-Codierung zunichtemachen würde. Aber das sind keine neuen Fähigkeiten. Erfahrene Entwickler haben das schon immer im Kopf getan. Der Unterschied ist, dass die Spezifikationsgetriebene Entwicklung die Planung des Software-Designs für alle Aufgaben externalisiert. Die Designverhandlung, die früher intern, zwischen Ihnen und Ihrem eigenen Urteil, stattfand, findet nun in einem Chatfenster statt.

Bevor du den Chat öffnest, musst du wissen, was du willst. Nicht die Implementierung, sondern das Verhalten, die Randbedingungen, die Form der Sache. Du musst deine Codebasis gut genug kennen, um dem Modell zu sagen, wo seine Arbeit passen muss. Wenn das Modell mit einer Antwort zurückkommt, wird es wahrscheinlich laufen. Das reicht nicht. Du musst wissen, ob es tatsächlich in das System passt, das du bereits hast.

Manchmal erkennt man, dass das Modell recht hat und man unrecht hat, und man braucht die Bescheidenheit, um das fair zu bewerten.

Während des gesamten Prozesses ist es Geduld, die diejenigen, die diese Werkzeuge gut nutzen, von denen unterscheidet, die sie schnell nutzen: die Bereitschaft, fünf- oder sechsmal hin und her zu gehen, anstatt sich in der zweiten Runde mit etwas Mittelmäßigem zufriedenzugeben. Es gibt auch die Fähigkeit, präzise über Code zu schreiben, ohne Code zu schreiben, und Datenflüsse, Randfälle und Fehlermodi in einfacher Sprache zu beschreiben. Und es gibt Gespür, das schwer zu definieren, aber leicht zu erkennen ist: ein Gefühl dafür, wie gute Software aus der Perspektive der Langzeitwartung wirkt, nicht nur, ob sie läuft.

Und dann ist da der unangenehme Teil. Die meisten dieser Fähigkeiten sind Mustererkennung, die aus Jahren des Fehlermachens aufgebaut ist. Du erkennst eine schlechte Architekturentscheidung, weil du mit den Konsequenzen einer solchen gelebt hast. Du lehnst die erste Antwort des Modells ab, weil du schon einmal deine erste Idee umgesetzt hast und es bereut hast.

Junior-Ingenieure werden in Situationen versetzt, in denen sie Designabstimmung auf hohem Niveau durchführen müssen, aber es scheint keinen Lehrplan dafür zu geben. Es ist an der Zeit, von “LeetCode” zu Designabstimmung überzugehen, und dies wird das Thema zukünftiger Beiträge in dieser Reihe sein.

Anhang

Soziale Kompetenzen für das Aushandeln einer Spezifikation mit KI

Während der Verhandlung

• Code-Leseflüssigkeit: Scannen Sie, was das Modell erzeugt, auf strukturelle Solidität, nicht nur auf Syntax. Sie lesen auf Passgenauigkeit, nicht auf Fehler. Warum es wichtig ist: Das Modell kann gültigen Code erzeugen, der nicht zu Ihrem System gehört. Sie müssen das schnell erkennen.

• Architekturgeschmack: Erkennen, wann eine Lösung technisch gültig ist, aber für dieses System falsch ist. Warum es wichtig ist: Das Modell weiß nicht, was 'falsch für uns' bedeutet. Du weißt es.

• Kreative Lenkung: Finde alternative Rahmen, wenn das Modell feststeckt. Formuliere das Problem neu, biete eine Analogie an, begrenze es anders. Warum es wichtig ist: Das Modell reagiert darauf, wie du Sachverhalte rahmst, und ein besserer Rahmen führt zu einem besseren Ergebnis.

• Wissen, wann man eine Position beziehen sollte: Das Modell präsentiert Optionen neutral. Sie entscheiden und artikulieren warum ein Ansatz für Ihren Kontext besser ist. Warum es wichtig ist: Das ist Ingenieururteil, und es braucht Jahre, um es aufzubauen.

• Produktive Skepsis: Gehen Sie davon aus, dass die erste Antwort des Modells ein Entwurf ist, keine Lösung. Kein Zynismus, sondern die Gewohnheit, vor der Annahme einen Belastungstest durchzuführen. Warum es wichtig ist: Erstentwürfe sind verführerisch, weil sie flüssig sind. Flüssigkeit ist nicht Korrektheit.

• Wissen, was man nicht weiß: Erkenne, wenn das Modell richtig liegen könnte und du falsch liegst. Warum es wichtig ist: Die Verhandlung geht in beide Richtungen. Manchmal bringt sie einen Ansatz zum Vorschein, den du nicht in Betracht gezogen hast, und du brauchst die Bescheidenheit, um ihn fair zu bewarten.

Über den gesamten Prozess

• Geduld: Fünf oder sechs Mal hin und her gehen, anstatt bei Runde zwei etwas Mittelmäßiges zu akzeptieren. Warum es wichtig ist: Dies unterscheidet diejenigen, die das Werkzeug gut nutzen, von denjenigen, die es schnell nutzen.

• Technische Kommunikation: Präzise über Code schreiben, ohne Code zu schreiben. Datenflüsse, Zustandsänderungen, Randfälle und Fehlermodi in einfacher Sprache beschreiben. Warum es wichtig ist: Dies ist schwieriger, als die meisten Ingenieure denken, und es ist die primäre Schnittstelle zwischen Ihnen und dem Modell.

• Komplexität im Kopf behalten: Verfolgen, wie die aktuelle Entscheidung mit drei anderen Teilen des Systems interagiert, von denen das Modell nichts weiß. Warum es wichtig ist: Das Modell hat keinen persistenten Architekturkontext. Du bist das Arbeitsgedächtnis.

• Software-Intuition: Ein Gefühl dafür, wie gute Software sich aus der Perspektive des Nutzers anfühlt. Nicht nur "funktioniert es", sondern "ist dies die richtige Erfahrung, das richtige Verhalten, das richtige Maß an Komplexität." Warum es wichtig ist: Ohne dies wirst du Lösungen akzeptieren, die funktional, aber falsch sind.

• Wissen, wann man aufhören muss: Erkenne, wann die Spezifikation gut genug ist, um an die Umsetzung weiterzugeben, und wann Überverfeinerung stattfindet. Warum es wichtig ist: Die Grenznutzenabnahme ist real. Irgendwann kosten weitere Verhandlungen mehr, als sie verbessern.