Zählt die Sprache, die du kannst, noch?

Du hast Jahre damit verbracht, in einer Sprache gut zu werden. Du hast ihre Regeln gelernt, dann ihre Gewohnheiten, dann die kleinen hässlichen Wahrheiten, die man nur bekommt, wenn man Dinge damit ausliefert und zusieht, wie sie kaputtgehen. Und jetzt schreibt ein Modell diese Sprache fließend, und jede andere gleich mit, sobald du fragst. Also kommt die Frage, in irgendeiner Version: Soll ich bei dem bleiben, was ich kann, oder zu dem wechseln, wohin gerade alle wechseln? Die Angst darunter ist einfacher als die Frage. Haben die Jahre einfach aufgehört zu zählen?

Die Sprache ist zwei Dinge

Es gibt die Sprache als Tippen: ihre Syntax, die Form einer Schleife, wo die Semikolons hingehören. Und es gibt alles darunter: wie sie Speicher verwaltet, wie sie damit umgeht, wenn zwei Dinge gleichzeitig passieren, die Fehlermodi, die ihr gehören und keiner anderen, die Idiome, die richtig sind, und die, die nur richtig aussehen, das Ökosystem und die Tools, die um sie herum gewachsen sind. KI hat das Tippen billig gemacht. Den Rest hat sie kaum berührt, und das hat einen Grund. Der Rest steht nicht wirklich im Text. Er lebt in laufenden Systemen und in der Erinnerung daran, was kaputtging, und ein Modell lernt aus Text. Deshalb hat die tiefe Hälfte den Wandel nicht nur überlebt. Sie ist die Hälfte, die der Wandel knapp gemacht hat.

Schau, welche Bugs leichter geworden sind

Die Fehler, vor denen flache Geläufigkeit früher geschützt hat, sind genau die, die das Modell jetzt vermeidet und die der Compiler schon immer gefangen hat: ein falsches Keyword, ein missbrauchtes Stück Syntax, ein Aufruf von etwas, das nicht existiert. Was übrig bleibt, sind die Fehler, die nur Tiefe fängt: das Sicherheitsloch, das sich wie gewöhnlicher Code liest, die Designentscheidung, die falsch ist, obwohl jede Zeile stimmt, der Concurrency-Bug, den du auf keiner einzelnen Zeile sehen kannst. KI hat die billigen Fehler aufgeräumt und die teuren übrig gelassen, und die billigen waren die einzige Sorte, die flaches Wissen je gefangen hat.

Tiefe ist ein Alarm, der von selbst losgeht

Es gibt ein Gefühl, das jeder erfahrene Entwickler kennt. In der Sprache, die du tief kennst, löst falscher Code einen Alarm aus, bevor du sagen kannst, warum. Etwas an seiner Form stimmt nicht, also hältst du an und schaust hin. In einer Sprache, die du nur halb kannst, geht dieser Alarm nie los. Der Code sieht plausibel aus, also nimmst du ihn an. Ein Modell produziert plausiblen Code per Konstruktion, Seite um Seite davon. Tests fangen einen Teil dessen, was daran falsch ist, und du kannst ein zweites Modell auf das erste ansetzen, aber eine Suite prüft nur die Fehler, an die jemand beim Schreiben gedacht hat, und Modelle, die auf demselben Code trainiert wurden, teilen dieselben blinden Flecken. Am Ende steht zwischen plausibel und korrekt ein Leser, dessen Alarm noch funktioniert. Dieser Leser ist jemand, der die Sprache tief kennt. Zum Alarm gibt es keine Abkürzung.

Wechsle aus einem Grund, nicht aus einer Laune

Die Wechselkosten teilen sich genauso auf wie die Sprache. Du kannst noch am selben Nachmittag plausibel aussehenden Code in einer neuen Sprache schreiben, und dieser Teil hat früher Monate gedauert. Die Idiome, die Runtime, die Art, wie genau diese Sprache scheitert: davon überträgt sich wenig zwischen Sprachen, die einander fremd sind. Zwischen nahen Verwandten, Sprachen, die sich ein Ausführungsmodell teilen, trägt mehr davon hinüber, und das ist die einzige echte Abkürzung, die es gibt. Der Rest muss nach wie vor erarbeitet werden. Was sich vollständig überträgt, ist der Teil, der nie mit der Sprache zu tun hatte: wie du ein Problem zerlegst und über ein System nachdenkst.

Also wechsle, wenn es einen echten Grund gibt, eine Domäne, die es verlangt, einen Job, den du willst, ein Problem, für das die Sprache gebaut wurde, und nicht, weil der Lärm laut geworden ist. Manche Domänen entscheiden die Sprache für dich. Echtzeit- und Embedded-Arbeit kann sich keinen Garbage Collector leisten, der im falschen Moment pausiert, also gehört dieser Boden den Systemsprachen, und der Browser ist der Browser; in beiden steht die Sprache für ein Ausführungsmodell, das du im Kopf halten musst, und keine noch so große Geläufigkeit eines Modells ändert, was die Hardware tun wird. Machine Learning gehört Python aus einem anderen Grund, dem Ökosystem, und der Effekt ist derselbe.

Nimm den konkreten Wechsel, über dem sich alle den Kopf zerbrechen: bei C++ bleiben oder Rust lernen. Als Streit darüber, welche Sprache gewinnt, hat er keine saubere Antwort, und er endet nie. Durch die Brille der Tiefe betrachtet gibt es weniger zu streiten. Wenn du C++ gut kannst, ist das meiste von dem, was Rust von dir verlangt, das harte Nachdenken über Ownership und Lifetimes, Gewicht, das du ohnehin schon getragen hast, nur trägt der Compiler es jetzt mit. Das ist näher am Levelaufstieg als am Neuanfang. Und die erwachsene Version des Wechsels ist meistens gar kein sauberer Wechsel, sondern genug von beiden zu können, um dort zu arbeiten, wo die jeweilige hingehört. Der Fehler war, es als Entweder-oder zu behandeln.

Der Markt redet mit

Es gibt noch einen Grund zu wechseln, und es ist der am wenigsten romantische: die Tür. Wie viel das Etikett auf deiner Erfahrung zählt, hängt davon ab, wie du dein Geld verdienst. Bau dein eigenes Produkt, und niemand, der es kauft, fragt, worin es geschrieben ist. Hilf anderen, ihres zu bauen, Consulting, Freelancing, Agenturarbeit, und du arbeitest in deren Stack, also muss deiner nah genug dran sein, um den Auftrag zu bekommen. Und in der klassischen Anstellung kann das Etikett alles entscheiden, bevor ein Mensch deinen Namen liest. Der Filter will Jahre in einem ganz bestimmten Framework, und Tiefe in einer benachbarten Sprache bringt dich nicht ins Vorstellungsgespräch.

Auch der Markt hat Jahreszeiten. Die Nachfrage nach Sprachen schwillt an und schrumpft, in Zyklen, die mit der Qualität der Sprache wenig zu tun haben, und ein Stack, der ein Jahrzehnt lang die Stellenanzeigen gefüllt hat, kann still werden, während einer, den du nie angefasst hast, in jeder Ausschreibung steht. Das ist kein Grund, jeder Saison hinterherzujagen. Es ist ein Grund zu wissen, welches Spiel du spielst. Wenn dein Einkommen über die Stacks anderer Leute läuft, halte dir mindestens eine Sprache warm, die der Markt in dieser Saison will, und nutze die Maschine für das, was sie inzwischen gut kann, dich in einem neuen Stack schnell auf plausibel zu bringen, während du den Teil übernimmst, den sie nicht kann: genug Tiefe aufzubauen, um den Code im Vorstellungsgespräch zu verteidigen und danach, wenn du eingestellt bist. Das Häkchen öffnet die Tür, und die Tiefe ist das, was dich drinnen hält.

Wo Tiefe sich auszahlt und wo nicht

Nichts davon macht Breite wertlos. Eine zweite Sprache, besonders eine, die anders denkt als deine erste, schärft den Blick auf die erste, und KI macht das Hineinschnuppern billig, also kostet Herumstreifen jetzt fast nichts. Was an Wert verloren hat, ist Breite als Haufen von Syntaxen, fünf Sprachen, die du tippen kannst, und keine, die du verteidigen kannst.

Tiefe zahlt sich auch nicht überall aus. Für ein Wegwerfskript, ein bisschen Glue-Code, einen Prototyp, den du am Freitag löschst, ebnet das Modell das Feld, und die Sprache spielt kaum eine Rolle. Tiefe verdient ihren Unterhalt in dem Code, der lebt: im reifen System, in dem Performance oder Sicherheit wirklich zählt, im Code, den du in drei Jahren noch wartest.

Der unangenehme Teil ist, dass die Wiederholungen, die früher Tiefe aufgebaut haben, mit dem Job frei Haus kamen, und jetzt nicht mehr. Du hast die Schleifen selbst geschrieben, du bist in die billigen Bugs gelaufen, du hast sie behoben, und Tiefe hat sich als Nebeneffekt angesammelt. Diesen Teil macht jetzt die Maschine, also müssen die Wiederholungen bewusst gewählt werden. Debugge den generierten Code, statt ihn neu generieren zu lassen. Lies das Diff so, wie ein Reviewer es lesen würde. Mach absichtlich etwas kaputt, um zu sehen, wie es scheitert. Früher ist Tiefe dir einfach passiert; jetzt muss sie eine Entscheidung sein.

Das ist ein älterer Punkt, der wieder an die Oberfläche kommt: Die mechanische Produktion von Code war nie das, wofür du bezahlt wurdest, und jetzt ist sie der Teil, den eine Maschine übernimmt. Was bleibt, ist Urteilsvermögen, und Urteilsvermögen beim Programmieren ist nicht so sprachunabhängig, wie wir uns das gern einreden. Ein großer Teil davon lebt in einer einzigen Runtime, gelernt auf die langsame Art: indem man Dinge darin baut und dabei ist, wenn sie scheitern.

Die Jahre haben also gezählt. Der Teil, der seinen Wert verloren hat, war nie der Teil, der gezählt hat. Die Syntax, die du auswendig gelernt hast, ist jetzt weniger wert, und viel wert war sie nie. Das Modell der Sprache, das du darunter gebaut hast, tief genug, um zu merken, wann der generierte Code dich anlügt, ist mehr wert als je zuvor. Lerne eine Sprache so gut, dass du sie reviewen kannst.