Wie man mit AI programmiert, ohne von ihr abhängig zu werden

Es ist leise zu einer der häufigsten Fragen geworden, die ein Entwickler laut ausspricht: Wie programmiere ich, ohne völlig von AI abhängig zu werden? Diejenigen, die sie stellen, sind oft die, von denen man es am wenigsten erwarten würde. Ein Informatikstudent, der die Theorieprüfungen besteht, aber jedes echte Projekt mit einem Modell an seiner Seite gebaut hat und nun keine Funktion mehr schreiben kann, ohne danach zu greifen. Ein berufstätiger Entwickler, der an einem ganz gewöhnlichen Nachmittag bemerkt, dass er seit Wochen keine Zeile mehr ohne Hilfe getippt hat. Die übliche Antwort kommt schnell und nahezu einstimmig zurück, und sie ist für genau eine Sorte Mensch richtig und für fast alle, die fragen, falsch.

Die Antwort lautet: die Krücke wegnehmen.

Kündige das Abo. Deinstalliere es. Programmiere offline, als wäre es 2010. Die Metaphern kommen wie aufs Stichwort, und einige davon sind gut. Stützräder, festgeschraubt am einzigen Fahrrad, das man besitzt. Schummeln in einer Prüfung. Ein Taschenrechner. Die schärfste Version davon: AI war ein Rollstuhl, den du nie gebraucht hast, deine Programmiermuskeln sind verkümmert, und der einzige Weg, sie wieder stark zu machen, ist, das Gewicht selbst zu tragen.

Wenn du gerade als Student die Grundlagen lernst, ist dieser Rat richtig, und ich werde ihn nicht abschwächen. Du kannst kein mentales Modell eines Problems aufbauen, wenn eine Maschine jedes Mal die Lösung für dich baut. Die behutsamste Version der Warnung benennt die eigentliche Gefahr genau: Sie liegt nicht darin, AI zu benutzen, sondern darin, die AI genau den Teil überspringen zu lassen, in dem dein Gehirn das Modell des Problems baut. Für diesen Menschen muss die Krücke weg, denn es ging bei der Übung nie um das fertige Programm. Es ging um die Verdrahtung im Kopf, die du dir dabei aufbaust, während du es herstellst.

Aber die meisten, die diese Frage stellen, werden keine Menschen werden, die AI nie anrühren. Sie werden zu Profis, deren Aufgabe zunehmend darin besteht, sie zu dirigieren. Und für die ist "weniger AI" keine Antwort. Es ist ein Hinhaltemanöver, das die eigentliche Frage um ein Jahr vertagt.

Die eigentliche Ursache

Das ist der Punkt, den die Krücken-Metaphern übersehen.

Abhängigkeit entsteht nicht dadurch, dass AI deinen Code schreibt. Sie entsteht dadurch, dass AI Code schreibt, den du nie in Verständnis verwandelt hast.

Ich sollte sagen, wo ich stehe, denn es ist nicht die Seite der Abstinenz. Ich habe die letzten Monate damit verbracht, AI-Werkzeuge zu bauen: eine Pipeline, die aus einem Satz einen Plan macht und ihre eigenen Pull Requests eröffnet, eine Steuerungsebene, die ganze Flotten von Agenten steuert. Ich benutze diese Werkzeuge jeden Tag, und ich werde niemandem eine Predigt über Reinheit halten. Aber jedes einzelne von ihnen ruht auf einer einzigen Regel, die nichts damit zu tun hat, wie viel AI man nutzt: Niemand mergt, was er nicht erklären kann.

Diese Regel ist der ganze Unterschied zwischen einem Werkzeug benutzen und von ihm abhängen. Unter den Metaphern taucht immer wieder ein härterer Punkt auf. Stell dir den reinen AI-Entwickler vor, wie er generierten Code in ein echtes Produktivsystem ausliefert, zusieht, wie er zusammenbricht, und dann Code reparieren muss, den er nie verstanden hat. Und die beliebte Angeberei, man könne die AI "die ganze App bauen lassen, ohne selbst etwas beizutragen", zerfällt bei der ersten Berührung: Du lieferst immer noch die Vorgaben und prüfst das Ergebnis, also trägst du etwas bei; und wenn du es wirklich nicht prüfst, dann lieferst du die Sicherheitslücken eben selbst aus. Der Preis der Abhängigkeit ist nicht, dass du AI benutzt hast. Er ist, dass du um zwei Uhr nachts genau das nicht reparieren kannst, was mit deinem Namen auf dem Commit steht.

Warum der Taschenrechner-Vergleich scheitert

Der Vergleich, zu dem alle greifen, ist der Taschenrechner. Taschenrechner haben niemanden vom Rechnenlernen abgehalten, warum sollte AI also jemanden vom Programmierenlernen abhalten?

Weil ein Taschenrechner eine Antwort liefert, der du vertrauen kannst. Sieben mal acht ist sechsundfünfzig, ob du es verstehst oder nicht. Ein LLM liefert eine Antwort, die du überprüfen musst. Das ist der ganze Unterschied, und er verläuft genau entgegengesetzt zur Beruhigung: Verständnis zählt im AI-Zeitalter mehr, nicht weniger. Der Taschenrechner durfte dich das Rechnen vergessen lassen, weil er nie falsch lag. Das Sprachmodell darf dich das Verstehen von Code nicht vergessen lassen, denn du bist sein Prüfer, und ein Prüfer, der nicht versteht, was er liest, prüft in Wirklichkeit gar nichts.

Die Disziplin, die wirklich funktioniert

Das Ziel ist also nicht weniger AI. Es ist, das im Besitz zu behalten, was dir die Abhängigkeit nimmt. In der Praxis ist das eine kurze Liste, und das meiste davon greift den besseren Rat auf, den ohnehin jeder gibt.

Schreib die erste Version von Hand. Bau die hässliche, langsame Version selbst, und lass die AI sie dann vergleichen, kritisieren oder refactoren. Das Ringen ist keine Reibung, die dem Lernen im Weg steht. Es ist der Ort, an dem sich das Modell des Problems bildet.

Nutze sie als den erfahrenen Kollegen neben dir, nicht als deine Hände. Am nützlichsten bringt man es so auf den Punkt: als Mentor, nicht als Programmierpraktikant. Hinterfrage, was sie dir gibt, verlange die Links, und lies dann die Dokumentation selbst. In dem Moment, in dem sie zu deinen Händen wird statt zu deinem Ratgeber, hast du aufgehört, die Fähigkeit zu besitzen, und angefangen, das Ergebnis zu mieten.

Merge nie, was du nicht erklären kannst. Das ist die ganze Regel, und sie ist durchsetzbar. Wenn du einer Kollegin nicht erklären kannst, warum der generierte Code funktioniert, dann gehört er dir noch nicht. Er ist eine Verbindlichkeit, für die du unterschrieben hast.

Mach das Review echt. Ich habe in einem anderen Beitrag geschrieben, dass man nach genug Freigaben aufhört zu lesen, und ein Tor, durch das man nicht hindurchliest, ist kein Tor. Dasselbe gilt für einen einzelnen Menschen an der Tastatur: Das Diff, das du ohne Verständnis annimmst, ist genau die Linie, an der die Abhängigkeit beginnt.

Der klarsichtigste Kompromiss, den ich je jemanden habe beschreiben hören, ist eine Hantel: alles von Hand schreiben und debuggen, außer unter Termindruck oder bei Wegwerf-Skripten, wo du zur AI greifst, im vollen Bewusstsein, dass das technische Schulden aufbaut und dich ein wenig dümmer macht. Diese Haltung gefällt mir mehr als jede Reinheit. Es ging nie darum, so zu tun, als gäbe es AI nicht. Es geht darum, genau zu wissen, was man eingetauscht hat, und es zurückkaufen zu können.

Was der Muskel wirklich ist

Die Leute, die dir raten, dein Abo zu kündigen, schützen etwas Echtes: die Stärke, die du nur aufbaust, indem du den schweren Teil selbst machst. Sie haben recht, dass du sie von Hand aufbaust, und recht, dass sie verkümmert, wenn eine Maschine das Gewicht für dich trägt.

Aber der Muskel, der einen arbeitenden Entwickler davor bewahrt, abhängig zu werden, ist nicht die Fähigkeit, Code ohne Hilfe zu produzieren. Es ist das Urteilsvermögen zu erkennen, wann die Hilfe falsch ist. Das erarbeitest du dir wie jedes Urteilsvermögen: indem du verstehst, was die Maschine geschrieben hat, jedes einzelne Mal, bevor es dir gehört.

Nutze also so viel AI, wie du willst. Verschick nur nie eine Zeile, die du nicht selbst hättest erwischen können.