Wenn ich sage, dass wir KI-Systeme bauen, nicken die Leute. Wenn ich sage, dass ich Unternehmen und Teams in die Welt von AI Driven Development und Vibe Coding führe, fragen sie: Was heisst das konkret?
Das Missverständnis
Die meisten Unternehmen glauben, KI einführen sei ein Technikprojekt. Man kauft Lizenzen, man richtet einen Coding Agent ein, man macht eine Schulung. Fertig.
Dann passiert Folgendes: Zwei Entwickler benutzen es intensiv und werden schnell. Fünf probieren es aus und lassen es wieder. Der Rest macht weiter wie bisher. Nach drei Monaten sagt der CTO, die Produktivität sei nicht messbar gestiegen. Und er hat recht.
Was ich tatsächlich mache
Ich komme in ein Team, das Software baut. Banken, Telekommunikation, Industrie. Leute, die ihr Handwerk können. Und ich arbeite mit ihnen daran, dass sie nicht mehr jede Zeile selber schreiben, sondern Agenten führen, die das für sie tun.
Das klingt nach weniger Arbeit. Es ist andere Arbeit. Statt zu schreiben, muss man beschreiben. Statt zu debuggen, muss man prüfen. Statt eine Lösung zu bauen, muss man entscheiden, welche von drei generierten die richtige ist, und warum.
Ein Senior Entwickler, der das versteht, wird in wenigen Wochen sehr viel schneller. Einer, der es nicht versteht, bekommt mehr Code und mehr Probleme.
Wie so eine Einführung abläuft
Ich habe das inzwischen oft genug gemacht, um ein Muster zu sehen.
Woche 1 bis 2: Zuschauen. Wie arbeitet das Team heute? Wo geht die Zeit hin? Welche Regeln gibt es, und welche sind nur im Kopf von zwei Leuten?
Woche 3 bis 4: Ein echtes Ticket, mit einem Agenten, zusammen. Kein Beispiel, kein Spielprojekt. Etwas aus dem Backlog, das sowieso gemacht werden muss.
Woche 5 bis 8: Regeln aufschreiben. Architektur, Konventionen, was der Agent darf und was nicht. Das ist der Teil, den alle unterschätzen.
Danach: Das Team arbeitet allein. Ich komme in Abständen zurück und schaue, was sich eingeschlichen hat.
Der wichtigste Schritt ist der dritte. Wenn ein Team seine Regeln nicht aufschreibt, arbeitet der Agent nach seinen eigenen. Und die passen nie zu einem System, das fünfzehn Jahre gewachsen ist.
Warum NeoCoder dabei hilft
Wir haben NeoCoder zuerst für uns gebaut, weil wir unsere fünfzig Micro-Modelle und unsere eigenen Projekte anders nicht mehr im Griff hatten. Inzwischen nehme ich es in Teams mit, weil es genau die Struktur erzwingt, die ein Team am Anfang noch nicht hat.
Ein Architekt-Agent, der zuerst Spezifikation und Contract schreibt. Coding Agents, die nur gegen diesen Contract arbeiten. Eine QS, die nicht der Agent selbst ist. Artefakte statt Chat-Verläufe. Das sind keine Features. Das sind die Regeln, die ein gutes Team sowieso hätte, nur dass sie jetzt nicht mehr optional sind.
Für ein Team, das einsteigt, ist das eine enorme Erleichterung. Es muss nicht selber herausfinden, wie man Agenten davon abhält, sich gegenseitig Dinge in den Code zu bauen. Das haben wir schon herausgefunden, auf unsere Kosten.
Über den Widerstand
Es gibt in jedem Team jemanden, der nicht will. Meistens ist es nicht der Schlechteste, sondern einer der Besten. Jemand, der stolz auf seinen Code ist und zu Recht.
Ich versuche nicht, diese Person zu überreden. Ich gebe ihr die schwierigste Aufgabe. Die Regeln schreiben. Entscheiden, welche Patterns wo gelten. Den Agenten zeigen, wie dieses System funktioniert. Das ist Architekturarbeit, und meistens merkt die Person nach ein paar Wochen, dass sie genau das immer wollte und nur nie Zeit dafür hatte.
Was danach anders ist
Fakt ist: Die Teams werden kleiner. Das sage ich offen, auch wenn es niemand gern hört. Wofür man zwanzig Leute hatte, reichen fünf gute mit Agenten.
Aber die fünf arbeiten anders. Sie reden mehr über Architektur und weniger über Syntax. Sie streiten über Contracts statt über Einrückungen. Sie wissen, was das System kostet, weil sie jeden Agenten-Aufruf sehen. Und sie haben, zum ersten Mal seit Jahren, Zeit für die Fragen, die wirklich schwierig sind.
Das ist die Welt, in die ich Teams bringe. Nicht die Welt, in der KI alles macht. Die Welt, in der Menschen wieder das machen, wofür man sie eingestellt hat.
Wer mit mir arbeiten will, bekommt keine Schulung und kein Tool. Er bekommt ein paar Wochen, in denen sein Team lernt, Code zu führen statt zu schreiben. Danach braucht er mich nicht mehr. So soll es sein.
Geschrieben von mir. Die Gedanken, die Werte, die Learnings, die Fehler: alles meins. Grammatik und Rechtschreibung korrigiert unser eigenes Twin-Modell, das auf meinen Texten trainiert ist. Manchmal bleibt ein Hüpfer drin. Das ist dann auch von mir.