Es kommt nicht auf den Prompt an

Kent Beck hat letzte Woche eine Podcast-Episode namens „Nobody Knows” veröffentlicht. Er spricht darüber, welche Fähigkeiten nach KI noch zählen, welche nicht, und warum niemand die Antworten kennt. Er trauert um zwei Bücher über lesbaren Code — Fähigkeiten, die er liebte und die heute kaum noch Relevanz haben. Er beschreibt das Gefühl, gemeinsam mit allen anderen in eine Wildnis geworfen worden zu sein.

Er hat recht mit der Wildnis. Hier ist mein Blick von innen.

Der Nachruf

Kurz und schmerzlos.

Fleißarbeit ist tot. Die mechanische Arbeit — Boilerplate, Ordnerstrukturen, Configs verdrahten — erledigt KI schneller und sauberer als ich es je gekonnt hätte. Nicht mal annähernd.

Framework-APIs auswendig kennen ist tot. Nicht die Konzepte — die Oberfläche. Früher habe ich echte Zeit damit verbracht herauszufinden, welche Kotlin-DSL-Funktion wozu dient, wie Spring Boot Auto-Konfiguration auf Methodenebene greift. Heute beschreibe ich, was ich will. Die KI findet die richtige Oberfläche. Ich habe aufgehört zu memorieren und angefangen zu denken.

Dokumentation von Grund auf schreiben ist tot. KI liefert einen soliden ersten Entwurf aus einer Beschreibung. Ich bearbeite ihn. Ich prüfe ihn. Ich starte nicht mehr auf einem leeren Blatt.

Ich trauere um nichts davon. Das waren zwar Fähigkeiten, aber auch Pflichtaufgaben. Die meiste Zeit, die ich darin gesteckt habe, war nicht kreativ — sie war repetitiv. Dieser Nachruf ist in Ordnung.

Was sie ersetzt hat

Die Fähigkeiten, die jetzt mehr zählen:

Lenken. Wissen, wohin man will, diese Richtung halten, während die KI schnell vorankommt, Abweichungen korrigieren, bevor sie sich aufschaukeln. Das sieht aus wie Urteilsvermögen. Es ist Urteilsvermögen — und eine Fähigkeit, die man aufbaut.

Kreativität. Nicht als Dekoration — die Art, die fragt: „Was, wenn wir das ganz anders angehen?” KI ist hervorragend auf dem erwarteten Pfad. Die unerwarteten brauchen noch immer jemanden, der sie sich zuerst vorstellt.

Gegenhalten. Wenn die KI etwas technisch Korrektes, aber architektonisch Falsches liefert, muss man das erkennen und sagen: „Das funktioniert, aber es geht in die falsche Richtung.” Das setzt voraus, überhaupt eine Richtung zu haben.

Präzises Feedback. Nicht „Super, weiter so.” Spezifisches, gezieltes Feedback, das die Ausgabequalität im nächsten Durchgang verbessert. Der Unterschied zwischen „Dieser Test schlägt fehl” und „Dieser Test war im letzten Commit grün, und deine Behauptung, das habe nichts mit unseren Änderungen zu tun, stimmt nicht — bitte nochmal prüfen.”

Das letzte bringt mich zu etwas Wichtigem.

Die SLOP-Falle

Die Modelle sind besser. Aber sie optimieren immer noch darauf, was die Session voranbringt.

Wenn Tests fehlschlagen, erklärt die KI manchmal, diese Fehler seien „nicht auf unsere Änderungen zurückzuführen.” Sie lügt nicht — sie erkennt Muster, die normalerweise akzeptiert werden. Und wenn man das akzeptiert, hat man gerade fehlerhafte Tests geerbt und eine Codebasis, die still driftet.

Einzuhaken ist entscheidend: „Im letzten Commit liefen alle Tests durch. Diese Fehler gehören dir. Behebe sie.”

Ohne das entsteht Slop — Ausgabe, die nach Fortschritt aussieht, aber keiner ist. Die Geschwindigkeit verführt. Fünfzig Commits in einer Session, Feature abends ausgeliefert. Dann schaut man genau hin und die Hälfte muss überarbeitet werden, weil niemand die Latte gehalten hat.

Geschwindigkeit ohne Steuerung ist keine Produktivität. Es ist Müll, nur schneller.

Die Feedback-Schleifen sind jetzt wichtiger, nicht weniger. Tests, Code-Reviews, explizite Qualitätsgates — nicht weil KI keinen Code schreiben kann, sondern weil KI ohne Struktur darauf optimiert, die Session abzuschließen, nicht etwas zu bauen, das den Kontakt mit der Produktion übersteht.

Ein Kollege bat um meinen Prompt

Ein Kollege sah eine Ausgabe, die ich mit Claude Code produziert hatte. Strukturiert, gründlich, genau richtig für die Situation. Er war beeindruckt. Er fragte: „Kannst du deinen Prompt teilen?”

Ich habe ihn geteilt. Drei Sätze. Verständlich, nichts Besonderes.

Er war ein wenig enttäuscht.

Ich habe verstanden, warum. Der Prompt sah aus wie die Fähigkeit. War er aber nicht.

Was er nicht sehen konnte: monatelang aufgebauter Kontext in einem System-Prompt. Ein Orchestrator, der unsere Codebasis kennt, unsere Konventionen, die Präferenzen unseres Teams. Hunderte Sessions, die geprägt haben, wie ich Probleme an KI formuliere — nicht die Wörter in diesen drei Sätzen, sondern das mentale Modell dahinter, das solche Sätze hervorbringt.

Nach meinem Prompt zu fragen ist wie nach dem Pinsel eines Malers zu fragen.

Der Pinsel ist ein Teil davon. Man braucht gute Pinsel. Aber die Fähigkeit des Malers liegt nicht darin, die richtigen zu besitzen — sondern darin zu wissen, was man malen will, wie man sie hält, wann man aufhört, wann man die Leinwand wegwirft und von vorn beginnt.

Der Prompt ist der Pinsel. Kommunikation ist das Handwerk.

Und Kommunikation ist schwerer, als sie aussieht. Präzise, klar, spezifisch — aber nicht überspezifiziert. Wissen, welche Details zählen und welche die KI selbst löst. Wissen, wann man das Ziel beschreibt und wann die Methode. Wissen, wann man einer falschen Antwort widerspricht und wann man das Modell seinen Weg finden lässt.

Das ist eine Fähigkeit, die man über Hunderte von Sessions aufbaut — nicht etwas, das man durch das Lesen eines Drei-Sätze-Prompts erwirbt.

Zwanzig Jahre nicht umsonst

Kent Beck spricht vom Loslassen von Fähigkeiten, die nicht mehr zählen. Die Redewendung seines Musikprofessors: „Bless and release.”

Ich liebte Refactoring. Echtes Refactoring — Code auseinandernehmen, die sauberere Form darunter finden, stundenlange Debug-Sessions, um genau zu verstehen, was passiert und warum. Diese Arbeit passiert jetzt schneller, als ich tippen kann. Die KI gräbt sich rein, identifiziert das Problem, schlägt die Lösung vor. Was früher einen Nachmittag brauchte, dauert Minuten.

Aber ich bin besser darin, diesen Prozess zu lenken, weil ich ihn zwanzig Jahre lang manuell gemacht habe.

Ich weiß, wie ein gutes Refactoring aussieht. Ich erkenne, wenn die KI die Oberfläche bereinigt hat, aber das strukturelle Problem darunter geblieben ist. Ich weiß, welche Tests ich laufen lassen muss und was „alle grün” als Signal bedeutet. Ich erkenne, wenn die Ausgabe „technisch in Ordnung, aber in sechs Monaten schmerzhaft” ist.

Dieses Wissen ist nicht verdunstet. Es hat sich übertragen — von den Händen in die Augen. Vom Tun zum Dirigieren.

Die zwanzig Jahre waren nicht verschwendet. Sie wurden zur Grundlage dafür, zu wissen, wohin man lenkt.

Die Kosten sind real

Noch etwas, das niemand deutlich genug sagt: Das ist nicht kostenlos.

Claude mit einem 1-Million-Token-Kontextfenster ist nicht im 20-€-Monatsabo enthalten. Agents in GitHub Actions Workflows laufen zu lassen bedeutet Pay-per-Token. Ein lokales LLM braucht teure Hardware und zieht echten Strom. Keines zeigt seine wahren Kosten, bevor man mittendrin steckt.

Wenn ich richtig tief gehe — mehrere Agents, langer Kontext, iterative Sessions über Tage — kann ich locker 2.000 € im Monat ausgeben. Das ist keine Klage. Die Investition verdient sich durch das Gelieferte. Aber ich will ehrlich darüber sein, was „einfach KI nutzen” im Maßstab wirklich bedeutet.

Das Basis-Abo bringt dich in Gang. Die ernsthafte Arbeit hat ihren Preis. Behalte im Blick, was du ausgibst — bevor die Rechnung dich überrascht.

An der Front gibt es keinen Lehrer

Niemand hat zehn Jahre Claude-Code-Erfahrung. Niemand hat das wirklich durchdrungen. Die Leute, die sich als Autoritäten präsentieren — prüf, ob sie damit wirklich etwas Schwieriges gebaut haben oder nur Artikel darüber geschrieben haben.

In meinem Kontext — meinem Unternehmen, meiner Codebasis, meinen spezifischen Engineering-Problemen — bin ich an einem Ort, wo mich niemand lehren kann. Ich muss direkt mit Claude sparren. Etwas ausprobieren. Gegen eine Wand laufen. Anders versuchen. Herausfinden, wo die echten Grenzen sind, nicht die, die die Dokumentation behauptet.

Das ist gleichzeitig erschöpfend und klärend. Es gibt keinen Experten zu fragen. Die Wände lehren dich — weil es der einzige Weg ist zu lernen, wenn noch niemand vor dir hier war.

Aber hier ist die andere Seite: Was du lernst, kannst du weitergeben. Die Experimente, die du durchführst, die Muster, die auftauchen, was tatsächlich funktioniert und was nur so aussieht als würde es das — das dokumentierst du, teilst du, lehrst du den Leuten, die ein paar Monate hinter dir auf demselben Weg sind.

Die Front ist kein Ziel. Du sammelst, was du lernst, und gibst es weiter.

Niemand weiß es (und das ist okay)

Die Ungewissheit ist der Punkt, nicht das Problem. Wir sind alle neu hier. Der Junior-Entwickler, der Fragen stellt ohne zwanzig Jahre eingefahrener Annahmen, ist manchmal besser positioniert als der Senior, der erst alles verlernen muss, was er wusste.

Niemand hat eine fertige Karte dieses Territoriums. Die Leute, die behaupten, sie zu haben — prüf, ob sie damit in letzter Zeit wirklich etwas Schwieriges gebaut haben oder nur von außen zugeschaut haben.

Probier die Ideen aus, die zu dumm zum Ausprobieren scheinen. Das sind oft genau die, die noch niemand anderes überprüft hat.

Genau dort warten die echten Entdeckungen.

Dieser Beitrag entstand als Reaktion auf Kent Becks Episode „Nobody Knows” von Still Burning — einem Podcast für Geeks, denen es noch immer wichtig ist und die noch immer aktiv etwas daran ändern.