Vitalij Bojatschkin

10 Fehler bei der LLM-Integration in Engineering-Teams (und wie ihr sie vermeidet)

Q: Welcher Fehler ist am häufigsten?

Eindeutig: kein gemeinsamer Standard. Jeder Engineer nutzt das Tool anders, es gibt keine CLAUDE.md, keine Custom Commands, keine Reviews. Resultat: schwankende Code-Qualität, lange PR-Reviews, frustrierte Teams. Lösung: 2-Tage-Onboarding-Sprint mit dokumentiertem Setup.

Q: Welcher Fehler ist am teuersten?

Fehlendes Permission-Modell, gefolgt von ungeprüften Costs. Ohne Permissions kann ein AI-Tool theoretisch in Produktions-Daten schreiben — der erste Incident kostet mehr als jahrelanges Subscription-Budget. Ungeprüfte API-Costs können in 2-3 Monaten 5-stellige Euro-Beträge erreichen.

Q: Wie erkenne ich, ob mein Team in einem dieser Fehler steckt?

Schnell-Check: Frag 3 Engineers, welches AI-Coding-Tool sie nutzen und wie ihr CLAUDE.md aufgebaut ist. Wenn ihr 3 verschiedene Antworten bekommt: Fehler #1 (kein Standard). Wenn niemand weiß was Permissions sind: Fehler #4 (kein Permission-Modell). Wenn niemand die Kosten kennt: Fehler #5.

Q: Können diese Fehler nachträglich behoben werden?

Ja, aber mit unterschiedlichem Aufwand. Standard-Etablierung in einem 4-Wochen-Sprint möglich. Permission-Modell nachrüsten ist 1-2 Wochen. Cost-Tracking nachrüsten ist Stunden-Sache. Schwieriger ist Team-Habituation an neue Patterns — die Fehler sind oft mental, nicht technisch.

Q: Was sollte ein neues Team von Tag 1 anders machen?

Zwei Dinge: (1) eine schlanke CLAUDE.md schreiben bevor der erste Engineer Claude Code öffnet (nicht später) und (2) ein Permission-Modell festlegen (was darf der Agent lesen, editieren, ausführen). Das ist 4 Stunden Vorab-Investment, das später monatelange Korrekturen spart.

Aus Audits und Praxisprojekten: Die 10 häufigsten Fehler, die Engineering-Teams bei der Einführung von Claude Code, Codex und Cursor machen — mit konkreten Lösungen aus echten Setups.

import BlogFAQ from '../../src/components/BlogFAQ'; import KeyTakeaways from '../../src/components/KeyTakeaways';

<KeyTakeaways items= /

<p data speakable Aus zwei Jahren Audits und Praxisprojekten kristallisieren sich 10 wiederkehrende Fehler heraus, die Engineering Teams bei der LLM Integration machen. Keiner davon ist exotisch — die meisten Teams machen mindestens 3 davon parallel. Dieser Post zeigt sie konkret, mit Symptomen, Kosten und Lösungen. Wer's vermeidet, spart messbar Monate und niedrige fünfstellige Euro Beträge. </p

Fehler 1: Kein gemeinsamer Standard

Symptom: Jeder Engineer nutzt Claude Code anders. Einer hat eine CLAUDE.md, ein anderer nicht. Custom Commands existieren oder existieren nicht. Workflow Reviews finden nie statt.

Konsequenz: Code Qualität schwankt zwischen Engineers, PR Reviews dauern lang weil jede AI generierte Lösung anders aussieht, neue Teammitglieder müssen sich ihr eigenes Setup zusammenstückeln.

Lösung: Einmaliger 2 Tage Onboarding Sprint, in dem das Team eine gemeinsame CLAUDE.md, 3 5 Custom Commands und einen Workflow Standard etabliert. Danach quartalsweises Refresh Meeting. Mehr dazu: Claude Code & Codex Onboarding.

Fehler 2: Tool Overload (3+ Tools parallel)

Symptom: Jeder Engineer hat Cursor + Continue + Claude Code + Copilot installiert, weil „man muss ja was probieren". Niemand weiß, welches Tool wann genutzt wird.

Konsequenz: Kosten von 200 400€ pro Engineer pro Monat ohne klaren ROI. Workflow Inkonsistenz, weil Engineers in unterschiedlichen Tools unterschiedliche Patterns lernen. Audit Trail unmöglich.

Lösung: Maximal 2 Tools parallel pro Engineer, klar nach Use Case getrennt. Beispiel: Cursor für IDE Arbeit, Claude Code für Terminal /Multi Repo Tasks. Audit nach 6 Monaten ob die Aufteilung noch passt. Mehr: Agent Workflow Audit.

Fehler 3: CLAUDE.md als Marketing Copy

Symptom: Die CLAUDE.md enthält Sätze wie „Wir bauen weltklasse Software" oder „Schreibe sauberen Code". Keine konkreten Conventions, keine Quick Reference, keine Known Friction Liste.

Konsequenz: Claude ignoriert den Inhalt weitgehend, weil nichts Konkretes drinsteht. Engineers lesen die CLAUDE.md einmal und nie wieder. Wartung findet nicht statt.

Lösung: 5 Pflichtsektionen (Stack, Quick Reference Commands, Coding Conventions mit Beispielen, Workflow Patterns, Known Friction). Mit konkretem Code Snippet pro Convention. Mehr dazu: CLAUDE.md Template für Engineering Teams.

Fehler 4: Kein Permission Modell

Symptom: Claude Code läuft mit Default Permissions (alles erlaubt). Niemand hat die settings.json angefasst. Keine Pre Bash Hooks für gefährliche Befehle.

Konsequenz: Der Agent kann theoretisch in Produktions Datenbanken schreiben, sensitive Files lesen, oder kubectl delete ns prod ausführen. Bisher kein Incident — Frage der Zeit.

Lösung: Explizites Permission Modell in .claude/settings.json + Pre Bash Hooks für gefährliche Patterns. Konkrete Patterns: Claude Code Hooks Cookbook.

Fehler 5: Kein Cost Tracking

Symptom: Niemand weiß, wie viel die AI Coding Tools pro Monat kosten. Subscriptions laufen, LLM API Bills kommen ungelesen. „Es funktioniert ja."

Konsequenz: Realistische 2026 Zahlen aus Audits: 80 180€ pro Engineer pro Monat an LLM API Kosten. Bei 20 Personen Team unbemerkt 30k€ Jahresbudget verbrannt. Häufig 30 50% Doppel Spend.

Lösung: Cost Dashboard pro Tool und Engineer. Monthly Review mit Cost Owner. Automatische Alarms bei Budget Überschreitung. Wer Provider Dashboard nicht ausreichend findet: eigenes Reporting bauen, Aufwand 1 2 Tage.

Fehler 6: Workflows als One shot Prompts

Symptom: Komplexe Workflows (Code Review, Test Generation, Doku Sync) werden als einzelner riesiger Prompt geschrieben, der „alles auf einmal" macht.

Konsequenz: Inkonsistente Ergebnisse, lange Antwortzeiten, schwer zu debuggen wenn was schiefgeht. Engineers verbrennen Zeit beim Korrigieren statt beim eigentlichen Coden.

Lösung: Multi Step Workflows mit klaren Zwischenergebnissen. Plan First Pattern für Refactorings. Workflow als Custom Command versionieren, nicht ad hoc neu schreiben. Mehr: Agent Workflow Patterns.

Fehler 7: Tests fehlen oder sind nachgelagert

Symptom: AI generierter Code wird ohne Tests gemerget. Tests werden „später" geschrieben. Coverage sinkt schleichend.

Konsequenz: Production Bugs in AI generiertem Code sind schwerer zu debuggen, weil der ursprüngliche Engineer den Code nicht selbst geschrieben hat. Refactorings werden mit der Zeit riskanter, weil Test Coverage fehlt.

Lösung: Test First Pflicht oder zumindest Test Coverage Mindestwert pro PR (z.B. via CI Check). Custom Command für Test Generation aus Diff als Standard. Pre Commit Hook für Test Run vor Commit.

Fehler 8: Vendor Lock In durch Vendor spezifische Patterns

Symptom: Custom Commands sind nur in Claude Code, Plugins sind nur in Cursor, Pipelines sind nur in Codex. Wechsel zu einem anderen Tool würde Wochen kosten.

Konsequenz: Wenn ein Vendor Strategie ändert, Preise erhöht, oder eine Funktion einstellt, ist das Team gefangen. Verhandlungsposition gegenüber Vendor sinkt.

Lösung: Vendor agnostische Layer wo möglich. MCP Server für interne Integrationen (funktioniert tool übergreifend). CLAUDE.md statt vendor spezifischen Config Files als Single Source of Truth. Workflows als CLI Skripte, nicht nur als Tool Plugins.

Fehler 9: Onboarding wird improvisiert

Symptom: Neue Engineers bekommen einen Link zur Claude Code Doku und ein „viel Erfolg". Kein strukturiertes Onboarding, kein Pair Programming Slot, keine Begleitung.

Konsequenz: Neue Engineers brauchen 4 6 Wochen statt 1 2 Wochen, bis sie produktiv mit dem AI Coding Setup arbeiten. In dieser Zeit reproduzieren sie viele der Fehler dieser Liste eigenständig.

Lösung: 1 tägiges AI Coding Onboarding für neue Teammitglieder. Pair Programming Slot in der ersten Woche. Mentor System (Senior + Junior gepaart für 4 Wochen). Mehr dazu: Claude Code & Codex Onboarding deckt den initialen Team Setup ab.

Fehler 10: Kein systematisches Review

Symptom: Das AI Coding Setup wird einmal aufgebaut und dann nie wieder angeschaut. Tools entwickeln sich weiter, Anthropic released neue Features, MCP Spec ändert sich — niemand triaget das.

Konsequenz: Setup veraltet still. Engineers stolpern über Features, die seit 6 Monaten anders funktionieren. Sicherheitsrelevante Updates werden verpasst.

Lösung: Quartalsweise Review Session (60 Minuten) mit dem Team. Was hat sich bei den Tools geändert, was sollte ins Setup übernommen werden, was kann weg. Für Teams ohne eigene Kapazität: LLM Office Hours Retainer deckt genau diesen kontinuierlichen Update Bedarf ab.

Bonus Fehler: AI Coding als Buzzword Compliance

Nicht direkt einer der 10, aber häufig der Wurzel Fehler: AI Coding wird eingeführt, weil „man muss". Niemand fragt nach konkretem Business Outcome. Resultat: Tool ist da, Setup ist da, aber Engineers nutzen es kaum, weil's nicht klar zu ihrem Workflow passt.

Lösung: Vor der Tool Einführung 30 Minuten Diskussion: was wollen wir damit erreichen, woran messen wir Erfolg, wer ist Owner. Wenn keine Antworten kommen — nicht einführen, sondern erst das Problem schärfen.

Welche dieser Fehler steckt euch?

Schnell Selbsttest in 3 Fragen:

1. Fragt 3 zufällige Engineers, welches AI Coding Tool sie nutzen und wie ihr CLAUDE.md aussieht. Bei 3 verschiedenen Antworten: Fehler 1. 2. Schaut in die .claude/settings.json. Wenn da nichts steht: Fehler 4. 3. Fragt den Engineering Manager nach den AI Coding Tool Kosten der letzten 3 Monate. Wenn keine konkrete Zahl kommt: Fehler 5.

Wer alle drei „bestanden" hat: glückwunsch, ihr seid in den oberen 10% der Teams. Wer 1 2 davon schief beantwortet hat: gute Nachricht, das sind in den meisten Fällen 4 Wochen Sprints zur Behebung.