Programmiersprachen werden unwichtiger. Software Engineering wird wichtiger.

Sind Programmiersprachen im KI-Zeitalter noch wichtig? Weniger als Maß dafür, wer Code produzieren kann, und mehr als Menge technischer Constraints. KI generiert Java, Go, Python, Rust oder TypeScript auf Abruf. Sie beseitigt weder deren Runtime- und Speichermodell noch die Folgen für Concurrency, Security, Ökosystem und Wartung. Syntax wird billiger. Engineering-Urteil nicht.

Genau diese Unterscheidung fehlt in der zugespitzten These „Programmiersprachen sind egal“. Teams tippen weniger Routinecode selbst und produzieren mit Coding-Agenten mehr Software. Je schneller Code entsteht, desto wertvoller wird jedoch das Wissen darüber, was überhaupt entstehen soll, wie die Teile zusammengehören, wie sich die Runtime unter Last verhält und wie ein anderer Mensch das System in zwei Jahren sicher ändern kann.

Was bedeutet „Programmiersprachen werden unwichtiger“ konkret?

Der Marktwert der Tätigkeit, eine klare Anforderung in gültige Syntax zu übersetzen, sinkt. Das heißt nicht, dass Implementierungsentscheidungen austauschbar werden. Ein Coding-Agent kann eine Datentransformation in Minuten von Python nach Go übertragen. Ob diese Transformation in einen Request-Handler, Queue-Worker, eine Datenbankabfrage, einen Stream-Prozessor oder überhaupt nicht ins System gehört, ist eine andere Entscheidungsklasse.

GitHub befragte 2.000 Mitglieder von Enterprise-Softwareteams in den USA, Brasilien, Deutschland und Indien. 60 bis 71 Prozent sagten, KI-Tools erleichterten den Einstieg in eine neue Sprache oder das Verstehen einer bestehenden Codebasis. Sprachbarrieren erodieren also tatsächlich. Die Folgen der Sprachwahl verschwinden dadurch nicht.

Schreiben Entwickler wirklich weniger Code von Hand?

Es gibt keinen globalen Zähler für handgeschriebenen und KI-generierten Code. Jede universelle Prozentzahl wäre Show. Die Richtung ist in Nutzungsstudien trotzdem sichtbar. Laut Stack Overflow Developer Survey 2025 nutzten oder planten 84 Prozent der Befragten KI-Tools. Unter jenen, die KI teilweise in ihren Workflow eingebaut hatten, war Code schreiben mit 59 Prozent der häufigste Anwendungsfall.

Bei Anthropic—einem Anbieter und damit keiner neutralen Population—gaben 132 Engineers und Researcher an, Claude in 59 Prozent ihrer Arbeit einzusetzen und 50 Prozent produktiver zu sein. Anthropic beobachtete außerdem 67 Prozent mehr gemergte Pull Requests pro Engineer und Tag. Interessant ist weniger der exakte, selbstberichtete Uplift als die Form der Veränderung: etwas weniger Zeit pro Aufgabe, deutlich mehr Output und 27 Prozent KI-unterstützte Arbeit, die sonst gar nicht erledigt worden wäre.

Eine frühere Anthropic-Auswertung von 500.000 Coding-Interaktionen klassifizierte 79 Prozent der Claude-Code-Konversationen als Automation und 21 Prozent als Augmentation. Im Juni 2026 beschrieb eine Analyse von rund 400.000 Claude-Code-Sessions die Arbeitsteilung noch klarer: Menschen trafen die meisten Planungsentscheidungen—was getan wird—und Claude die meisten Ausführungsentscheidungen—wie es umgesetzt wird.

Macht KI Software-Expertise weniger wichtig?

Nein. Sie verschiebt, welche Expertise Rendite bringt.

In Anthropics Forschung vom Juni 2026 erreichten als „Novice“ bewertete Sessions in 15 Prozent der Fälle verifizierten Erfolg. Intermediate- und Expert-Sessions lagen bei 28 bis 33 Prozent. Die Forschenden stellten fest: Je mehr Domänenwissen eine Person mitbrachte, desto mehr Arbeit erledigte der Agent pro Anweisung. Ihre ungewöhnlich direkte Schlussfolgerung: Einen Agenten zum Erfolg zu steuern hing stärker von Domänenbeherrschung ab als von der Fähigkeit, selbst Code zu schreiben.

"Wenn Code im Überfluss vorhanden ist, wird Urteilskraft zum knappen Input. Wertvoll ist nicht mehr, wer am meisten Implementierung tippt, sondern wer entscheidet, was gebaut werden soll, den Agenten begrenzt und beweist, dass das Ergebnis laufen darf."

Das heißt nicht, dass jeder Architect gewinnt und jeder Programmer verliert. Architektur ohne Feedback aus Implementierung und Betrieb wird zur PowerPoint. Starke Engineers bleiben nah genug an Code, Traces, Datenbanken, Queues, Deployment-Pipelines und Incidents, um zu erkennen, wann ihr Systemmodell falsch ist. Sie verbringen nur weniger ihrer knappen Aufmerksamkeit mit vorhersehbarer Tipparbeit.

Warum widersprechen sich Studien zur Produktivität?

Weil „KI macht Entwickler schneller“ kein einzelnes Experiment ist. Vertrautheit mit der Aufgabe, Tool-Generation, Repository-Qualität, Erfahrung, Review-Latenz und parallele Agenten verändern das Resultat.

METRs kontrollierte Studie von Anfang 2025 fand bei erfahrenen Open-Source-Entwicklern in sehr vertrauten Codebasen eine Verlangsamung um 19 Prozent. Im Februar 2026 meldete METR, spätere Daten deuteten auf Beschleunigung hin, warnte aber vor Selection Effects und unzuverlässiger Zeitmessung. Das ehrliche Update lautet: Anfang 2026 war eine Beschleunigung wahrscheinlich, ihre Größe ließ sich aber nicht zuverlässig messen.

DORAs Forschung 2025 löst einen Teil des Widerspruchs auf: KI ist ein Verstärker. Die Studie fand positive Beziehungen zu Throughput und Product Performance, während die Beziehung zur Software-Delivery-Stabilität negativ blieb. Anders gesagt: KI schiebt mehr Änderungen durch das System und legt schwache Tests, zu große Batches, langsames Feedback und unreifes Platform Engineering frei.

Die richtige Frage ist daher nicht „Um wie viel macht KI einen Developer schneller?“, sondern „Was passiert mit dem gesamten Delivery-System, wenn Implementation-Throughput steigt?“ Skalieren Review, Tests, Architekturentscheidungen, Security, Deployment-Sicherheit und Observability nicht mit, produziert das Unternehmen mehr Risiko pro Woche statt mehr Wert.

Warum sind Programmiersprachen weiterhin wichtig?

Weil eine Sprache nicht nur Syntax ist. Sie ist ein Paket aus Defaults und Garantien, das bestehen bleibt, nachdem der Agent den Pull Request geschlossen hat.

Runtime-Verhalten landet weiterhin auf der Rechnung

Garbage Collection, Startzeit, JIT-Warm-up, Event Loops, Thread Scheduling, Async-Runtimes, Binary-Größe und FFI-Grenzen beeinflussen Latenz, Infrastrukturkosten, Deployability und Failure-Modes. Ein LLM kann beide Varianten schreiben. Produktion bezahlt weiterhin die gewählte.

Speichermodelle landen weiterhin in der Security

Googles Android-Team liefert einen seltenen Realitätsvergleich. 2025 waren Memory-Safety-Probleme erstmals für weniger als 20 Prozent der Android-Schwachstellen verantwortlich, nachdem neue native Entwicklung stärker auf Rust verlagert wurde. Google schätzte für Rust eine über 1.000-fach niedrigere Dichte an Memory-Safety-Schwachstellen als in historischem C- und C++-Code. Rust-Änderungen hatten außerdem eine viermal niedrigere Rollback-Rate und verbrachten 25 Prozent weniger Zeit im Code Review.

Diese Zahlen gelten für Android und lassen sich nicht blind auf jedes Team übertragen. Sie widerlegen dennoch klar, dass die Sprachwahl egal geworden sei. CISA empfiehlt ebenfalls Memory-Safe Languages für neue Produktlinien und die schrittweise Migration exponierter oder privilegierter Komponenten. KI erleichtert beide Sprachen; sie hebt deren Sicherheitsmodelle nicht auf.

Typsysteme und Concurrency-Modelle formen weiterhin Fehler

Ein Compiler, der ungültige Zustände schwer ausdrückbar macht, verändert, was ein Agent versehentlich ausliefern kann. Ownership, Nullability, algebraische Datentypen, Effect Boundaries, Structured Concurrency und Race Detection sind keine Geschmacksfragen. Sie verschieben Fehler von Produktion in Generierung oder Compile-Zeit, wo sie billiger sind.

Ökosysteme entscheiden weiterhin über den Betrieb

Reife Packages, Security Response, Datenbanktreiber, Observability-Tools, Cloud-Support, Hiring-Tiefe, Release-Zyklus und Governance zählen mehr als die Frage, ob ein Agent eine Funktion erzeugen kann. Eine Sprache mit perfekten Benchmarks und dünnem Betriebsökosystem kann die teure Wahl sein.

Was wird wichtiger als Sprachflüssigkeit?

1. System Design: Grenzen, Daten-Ownership, Failure Isolation, Konsistenz, Integrationsverträge und Änderbarkeit.
2. Runtime Literacy: Verstehen, was aus Code wird: Allokationen, Syscalls, Prozesse, Threads, Event Loops, Netzwerkverbindungen, DB-Locks, Caches und Queues.
3. Architektur mit Beweisen: Fitness Functions, Dependency-Regeln, Contract Tests, Performance Budgets, Threat Models und Observability statt bloßer Diagramme.
4. Domänenmodellierung: Regeln, die kein Modell aus einem Ticket errät: Wem gehört das Geld? Wann ist eine Bestellung final? Welche Zustandswechsel sind legal?
5. Verifikation: Tests, Static Analysis, Review, Fuzzing, Lasttests, Migrationen, Rollbacks und Production-Telemetrie. Generation skaliert nur, wenn Ablehnung mitskaliert.
6. Wartbarkeit: Naming, Kohäsion, kleine Interfaces, dokumentierte Entscheidungen, wenige Dependencies und eine Codebasis, die ein neuer Mensch ohne Originalprompt versteht.
7. Technische Führung: Arbeit begrenzen, Risiken sequenzieren, Standards setzen, Automation bewusst auslassen und Ownership im Team halten.

Das erweitert unser früheres Argument, dass bei Coding-Agenten Kontext statt rohe Intelligenz der Engpass ist. Kontext erklärt dem Agenten, was existiert. Engineering-Urteil entscheidet, was existieren sollte und wie Sicherheit bewiesen wird.

Wie sollte ein CTO heute eine Programmiersprache wählen?

Für System und Organisation, nicht für den Agenten. Agenten senken die Kosten unbekannter Syntax. Dadurch kann das Team den Eigenschaften, die bleiben, mehr Gewicht geben.

Der modische Stack ist selten die Antwort. Meistens ist es ein langweiliger Primär-Stack, den das Team betreiben kann, plus eine bewusste Ausnahme, wo eine andere Runtime oder ein anderes Sicherheitsmodell messbaren Wert erzeugt. KI macht Ausnahmen billiger zu implementieren. Sie macht sie nicht kostenlos zu besitzen.

Wie bleibt KI-generierter Code wartbar?

1. Constraints vor Prompts schreiben. Architekturgrenzen, nicht-funktionale Anforderungen, verbotene Dependencies, Datenregeln und Abnahmetests gehören ins Repository.
2. Änderungen klein halten. Ein begrenzter Intent pro Pull Request. Große generierte Diffs machen menschliches Review zur Zeremonie.
3. Architektur ausführbar machen. Dependency-Tests, Linters, Schemas, API Contracts, Policy-as-Code und Performance Budgets lassen Verstöße automatisch scheitern.
4. Eigenschaften statt nur Beispiele testen. Was muss bei falschem Input, Retries, Concurrency, Teilausfällen und Angriffen immer wahr bleiben?
5. Design vor Diff reviewen. Eine perfekte Implementierung der falschen Grenze bleibt falsch. Erst den Plan freigeben, dann den Agenten ausführen lassen.
6. System-Outcomes messen. Change-Failure-Rate, Review-Zeit, entkommene Defekte, Incident-Last, Kosten pro erfolgreicher Aufgabe und Time to Restore statt erzeugter Zeilen.
7. Aggressiv löschen. KI macht Hinzufügen billig. Gute Teams testen damit Ideen und entfernen anschließend die verlorene Implementierung, Dependency und Abstraktion.

Wenn deine KI-generierte Codebasis bereits schnell wächst, beginne mit unserer QA-Checkliste für KI-generierten Code oder der operativen Production-Readiness-Checkliste. Das Ziel ist nicht, dem Agenten schlechten Code nachzuweisen. Das Ziel ist zu beweisen, dass dein Team das System sicher besitzen kann.

Wofür sollten Unternehmen in einem AI-first Engineering-Team einstellen?

Für Menschen, die Ebenen wechseln können. Sie erklären die Kundenregel, zeichnen den Datenfluss, sagen die Runtime-Folge voraus, prüfen generierten Code, entwerfen den Test, lesen den Production-Trace und machen den Trade-off fürs Business verständlich. Reine Syntax-Spezialisten sind leichter zu ersetzen. Wer Outcomes über diese Ebenen besitzt, wird wertvoller.

Für Juniors heißt das nicht, Grundlagen zu überspringen. Du kannst Speicher-, Concurrency-, Datenbank- oder Security-Verhalten nicht prüfen, wenn du nie gelernt hast, es zu sehen. Nutze KI, um Praxis zu beschleunigen, nicht um mentale Modelle zu umgehen. Für Seniors heißt es, implizites Urteil in sichtbare Repository-Constraints zu übersetzen, denen Agenten und weniger erfahrene Kollegen folgen können.

Quellen und Hinweise zur Einordnung

• Anthropic: Agentic coding and persistent returns to expertise, 16. Juni 2026 — rund 400.000 Sessions; Vendor-Daten und vom Autorenteam benannte Classifier-Grenzen.
• Anthropic: How AI is transforming work at Anthropic, 2. Dezember 2025 — interne Befragung, Interviews und Usage-Daten; nicht repräsentativ für alle Entwickler.
• DORA: State of AI-assisted Software Development 2025 — KI als Verstärker des zugrunde liegenden Delivery-Systems.
• Stack Overflow Developer Survey 2025: AI — Adoption und Vertrauen; insgesamt mehr als 49.000 Befragte.
• METR: Update zum Developer-Produktivitätsexperiment, 24. Februar 2026 — warum spätere Speedup-Schätzungen unsicher bleiben.
• GitHub: Enterprise-Umfrage zu AI Coding Tools, aktualisiert 15. April 2025 — Wahrnehmung von Sprachwechsel und Codebase-Verständnis.
• Google Android Security: Rust in Android, 13. November 2025 — Android-spezifische Daten zu Security, Rollbacks und Review.