KI-Abhängigkeit im Team vermeiden

1. Was KI-Abhängigkeit im Entwicklerteam konkret bedeutet

KI-Abhängigkeit bezeichnet in diesem Kontext keine Suchtmetapher, sondern einen schleichenden Kompetenzverlust: Ein Entwickler oder ein ganzes Team verliert die Fähigkeit, Probleme ohne KI-Unterstützung eigenständig zu durchdenken, weil diese Fähigkeit über Monate hinweg zu selten trainiert wird. Der Unterschied zwischen einem Werkzeug und einer Krücke liegt nicht in der Technologie selbst, sondern in der Nutzungsgewohnheit. Ein Werkzeug beschleunigt eine Fähigkeit, die vorhanden bleibt. Eine Krücke ersetzt die Fähigkeit so vollständig, dass sie ohne das Hilfsmittel nicht mehr funktioniert.

In der Praxis zeigt sich das an konkreten Situationen: Ein Entwickler öffnet bei jedem Compiler-Fehler zuerst Claude, bevor er die Fehlermeldung selbst liest. Ein Reviewer approved einen Pull Request, dessen Logik er nicht in eigenen Worten erklären könnte. Ein Team braucht spürbar länger für ein Bugfix, sobald der KI-Dienst einmal nicht erreichbar ist. Keine dieser Situationen ist ein Beweis für generelle Unfähigkeit, aber jede davon ist ein Signal, das ernst genommen werden sollte, bevor daraus ein strukturelles Problem im Team wird. Dieser Artikel ist kein Plädoyer gegen Claude oder Claude Code, sondern für einen bewussten Umgang, der Geschwindigkeit und Kompetenzerhalt gleichzeitig ermöglicht.

2. Wie Skill-Atrophie entsteht: Nutzen versus Verstehen

Die Kognitionspsychologie kennt den sogenannten Generierungseffekt: Wer eine Antwort selbst erarbeitet, auch mit Umwegen und Fehlversuchen, behält sie deutlich zuverlässiger als jemand, der dieselbe Antwort nur liest. Beim Programmieren mit KI-Assistenten fällt genau dieser aktive Anteil häufig weg. Ein Entwickler liest einen fertigen, funktionierenden Vorschlag, findet ihn plausibel und übernimmt ihn, ohne den Lösungsweg selbst nachvollzogen zu haben. Kurzfristig ist das Ergebnis identisch, langfristig bleibt beim passiven Lesen deutlich weniger an belastbarem mentalem Modell zurück als beim aktiven Erarbeiten.

Typische Symptome dieser schleichenden Entwicklung sind beobachtbar, bevor sie zum echten Problem werden: Die Zeit bis zur ersten eigenen Lösungsidee bei einer neuen Aufgabe wird länger, während die Zeit bis zum ersten Prompt kürzer wird. Debugging-Sitzungen verlaufen zunehmend als Copy-Paste der Fehlermeldung in den Chat, statt als systematisches Eingrenzen mit Log-Ausgaben und Breakpoints. Und am deutlichsten zeigt es sich, wenn ein Entwickler einen von ihm selbst gemergten Pull Request zwei Wochen später nicht mehr erklären kann, ohne erneut die KI zu befragen. Keines dieser Symptome ist dramatisch für sich allein, in der Summe über ein Team hinweg wird die Abhängigkeit jedoch strukturell sichtbar.

3. Jeden KI-Vorschlag verstehen, bevor er akzeptiert wird

Die wirksamste einzelne Gewohnheit gegen Skill-Atrophie ist simpel formuliert und in der Praxis trotzdem schwer durchzuhalten: Kein Codevorschlag wird akzeptiert, den der Entwickler nicht in eigenen Worten erklären kann, ohne dabei die Erklärung der KI zu wiederholen. Das bedeutet nicht, jede Zeile misstrauisch zu hinterfragen, sondern bewusst innezuhalten, bevor ein Diff mit „Accept“ übernommen wird, und sich selbst zu fragen, warum diese Lösung funktioniert und welche Alternative verworfen wurde. Bei kleinen, offensichtlichen Änderungen dauert das Sekunden. Bei komplexerer Logik ist genau dieser Moment des Innehaltens der Punkt, an dem tatsächliches Verständnis entsteht statt bloßer Übernahme.

Technisch lässt sich diese Gewohnheit teilweise erzwingen, auch wenn keine Automatisierung fehlendes Verständnis wirklich ersetzen kann. Ein Git-Hook, der bei größeren, als KI-generiert markierten Änderungen eine kurze Begründung im Commit verlangt, schafft zumindest einen Reibungspunkt, der zum Nachdenken zwingt. Wichtiger als das Werkzeug bleibt aber die Teamnorm dahinter: Begründungen wie „Claude hat das so vorgeschlagen“ werden im Review explizit nicht akzeptiert, es sei denn, sie werden um eine eigene fachliche Einschätzung ergänzt.

#!/usr/bin/env bash
# .git/hooks/commit-msg: require a rationale trailer for large AI-assisted commits
set -euo pipefail

commit_msg_file="$1"
diff_lines=$(git diff --cached --numstat | awk '{sum += $1 + $2} END {print sum+0}')
threshold=40

# Only enforce the rule for sizeable changes, small tweaks pass through
if (( diff_lines > threshold )); then
  if ! grep -qi "^Reviewed-Understanding:" "$commit_msg_file"; then
    echo "[BLOCKED] Commits over ${threshold} changed lines need a 'Reviewed-Understanding:' trailer." >&2
    echo "Explain in one sentence why this change works, in your own words." >&2
    exit 1
  fi
fi

exit 0

4. Periodisches KI-freies Problemlösen als bewusstes Training

Ebenso wichtig wie die Prüfung jedes einzelnen Vorschlags ist regelmäßiges, bewusst KI-freies Arbeiten. Das bedeutet nicht, produktive Zeit zu verschwenden, sondern gezielt Situationen zu schaffen, in denen das Team wieder ohne Autocomplete und ohne Chat-Fenster denkt: ein Bug wird zunächst zwanzig Minuten lang ausschließlich mit Logs, Debugger und eigenem Verständnis der Codebasis eingegrenzt, bevor überhaupt eine KI befragt wird. Eine neue Kata oder Übungsaufgabe wird einmal pro Woche komplett ohne KI-Unterstützung gelöst, auch wenn die Lösung dadurch länger dauert und stellenweise unelegant ausfällt.

Der Wert dieser Übungen liegt nicht im Ergebnis, sondern im Prozess: Wer regelmäßig ohne Hilfsmittel eine Rate-Limiter-Implementierung, eine kleine Zustandsmaschine oder einen Parser von Grund auf selbst schreibt, behält die grundlegenden Denkmuster, die beim reinen Reviewen von KI-Code verkümmern. Wichtig ist, diese Übungen nicht als Strafe oder Ideologie zu framen, sondern als das, was sie sind: gezieltes Training einer Fähigkeit, die im Alltag sonst zu selten beansprucht wird, ähnlich wie ein Musiker Tonleitern übt, obwohl im Konzert niemand einzelne Tonleitern hört.

# kata_rate_limiter.py: weekly AI-free exercise, attempt this without an assistant first
# Goal: implement a sliding-window rate limiter from scratch, then compare with a Claude version

import time
from collections import deque


class SlidingWindowRateLimiter:
    """Allows at most max_requests within window_seconds, per client key."""

    def __init__(self, max_requests: int, window_seconds: float):
        self.max_requests = max_requests
        self.window_seconds = window_seconds
        self.requests: dict[str, deque[float]] = {}

    def allow(self, client_key: str) -> bool:
        now = time.monotonic()
        timestamps = self.requests.setdefault(client_key, deque())

        # Drop timestamps outside the current window before counting
        while timestamps and now - timestamps[0] > self.window_seconds:
            timestamps.popleft()

        if len(timestamps) >= self.max_requests:
            return False

        timestamps.append(now)
        return True


# Self-check: write your own test cases before asking an AI to review the edge cases
limiter = SlidingWindowRateLimiter(max_requests=3, window_seconds=1.0)
assert limiter.allow("client-a") is True
assert limiter.allow("client-a") is True
assert limiter.allow("client-a") is True
assert limiter.allow("client-a") is False  # fourth request within the same second

5. Junior-Entwickler: das Risiko ohne eigenes mentales Modell

Bei erfahrenen Entwicklern ersetzt KI-Abhängigkeit vorhandenes Wissen schrittweise. Bei neuen Teammitgliedern kann sie verhindern, dass dieses Wissen überhaupt erst entsteht. Wer vom ersten Arbeitstag an jede Frage zur Codebasis sofort an Claude Code stellt, statt sich durch Repository-Struktur, Namenskonventionen und Modulgrenzen selbst zu navigieren, baut nie ein eigenes mentales Modell des Systems auf. Das fällt oft erst Monate später auf, wenn genau dieser Entwickler in einer Situation ohne KI-Zugriff, etwa bei einem Kundentermin oder während eines Netzwerkausfalls, nicht mehr in der Lage ist, sich im eigenen Projekt zu orientieren.

Ein pragmatischer Gegenentwurf ist ein bewusst gestaffeltes Onboarding: In den ersten zwei bis drei Wochen navigiert der neue Entwickler das Repository primär selbst, unterstützt durch Pair Programming mit erfahrenen Kollegen statt durch einen Chat. Claude Code darf für Recherchefragen zu Magento- oder Hyvä-APIs genutzt werden, nicht aber, um sich die Struktur des eigenen Projekts erklären zu lassen, die durch aktives Erkunden erlernt werden soll. Diese Einschränkung ist zeitlich begrenzt und explizit kommuniziert, damit sie nicht als Misstrauen gegenüber der Technologie missverstanden wird, sondern als gezielte Lernphase.

6. Der Erklär-Test: Code-Review als Verständnis-Check

Code-Reviews prüfen traditionell Korrektheit, Stil und Architektur. Eine ergänzende, einfache Regel macht sie zusätzlich zu einem Verständnis-Check: Der Reviewer fragt gezielt nach dem Warum einer nicht offensichtlichen Entscheidung, und eine Antwort wie „so hat Claude es vorgeschlagen“ gilt explizit nicht als ausreichend. Diese Regel kostet in den meisten Reviews nur wenige zusätzliche Minuten, deckt aber zuverlässig auf, wenn ein Autor Code gemergt hat, den er selbst nicht vollständig durchdrungen hat, unabhängig davon, ob der Code ursprünglich von einem Menschen oder von einer KI stammt.

Für Teams, die diese Praxis strukturiert einführen wollen, hilft eine sichtbare Checkliste im Pull-Request-Template, die eine kurze Freitext-Begründung für nicht triviale Änderungen einfordert, bevor der Review-Status auf „bereit“ gesetzt werden kann. Das folgende Beispiel zeigt, wie sich ein solcher Zwischenschritt clientseitig mit Alpine.js visualisieren lässt, wie es in Hyvä-Themes ohnehin bereits verwendet wird. Wichtig ist, dass eine rein clientseitige Prüfung keine echte Durchsetzung ersetzt, sie macht die Erwartung lediglich sichtbar, bevor ein Reviewer manuell nachhakt.

// pr-checklist.js: Alpine.js component making the "explain before approve" habit visible
// Client-side nudge only, does not replace an actual review by a human reviewer
document.addEventListener('alpine:init', () => {
  Alpine.data('prChecklist', () => ({
    explanation: '',
    aiAssisted: false,
    get canApprove() {
      // Require at least a short, non-generic rationale for non-trivial changes
      const wordCount = this.explanation.trim().split(/\s+/).filter(Boolean).length;
      return wordCount >= 8 && !/claude|chatgpt|ki hat/i.test(this.explanation);
    },
    approve() {
      if (!this.canApprove) {
        alert('Please explain the change in your own words before approving.');
        return;
      }
      console.log('Approved with rationale:', this.explanation);
    }
  }));
});

7. Team-Leitplanken: klare Regeln statt Bauchgefühl

Ohne schriftliche Vereinbarung entscheidet jeder Entwickler individuell und uneinheitlich, wann KI-Unterstützung angemessen ist. Das führt in der Praxis zu einem Team, in dem manche Mitglieder jede Codezeile durch Claude generieren lassen, während andere aus Prinzip komplett verzichten, ohne dass diese Unterschiede jemals bewusst besprochen wurden. Eine kurze, dokumentierte Team-Policy schafft hier gemeinsamen Grund, ohne die individuelle Arbeitsweise übermäßig einzuschränken. Sie unterscheidet typischerweise zwischen risikoarmen Aufgaben wie Boilerplate-Code, Testgerüsten und Dokumentation, bei denen großzügige KI-Nutzung ausdrücklich erwünscht ist, und Kernlogik, Architekturentscheidungen sowie sicherheitsrelevantem Code, bei denen ein höheres Maß an eigenständigem Durchdenken verlangt wird.

Eine solche Policy muss kein bürokratisches Dokument sein, ein kurzes, versioniertes Konfigurationsfile im Repository reicht aus und macht die Regeln für neue Teammitglieder sofort sichtbar. Entscheidend ist, dass sie regelmäßig überprüft und angepasst wird, etwa im vierteljährlichen Team-Retro, statt einmal geschrieben und dann vergessen zu werden. Eine Policy, die niemand mehr kennt, hat denselben Effekt wie keine Policy.

{
  "ai_usage_policy_version": "1.2",
  "last_reviewed": "2026-07-12",
  "categories": {
    "boilerplate_and_tests": {
      "ai_usage": "encouraged",
      "review_requirement": "standard"
    },
    "documentation": {
      "ai_usage": "encouraged",
      "review_requirement": "standard"
    },
    "core_business_logic": {
      "ai_usage": "allowed_with_explanation",
      "review_requirement": "author must explain rationale without repeating AI wording"
    },
    "architecture_decisions": {
      "ai_usage": "input_only",
      "review_requirement": "human-authored ADR required, AI suggestion cited as one input"
    },
    "security_and_payments": {
      "ai_usage": "allowed_with_explanation",
      "review_requirement": "mandatory security review, see AI-code-risk-tiers policy"
    }
  },
  "onboarding_exception": {
    "first_weeks": 3,
    "ai_usage": "research_only",
    "note": "New developers explore repository structure themselves before consulting AI on it"
  }
}

8. Abhängigkeit im Team beobachten und messen

Skill-Atrophie entsteht schleichend und wird oft erst bemerkt, wenn sie bereits spürbare Auswirkungen hat, etwa wenn ein Bugfix während eines KI-Ausfalls plötzlich Stunden statt Minuten dauert. Ein paar einfache, nicht-invasive Beobachtungen helfen, das Risiko früher zu erkennen. Dazu zählt, wie oft in Reviews die Begründung „habe ich nicht selbst geprüft, KI hat es vorgeschlagen“ auftaucht, wie häufig Entwickler in Standups berichten, bei einer Aufgabe zunächst auf die KI-Antwort gewartet zu haben, statt einen eigenen Lösungsansatz zu skizzieren, und wie sich die Zeit bis zur ersten sinnvollen Debugging-Hypothese über die Zeit entwickelt.

Diese Beobachtungen sollten niemals zu individueller Leistungsbewertung einzelner Entwickler missbraucht werden, das würde die notwendige Offenheit im Team zerstören und dazu führen, dass Probleme verschwiegen statt besprochen werden. Sinnvoll ist ein aggregierter, anonymisierter Blick auf das Team als Ganzes, etwa im Rahmen eines Retros. Ein einfaches Skript, das Commit-Trailer und Review-Kommentare auswertet, liefert dafür brauchbare Anhaltspunkte, ohne einzelne Personen bloßzustellen.

#!/usr/bin/env bash
# team-ai-signal-report.sh: aggregated, anonymized signal for the quarterly retro
# Never use this to evaluate individual developers, only team-level trends
set -euo pipefail

since="${1:-30 days ago}"

echo "== AI-assisted commits without a rationale trailer =="
git log --since="$since" --grep="Co-authored-by: Claude" --pretty=format:"%H" | while read -r sha; do
  git log -1 --format="%B" "$sha" | grep -qi "^Reviewed-Understanding:" || echo "$sha"
done | wc -l

echo "== Average review comments per AI-assisted PR (needs gh CLI) =="
gh pr list --state merged --search "Co-authored-by: Claude" --json number \
  --jq '.[].number' | while read -r pr; do
    gh pr view "$pr" --json comments --jq '.comments | length'
  done | awk '{sum+=$1; n++} END {if (n>0) printf "%.1f comments/PR (n=%d)\n", sum/n, n}'

9. Produktivität und Kompetenzerhalt im direkten Vergleich

Der Zielkonflikt zwischen Geschwindigkeit und Kompetenzerhalt lässt sich nicht pauschal auflösen, wohl aber pro Szenario bewusst entscheiden. Die folgende Übersicht ordnet typische Situationen im Entwickleralltag danach ein, welcher Umgang die Abhängigkeit fördert und welche Praxis Verständnis und Geschwindigkeit gleichzeitig sichert.

Die Tabelle zeigt ein wiederkehrendes Muster: Nicht die Nutzung von KI selbst ist das Problem, sondern der Zeitpunkt, an dem sie ins Spiel kommt. Wird die KI erst nach einem eigenen ersten Lösungsversuch konsultiert, bleibt das Verständnis erhalten und die Geschwindigkeit steigt trotzdem, weil der eigene Ansatz gezielt mit einer zweiten Perspektive abgeglichen werden kann. Wird die KI hingegen an die erste Stelle gesetzt, ersetzt sie das eigene Denken vollständig, noch bevor es überhaupt beginnen konnte.

10. Zusammenfassung

KI-Abhängigkeit im Entwicklerteam entsteht nicht durch die Nutzung von Claude an sich, sondern durch die Gewohnheit, Vorschläge zu übernehmen, ohne sie zu verstehen. Der Generierungseffekt aus der Kognitionspsychologie erklärt, warum aktives Erarbeiten robustere mentale Modelle hinterlässt als passives Lesen fertiger Lösungen. Die wirksamste Einzelmaßnahme bleibt einfach: Kein Vorschlag wird akzeptiert, den der Entwickler nicht in eigenen Worten erklären kann. Ergänzend braucht es periodisches, bewusst KI-freies Problemlösen, damit grundlegende Denkmuster wie Debugging und algorithmisches Denken trainiert bleiben, statt zu verkümmern.

Besonders gefährdet sind Junior-Entwickler, die ohne eigenes mentales Modell der Codebasis starten, wenn KI von Anfang an uneingeschränkt verfügbar ist. Ein gestaffeltes Onboarding, ein Erklär-Test im Code-Review und eine schriftliche, regelmäßig überprüfte Team-Policy schaffen gemeinsame Leitplanken, ohne die Produktivitätsgewinne von KI-Assistenten zu opfern. Die Beobachtung von Abhängigkeitssignalen auf Teamebene, niemals zur individuellen Bewertung, hilft, das Risiko zu erkennen, bevor ein KI-Ausfall oder ein Kundentermin ohne Zugriff die Lücke schmerzhaft offenlegt.

11. FAQ: KI-Abhängigkeit im Team vermeiden