Überall liest man von Entwicklern, die angeblich fünf KI-Assistenten gleichzeitig orchestrieren und ihre Produktivität verzehnfacht haben. Klingt beeindruckend. Entspricht nur nicht meiner Erfahrung.
In den letzten Monaten habe ich meinen kompletten Entwicklungsworkflow auf KI-Unterstützung umgestellt – von ChatGPT-Copy-Paste über Aider bis zu Claude Code. Was dabei wirklich passiert ist? Ich bin vom Programmierer zum Dirigenten geworden.
Das bedeutet nicht, dass ich nichts mehr tue. Es bedeutet, dass ich anders arbeite: Ich orchestriere, ich reviewe, ich beaufsichtige. Wie ein Chef, der einen brillanten, aber manchmal zerstreuten Mitarbeiter einarbeitet.
Der eigentliche Produktivitätsgewinn? Nur in Teilen die Geschwindigkeit. Wichtig ist auch die Ruhe im Kopf. Und die Qualität durch Pair-Programming.
Im neuen Blogartikel beschreibe ich meinen Weg – ehrlich, ohne Marketing-Hype.
Der Anfang: Copy-Paste war gestern
Ende letzten Jahres bekam ich einen Tipp von einem Kollegen aus einem Partnerunternehmen. Er schwärmte von einem Tool namens Aider. Bis dahin kannte ich das KI-gestützte Programmieren so: Man fragte ChatGPT nach einer Lösung, kopierte Code hin und her, passte manuell an. Funktionierte, war aber sperrig. Man nutzte es sehr punktuell.
Aider war anders. Das Tool arbeitete direkt in Visual Studio Code. Ich gab Anweisungen ein, und die KI schaute sich eigenständig meine Quelltexte an, veränderte sie, fragte nach weiteren Dateien, wenn sie Kontext brauchte. Das fühlte sich zum ersten Mal nach echtem Pair-Programming an – nur dass mein Partner eine KI war.
Das Schema war simpel: Die KI schrieb Code, ich reviewte. Kleine, konkrete Aufgaben. Fehlerarm und überraschend schnell.
Zwei Gespräche, die alles veränderten
Dann kamen zwei Gespräche, die meine Perspektive verschoben.
Ein Kollege aus einer Partnerfirma sagte zu mir: „Nee, nee, du sagst dem nur noch, was du willst. Du wirst nicht mehr programmieren.“ Ich war skeptisch. Aber ich behielt es im Hinterkopf.
Der zweite Input kam von einem freiberuflichen Entwickler, den ich aus anderen Kontexten kannte. Er hatte seinen kompletten Arbeitsablauf automatisiert. Er schrieb Tickets, eine KI erledigte die Implementierung, er schaute sich am Ende das Ergebnis an. Seine wichtigste Erkenntnis: Die KI muss alles testen. Und dazu muss sie ihre eigenen Tests schreiben.
Das war der Schlüssel.
Der erste echte Test: Performance-Optimierung
Ich wandte diese Erkenntnisse auf ein Kundenprojekt an. Die Software hatte Performance-Probleme, und ich kannte über die Jahre bestimmte Hotspots – Stellen, die ich aus verschiedenen Gründen nie angefasst hatte. Zu komplex. Zu riskant. „Das fass ich lieber nicht mehr an.“. Ganz real ist es ja so, dass man ggü. den Kunden teils nur verlieren kann. Bestimmte Codeteile „laufen“. Wer sie optimiert, weil es danach „besser“ ist… bringt dem Kunden keine sichtbaren Ergebnisse. Außer potentieller Fehler. Und kann somit primär verlieren 😁.
Ein Beispiel waren Signalverarbeitungsfilter. Ehrlich gesagt: Für das menschliche Gehirn ist es schwer zu erfassen, ob die Ergebnisse nach einer Änderung noch stimmen. Man müsste sich mit Excel hinsetzen, manuell validieren. Das hatte ich nie gemacht.
Jetzt ließ ich Claude zuerst Unit Tests für diese Filter schreiben. Als die Tests funktionierten, ließ ich die Filter umschreiben. Danach prüfte ich optisch, ob die Kurven noch stimmten – und ließ die Tests laufen. Sie liefen durch.
Das Ergebnis: Erhebliche Performance-Verbesserungen an Stellen, die ich als Mensch nie angefasst hätte.
Die Grenze: Wenn 250.000 Token nicht reichen
Das zweite Optimierungsprojekt war komplexer. Es ging um GUI-Komponenten, Graphen, die effizienter gezeichnet werden sollten. Hier wurde Gott und die Welt optimiert, probiert, verworfen.
Ich merkte, wie Claude Open (4.5) an seine Grenzen kam. Mit 250.000 Token Kontextfenster verlor das Modell bei diesem großen Projekt manchmal den Überblick. Ich war mir nicht mehr sicher, ob es noch alle Zusammenhänge verstand.
Eine interessante Beobachtung machte ich dabei: Ich testete das nominell schwächere Sonnet, das aber eine Million Token Kontext bietet. Und ich bin mir nicht sicher, ob das nominell schwächere Modell nicht durch die bessere Übersicht bei komplexen Aufgaben bessere Ergebnisse lieferte. Das kann man bei solchen Projekten ehrlich gesagt nur noch schwer auseinanderhalten.
Die neue Rolle: Vom Coder zum Dirigenten
Was passierte in den folgenden Monaten? Ich wurde zum – nennen wir es – „Poweruser“. Aber nicht in dem Sinne, dass ich immer mehr selbst programmierte. Sondern in dem Sinne, dass ich orchestrierte.
Ich ertappe mich heute dabei, dass ich fast nur noch KIs dirigiere. Ich sage einer künstlichen Intelligenz, was sie tun soll. Ich reviewe. Ich beaufsichtige. Wie ein Chef, der einen sehr guten, aber manchmal zerstreuten Programmierer einarbeitet.
Das klingt vielleicht nach weniger Arbeit. Ist es nicht. Es ist andere Arbeit.
Wenn ich sah, dass Claude sich regelmäßig an bestimmten Problemen aufhielt, forderte ich ihn auf, diese Erkenntnisse in einer Projektdokumentation festzuhalten – damit die nächste Instanz den gleichen Fehler nicht wiederholt. Wenn Beschreibungen zu komplex wurden, ließ ich sie vereinfachen. Kontinuierliche Verbesserung, angewandt auf KI-Workflows.
Der Mythos der fünf Fenster
Jetzt zum Elefanten im Raum. Man liest überall von Entwicklern, die angeblich mehrere KI-Instanzen parallel bedienen und ihre Produktivität vervielfacht haben.
Ehrlich gesagt: Ja, ich habe das auch erlebt. Zwei Fenster, zwei Projekte. Kommt vor.
Aber es ist nicht der bevorzugte Modus. Und es ist definitiv nicht der typische Modus.
Der Grund ist simpel: Das Gehirn braucht Kontextwechsel. Wenn man auf eine KI wartet, könnte man theoretisch im anderen Fenster weiterarbeiten. Praktisch bedeutet das aber, dass man ständig zwischen Kontexten springt. Das ist anstrengend. Und es geht auf Kosten der Qualität.
Ich könnte jetzt einen coolen Artikel schreiben, wie toll sich meine Effektivität geboostet hätte, weil ich fünf Fenster gleichzeitig bediene. Aber das wäre Marketing, keine Praxiserfahrung.
Was wirklich zählt
Der eigentliche Gewinn ist ein anderer: Ruhe im Kopf.
Durch die Orchestrierung habe ich Zeit, dass ordentliche Tests mitlaufen. Zeit, dass ich Bugfixes und Feature-Implementierungen wirklich übergucke. Zeit für Qualität.
Die Softwareprojekte, die ich in den letzten Monaten betreut habe, wurden massiv besser. Nicht weil sie vorher schlecht waren. Sondern weil ich in der Lage war, technische Schulden abzubauen, die ich als einzelner Entwickler nie angefasst hätte.
Dinge umstrukturieren, die eigentlich funktionieren, aber nicht schön sind? Wenn man Tests hat und eine KI die Arbeit macht, wird man hemmungslos. Ein Kundenprojekt wurde komplett von links auf rechts gedreht. Völlig andere Verzeichnisstruktur, durchgezogen durch CIs und alles. Hinterher: eine deutlich besser wartbare Codebasis.
Fazit: Der Dirigent braucht kein Orchester aus fünf KIs
Mein Workflow hat sich fundamental verändert. Ich bin schneller geworden – aber nicht, weil ich mehr parallel mache. Sondern weil ich anders arbeite.
Die Rolle des Programmierers verschiebt sich. Vom Schreiber zum Reviewer. Vom Einzelkämpfer zum Dirigenten. Vom „Das fass ich lieber nicht an“ zum „Lass uns das mal ordentlich machen“.
Der Produktivitätsgewinn liegt nicht in der Anzahl der Fenster. Er liegt in der Qualität der Aufsicht.
Dies ist Teil 1 einer dreiteiligen Serie über KI-gestützte Softwareentwicklung in der Praxis. In Teil 2 geht es um Projektstrukturen, die KI-Wartbarkeit ermöglichen – von der claude.md bis zur Testarchitektur.
Jan Brinkhaus, Jahrgang 1977 ist Geschäftsführer der Brinkhaus GmbH. Er gründete mehrere Firmen und ist ein leidenschaftlicher Programmierer.