Skip to main content
Entwickler Themen
Toggle Dark/Light/Auto mode Toggle Dark/Light/Auto mode Toggle Dark/Light/Auto mode Back to homepage

0.4. KI-Nutzung – vom Anfänger zum Profi

Kurzfassung

Unter Was sind LLMs steht die Arbeitsweise. Unter Probleme bei der Nutzung stehen die Grenzen. Dieses Kapitel ist das Handwerk dazwischen: Wie steige ich vom ersten Chat zum verantwortlichen Einsatz mit Plan, Regeln und Agenten auf?

Die Reihenfolge ist absichtlich. Zuerst eine klare Anfrage. Dann prüfen und iterieren. Dann eine Spec statt eines Wunsches. Dann gezielter Kontext. Dann Plan vor Code. Dann Tests und kleine Diffs als Harness. Dann persistente Regeln für das, was sich wiederholt. Erst danach Skills und Agenten — mit Grenzen für Werkzeuge und Seiteneffekte.

Nichts davon macht Halluzinationen oder Injection weg. Es verringert die Trefferquote falscher Richtung. Produktnamen (Plan Mode, Rules, Skills) sind Beispiele. Das Lehrbare ist das Prinzip dahinter.

Ich fange mit einer klaren Anfrage an

Eine brauchbare Anfrage enthält mindestens drei Dinge: was herauskommen soll, in welchem Format, und welcher Kontext nötig ist — Sprache, Datei, Fehlertext, Beispiel. OpenAI, Anthropic und GitHub Copilot formulieren dasselbe: Klarheit und Beispiele statt Magie. Few-shot — also ein oder zwei Demonstrationen im Prompt — steuert Format und Muster, ohne dass ich ein Modell nachtrainiere. Brown und Kollegen haben das für GPT-3 gezeigt: Die Aufgabe steht im Text, die Gewichte bleiben stehen.

Was ich am Anfang nicht brauche: Agentenschwärme, Fine-Tuning, Prompt-Framework-Sammlungen aus Blogs, Jailbreak-Übungen. Spezifikation, Plan und Agenten multiplizieren eine schlechte Anfrage — sie reparieren sie nicht.

Rollen-Theater („Du bist ein Senior …“) kann Ton und Fokus setzen. Es ersetzt keine Aufgabe. Anthropic und OpenAI nutzen Rollen als Ergänzung, nicht als Spec.

Ich prüfe jedes Ergebnis

Ein Prompt ist ein Versuch, kein Abschluss. Copilot sagt ausdrücklich: experimentieren und iterieren; Code reviewen und testen; Werkzeug, kein Ersatz. Codex schreibt: menschliche Aufsicht sei nötig. Anthropic empfiehlt für Claude Code einen Verification Loop — Tests, Build, Screenshot als Pass/Fail: Dem Modell einen Weg geben, seine Arbeit zu prüfen.

Ohne Orakel trainiere ich nur Over-Reliance. „Sieht plausibel aus“ ist kein Orakel. Dokumentation, Compiler, Registry und Tests sind es. Die erste Antwort merge ich nicht. Endlose Threads ohne bereinigte History machen den Kontext schlechter, nicht klüger — Copilot rät zu neuen Threads für neue Aufgaben.

Übergang: Ich lehne Antworten ab, iteriere gezielt, und habe mindestens ein externes Orakel — nicht nur den Chat-Ton. Was ich nicht erklären kann, merge ich nicht. Das gilt auf jeder späteren Stufe weiter.

Ich schreibe eine Spec, keinen Wunsch

„Mach mir Auth“ ist ein Wunsch. Eine Spec nennt Ziel, Randbedingungen, Akzeptanzkriterien und Format. GitHub beschreibt ideale Agent-Aufgaben so: klare Problembeschreibung, vollständige Acceptance Criteria, Hinweise welche Dateien — und eine Stopping Condition, wann „fertig“ ist. Anthropic empfiehlt bei größeren Features erst Spec (ggf. im Dialog erarbeiten), dann frische Session zur Umsetzung.

Wann Reasoning-Modelle? OpenAI trennt grob: schnelle Modelle für klare Ausführung, Reasoning-Modelle für Planung und Ambiguity. Bei Reasoning-Modellen brauche ich oft kein „denk Schritt für Schritt“ — das kann sogar stören. Einfache, direkte Prompts zuerst. Anthropic warnt vor Overthinking: längeres Nachdenken kostet Tokens und Latenz. Eine Variable umbenennen braucht kein Reasoning-Modell.

Übergang: Ich kann „done“ in prüfbaren Kriterien formulieren und wähle bewusst schnell vs. Reasoning.

Ich liefere Kontext gezielt

Mehr Kontext ist nicht automatisch besser. Das Kontextfenster ist Working Memory dieser Anfrage, nicht das Trainingskorpus — siehe Probleme bei der Nutzung. Liu und Kollegen zeigen: Leistung oft an Anfang und Ende, schlechter in der Mitte. Anthropic nennt dasselbe als Context Rot: zu viel Kontext kann schaden; kuratieren.

Deshalb hänge ich relevante Ausschnitte an, nicht das ganze Repository. Offene, irrelevante Dateien und aufgeblähte Tool-Kataloge füllen dasselbe Fenster. Cursor empfiehlt @-Mentions, wenn die Dateien bekannt sind; sonst das Modell suchen lassen. Wichtiges gehört an den Rand oder kommt mehrfach — nicht in die Mitte eines 200-Dateien-Dumps.

Übergang: Ich wähle bewusst wenige Dateien oder Ausschnitte und weiß, wann ein neuer Thread nötig ist.

Ich plane vor dem Code

Bei unklarem Scope, vielen Dateien oder Architekturentscheidungen gilt: Explore → Plan → Implement → Verify, nicht sofort Code. In Cursor heißt das Plan Mode: recherchieren, Klärfragen, reviewbarer Plan, dann bauen — bei Fehlschlag den Plan schärfen statt endlos zu patchen. Anthropic beschreibt für Claude Code denselben Workflow und einen Plan-Permission-Modus. OpenAI nutzt Reasoning-Modelle oft als Planner und schnellere Modelle als Workhorse für die Ausführung.

Das löst keine Halluzinationen. Es verringert falsche Richtung und Scope-Creep. Der Generator bleibt ein Sprachmodell. Den Plan gebe ich nicht ungeprüft frei. Für Tippfehler und Einzeiler spare ich den Overhead — Cursor und Anthropic sagen dasselbe.

Übergang: Bei Multi-File und unklarem Scope lese und editiere ich den Plan zuerst. Kleine Tasks mache ich bewusst ohne Plan.

Tests und kleine Diffs sind der Harness

Der DORA-Report 2025 (extern) beschreibt KI als Amplifier: Sie verstärkt vorhandene Stärken und Schwächen. Tempo kann steigen; Stabilität kommt nicht gratis. Kleine Batches, Version Control und eine Plattform mit Tests bleiben der Hebel.

Deshalb gehen KI-Diffs durch dieselbe Pipeline wie Menschen-Diffs: Tests, Review, kleine Änderungen. Claude Code und Copilot setzen Verification voraus. Persistente Regeln und Agenten ohne diesen Harness skalieren Fehler nur schneller.

Übergang: Ich merge nur, was grün ist und was ich erklären kann.

Was sich wiederholt, schreibe ich fest

Modelle behalten in den Gewichten kein zuverlässiges Projektgedächtnis zwischen Sessions. Was immer wieder falsch läuft — Coding-Stil, Testbefehl, „niemals Secret in Logs“ — gehört in persistente Anweisungen, nicht in jeden Chat.

Die Produktnamen unterscheiden sich; das Prinzip ist gleich:

  • Cursor: Rules und oft AGENTS.md
  • Claude Code / Projects: CLAUDE.md und Project Instructions
  • GitHub Copilot: .github/copilot-instructions.md

Labs und Docs sind einig: kurz, konkret, grounded — erst wenn derselbe Fehler sich wiederholt. Romane in Always-Apply-Rules füllen den Kontext und werden ignoriert. Domain-Workflows gehören eher in Skills (nächste Stufe), nicht alles in die Dauer-Anweisung. Secrets und Persönliches gehören nicht in geteilte Projektregeln.

Übergang: Wiederholte Korrekturen landen in einer kurzen Rule; der Chat wird kürzer, nicht länger.

Wiederkehrende Abläufe werden Skills

Rules gelten oft immer oder pfadbasiert. Skills sind situativ: ein Workflow-Paket on-demand — Review-Checkliste, Release-Schritte, Issue-Fix-Muster — das nicht dauernd im Kontext liegt. Cursor und Claude Code haben dafür Produktbegriffe (SKILL.md, .claude/skills/); dasselbe Prinzip geht als Template im Repo ohne Produkt.

Ich muss nicht jeden Skill selbst schreiben. Es gibt fertige Skillsets — Pakete für wiederkehrende Abläufe, die jemand anderes gebaut hat. Ein bekanntes Beispiel sind die Matt Pocock Skills. Sie sind besonders geeignet, wenn ich mit einem Coding-Agenten Software entwickle: Idee erst schärfen, bei größerer Arbeit Spec und Tickets schneiden, dann umsetzen; eigene Einstiege für Bugs, Recherche und Architektur. Das ist kein Prozess, der die Steuerung übernimmt. Es sind kleine, kombinierbare Workflows gegen typische Agent-Fehler.

Nicht jeden Prompt zum Skill machen. Skills mit Seiteneffekten (Deploy, Mail, Produktion) nur bewusst und oft manuell auslösen. Skills vor beherrschter Spec und Iteration bringen wenig — auch fertige Sets.

Übergang: Mindestens ein wiederkehrender Ablauf ist dokumentiert und spart wiederholte Chat-Erklärungen.

Agenten erst mit Werkzeug-Grenzen

Ein Agent ist kein zweites Gehirn. Es ist oft dasselbe Modell in einer Schleife mit Werkzeugen: Gedanke, Aktion, Beobachtung — ReAct. Function Calling macht die Grenze klar: Das Modell erzeugt strukturierte Aufrufe; die Anwendung führt aus. Die Vertrauensgrenze liegt in meinem Code.

MCP ist die Steckerleiste dazu: Daten und Tools anbinden — Infrastruktur, kein Multi-Agent-Algorithmus. OWASP warnt vor Excessive Agency: zu viele Tools, zu weite Rechte, zu viel Autonomie. Anthropic rät bei Computer Use zu Aufgaben mit geringem Risiko und zu Bestätigung vor echten Seiteneffekten. Prompt Injection über Tools und fremde Inhalte gehört zu Problemen bei der Nutzung.

Wann Agenten helfen: klare Ziele, etablierte Patterns, Tests als Gate, begrenzte Tools, Approval für High-Impact, kleine Batches. Wann sie schaden: unklare Spec, keine Tests, offene Shell mit Admin-Rechten, unbeaufsichtigte Multi-File-Refactors, jeder MCP-Server „an“.

Multi-Agent-Frameworks sind keine Pflichtstufe. Cursor selbst: Agenten bei klaren Zielen und mit Oversight; sie sind teurer. Profi heißt auch: begründen können, warum kein Agent nötig ist.

Was auf jeder Stufe mitläuft

Kanal: Consumer-Chat, API/Enterprise und lokal sind verschiedene Verarbeitungen — ausführlich unter Problemen bei der Nutzung. Agenten vergrößern die Fläche (Tools, MCP, Logs), ändern die Grundregel aber nicht: keine Secrets und keine Kundendaten in Prompts, die das nicht tragen dürfen.

Kosten: Große Kontexte und Agent-Schleifen verbrauchen deutlich mehr als eine kurze Chat-Frage. Gezielter Kontext und Plan vor Blind-Loops sind auch Kostendisziplin.

Modellwahl: „Auto“ ist Einstieg. Profi wählt nach Aufgabe — schnell für Klarsichtiges, Reasoning für Ambiguity, Agent-fähig nur wenn Tools nötig sind. Namen und Defaults ändern sich; das Prinzip bleibt.

Kompetenz: Diff erklären können ist kein Abschlusszertifikat. Es ist Dauerzustand.

Was man davon mitnehmen sollte

Vom Anfänger zum Profi heißt nicht „mehr Automatisierung“. Es heißt mehr Steuerung und mehr Prüfung:

  1. Klare Anfrage vor Framework-Zoo.
  2. Prüfen und iterieren vor dem Merge.
  3. Spec und gezielter Kontext vor dem Agenten.
  4. Plan vor großem Code; Tests und kleine Diffs als Harness.
  5. Wiederholtes festschreiben (Rules), situatives auslagern (Skills).
  6. Agenten mit Least Privilege und Human Approval — oder bewusst weglassen.

Genau deshalb bleiben Clean Code, Architektur und Tests auf dieser Seite zentral. Sie sind Handwerk für Menschen — und die Leitplanken, an denen die KI gemessen wird.

Quellen und Vertiefung

Die Aussagen oben stützen sich auf First-Party-Dokumentation der Labore und Werkzeuge sowie auf wenige Originalarbeiten. Produkt-UIs und Modellnamen veralten; die Progression trägt das Konzept.

Note
Wer nur wenige Quellen lesen will: OpenAI Prompting und Reasoning, Anthropic Claude-Code-Best-Practices (Verify, Plan, CLAUDE.md, Skills), Cursor Plan Mode / Rules / Skills — ergänzt um Copilot Prompting und DORA 2025.

Einstieg: Anfrage, Iteration, Spec

Prüfen, Kontext, Plan, Harness

Persistente Steuerung, Skills, Agenten