Der Entwickler „Code-Athlet“

Früher habe ich Hunderte von Programmierübungen pro Jahr gemacht. Letztes Jahr zum Beispiel habe ich TDD mit Datenstrukturen, F#, Thread-Synchronisierung und verschiedenen anderen Dingen geübt, weil ich immer agil im Coden sein musste und mit Exceptions, Konfigurationen, Bibliotheken und all dem praktischen Teil der Entwicklung klarkommen musste.

Ich bin damit aufgewachsen, Programmieren durch Übungslisten und Deadlines zu lernen. Ich hatte immer das Mantra im Kopf, das auf dem berühmten Ausspruch basiert:

„Talk is Cheap. Show me the Code.“

Und auch im alten:

„Übung macht den Meister.“

Für mich bedeutete ein guter Programmierer zu sein, viel zu üben. Je mehr Code ich schrieb, desto schneller konnte ich Probleme lösen.

Meine Interview-Tests waren oft buchstäblich stundenlanges Coden vor allen Leuten. Später, als ich Erfahrung sammelte, ging es bei den Tests viel mehr darum, Konzepte allgemein zu diskutieren.

Aber auch dann musste ich noch eine sehr große Fähigkeit zur Implementierung haben. Ich musste APIs, Bibliotheken, .NET-Funktionen, Konfigurationen auswendig kennen und in der Lage sein, schnell eine Idee in Code umzusetzen.

Ich war in gewisser Weise ein „Code-Athlet“.

🚀 Der Schock der Realität

Dann kam der Schock.

Als ich Claude Code kennenlernte, brachte es mich dazu, diese Sichtweise auf die Programmierung stark zu überdenken.

Ich sah, wie er Implementierungen wie Login mit Microsoft und Google in weniger als einer Stunde durchführte, mit nur sehr wenigen Dingen, die zu korrigieren waren – und oft korrigierte er die Probleme selbst.

Das ist etwas, das mich früher leicht mehrere Tage oder sogar eine Woche kosten konnte.

Ich hätte über das Layout nachdenken, herausfinden müssen, wie die Endpoints funktionieren, die Dokumentation lesen, verstehen, welche APIs konfiguriert werden sollten, die notwendigen Konfigurationen herausfinden, implementieren, testen und korrigieren müssen.

Plötzlich konnte ein relativ generischer Prompt eine enorme Menge dieser Arbeit erledigen.

Und es war nicht einfach funktionierender Code.

Der erzeugte Code folgte Mustern, wandte Clean Code an, verwendete Entwurfsmuster und, vor allem, der Agent konnte seine eigenen Fehler analysieren und korrigieren.

Da tauchte eine ziemlich unbequeme Frage auf:

Wenn die manuelle Fähigkeit, schnell Code zu schreiben, nicht mehr das Hauptunterscheidungsmerkmal ist, was bedeutet es dann, ein exzellenter Programmierer zu sein?

🧠 Der Wendepunkt „Talk is Cheap Show me the Code“ vs. „Cognitive Coverage“

Da sah ich ein Video auf YouTube, das das Konzept der „kognitiven Abdeckung“ vorstellte.

In diesem Moment habe ich meine Art zu üben praktisch neu strukturiert.

Anstatt weiterhin eine enorme Menge Zeit darauf zu verwenden, jedes Implementierungsdetail zu meistern, begann ich, meine Praxis in Themen zu organisieren, um die Breite der Konzepte, die ich kenne, zu erhöhen.

Das wurde mein neues Mantra.

Heute bin ich kein Cloud-Experte, aber ich kenne viele Cloud-Dienste und kann Infrastruktur in zwei Clouds aufbauen.

Ich bin kein KI-Experte, aber ich kenne viele Konzepte, Werkzeuge und Plattformen wie Azure AI Foundry.

Ich habe auch begonnen, neue Techniken wie Spec-Driven Development, Machine Learning, Data Engineering und Agenten-Orchestrierung zu studieren.

Meine Sorge begann sich zu ändern.

Jetzt ist es mir egal, eine API mit gRPC oder einen Bildschirm in .NET MAUI auswendig codieren zu können, aber ich kümmere mich um kognitive Abdeckung.

Ich möchte eine große Bandbreite an Konzepten haben, um Spezifikationen im Prompt für den Agenten zu erstellen. Und zu verstehen, was der Agent tut, um ihn zu meinen Zielen und denen des Unternehmens, für das ich arbeite, zu führen.

⚙️ Der Engpass von TDD und SDD

In diesem Prozess begann ich besser zu verstehen, warum so viele Menschen bestimmte Methoden nicht streng befolgen.

Ich erinnere mich an eine Studie oder Schätzung, die ich gesehen habe und die Kent Beck die Idee zuschrieb, dass etwa 92 % der Entwickler TDD nicht rigoros einsetzen. Ich erinnere mich nicht genau an die Quelle, also möchte ich diese Zahl nicht als endgültige Tatsache behaupten.

Aber die Logik dahinter hat meine Aufmerksamkeit erregt.

Das Problem ist einfach:

über das Design nachzudenken, bevor man implementiert, ist schwierig.

Bei komplexen Funktionen erfordert das Schreiben der Tests vor der Implementierung, dass Sie das Verhalten antizipieren, über Schnittstellen, Anwendungsfälle und darüber nachdenken, wie dieser Code funktionieren soll, bevor Sie ihn überhaupt bauen.

Das ist kognitiv sehr anstrengend.

Und mir ist etwas Ähnliches mit Spec-Driven Development aufgefallen.

Ich hatte SDD als eine Möglichkeit verstanden, alles zu spezifizieren: Anforderungen, Design, Implementierung und Aufgaben, die in einer Reihenfolge organisiert sind, bis hin zu einer tasks.md-Datei, die extrem detailliert ist.

Nur gibt es ein Problem.

Die Implementierung auf niedriger Ebene zu spezifizieren, kann noch schwieriger sein als die Implementierung selbst.

Sie müssen im Voraus daran denken, wie diese Lösung gebaut wird, alles in Aufgaben aufteilen, die Reihenfolge organisieren und Details vorhersehen, die vielleicht erst während der Implementierung natürlich entdeckt worden wären.

Deshalb ist mir aufgefallen, dass viele Leute hauptsächlich mit Spezifikationen auf hoher Ebene arbeiten, ohne unbedingt die gesamte Implementierung auf niedriger Ebene zu beschreiben.

🛠️ Das praktische Beispiel: Als ich feststeckte

Das wurde mir auf meiner eigenen Website sehr deutlich.

Ich entwickelte Funktionen rund um Audiobuch und ePub und begann, Spec-Driven Development auf extrem perfektionistische Weise anzuwenden.

Ich wollte alles abbilden.

Ich wollte jeden Schritt beschreiben.

Ich wollte bis zur Ebene der Implementierungsaufgaben gehen.

Und ich blieb einfach stecken.

Es war einer dieser Momente, in denen mir klar wurde, dass der Prozess, der mir helfen sollte, anfing, mich am Fortschreiten zu hindern.

Da dachte ich:

Warum versuche ich manuell einen Teil zu erledigen, den ein Agent viel besser und viel schneller erledigen kann?

Ich begann, die Implementierung auf niedriger Ebene an Claude Code zu delegieren.

Ich behielt weiterhin die Kontrolle über die Absicht, die Architektur, was ich bauen wollte und die erwarteten Ergebnisse, aber ich ließ den Agenten durch einen großen Teil der Implementierung navigieren.

Das Ergebnis war eine Produktivitätssteigerung um ein Vielfaches.

Da fiel der Groschen.

Ich musste nicht länger mit der Maschine bei dem konkurrieren, worin sie absurd gut wurde.

🎯 Die neue Realität

Anstatt danach zu streben, ein vorbildlicher Kodierer zu sein, der täglich Code schreibt und Hunderte von Übungen praktiziert, muss ich meine Bandbreite an Konzepten und Grundlagen erweitern. Ich muss eine ausreichend breite Sicht entwickeln, um zu verstehen und abzudecken, was KI leisten kann, ihre Implementierungen überprüfen, sie zu den richtigen Zielen führen und oft aus dem von ihr erzeugten Code lernen, indem ich seine Vor- und Nachteile sowie Einschränkungen verstehe.

Der große Vorteil der Arbeit auf hoher Ebene mit Spezifikationen ist, dass ich meinen Lieferumfang erweitern kann.

Der große Vorteil, den Fokus auf die Arbeit auf hoher Ebene zu verlagern, die auf klaren Spezifikationen basiert, ist der exponentielle Skalierungsgewinn bei dem, was ich liefern kann.

Früher erforderte die Integration eines neuen Ökosystems Tage, die ich über Dokumentationen gebeugt verbrachte, um Endpoints zu kartieren, Ausnahmen zu behandeln und die Schnittstelle von Grund auf neu zu erstellen. Heute, wenn ich Lösungen wie Azure AI Foundry oder Microsoft Agent Framework konzeptionell verstehe, genügt es, eine klar definierte Spezifikation zu erstellen, die die erwarteten Eingaben, Verhaltensweisen und Ausgaben des Agenten festlegt, damit die KI die notwendige Implementierung generiert.

Mit wenigen Klicks und Befehlen verwandle ich ein architektonisches Konzept in ein funktionales, hochwertiges Werkzeug, ohne in den Details auf niedriger Ebene zu ertrinken, die Wochen dauern würden.