KI und die Kunst des Erkennens

In Entwicklerkreisen gibt es einen laufenden Witz: KI-generierter Code sei „Müll" – minderwertige Ausgabe, der man nicht vertrauen sollte. Aber diese Sichtweise verfehlt das Wesentliche. Müll ist nicht Code, den eine KI geschrieben hat. Müll ist Code, der fertig aussieht, aber Bugs, Unstimmigkeiten und Fragilität versteckt. Es war nie um das Werkzeug gegangen. Es ging um das Denken dahinter.

Was ich nach Monaten mit KI-gestützter Entwicklung beobachtet habe: Die Freude am Programmieren ist nicht verschwunden. Sie ist umgezogen.

Tippen war nie der Kern

Erinnerst du dich an den Moment, als ein Stück Code plötzlich Sinn ergab? Wenn eine Lösung nicht nur das Problem vor dir löste, sondern auch Randfälle abdeckte, an die du noch gar nicht gedacht hattest? Das Gefühl – das ist der Moment, den wir eigentlich verteidigen wollen.

Jahrelang passierte dieser Moment beim Tippen. Du kämpftest mit einem Problem, probiertest Varianten, löschtest die Hälfte davon, und landetest irgendwann bei etwas Elegantem. Die Tastatur war das Wohnzimmer des Denkens.

Aber die Sache ist: Der Moment steckte nie in den Tasten. Er steckte im Erkennen. In dem Moment, in dem du eine Lösung sahst, die mehr war als maßgeschneidert – etwas, das die eigentliche Struktur des Problems erfasste. Das machte es befriedigend. Das machte es zur Ingenieurskunst.

Günstiger Code, teures Urteilsvermögen

KI hat die Kosten für das Ausliefern eines Features drastisch gesenkt. Prompt schreiben, funktionierenden Code bekommen, ausliefern. Die Messlatte hat sich verschoben. Und für viele Entwickler fühlt sich das unangenehm an. Es kommt einem vor, als sei das Handwerk verwässert worden.

Aber es gibt eine andere Kostenstelle, die nicht gesunken ist: zu wissen, welche Lösung man wählen soll.

Wenn ich an einem neuen Projekt bei NameOcean arbeite oder Kunden bei komplexer Infrastruktur helfe, liefert mir KI schnell Optionen. Drei Versionen einer DNS-Konfiguration. Vier Ansätze für den Umgang mit SSL-Zertifikaten. Fünf Wege, eine Deployment-Pipeline zu strukturieren.

Die erste Version ist fast immer die maßgeschneiderte – löst genau das, was ich beschrieben habe, und hört dann auf. Nützlich, aber begrenzt. Der vierte oder fünfte Versuch zeigt oft etwas anderes: eine Struktur, die Fälle berücksichtigt, die ich nicht erwähnt habe, Patterns, die über meinen ursprünglichen Rahmen hinaus skalieren.

Dort, in der Unterscheidung, liegt das Ingenieursurteil jetzt. Nicht mehr im code from scratch, sondern im Erkennen, welcher der Kandidaten die wahre Form des Problems abbildet.

Lesen ist das neue Schreiben

Die Verschiebung klingt einfach: mehr generieren, mehr lesen, weise wählen. Aber es ist eine echte Veränderung im Arbeitsablauf.

Wenn du Code von Hand schreibst, suchst du innerhalb dessen, was du bereits kennst. Deine Gewohnheiten, deine Patterns, dein mentales Vokabular. Mit KI-Unterstützung explodiert der Suchraum. Du kannst nach unkonventionellen Ansätzen fragen, State-Machine-Patterns, wo du normalerweise zu if-Statements greifen würdest, Schema-first-Denken, wo du sonst zur Feld-für-Feld-Validierung tendieren würdest.

Der Hebel liegt nicht in der Generierung – er liegt im Lesen. Du durchsuchst einen viel breiteren Möglichkeitsraum, und der Preis ist, über mehrere Versuche zu lesen, anstatt einen zu tippen.

Deshalb funktioniert „Vibe Coding", wenn man es richtig macht. Du nimmst nicht einfach die erste Ausgabe. Du iterierst, kritisierst, drängst die KI zu besseren Formulierungen. Du nutzt sie als Denkpartner, nicht als Code-Schreibmaschine.

Die Urteilssteuer

Es gibt einen Haken, den man benennen sollte: Die Fähigkeit, die elegante Lösung zu erkennen, ist nicht günstiger geworden wie alles andere. Jahre des Debuggens, Refaktorierens und Auslieferns von Code haben diese Muskeln leise aufgebaut. Sie sind immer noch teuer.

Du kannst fünfzig Kandidaten in der Zeit generieren, die du früher für einen gebraucht hast. Aber den einen auswählen, der am weitesten trägt – der das Problem von heute löst, ohne das Problem von morgen zu schaffen – dieses Urteil bleibt bei dir.

Die Ingenieure, die in dieser neuen Welt erfolgreich sind, sind nicht die, die am schnellsten Code schreiben. Sie sind die, die am breitesten lesen und am schärfsten urteilen. Das Handwerk ist nicht gestorben. Es hat ein Level aufgestockt.

Wo der Moment jetzt lebt

Hier ist mein Lieblingsteil: Der Moment passiert immer noch. Dieses Erkennen, wenn eine Form einrastet und du siehst, dass sie Fälle abdeckt, die noch niemand angesprochen hat? Er existiert noch. Er passiert nur beim Lesen über vier Versuche, statt beim Tippen von einem.

Letzte Woche arbeitete ich an einem Konfigurationsparser für das Hosting-Setup eines Kunden. Der erste KI-Vorschlag erledigte den Happy Path. Der dritte Vorschlag nutzte eine Schema-Deklaration, die das Ganze einrasten ließ – Validierung, Type Safety, Dokumentation und zukünftige Erweiterbarkeit fielen aus einer einzigen Struktur heraus.

Ich habe diese Lösung nicht getippt. Aber ich habe sie erkannt, als ich sie sah. Und das war der Teil, der sich genau gleich angefühlt hat.

Die Freude ist nicht verschwunden. Sie ist dorthin gezogen, wo die eigentliche Ingenieursarbeit stattfindet: Probleme tief genug verstehen, um zu erkennen, wenn eine Lösung mehr ist, als sie aussieht.

Wenn du Widerstand gegen KI-gestützte Entwicklung spürst, würde ich dich bitten zu bemerken, was du eigentlich verteidigst. Das Tippen? Das wird günstig. Das Erkennen, das Urteil, der Geschmack für elegante Lösungen – dort lebt das Handwerk jetzt. Und dieser Teil hat sich einwandfrei übertragen.

Der Soundtrack beim Softwarebau hat sich verändert. Aber die Musik ist noch da.