6 Alle reden über KI-gestützte Entwicklung. Benchmarks. Produktivitätsgewinne. Zehnfach-Engineers. Code in Sekunden. Weniger Beachtung findet, was passiert, nachdem die KI den Code geschrieben hat. Bei Scality haben wir gelernt, dass die eigentliche Verbesserung nicht im Prompt stattfindet. Sie findet im Diff statt – im Raum zwischen dem, was die KI generiert, und dem, was der Engineer letztlich ausliefert. KI verbessert sich nicht von selbst. Sie verbessert sich, wenn jemand die Ergebnisse untersucht, hinterfragt und die Erkenntnisse ins System zurückführt. Ein Blick auf die tatsächliche Arbeit Als VP of Engineering verantworte ich acht Engineering-Teams, die an Systemen für verteilten Speicher arbeiten – in mehreren Sprachen und Technologien, darunter C, Go, Python, JavaScript und React. Unsere Arbeit reicht vom Low-Level-Hardwaremanagement bis zur Verwaltungsoberfläche, die Kunden täglich nutzen. Zu meinen Aufgaben gehört es unter anderem, Performance-Standards zu sichern und die Entwicklung unserer Engineering-Führungskräfte zu unterstützen. Im vergangenen Jahr, als KI-Tools Teil unseres Workflows wurden, habe ich mich auf ein Prinzip aus der Fertigungspraxis gestützt: Gemba (auf Englisch). . Mehrmals pro Woche setze ich mich mit einem Engineer und seiner Führungskraft zusammen. Wir sehen uns keine Folien an. Wir diskutieren keine Roadmap-Prioritäten. Wir untersuchen die tatsächliche Arbeit: Die echten Prompts Den generierten Code Die finale Version, die ausgeliefert wird Und vor allem den Diff zwischen dem, was die KI erzeugt hat, und dem, was der Engineer letztlich ausliefert. Wer verstehen will, wie KI die Engineering-Praxis verändert, findet dort das entscheidende Signal. Gemba in der KI-Entwicklung: Die eigentliche Werkhalle ist die Codebasis In der Fertigung bedeutet Gemba, in die Werkhalle zu gehen – dorthin, wo die Arbeit tatsächlich stattfindet. Für Engineering-Teams ist die Werkhalle die Codebasis. In einem KI-gestützten Workflow gehören auch Prompts, gemeinsame Konfigurationsdateien und die Ergebnisse dieser Systeme dazu. Führung bedeutet in diesem Umfeld nicht, Tools freizugeben. Es geht darum, nah genug an der Arbeit zu bleiben, um zu verstehen, wie sich diese Tools in der Praxis verhalten. Wenn Sie mit Engineers zusammensitzen und gemeinsam Diffs prüfen, sehen Sie Urteilsvermögen in Aktion: Wo etwas vereinfacht wurde Wo ein Stück Logik vollständig verschwunden ist Wo eine Abstraktion umgeschrieben wurde, um besser zum System zu passen Wo der generierte Code unverändert übernommen wurde Kennzahlen zeigen diesen Detailgrad nicht. Sie sehen ihn nur, wenn Sie direkt auf die Arbeit schauen. Was Diffs über KI-generierten Code verraten KI-Coding-Tools sind unbestreitbar nützlich. Sie beschleunigen Iterationen und nehmen dem Entwicklungsprozess viel mechanische Arbeit ab. Doch wer sich Zeit für die Diffs nimmt, erkennt bestimmte Muster schnell. KI neigt zum Over-Engineering. Sie führt Abstraktionen ein, die für das konkrete System nicht nötig sind, oder wiederholt Logik über Schichten hinweg, wo ein menschlicher Engineer sie zusammenführen würde. Manchmal funktioniert der generierte Code technisch und besteht sogar die Tests, ist aber trotzdem nicht produktionsreif. Nichts davon ist überraschend. Das Modell optimiert auf allgemeine Lösungen, Engineers optimieren auf den Kontext. In der Spannung zwischen diesen beiden Perspektiven steckt viel Engineering-Wissen. Warum der Diff wichtiger ist als der Prompt Das erste Ergebnis ist nicht das Artefakt. Das aussagekräftige Artefakt ist die Differenz zwischen der KI-Ausgabe und der finalen, vom Engineer geprüften Version. Diese Differenz enthält architektonisches Urteilsvermögen, Abwägungen zur Performance, in der Produktion erlernte Konventionen und die Disziplin, die Systeme zuverlässig hält. Wer diese Lücke nicht untersucht, verpasst das Signal. Und wenn die Begründung hinter diesen Änderungen nie festgehalten wird, verbessert sich die Organisation nicht wirklich. Der Code wird besser, aber das System, das den Code erzeugt, nicht. Engineers bleiben Herr über die Feedbackschleife Nicht die KI verantwortet die Feedbackschleife, sondern die Engineers. KI kann sich weder selbst bewerten noch selbst korrigieren. Sie hat kein Urteilsvermögen und trägt keine Verantwortung. Wenn KI Code erzeugt, der geändert werden muss, ist es der Engineer, dem die Folgen nicht egal sind. Das eigentliche Feedback besteht aber nicht nur darin, den Code zu korrigieren. Es geht darum zu fragen, warum die KI ihn so erzeugt hat, und dann das System anzupassen, das die Ausgabe prägt. Das kann bedeuten, gemeinsame Prompt-Frameworks zu verfeinern, Konfigurationsdateien zu aktualisieren, architektonische Leitlinien zu stärken oder Standards festzuschreiben, die in Diffs immer wieder auftauchen. Mit anderen Worten: Menschen korrigieren nicht nur den Code. Sie verbessern das System, das ihn erzeugt. Wenn wiederkehrende Muster aus Diffs mit der Zeit in Prompts, Konfigurationen und Engineering-Standards zurückfließen, werden die Tools nützlicher – sie bleiben aber Werkzeuge innerhalb eines Systems, das Menschen verantworten. KI-Einführung ist eine Engineering-Praxis, keine Tool-Entscheidung Viele Organisationen behandeln die Einführung von KI als Tool-Entscheidung: Welches Modell? Welcher Anbieter? Welche Lizenz? Diese Fragen sind wichtig, doch Reife entsteht nicht durch Beschaffung. Sie entsteht durch die Beteiligung der Führung an echten Workflows: Reibung direkt beobachten, wiederholte Korrekturen in Standards überführen und das Engineering-System kontinuierlich verbessern. KI wird besser, wenn Ihr Engineering-System besser wird – und das erfordert Disziplin. Die Disziplin hinter der Produktivität KI ist leistungsstark. Sie beschleunigt Iterationen und ermöglicht Engineers, Dinge auszuprobieren, die früher viel länger gedauert hätten. Sie verbessert aber nicht automatisch, wie eine Organisation Software entwickelt. Verbesserung geschieht nach wie vor so wie immer: durch Reviews, durch Diffs, durch die Summe kleiner Engineering-Entscheidungen, die Produktionssysteme über die Zeit prägen. Diese Haltung bestimmt, wie wir bei Scality KI einführen – genauso, wie wir resiliente, leistungsstarke Software entwickeln: durch Beobachtung, Iteration und disziplinierte Engineering-Praxis, nicht durch Hype.
