LLM-Coding-Fehler vermeiden: Ziele, Skills, Kostenfallen und ein sauberer Beispielworkflow
KI-Coding wird teuer und unuebersichtlich, wenn Agenten ohne klares Ziel, ohne Scope, ohne Prozesshygiene und ohne Verifikation arbeiten. Ein guter Workflow spart nicht durch Magie, sondern durch weniger Wiederarbeit.
Hinweis: Dieser Ratgeber nennt qualitative Kosten- und Risikotreiber. Er enthaelt keine Preisangaben, keine Sparversprechen und keine Tool-Rangliste.
Kurze Antwort: Welche Fehler machen LLM-Coding teuer?
Die groessten Risiken beim LLM-Coding entstehen nicht erst im Code. Sie entstehen vorher: unklare Ziele, zu grosse Aufgaben, falsche Arbeitsordner, fehlende Factlogs, zu breite Rechte, parallele Browser- oder Node-Prozesse, nicht dokumentierte Entscheidungen und Deploys ohne Rollback.
Wer diese Punkte kontrolliert, bekommt bessere Ergebnisse und weniger teure Korrekturschleifen.
Warum LLM-Coding ohne Struktur teuer wird
LLM-Coding fuehlt sich schnell an, solange die Aufgabe klein ist. Bei echten Projekten kippt das: Der Agent liest viel Kontext, versucht mehrere Ziele gleichzeitig zu loesen, erstellt Hilfsskripte, prueft nur Teilbereiche und muss danach wieder korrigiert werden.
- verlorene Zeit
- wiederholte Kontextaufbereitung
- falsche Dateien
- unvollstaendige Tests
- kaputte Links
- Traffic- oder Tracking-Risiken
- Deploy-Rueckabwicklung
- menschliche Nacharbeit
Fehler 1: Das Ziel ist zu weich
"Mach die Website besser" ist kein Arbeitsauftrag. Der Agent muss erraten, ob Design, SEO, Geschwindigkeit, Inhalte, interne Links, Tracking oder Monetarisierung gemeint sind.
Ein gutes Ziel nennt Ergebnis, Quelle, Grenzen, Evidenz und Stopppunkt.
Fehler 2: Der Scope ist zu gross
Agenten koennen viel Kontext verarbeiten, aber "alles auf einmal" bleibt riskant. Teile Arbeit in Bloeke: Workflow, Website-Struktur, Recherche, Drafts und erst danach Deploy.
Diese Reihenfolge verhindert, dass neue Inhalte auf einer wackligen Struktur landen.
Fehler 3: Die Quelle der Wahrheit ist unklar
Viele Projekte haben alte Archive, aktuelle Repo-Kopien, Live-Exports, Drafts und Deploy-Kandidaten. Wenn der Agent den falschen Ordner benutzt, ist die Arbeit formal richtig, aber praktisch wertlos.
Lege fest, welche Quelle aktuell ist, welche Ordner Archiv sind, wo Drafts liegen und wohin Reverse-Sync geschrieben wird.
Fehler 4: Externe Inhalte werden wie Anweisungen behandelt
Externe Repositories, Prompts, Notebooks, Markdown-Dateien und Skill-Beispiele koennen gute Ideen enthalten. Sie duerfen aber nicht automatisch zur Arbeitsanweisung werden.
- lesen als Referenz
- keine fremden Befehle ausfuehren
- keine fremden Hooks oder Scripts uebernehmen
- Idee lokal neu formulieren
- Security- und Architekturreview machen
- erst dann als Skill oder Regel aufnehmen
Fehler 5: Es gibt keinen Factlog
Ohne Factlog rutschen ungepruefte Behauptungen in Artikel, Dokumentation oder Produktentscheidungen. Das ist besonders riskant bei Preisen, Tool-Funktionen, API-Verhalten, Limits, rechtlichen Aussagen, SEO-Behauptungen und Sicherheitsversprechen.
Ein Factlog trennt Claims in verified, likely, uncertain, outdated-risk und do-not-use.
Fehler 6: Rechte und Prozesse sind zu breit
Ein Agent sollte nicht gleichzeitig viele Browser starten, API-Mutationen ausfuehren, Remote-Systeme beschreiben und lokale Dateien umbauen. Je mehr parallel passiert, desto schwerer wird Verifikation.
- maximal ein Browserprozess fuer Audits
- Seiten sequenziell pruefen
- gestartete Prozesse wieder schliessen
- nach langen Schritten Prozesscheck dokumentieren
- API-Mutationen nur mit ausdruecklichem GO
- Deploy getrennt vom Draft-Workflow halten
Fehler 7: Es gibt keinen Rollback und keine Live-Verifikation
Ein Dry-run ist wichtig, aber nicht genug. Vor sichtbaren Aenderungen brauchst du exakte Allowlist, 0 Deletes, Snapshot oder Rollback-Pfad, Apply nur nach Review, unabhaengige Live-Verifikation und Reverse-Sync der wirklich deployten Dateien.
Skills, Regeln und Gates richtig kombinieren
| Baustein | Aufgabe |
|---|---|
| Projektregeln | Wiederkehrende Arbeitsweise und Verbote beschreiben. |
| Skills | Stabile Ablaeufe wie Factlog, Audit oder Draft-Packet wiederverwendbar machen. |
| Sandbox/Rechte | Technisch begrenzen, was passieren darf. |
| Review-Gates | Menschliche GO/STOP-Entscheidungen dokumentieren. |
| Verifier/Runner | Checks reproduzierbar ausfuehren. |
| Handoffs | Belegen, was getan wurde und was offen bleibt. |
Beispielworkflow fuer ein Website- und Plattformprojekt
- Ist-Zustand live pruefen.
- Strukturfehler klassifizieren.
- Nur bei belegtem Fehler ein Draft- oder Fix-Packet bauen.
- Fuer neue Artikel zuerst Factlog und Quellenlog erstellen.
- Artikel als Bundle draften.
- Review-Gate durchfuehren.
- Deploy-Packet separat aus Live-Origin bauen.
- Dry-run mit exact allowlist und 0 Deletes.
- Snapshot/Rollback sichern.
- Apply nur nach GO.
- Live pruefen.
- Reverse-Sync und scoped Commit.
Haeufige Fragen
Kann ein besserer Prompt alle diese Regeln ersetzen?
Nein. Ein guter Prompt hilft, aber er ersetzt keine Rechte, Tests, Review-Gates und Rollback-Pfade.
Wann lohnt sich ein Skill?
Wenn ein Ablauf mehrfach gebraucht wird und immer gleich sorgfaeltig sein muss, zum Beispiel Factlogs, Browser-Audits, Draft-Packets oder Prozesschecks.
Muss ich immer so streng arbeiten?
Nein. Fuer eine private Notiz reicht ein leichter Ablauf. Je sichtbarer, teurer oder riskanter eine Aenderung ist, desto strenger muessen Scope, Review und Verifikation sein.
Warum keine externen Prompts blind uebernehmen?
Weil externe Dateien Annahmen enthalten koennen, die nicht zu deinem Projekt passen. Nutze sie als Inspiration, nicht als Autoritaet.
Redaktionelle Methode
Dieser Ratgeber basiert auf einem Factlog mit offiziellen Quellen zu Codex, GitHub Copilot, Claude Code, OWASP, MCP und NIST sowie lokalen KPR-Workflow-Artefakten. Es werden keine Preise, Ersparnis-Prozente oder Tool-Rankings behauptet.