← Blog
·11 blog.minutes

Der Stand der KI-gestuetzten Programmierung 2026: Trends, Tools und die naechste Entwicklung

KI-Coding-Assistenten haben den Graben ueberwunden. Ueber 70 % der professionellen Entwickler nutzen sie taeglich. Hier ist eine Uebersicht der Tools, Protokolle und Workflow-Aenderungen, die die Entwicklung im Jahr 2026 praegen.

Haette man Anfang 2024 Entwickler gefragt, ob KI-Coding-Assistenten eine voruebergehende Mode oder eine dauerhafte Veraenderung sind, waere die Meinung geteilt gewesen. Mitte 2026 klingt diese Frage seltsam. KI-gestuetztes Programmieren ist laengst nicht mehr experimentell, nicht mehr optional und kein Differenzierungsmerkmal mehr - es ist der Basisstandard. Die Diskussion hat sich von 'Sollten wir KI nutzen?' zu 'Wie standardisieren wir den KI-Einsatz in unserem Team?' und 'Wie bewerten wir, welches Tool fuer welchen Workflow geeignet ist?' verschoben.

Dieser Beitrag ist eine Momentaufnahme des aktuellen Stands. Ich behandle die Verbreitung, die wichtigsten Tools im Vergleich, die Protokolle, die KI von einer Chat-Oberflaeche zu einer Infrastrukturebene machen, und die konkreten Veraenderungen in den Entwicklungsablaeufen. Am Ende gebe ich meine Einschaetzung, worauf sich Entwickler als Naechstes konzentrieren sollten - denn die Faehigkeiten, die 2023 wichtig waren, sind nicht mehr dieselben.

Die Adoption hat den Graben ueberwunden

Der auffaelligste Wandel zwischen 2024 und 2026 ist nicht nur die Breite, sondern die Tiefe der Adoption. Fruehe Umfragen zeigten, dass etwa 40-50 % der Entwickler ein KI-Coding-Tool ausprobiert hatten. Anfaenge 2026 liegt diese Zahl bei ueber 80 %, und die taegliche aktive Nutzung unter professionellen Entwicklern liegt bei ueber 70 %. Es handelt sich nicht um Spielereien - Entwickler nutzen KI, um Produktionscode zu schreiben, komplexe Probleme zu debuggen, Legacy-Systeme zu refaktorisieren und Testsuiten zu generieren.

Der Wandel hat drei Gruende. Erstens hat sich die Zuverlaessigkeit dramatisch verbessert. Die Modelle hinter Tools wie Claude Opus 3.5, GPT-5 und Gemini 2.5 Pro produzieren korrekten, idiomatischen Code weitaus konsistenter als ihre Vorgaenger. Die 'Vibe-Coding'-Aera von 2024 - in der man akzeptierte, was die KI ausspuckte, und betete - hat einem vorhersehbareren, ingenieurmaessigen Interaktionsmodell Platz gemacht. Zweitens wurden die Tools tief in Editoren und Terminals eingebettet, anstatt in separaten Chat-Fenstern zu leben. Wenn KI nur einen Tastendruck entfernt in Ihrer tatsaechlichen Entwicklungsumgebung ist, nutzt man sie haeufiger und fuer kleinere, regelmaessigere Aufgaben. Drittens haben Teams begonnen, Prompt-Bibliotheken, Agentenkonfigurationen und Workflow-Muster zu teilen, was die Lernkurve dramatisch gesenkt hat.

GitHub Copilot meldet inzwischen ueber 5 Millionen zahlende Abonnenten. Cursor hat schaetzungsweise 15-20 % des VS-Node-adjacent-Marktes erobert, wobei viele Entwickler es als ihren primaeren Editor nennen. Claude Code, das Mitte 2025 auf den Markt kam, hat neu definiert, was ein terminalbasiertes KI-Tool leisten kann, und ist schnell zum Standard fuer Backend- und Infrastrukturarbeit geworden. Gemini Code Assist ist im Google-Workspace-Oekosystem schnell gewachsen, insbesondere bei Organisationen, die bereits Cloud Code und Firebase nutzen.

Der interessanteste Trend ist jedoch nicht der Marktanteil - es ist die Art und Weise, wie die Tools gleichzeitig konvergieren und sich differenzieren. Jedes grosse Tool bietet inzwischen agentische Faehigkeiten, MCP-Unterstuetzung und Multi-File-Editing. Die Differenzierung verschiebt sich hin zur Integrationstiefe, Protokollerweiterbarkeit und Workflow-Automatisierung, nicht zur grundlegenden Codegenerierungsqualitaet.

Die Tool-Landschaft 2026: Vier Saeulen

Claude Code - Terminal-nativer Agent

Claude Code hat alle ueberrascht, indem es bewies, dass ein terminalbasiertes KI-Tool leistungsfaehiger sein kann als ein IDE-Plugin. Die entscheidende Erkenntnis: Entwickler verbringen viel Zeit im Terminal - sie führen Builds aus, durchsuchen die Git-Historie, grep in Logs, bearbeiten Konfigurationsdateien. Indem KI direkt in diese Umgebung eingebettet wird, kann Claude Code alles sehen, was der Entwickler sieht, und auf derselben Oberflaeche arbeiten.

Im Gegensatz zu IDE-Plugins, die nur die geoeffnete Datei sehen, sieht Claude Code den gesamten Projektkontext: Dateibaum, Git-Historie, Terminalausgabe, Testergebnisse, Linter-Fehler. Es kann Dateien bearbeiten, Befehle ausfuehren, Dokumentation lesen und auf der Grundlage von Echtzeit-Feedback iterieren. Fuer die Backend-Entwicklung, Infrastructure as Code und alles, was komplexe Build-Pipelines betrifft, ist es fuer viele Teams zur Standardwahl geworden.

# Typical Claude Code session — implementing a new API endpoint
$ claude

> Add a rate-limited POST endpoint to the payments router

# Claude Code discovers the router pattern, reads existing endpoints,
# checks the database schema, generates the implementation, runs tests:

✓ Read src/routes/payments.ts (existing pattern)
✓ Read prisma/schema.prisma (rate_limit_config table)
✓ Generated src/middleware/rateLimit.ts (token bucket algorithm)
✓ Updated src/routes/payments.ts (new POST /payments/charge)
✓ Added tests in tests/routes/payments.test.ts
✓ Ran test suite — 47 passed, 0 failed
✓ Lint — clean

Review the diff with `claude diff` or approve with `claude apply`.

Der terminal-native Ansatz hat einen weiteren Vorteil: Er funktioniert headless in CI/CD-Pipelines. Teams nutzen Claude Code inzwischen in GitHub Actions, um Lint-Fehler automatisch zu beheben, Changelogs zu generieren und sogar erste Entwuerfe von Release-Notes zu schreiben. Dieselbe Oberflaeche, die interaktiv auf dem Rechner eines Entwicklers arbeitet, funktioniert auch automatisiert in einer Pipeline.

Cursor - Das IDE-native Kraftpaket

Cursor hat sich im Laufe des Jahres 2025 aggressiv weiterentwickelt. Die Composer-Funktion, die Multi-File-Edits von einer einzigen Eingabeaufforderung aus ermoeglicht, wurde zum Goldstandard fuer IDE-basierte KI-Interaktionen. Der entscheidende Unterschied ist die tiefe Indizierung: Cursor erstellt einen Vektorindex Ihrer gesamten Codebasis. Wenn Sie es bitten, 'die Benutzerprofilkomponente an das neue Designsystem anzupassen', weiss es bereits, wo die Designsystem-Tokens leben, welche Komponenten sie verwenden und wie das Migrationsmuster aussieht.

Cursors Agent-Modus verdient eine besondere Erwaehnung. Anders als das Inline-Vervollstaendigungsmodell kann der Agent-Modus autonom eine mehrstufige Aenderung planen, sie ueber mehrere Dateien hinweg ausfuehren, die Tests laufen lassen und bei Fehlschlaege iterieren. Der Entwickler ueberwacht, anstatt jeden Schritt vorzugeben. Fuer Frontend-Arbeiten - React-Komponenten, CSS-Refactoring, API-Client-Generierung - ist der Agent-Modus fuer viele Entwickler zum primaeren Workflow geworden.

GitHub Copilot - Der Unternehmensstandard

Copilot hat laenger gebraucht, um agentische Faehigkeiten auszuliefern, aber bis Anfang 2026 haben Copilot Workspace und Copilot Agent die meisten Feature-Luecken geschlossen. Copilots Vorteil ist die Verbreitung: Es wird mit jedem GitHub Enterprise-Konto mitgeliefert und ist nativ in Actions, Pull Requests und Code-Review-Workflows integriert. Wenn Ihr Team in GitHub lebt, ist die Huerde fuer die Einfuehrung von Copilot nahezu null.

Copilots am meisten unterschätzte Funktion ist die Pull-Request-Integration. Wenn ein Entwickler einen PR eroeffnet, generiert Copilot automatisch eine Zusammenfassung, hebt potenzielle Probleme hervor und schlaegt Schwerpunkte fuer die Pruefung vor. Es geht nicht darum, die menschliche Pruefung zu ersetzen - es geht darum, sie effizienter zu machen, indem die mechanischen Teile uebernommen werden. Teams, die dies eingefuehrt haben, berichten von einer Verkuerzung der PR-Pruefzeit um etwa 30-40 %.

Gemini Code Assist - Der Oekosystem-Ansatz

Gemini Code Assist ist stetig gewachsen, indem es sich auf das Google Cloud- und Android-Oekosystem konzentriert hat. Die tiefe Integration mit Cloud Code, Firebase und Google Workspace verschafft ihm einen Burggraben in diesen Umgebungen. Das herausragende Merkmal ist die kontextbewusste Vervollstaendigung in Google Cloud-Diensten: Wenn Sie Code schreiben, der mit Cloud Run, Firestore oder BigQuery interagiert, versteht Gemini die API-Oberflaeche und generiert korrekte, idiomatische Nutzung.

Die breitere Lehre aus der Tool-Landschaft ist, dass die Basisschicht - grundlegende Code-Vervollstaendigung - nur die Eintrittskarte ist. Die Differenzierung liegt in der Workflow-Integration, dem Kontextverstaendnis und der autonomen Faehigkeit. Kein einziges Tool gewinnt ueberall. Das beste Setup im Jahr 2026 ist oft eine Kombination: ein IDE-Plugin fuer Inline-Vervollstaendigungen, ein Terminal-Agent fuer komplexe Aufgaben und eine Unternehmensplattform fuer die teamweite Steuerung.

Die Protokollschicht: MCP und WebMCP

Die folgenreichste Infrastrukturentwicklung der letzten 18 Monate ist weder ein Tool noch ein Modell - es ist das Model Context Protocol (MCP). MCP ist ein offener Standard, der definiert, wie KI-Tools eine Verbindung zu externen Datenquellen und Diensten herstellen. Stellen Sie es sich wie USB-C fuer KI vor: ein einziges Protokoll, das es jedem MCP-kompatiblen Client ermoeglicht, eine Verbindung zu jedem MCP-kompatiblen Server herzustellen, unabhaengig vom Anbieter.

Vor MCP hatte jedes KI-Tool sein eigenes Plugin-System, seine eigene Integrations-API, seine eigene Art, auf Dateien, Datenbanken und APIs zuzugreifen. Tool-Entwickler mussten N Integrationen fuer N Datenquellen schreiben. MCP hat dies umgekehrt: ein Server pro Datenquelle, ein Client-Protokoll pro Tool, und sie sind alle interoperabel. Das Ergebnis war eine Explosion von Community-MCP-Servern fuer Datenbanken (PostgreSQL, SQLite, Redis), Cloud-Plattformen (AWS, GCP, Cloudflare), Entwicklungstools (GitHub, Linear, Sentry) und sogar Verbraucher-Apps (Notion, Gmail, Slack).

Eine typische MCP-Konfiguration sieht wie folgt aus:

// ~/.claude/mcp-servers.json — the MCP server registry
{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "."]
    },
    "postgres": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-postgres",
               "postgresql://localhost:5432/myapp"]
    },
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": { "GITHUB_TOKEN": "${GITHUB_TOKEN}" }
    },
    "linear": {
      "command": "npx",
      "args": ["-y", "@raycast/mcp-linear"]
    }
  }
}

Mit dieser Konfiguration kann ein Entwickler Claude Code bitten: 'Finde alle offenen Issues in Linear mit dem Tag 'Bug', pruefe, ob einige davon in den letzten drei Commits behoben wurden, und poste eine Zusammenfassung in unseren Team-Slack-Channel.' Das KI-Tool orchestriert ueber MCP-Server hinweg - Linear fuer Issues, GitHub fuer Commits, Slack fuer Nachrichten - ohne dass der Entwickler den Kontext wechseln oder Klebecode schreiben muss. Das ist keine Demo. Teams nutzen diese Workflows taeglich in der Produktion.

WebMCP, angekuendigt Ende 2025, erweitert das MCP-Protokoll auf Browser-Kontexte. Anstatt dass ein KI-Tool nur Ihre Codebasis sieht, kann es Webanwendungen sehen und mit ihnen interagieren: Dashboards, Dokumentationsseiten, Design-Tools in Figma, Projektboards. Ein Entwickler, der ein Produktionsproblem debuggt, kann die KI bitten, das Datadog-Dashboard zu oeffnen, den Fehleranstieg zu finden, die zugehoerigen Logs zu ueberpruefen und sie mit aktuellen Deployments zu korrelieren - alles ueber dieselbe MCP-Schnittstelle. WebMCP verwandelt den gesamten Browser in einen KI-zugaenglichen Arbeitsbereich.

MCP ist das wichtigste KI-Infrastrukturprojekt, von dem die meisten Entwickler noch nie gehoert haben. Es tut fuer KI-Tools, was HTTP fuer Webdienste getan hat - es bietet eine universelle Schnittstelle, die Clients von Servern entkoppelt und ein Oekosystem ermoeglicht, das kein einzelner Anbieter allein aufbauen koennte.

Wie sich Entwicklungsablaeufe tatsaechlich veraendert haben

Ueber die Tools und Protokolle hinaus ist die praktischste Frage: Wie hat sich die taegliche Arbeit am Schreiben von Software veraendert? Die Antwort haengt von der Art der Arbeit ab, aber einige Muster sind in Teams, die KI tief in ihre Prozesse integriert haben, durchgaengig zu beobachten.

Der dreiphasige KI-Workflow hat sich als Standardmuster in den meisten Teams etabliert. Er gilt unabhaengig davon, ob Sie eine neue Funktion entwickeln, einen Fehler beheben oder vorhandenen Code refaktorisieren:

  • Phase 1 - Erkunden: Sie beschreiben das Ziel, und die KI durchsucht die Codebasis, um den relevanten Kontext zu verstehen - bestehende Muster, Datenmodelle, Konfiguration, Tests. Sie sagen der KI nicht, wo sie suchen soll; sie findet es ueber den Codebase-Index oder den Dateibaum heraus. Diese Phase erzeugt einen Plan, den Sie ueberpruefen, bevor Code geschrieben wird.
  • Phase 2 - Generieren: Sobald der Plan genehmigt ist, generiert die KI die Implementierung. Je nach Tool und Aufgabenkomplexitaet kann dies eine einzelne Dateiaenderung oder eine mehrere Dateien umfassende Funktion sein, die sich ueber Dutzende von Dateien erstreckt. Die KI fuehrt den Build und die Tests automatisch aus und behebt alle Probleme, die sie loesen kann.
  • Phase 3 - Verfeinern: Sie ueberpruefen das Diff, hinterlassen Kommentare zu bestimmten Zeilen, und die KI iteriert. Dies ist die wichtigste Phase - Entwickler, die sie ueberspringen, erzielen die geringste Qualitaet. Der Unterschied zwischen einem guten KI-gestuetzten Entwickler und einem grossartigen liegt darin, wie effektiv sie verfeinern, nicht wie effektiv sie beim ersten Versuch prompten.

Das Code-Review hat sich staerker veraendert als jede andere Taetigkeit. Im Jahr 2024 waren die meisten PRs vollstaendig von Menschen geschrieben mit gelegentlichen KI-Beitraegen. Im Jahr 2026 ist das Gegenteil ueblich: Die KI schreibt den ersten Entwurf, der Entwickler prueft und verfeinert ihn, und der PR repraesentiert einen von Menschen ueberwachten KI-Beitrag. Pruefer verbringen jetzt weniger Zeit mit der Ueberpruefung von Syntax oder Stil (das erledigt die KI) und mehr Zeit mit der Bewertung von Architekturentscheidungen, der Behandlung von Grenzfaellen und der Korrektheit der Geschaeftslogik.

Betrachten Sie einen typischen PR-Zyklus im Jahr 2026:

# Developer workflow — adding a feature with AI

# Step 1: Explore
$ claude "Add CSV export to the analytics dashboard. Use the same
  pattern as the PDF export in reports.ts, but for CSV output."

# Claude produces a plan:
#   - Create src/services/csvExporter.ts
#   - Create src/routes/analytics/export.ts (new endpoint)
#   - Add tests in tests/routes/analytics/export.test.ts
#   - Update src/routes/analytics/index.ts (register router)

# Step 2: Generate (after plan approval)
$ claude apply
# Claude writes all files, runs tests, fixes 2 failing assertions

# Step 3: Refine
$ claude diff | less
# Developer spots missing edge case (empty dataset)
$ claude "Handle the case where the dataset is empty — return
  a CSV with just headers and a message row"

# Step 4: Ship
$ git add -A && git commit -m "feat: add CSV export to analytics
  dashboard" --author="Claude Code <ai@example.com>"

Auch Debugging-Workflows haben sich veraendert. Der alte Ansatz war eine lineare Jagd: den Fehler reproduzieren, den Umfang eingrenzen, den Code lesen, die Ursache identifizieren, beheben. Der KI-gestuetzte Ansatz ist parallel: das Symptom beschreiben, und die KI durchsucht die relevanten Codepfade, laesst die Testsuite auf Regressionen pruefen, ueberprueft die letzte Git-Historie auf moegliche Ursachen und praesentiert eine Rangliste von Hypothesen mit Belegen. Entwickler ueberpruefen und waehlen die Korrektur immer noch aus, aber die Untersuchungszeit hat sich drastisch verkuerzt.

Dokumentation hat sich von einer gefuerchteten Pflichtaufgabe zu einem automatisierten Artefakt entwickelt. Jedes grosse KI-Coding-Tool kann Dokumentation aus Code-Aenderungen generieren und aktualisieren. Wenn ein Entwickler eine Funktion implementiert, kann die KI API-Dokumente, Inline-Kommentare, README-Abschnitte und Changelog-Eintraege erstellen oder aktualisieren. Teams, die dieses Muster uebernehmen, berichten von einer Verbesserung der Dokumentationsabdeckung von etwa 30 % auf ueber 90 %, da die Kosten fuer das Schreiben von Dokumentation auf nahezu Null gesunken sind.

Was Entwickler als Naechstes lernen sollten

Der Aufstieg der KI-gestuetzten Programmierung macht Entwickler nicht ueberfluessig - er verschiebt, welche Faehigkeiten am wichtigsten sind. Syntaxkenntnisse und Framework-Memorisierung sind an Wert verloren. Die Faehigkeiten, die effektive Entwickler heute auszeichnen, sind andere und in gewisser Weise schwieriger zu erwerben:

  • Kontext-Engineering: Die Faehigkeit, eine projektebene Kontextdatei (CLAUDE.md, .cursorrules oder aehnlich) zu erstellen, die die Konventionen, Architekturentscheidungen und Standards Ihres Teams kodiert, ist zu einer Kernkompetenz geworden. Die Qualitaet der KI-Ausgabe ist direkt proportional zur Qualitaet des Kontexts, den Sie bereitstellen. Teams, die in ihre Kontextdateien investieren, erzielen dramatisch bessere Ergebnisse als solche, die dies nicht tun.
  • Workflow-Design: Zu verstehen, wie man eine Funktion in KI-geeignete Aufgaben zerlegt, wann man Inline-Vervollstaendigung versus Agentenmodus versus eine vollstaendig autonome Sitzung verwendet und wie man den Ueberpruefungszyklus strukturiert, ist heute eine Designfaehigkeit, keine Werkzeugfaehigkeit. Die besten KI-gestuetzten Entwickler denken ueber Prozesse nach, nicht nur ueber Prompts.
  • Bewertungskompetenz: Je mehr Code die KI generiert, desto wichtiger und schwieriger wird die Bewertung ihrer Ausgabe. Die Faehigkeit ist nicht nur 'kannst du sagen, ob das korrekt ist', sondern 'kannst du sagen, ob das fuer deinen spezifischen Kontext korrekt ist' - behandelt es deine Fehlerzustaende, befolgt es deine Konventionen, respektiert es deine Leistungsbeschraenkungen und vermeidet es deine bekannten Antipatterns.
  • Systemdesign-Kompetenz: KI ist gut darin, klar definierte lokale Aufgaben zu implementieren. Sie ist schlecht darin, architektonische Kompromisse zu treffen, die das gesamte System betreffen. Entwickler, die Systemdesign verstehen - die bewerten koennen, ob ein von der KI vorgeschlagener Ansatz skalieren wird, zu viel kostet, Kopplungen erzeugt oder Sicherheitsgrenzen verletzt - sind diejenigen, die Software produzieren, die in der Produktion funktioniert, nicht nur im Editor.
  • Sicherheitspruefung fuer generierten Code: KI-generierter Code fuehrt neue Risikoklassen ein. Modelle koennen Paketnamen halluzinieren (Abhaengigkeitsverwechslung), unsichere Konfigurationen generieren oder Autorisierungspruefungen auf eine Weise uebersehen, die korrekt aussieht. Entwickler muessen eine Sicherheitsdenkweise entwickeln, die speziell auf KI-Ausgaben abgestimmt ist - nicht von Boesartigkeit ausgehend, aber auch nicht von Korrektheit.

Keine dieser Faehigkeiten ist neu. Senior-Entwickler haben sie schon immer gebraucht. Was sich geaendert hat, ist, dass sie nicht mehr optional sind. Ein Junior-Entwickler, der keine KI-Ausgaben bewerten, Workflows entwerfen oder auf Sicherheit ueberpruefen kann, wird nicht zum Senior-Entwickler, indem er mehr Code schreibt - denn das Schreiben von Code wird zunehmend automatisiert. Der Weg zur Senoritaet fuehrt jetzt ueber Urteilsvermoegen, Design und Bewertung, nicht ueber die Anzahl der geschriebenen Codezeilen.

Es gibt auch eine praktische Faehigkeit, die nicht genug Beachtung findet: zu wissen, wann man KI nicht einsetzen sollte. Manche Aufgaben sind manuell schneller erledigt. Manche Probleme profitieren von der kognitiven Auseinandersetzung mit dem selbst geschriebenen Code - der Art, die ein Verstaendnis aufbaut, das man durch das Pruefen eines Diffs nicht bekommt. Die Entwickler, die 2026 erfolgreich sind, sind nicht diejenigen, die KI fuer alles nutzen. Es sind diejenigen, die KI strategisch einsetzen und genau wissen, wo der menschliche Touch immer noch zaehlt.

Was als Naechstes kommt

Mit Blick auf die Zukunft ist die Entwicklung klar: KI wird mehr von der Implementierungsebene uebernehmen, und Entwickler werden sich mehr auf die Spezifikations- und Bewertungsebenen konzentrieren. Die Tools werden autonomer, tiefer integriert und durch Protokolle wie MCP standardisierter. Die Kluft zwischen einem gut kontextualisierten KI-Team und einem, das einfach ein Chat-Fenster oeffnet und 'schreibe eine Funktion, die...' eintippt, wird sich zu einem Graben ausweiten.

Die wichtigste Erkenntnis aus dem Stand der KI-gestuetzten Programmierung im Jahr 2026 betrifft nicht ein bestimmtes Tool oder Modell. Es geht um die Verschiebung dessen, was es bedeutet, ein Entwickler zu sein. Code zu schreiben war immer ein Mittel zum Zweck - der Zweck ist funktionierende Software, die echte Probleme loest. KI macht das Mittel dramatisch billiger. Der Wert konzentriert sich auf die Zwecke: das Problem verstehen, die Loesung entwerfen, das Ergebnis bewerten und die Verantwortung fuer das Resultat uebernehmen.

Wenn Sie ein Entwickler sind, der dies liest, ist die beste Investition, die Sie taetigen koennen, nicht das neueste Framework zu lernen oder die neuesten Modell-Benchmarks auswendig zu lernen. Es ist, gut zu werden in den Teilen der Entwicklung, die KI noch nicht gut kann - und wahrscheinlich fuer eine Weile nicht koennen wird: zu verstehen, was Benutzer tatsaechlich brauchen, Systeme zu entwerfen, die kohaerent und wartbar sind, und Verantwortung fuer Ergebnisse zu uebernehmen, die zaehlen. Diese Faehigkeiten waren schon immer der Unterschied. KI hat diese Wahrheit nur unuebersehbar gemacht.