Gib Coding-Agenten den richtigen Kontext (nicht mehr davon)

·3 min read·Translated

Ein einzelner Satz, der nach einem Login-Endpoint fragt, reicht nicht. Der Agent muss noch dein Fehlerformat, die Ordnerstruktur, die Auth-Bibliothek, das Validierungsmuster und wissen, wie „done“ aussieht. Das kurze IBM-Technology-Video von Legare Kerrison Context-Aware Coding: Give AI Agents the Right Context (veröffentlicht am 2. November 2026) macht den Punkt konkret und praktisch für Teams, die bereits Coding-Agenten nutzen.

Das ist kein weiterer High-Level-Engpass-Essay. Es ist eine kurze Liste von Inputs, die den Output tatsächlich ändern.

Die Inputs, die zählen

  1. Dateien und Struktur. Starke Agenten können Dateien selbst suchen und öffnen. Deine Aufgabe ist, sie in die richtige Richtung zu weisen („folge dem Muster in der README“) und idealerweise eine kompakte Repo-Karte von Dateien und Symbolen zu geben, damit sie die Form sehen, ohne jede Zeile zu lesen.

  2. Exakte Dependency-Versionen. Zu wissen, dass du eine Bibliothek nutzt, reicht nicht. Die Lockfile speichert die aufgelösten Versionen (einschließlich transitiver) und damit, welche APIs tatsächlich existieren. Viele „halluzinierte“ Funktionen sind einfach Versions-Mismatches.

  3. Ein Test, den der Agent bestehen kann. Ein fehlschlagender Test verwandelt die Session in eine Write–Run–Fix-Schleife. Agentic Coding funktioniert besser, wenn der Agent weiß, wie gut aussieht.

  4. Konventionen und Constraints. Lege Build-Befehle, Coding-Standards und harte Regeln („fass dieses Verzeichnis nicht an“) in eine eingecheckte AGENTS.md (oder das Äquivalent, das dein Tool bereits liest). Das wird zu einer geteilten Team-Schnittstelle.

  5. Intent. Nur ein Mensch weiß, was done bedeutet, was die Constraints sind und was der Agent nicht tun darf. Der Agent kann das nicht herausfinden, indem er das Repo liest.

Drei Moves, bevor irgendein Code geschrieben wird

  • Bitte den Agenten, dich zu interviewen und so lange Fragen zu stellen, bis er die Aufgabe versteht.
  • Sag ihm, er soll das Repo erkunden und die Struktur in klarer Sprache zurück erklären. Jetzt teilt ihr beide eine Karte.
  • Lass ihn einen Plan schreiben und seine Annahmen listen. Review diese Annahmen vor der Implementierung. Wenn die Session endet, schreibe die nützlichen Entdeckungen zurück in die Instructions-Datei, damit die nächste Person (oder der nächste Agent) weiter vorne startet.

Schütte nicht das ganze Repo ab

Modelle schenken nicht allem in einem langen Kontext gleiche Aufmerksamkeit. Information am Anfang und Ende tendiert dazu, besser genutzt zu werden als Material, das in der Mitte begraben ist („lost in the middle“). Jede irrelevante Datei konkurriert mit einer relevanten. Für eine Login-Flow-Änderung braucht der Agent das Auth-Modul, seine Tests und die Konventionen — nicht den Billing-Service oder drei Wochen alte Build-Logs.

Praktische Konsequenzen:

  • Starte eine frische Session für jede neue Aufgabe.
  • Zeige auf spezifische Dateien und räume Lärm auf, wenn eine Session lang wird.
  • Bevorzuge einen Orchestrator, der fokussierte Sub-Tasks mit sauberem Kontext startet, gegenüber einer überladenen Konversation.

Das Ziel ist nicht mehr Kontext. Es ist der richtige Kontext, wobei ein Mensch immer noch die Entscheidungen trifft.

Die verwandte Diskussion auf Hacker News merkt weiter an, dass Agenten mehr Code generieren, als sie fertige, wartbare Software generieren; Review und Verifikation bleiben die knappen Schritte. Besserer Kontext entfernt diese Schritte nicht, aber er reduziert die Menge an Slop, die sie erreicht.

Quellen: das oben verlinkte IBM-Technology-Video. Dieselben Themen erscheinen in neueren Agentic-AI-Foundation- und AI-Engineer-Talks über Agent-Readiness und geteilte Interfaces, aber die kurze, konkrete Checkliste macht dieses Video an einem Montagmorgen nützlich.

Share