Die Zukunft der KI-gestützten Softwareentwicklung

1. Wo wir heute stehen: von Autovervollständigung zu Agenten

Die Entwicklung von KI-gestützten Programmierwerkzeugen verlief in klar erkennbaren Stufen. Zuerst kam die zeilenweise Autovervollständigung, die einzelne Codeblöcke basierend auf dem umgebenden Kontext vorschlug, aber jede Entscheidung dem Entwickler überließ. Danach kamen Chat-Assistenten, die längere Erklärungen und größere Codeschnipsel lieferten, aber weiterhin auf manuelles Kopieren und Einfügen angewiesen waren. Die aktuelle Stufe, agentische Werkzeuge wie Claude Code, schließt diese Lücke: Das Modell liest Dateien selbst, führt Befehle aus, beobachtet die tatsächliche Ausgabe und passt die nächsten Schritte eigenständig an. Das ist keine Spekulation über die Zukunft, sondern der Stand der heute produktiv eingesetzten Werkzeuge.

Für PHP- und Magento-Entwickler ist dieser Wandel besonders relevant, weil viele Aufgaben im Alltag repetitiv, aber musterbasiert sind: Modul-Scaffolding nach bestehenden Konventionen, Migrationen über mehrere Vendor-Module hinweg, PHPStan-Fehler systematisch abarbeiten. Genau solche Aufgaben profitieren von einer Ausführungsschicht, die nicht nur vorschlägt, sondern selbst prüft, ob der Vorschlag tatsächlich funktioniert. Gleichzeitig lohnt sich Vorsicht gegenüber der Erwartung, dass jede neue Modellgeneration automatisch bestehende Probleme wie unklare Anforderungen oder inkonsistente Legacy-Architekturen löst. Werkzeuge werden besser, aber die Probleme, die sie lösen sollen, bleiben oft dieselben.

2. Agentic Coding: von Vorschlägen zu ausgeführten Aufgaben

Agentic Coding bezeichnet ein Ausführungsmodell, bei dem ein Sprachmodell eine Aufgabe in Teilschritte zerlegt, jeden Schritt über ein Werkzeug tatsächlich ausführt, das reale Ergebnis liest, etwa eine Fehlermeldung oder eine Testausgabe, und den nächsten Schritt entsprechend anpasst. Der entscheidende Unterschied zu einem einmaligen Codevorschlag ist die geschlossene Feedback-Schleife: Das Modell arbeitet nicht mit einer Annahme darüber, ob eine Änderung funktioniert, sondern mit dem tatsächlichen Ergebnis eines Testlaufs oder eines Linters. Diese Schleife lässt sich beliebig oft wiederholen, bis ein objektiv prüfbares Kriterium erfüllt ist.

Der realistische nahe Trend ist nicht "vollständig autonome Softwareentwicklung", sondern länger laufende, aber weiterhin begrenzte Aufgabenketten mit klar definiertem Anfang und Ende. Ein Entwickler formuliert die Aufgabe und den Erfolgsmaßstab, das Modell arbeitet mehrere Schritte selbstständig ab, und am Ende steht eine Änderung, die vor dem Commit von einem Menschen geprüft wird. Diese Grenze verschiebt sich graduell nach oben, etwa durch bessere Fehlerkorrektur über mehrere Iterationen hinweg, aber sie verschwindet nicht, weil die Aufgabenstellung selbst weiterhin von einem Menschen kommen muss.

#!/usr/bin/env bash
# Realistic agentic session: multi-step task with a closed feedback loop
$ claude
> Refactor the ShippingRateCalculator to use the new TaxServiceInterface
> instead of the deprecated TaxCalculationModel, then run the tests.

# Step 1: locate all usages across the codebase
[tool] Grep: pattern="TaxCalculationModel" path="app/code/Mironsoft"

# Step 2: read the current implementation
[tool] Read: app/code/Mironsoft/Shipping/Model/ShippingRateCalculator.php

# Step 3: apply the change and ask for confirmation before writing
[tool] Edit: app/code/Mironsoft/Shipping/Model/ShippingRateCalculator.php
> Apply this change? (y/n)

# Step 4: verify by running the actual test suite, not by assumption
[tool] Bash: bin/cli vendor/bin/phpunit --filter ShippingRateCalculatorTest

# Step 5: if the test fails, read the error and iterate automatically
[tool] Bash output: 1 test, 1 failure: Argument #2 ($taxService) must be TaxServiceInterface
[tool] Edit: app/code/Mironsoft/Shipping/Model/ShippingRateCalculator.php

3. Tiefere Codebase-Kontexte: von Snippets zu ganzen Repositories

Frühe KI-Assistenten kannten nur, was manuell in ein Prompt-Fenster eingefügt wurde. Diese Einschränkung verschwindet zunehmend, allerdings nicht primär durch unbegrenzt große Kontextfenster, sondern durch gezielte Suchwerkzeuge. Moderne agentische Assistenten durchsuchen eine Codebasis mit Grep und Glob, laden nur die tatsächlich relevanten Dateien nach, und bauen sich so bei Bedarf ein Bild eines gesamten Repositorys auf, ohne jede Zeile permanent im Kontext halten zu müssen. Das ist technisch günstiger und in der Praxis oft treffsicherer als ein einzelnes riesiges Kontextfenster, weil gezielte Suche weniger irrelevantes Rauschen einbringt.

Für den Projektalltag bedeutet das: Dateien wie CLAUDE.md mit projektspezifischen Konventionen, Wrapper-Befehlen und Architekturregeln werden zu einem festen Bestandteil des Repositorys, vergleichbar mit einer README.md, nur eben primär für den KI-Assistenten statt für neue Kollegen geschrieben. Der realistische Trend ist eine feinere Steuerung dieses Kontexts, etwa verschachtelte Projektregeln pro Modul, statt eines einzigen unbegrenzten Kontextfensters, das ohnehin an Kosten und Latenz stößt. Wer erwartet, dass ein Assistent künftig ganze Monorepos vollständig "im Kopf" hält, unterschätzt, wie stark gezielte Suche gegenüber brute-force geladenem Kontext in der Praxis überlegen bleibt.

4. Tool-Nutzung und MCP: KI-Assistenten als Orchestratoren

Das Model Context Protocol (MCP) definiert eine standardisierte Schnittstelle, über die ein KI-Assistent mit externen Systemen sprechen kann, etwa einer Datenbank, einem Ticketsystem oder einem internen Deployment-Skript, ohne dass für jede Kombination aus Modell und System eine eigene Integration geschrieben werden muss. Dieser Standardisierungsschritt ist technisch unspektakulär, aber praktisch bedeutsam: Er verwandelt einen Assistenten von einem reinen Text- und Dateiwerkzeug in einen Orchestrator, der Informationen aus mehreren Systemen zusammenführt, etwa den aktuellen Lagerbestand eines Produkts aus der Magento-Datenbank abfragen, während gleichzeitig der zugehörige Code angepasst wird.

Der realistische nahe Trend ist der Ausbau projektspezifischer, selbst gehosteter MCP-Server für wiederkehrende interne Aufgaben, etwa das Abfragen von Store-Konfigurationen, das Anstoßen eines Katalog-Reindex oder das Nachschlagen offener Tickets, statt eines universellen Werkzeugs, das jede denkbare Aufgabe von sich aus beherrscht. Für Teams bedeutet das einen konkreten, planbaren Investitionsschritt: einen schmalen, gut dokumentierten MCP-Server für die eigenen internen Systeme bauen, statt auf eine hypothetische Zukunft zu warten, in der ein Assistent ohne jede Integrationsarbeit alles kann.

{
  "mcpServers": {
    "magento-catalog": {
      "command": "node",
      "args": ["./mcp-servers/magento-catalog/index.js"],
      "env": {
        "MAGENTO_BASE_URL": "https://staging.mironsoft.de",
        "MAGENTO_API_TOKEN": "${MAGENTO_API_TOKEN}"
      }
    },
    "internal-ticketing": {
      "command": "npx",
      "args": ["-y", "@mironsoft/mcp-ticketing-server"],
      "env": {
        "TICKETING_API_URL": "https://tickets.mironsoft.de/api"
      }
    }
  }
}

5. Was sich nicht so schnell ändert: Architektur und Geschäftslogik

Architekturentscheidungen wie die Wahl zwischen Monolith und Microservices, die Abgrenzung von Modulgrenzen oder die Frage, ob eine Funktionalität selbst gebaut oder eingekauft wird, hängen von Faktoren ab, die kein Modell allein bewerten kann: Teamgröße, Budget, langfristige Wartungsverantwortung, politische Realitäten im Unternehmen. Ein Assistent kann Vor- und Nachteile technisch sauber aufzählen, aber die eigentliche Entscheidung erfordert jemanden, der die Konsequenzen langfristig verantwortet und mit Stakeholdern über Kompromisse verhandelt. Diese Verantwortung lässt sich nicht an ein Werkzeug delegieren, weil ein Modell keine Rechenschaft für ein System übernehmen kann, das in drei Jahren noch existiert.

Ähnlich verhält es sich mit Geschäftslogik: Anforderungen sind in der Praxis selten vollständig und widerspruchsfrei spezifiziert. Bei einer Sonderregel für Rabattstaffelungen im Checkout etwa muss jemand entscheiden, wie sich zwei sich widersprechende Anforderungen aus Vertrieb und Buchhaltung auflösen lassen, bevor überhaupt Code geschrieben wird. Ein KI-Assistent kann eine Regel technisch korrekt umsetzen, sobald sie eindeutig formuliert ist, aber die Auflösung der Mehrdeutigkeit selbst bleibt eine menschliche Aufgabe, die Fachwissen über das Geschäft, nicht über Code, erfordert. Dieser Unterschied zwischen "Code korrekt schreiben" und "die richtige Regel definieren" wird absehbar bestehen bleiben, unabhängig von der Modellgeneration.

6. Veränderte Entwickler-Workflows: Review, Pairing, Automatisierung

Der Code-Review-Prozess verschiebt sich sichtbar: Statt primär Syntaxfehler oder Stilfragen zu prüfen, konzentriert sich menschliches Review zunehmend auf Architekturentscheidungen, Sicherheitsimplikationen und die Frage, ob eine Änderung tatsächlich das richtige Problem löst. Kleinere, häufigere Pull Requests werden wahrscheinlicher, weil agentische Assistenten einzelne, klar abgegrenzte Aufgaben schneller abschließen als früher. Gleichzeitig etabliert sich ein neues Muster aus Ticket-Beschreibung, agentischer Umsetzung und anschließender menschlicher Prüfung, das repetitive Zwischenschritte reduziert, ohne die eigentliche Prüfverantwortung zu verlagern.

Praktisch heißt das auch: Automatisierte Vorprüfung gewinnt an Bedeutung, etwa ein Skript, das eingehende Pull Requests nach Risikofaktoren wie Änderungen an Zahlungs- oder Authentifizierungscode triagiert, bevor ein Mensch überhaupt hineinschaut. Solche Automatisierungen ersetzen keine Reviewentscheidung, sondern helfen, die begrenzte Reviewzeit eines Teams gezielter einzusetzen. Der Kompetenzverschiebung entsprechend braucht es dafür allerdings ein neues Set an Fähigkeiten: klar formulierte Aufgabenbeschreibungen schreiben, Ergebnisse zügig verifizieren, statt jede Zeile selbst zu tippen.

"""Simple triage script: flag high-risk pull requests for priority review."""
import re
from dataclasses import dataclass

HIGH_RISK_PATTERNS = [
    r"app/code/\w+/Payment/",
    r"app/code/\w+/Customer/Model/Auth",
    r"etc/di\.xml$",
]

@dataclass
class PullRequest:
    number: int
    changed_files: list[str]
    author: str


def is_high_risk(pr: PullRequest) -> bool:
    """Return True if any changed file matches a high-risk pattern."""
    for path in pr.changed_files:
        for pattern in HIGH_RISK_PATTERNS:
            if re.search(pattern, path):
                return True
    return False


def triage(pull_requests: list[PullRequest]) -> list[PullRequest]:
    """Sort pull requests so high-risk changes surface first for reviewers."""
    return sorted(pull_requests, key=is_high_risk, reverse=True)

7. Risiken und Grenzen: Halluzinationen, Sicherheit, Übervertrauen

Drei Risikoklassen bleiben auch mit besseren Modellen relevant. Erstens: Halluzinierte APIs oder Methodensignaturen, die plausibel aussehen, aber nicht existieren, insbesondere bei selten dokumentierten oder internen Bibliotheken. Zweitens: subtil falsche Logik, die zwar syntaktisch korrekt ist und Tests besteht, aber einen Randfall übersieht, den die Tests nicht abdecken. Drittens: Übervertrauen im Team, das dazu führt, dass Reviewer generierten Code weniger kritisch prüfen als selbst geschriebenen, obwohl beide Arten von Fehlern grundsätzlich möglich sind.

Wirksame Gegenmaßnahmen sind selten neu, sondern bestehende Praktiken konsequent angewendet: statische Analyse wie PHPStan auf Level 5, eine belastbare Testsuite, die tatsächlich ausgeführt wird, und CI-Gates, die vor dem Merge greifen statt danach. Sicherheitsrelevante Bereiche wie Zahlungsabwicklung oder Authentifizierung profitieren zusätzlich von expliziten Kennzeichnungen, die ein strengeres Review-Level erzwingen, unabhängig davon, ob die Änderung von einem Menschen oder einem Assistenten stammt. Die Verantwortung für Qualität verschiebt sich nicht auf das Werkzeug, sie bleibt beim Team, das es einsetzt.

// CI check: flag AI-assisted commits touching sensitive areas for mandatory review
const HIGH_RISK_PATHS = [
  /app\/code\/\w+\/Payment\//,
  /app\/code\/\w+\/Customer\/Model\/Auth/,
  /etc\/di\.xml$/,
];

function requiresExtraReview(changedFiles, commitMessage) {
  const touchesHighRisk = changedFiles.some((file) =>
    HIGH_RISK_PATHS.some((pattern) => pattern.test(file))
  );
  const isAiAssisted = /co-authored-by:\s*claude/i.test(commitMessage);

  // Enforce a second reviewer whenever risk and AI assistance overlap
  return touchesHighRisk && isAiAssisted;
}

async function enforceReviewGate(pullRequest) {
  if (requiresExtraReview(pullRequest.changedFiles, pullRequest.commitMessage)) {
    await addRequiredReviewer(pullRequest.number, 'security-team');
    await blockMergeUntilApproved(pullRequest.number, { minApprovals: 2 });
  }
}

8. Team- und Organisationsauswirkungen: Rollen im Wandel

Die Rolle von Einsteigern verändert sich messbar: Wenn ein Assistent Boilerplate-Code und Standardmuster zuverlässig produziert, verschiebt sich der Lernbedarf hin zum Lesen, Verstehen und kritischen Prüfen fremden Codes, statt primär zum Tippen von Syntax. Das ist eine echte Herausforderung für das Onboarding, weil viele klassische Lernpfade genau über das wiederholte Selbst-Schreiben einfacher Aufgaben liefen. Teams, die neue Kolleginnen und Kollegen einarbeiten, sollten diesen Lernweg bewusst gestalten, etwa durch gezielte Code-Reading-Sessions und Debugging-Aufgaben, statt sich allein auf natürliches Lernen durch Tippen zu verlassen.

Für erfahrene Entwickler verschiebt sich der Schwerpunkt stärker in Richtung Architektur, Review und Aufgabenformulierung, eine Rolle, die eher einem technischen Redakteur als einem reinen Codeproduzenten ähnelt. Bei der Einstellungspraxis lohnt es sich, Systemdesign-Fähigkeiten, Debugging-Kompetenz und Urteilsvermögen bei mehrdeutigen Anforderungen stärker zu gewichten als reine Tippgeschwindigkeit oder Syntaxkenntnis einzelner Frameworks. Das größte organisatorische Risiko ist stiller Kompetenzverlust: Wenn ein Team sich vollständig auf einen Assistenten verlässt, ohne die Grundlagen aktiv zu pflegen, fehlt im Ernstfall, etwa bei einem Ausfall des Werkzeugs oder einem besonders komplexen Fehler, die Tiefe, um selbstständig weiterzukommen.

9. Anpassungsfähig bleiben: praktische Strategien im Vergleich

Angesichts eines sich schnell entwickelnden Werkzeugsatzes ist die widerstandsfähigste Strategie nicht, auf ein bestimmtes Werkzeug zu wetten, sondern auf Praktiken zu setzen, die unabhängig vom konkreten Assistenten tragfähig bleiben: konsequente Testabdeckung, dokumentierte Architekturentscheidungen (etwa als Architecture Decision Records), enge, überprüfbare Permission-Regeln und die Gewohnheit, jede Änderung vor dem Commit tatsächlich zu lesen, nicht nur zu überfliegen. Diese Praktiken zahlen sich unabhängig davon aus, ob der nächste Assistent von Anthropic, einem anderen Anbieter oder einem internen Tool kommt.

Ein zweiter Baustein ist die bewusste Trennung zwischen Aufgaben mit prüfbarem Erfolgskriterium, für die sich Automatisierung eignet, und Aufgaben, die echtes Urteilsvermögen erfordern, für die sie sich nicht eignet. Die folgende Übersicht ordnet einige verbreitete Erwartungen an die Zukunft der KI-gestützten Entwicklung realistisch ein und zeigt, welche praktische Konsequenz jeweils sinnvoll ist.

#!/usr/bin/env bash
# Guardrail script: enforce quality gates before any commit is created,
# regardless of whether the change was written by a human or an AI assistant
set -euo pipefail

echo "[guardrail] Running static analysis..."
bin/analyse app/code/Mironsoft --level=5

echo "[guardrail] Running the full test suite..."
bin/cli vendor/bin/phpunit

echo "[guardrail] Checking coding standard..."
bin/phpcs app/code/Mironsoft

echo "[guardrail] All checks passed, commit is allowed."

Die Tabelle macht den Kernpunkt sichtbar: Der realistische Fortschritt liegt in der Breite und Zuverlässigkeit dessen, was Werkzeuge ausführen können, nicht in einer Verschiebung der Verantwortung weg vom Menschen. Wer diese Unterscheidung im Team verankert, etwa in Form klarer Leitlinien, welche Aufgaben delegiert werden dürfen und welche nicht, bleibt anpassungsfähig, unabhängig davon, welches konkrete Werkzeug in zwei Jahren im Einsatz ist.

10. Zusammenfassung

Die Zukunft der KI-gestützten Softwareentwicklung liegt realistischerweise nicht in vollautonomer Codeerzeugung, sondern in drei greifbaren Trends: agentischen Assistenten, die Aufgaben über geschlossene Feedback-Schleifen selbstständig abarbeiten, wachsenden Codebase-Kontexten durch gezielte Suchwerkzeuge statt brute-force geladenem Text, und standardisierter Tool-Nutzung über Protokolle wie MCP, die Assistenten zu Orchestratoren über mehrere Systeme hinweg macht. Diese Entwicklungen sind bereits heute in Werkzeugen wie Claude Code sichtbar und werden sich in den kommenden Jahren vor allem in Breite, Zuverlässigkeit und Integrationstiefe weiterentwickeln, weniger in einer grundsätzlich neuen Fähigkeitsklasse.

Gleichzeitig bleibt eine klare Grenze bestehen: Architekturentscheidungen und Geschäftslogik erfordern menschliches Urteilsvermögen, Rechenschaftspflicht und Verhandlungsgeschick zwischen widersprüchlichen Anforderungen, Fähigkeiten, die kein Sprachmodell übernehmen kann, unabhängig von seiner Größe. Teams, die jetzt in Testabdeckung, dokumentierte Entscheidungen, enge Permission-Regeln und bewusste Kompetenzentwicklung investieren, bleiben anpassungsfähig, ganz gleich, welches konkrete Werkzeug in den nächsten Jahren den Alltag prägt.

11. FAQ: Die Zukunft der KI-gestützten Softwareentwicklung