Die Wände, die mich mehr gelehrt haben als die Durchbrüche

Ich habe drei Wochen mit Copilot Features zusammengeklopft und mich dabei wirklich produktiv gefühlt — bis mir auffiel, dass ich noch immer jede Zeile Logik selbst schrieb. Die KI füllte Syntax aus. Ich machte das gesamte Denken. Und ich hatte keine Ahnung, dass mir etwas fehlte.

Das ist die Form jeder Decke, auf die ich in meiner KI-Entwicklungsreise gestoßen bin. Kein dramatischer Absturz. Kein Moment, in dem etwas sichtbar kaputt geht. Nur ein stilles Plateau, auf dem alles gut genug läuft, dass man aufhört zu fragen, was als Nächstes kommt. Der Durchbruch, wenn er kommt, entsteht nie durch härteres Arbeiten auf dem aktuellen Level. Er kommt von außen — ein Video, ein Gespräch, ein Artikel, jemand, der dir zeigt, dass die Decke überhaupt da ist.

Die Decke, die man nicht sieht

Ein kurzer Hinweis zu den Levels, die ich in diesem Post verwende: L0 bis L∞ ist mein eigenes Kürzel-System, basierend auf den Stufen, die ich persönlich durchlaufen habe. Kein Standard. Es gibt viele andere, die ähnliche Entwicklungen mit anderen Bezeichnungen beschreiben — und in ein paar Jahren werden die konkreten Tools auf jeder Stufe wahrscheinlich ganz anders aussehen. Niemand wird sich noch für Copilot-Autocomplete interessieren, wenn Agents ganze Features eigenständig umsetzen. Aber für jetzt: Stell dir die Levels als Sprossen einer Leiter vor. Sie helfen, die Form der Reise zu verstehen — auch wenn sich die Sprossen ständig verschieben.

Das Gefährliche an diesen Wänden ist nicht, dass sie schwer zu überwinden sind. Es ist, dass sie unsichtbar sind. Wenn man auf L2 ist — Copilot nutzt, gute Autocomplete-Vorschläge bekommt, schneller ist als vorher — hat man keinen Grund, ein L3 zu vermuten. Copilot funktioniert. Der Code wird besser. Warum sollte man nach etwas anderem suchen?

Der Wechsel zum agentischen Coding — Tools wie Claude Code und Cursor — kam nicht davon, härter mit Copilot zu arbeiten. Bei mir begann es mit einem Gespräch darüber, was KI sein könnte, wenn man aufhört, sie als aufgewertetes Autocomplete zu behandeln, und anfängt, sie als Kollegen zu behandeln. Kein Produktivitäts-Hack. Eine grundlegend andere Arbeitsweise, bei der die KI die Codebase versteht, Entscheidungen trifft und lauffähigen Code über mehrere Dateien hinweg produziert.

Das ist keine kleine Verbesserung. Das ist eine andere Kategorie von Arbeit. Aber ich hätte sie nie gefunden, indem ich das optimiert hätte, was ich schon konnte.

Session 9: Acht Sessions unsichtbarer Investition

Als ich Session 9 erreichte, hatte ich schon acht Sessions lang Agent-Infrastruktur gebaut. Acht Sessions ohne ein einziges geshipptes Ticket. Nur Grundlagenarbeit: Agents aufteilen, Handler anlegen, Jira-, Slack- und Jenkins-Integrationen verdrahten. Wer von außen zugeschaut hätte, hätte gesagt, ich verschwende Zeit.

Die Wand hier war anders. Nicht unsichtbar — ich konnte sie spüren. Ich hatte Agents, die Einzelaufgaben erledigen konnten, aber der Übergang zwischen ihnen war manuell. Ich war der Klebstoff. Bei jedem Ticket musste ich den richtigen Agent aufrufen, Kontext übergeben, die Ausgabe prüfen, den nächsten aufrufen. Schneller als alles selbst zu tun — aber nicht autonom. Im Grunde eine aufwändigere Version von Copy-Paste.

Der Durchbruch war kein einzelner Moment. Es war die Entscheidung, meinen monolithischen Git-und-GitHub-Agent in zwei fokussierte Agents aufzuteilen — einen für Git-Operationen, einen für GitHub — und eine echte Orchestrierungsschicht zu bauen. Diese architektonische Entscheidung kam nicht davon, das Problem länger anzustarren. Sie kam aus einem Muster, das ich aus dem Microservice-Design kannte: Single Responsibility, saubere Interfaces, Komposierbarkeit.

Session 9 war das erste Mal, dass die vollständige Pipeline end-to-end lief. Jira-Ticket rein, Analyse, Implementierung, Tests, Code-Review, PR, CI-Monitoring, Slack-Benachrichtigung — alles orchestriert, ohne dass ich irgendetwas anfassen musste. Acht Sessions unsichtbarer Investition, dann eine Session, in der das ganze Ding plötzlich klickte.

Session 13: Erfolg verdeckt den Verfall

Vier Sessions und etwa eine Woche später lief die Pipeline rund. Mehrere Tickets autonom geshipped. Slack-gesteuerte Workflows, bei denen eine einzige Nachricht stundenlange Arbeit angestoßen hat. Ich war wieder entspannt.

Dann fiel mir auf, dass etwas nicht stimmte. Agents wurden langsamer. Antworten schlechter. Nicht dramatisch — nur genug, um sich falsch anzufühlen. Ich bin dem nachgegangen und habe das Problem gefunden: Meine Agents ertranken in ihrer eigenen Memory.

Der typescript-implementer war auf 95 KB angewachsen. 2.133 Zeilen akkumulierter Kontext, Anweisungen und Memory-Einträge. Größtenteils Rauschen — die Memory-Bloat-Krise. Jede Session hatte ein paar Zeilen hinzugefügt. Keine einzelne Session war das Problem. Es hatte sich einfach still angesammelt, bis die Performance nachgab.

Das war eine Wand, die ich nicht hätte kommen sehen können. Das System lief ja — also hat niemand nachgeschaut. Erfolg hat den Verfall verdeckt.

Der Durchbruch kam davon, einen Schritt zurückzutreten und eine Designfrage zu stellen: Warum sind Agents gleichzeitig dafür zuständig, was sie lernen aufzuzeichnen, und zu entscheiden, was es wert ist, behalten zu werden? Das sind zwei verschiedene Aufgaben. Aufzeichnen ist mechanisch. Kuratieren erfordert Urteilsvermögen.

„Agents record. Optimizer thinks.” — dieses Prinzip hat die gesamte Memory-Architektur neu strukturiert. Agents schreiben in geteilte Logs. Ein dedizierter Optimizer-Agent liest diese Logs, erkennt Muster, die sich dreimal oder öfter wiederholen, und destilliert sie zu dauerhaftem Wissen. Separation of Concerns — angewendet auf Wissensmanagement.

Das habe ich nicht aus dem Nichts erfunden. Das Muster kam aus der Welt der Monitoring-Systeme — man bittet den Service nicht, seine eigenen Logs zu analysieren. Man schickt die Logs an ein System, das dafür gebaut ist. Dieser Transfer aus einem anderen Fachgebiet — ein bewährtes Muster in einen neuen Kontext übertragen — ist genau der Typ externer Input, der Decken zum Einsturz bringt. Den sieht man nicht, wenn man tief im Problem steckt. Man braucht eine Perspektive von außen.

Der eine Schritt, den man nicht alleine tut

Rückblickend haben beide Durchbrüche dieselbe Struktur. Ich war produktiv auf einem Level, stieß an eine unsichtbare Decke, und kam erst weiter, als etwas außerhalb meines aktuellen Kontexts das nächste Level sichtbar gemacht hat. Ein Microservice-Muster auf Agent-Design angewendet. Eine Monitoring-Architektur auf Wissensmanagement übertragen.

Die unbequeme Wahrheit: Dieser externe Input kommt fast nie von innen. Man sieht die Decke nicht von unten. Man braucht jemanden, der schon drüber ist — oder zumindest aus einem anderen Winkel schaut. Und die Levels, auf denen das am meisten zählt, sind genau die, auf denen man sich am kompetentesten fühlt. L2 fühlt sich produktiv an. L3 fühlt sich mächtig an. L4 fühlt sich an, als hätte man es raus. Jedes Level ist wirklich gut — und genau das macht die unsichtbare Decke so schwer zu bemerken.

Warum das über meine Geschichte hinaus wichtig ist

Ich sehe dasselbe Muster bei jedem Entwickler, mit dem ich über KI-Tooling spreche.

Die meisten sind irgendwo bei L2. Sie nutzen Copilot oder ChatGPT. Sie bekommen Mehrwert. Sie sehen nicht, was als Nächstes kommt — nicht weil sie es nicht könnten, sondern weil ihnen noch nichts gezeigt hat, dass die Decke überhaupt existiert. Sie optimieren Autocomplete, während sie mit Agents arbeiten könnten, die ihre gesamte Codebase verstehen.

Einige sind bei L3 oder L4, tief in Context Engineering und Multi-Agent-Setups. Effektiv — und trotzdem an der nächsten Wand. Denn jeder Sprung erfordert ein grundlegend anderes mentales Modell. Keinen besseren Prompt, sondern einen architektonischen Wechsel, den man aus dem, was man schon weiß, einfach nicht ableiten kann.

Deshalb habe ich angefangen, Trainings und individuelles Coaching anzubieten. Ich habe diese Wände selbst getroffen. Ich habe die Sessions damit verbracht, mich durchzukämpfen. Wenn ich mit einem Entwickler arbeite, der bei L2 feststeckt, kann ich meistens auf die konkrete Decke zeigen, die er nicht sieht — weil ich mich erinnere, sie selbst nicht gesehen zu haben. Das ersetzt die Arbeit nicht. Das Experimentieren und Iterieren bleibt ihr oder sein Ding. Aber der Funke — der Moment, in dem das nächste Level sichtbar wird — den sollte man nicht alleine suchen müssen.

Die Wand, gegen die ich gerade stoße

Diese Reise hat kein Ende. Gerade jetzt, mit einer vollständig autonomen Pipeline und einem selbstverbessernden Memory-System, kann ich spüren, wie die nächste Decke entsteht. Die Agents funktionieren. Die Orchestrierung ist solide. Aber wenn ein Agent mitten in der Pipeline scheitert, läuft die Fehlerbehandlung manuell — ich muss selbst diagnostizieren, was schiefgelaufen ist, entscheiden, was wiederholt werden muss, und den richtigen Schritt neu anstoßen. Das System ist auf dem Happy Path zuverlässig, aber spröde, sobald etwas schiefläuft. Adaptives Error Recovery — nicht nur saubere Übergaben.

Ich weiß noch nicht, wie der Durchbruch aussehen wird. Das ist der Punkt. Das weiß man nie, bis etwas von außen es sichtbar macht.

Das einzige, was ich sicher weiß: Er kommt nicht davon, das zu optimieren, was ich schon habe.