Können Coding-Agenten große Codebasen wirklich produktiv bearbeiten? Wer mit KI-gestützter Entwicklung arbeitet, kennt die Reibungsverluste: Der Agent schreibt plausiblen Code, referenziert eine längst stillgelegte API, dupliziert einen Service, der schon existiert, oder scheitert an einer Contract-Prüfung in CI. Die Modelle werden leistungsfähiger, das Problem bleibt. Es liegt nicht an der Intelligenz, sondern am Kontext — so lautet zumindest die These von Talia Kohan, die sie im Blog des API-Plattform-Anbieters Postman ausführt. Der Beitrag ist damit keine neutrale Berichterstattung, sondern ein Herstellerargument, das am Ende auf Postmans eigene Produkte zuläuft. Lesenswert ist er trotzdem, denn die Diagnose deckt sich mit dem, was viele Teams gerade erleben.
Ein stiller Trend quer durch die Branche
Kohan beobachtet ein Muster quer durch Plattform-Teams in Unternehmen, die sonst nichts gemeinsam haben: Überall entstehen Datenstrukturen mit demselben Grundaufbau — typisierte Entitäten, die beschreiben, was in der Organisation existiert, und typisierte Beziehungen, die zeigen, wie diese Entitäten zusammenhängen. Mal heißt das Service-Katalog, mal API-Registry, mal Ownership-Map, mal Dependency-Graph, mal interne Developer-Plattform. Die Labels unterscheiden sich, die Form darunter ist gleich.
Diese Konvergenz kommt aus ihrer Sicht nicht von ungefähr. KI-Coding-Agenten haben die Wirtschaftlichkeit verändert. Ein Agent, der in einem Wochenend-Projekt arbeitet, verhält sich anders als einer, der in eine gewachsene Codebasis eingeworfen wird. Der Unterschied liegt nicht im Modell, sondern darin, wie viel Kontext aus dem Team den Agent erreicht. Bei einem Startup mit einem Dutzend Services ist die Lage schon unübersichtlich, bei einem Unternehmen mit fünfhundert Services ist sie eskaliert. Die nützlichen Informationen liegen verstreut in anderen Repositories, bei anderen Teamkollegen, in alten Service-Verträgen, in internen APIs ohne Katalog, in seit Monaten nicht aktualisierten Policy-Dokumenten und in Slack-Threads, die die halbe Frage beantworten.
Ein Agent ohne Graph rät. Kohan schildert, was sie beim Zusehen immer wieder erlebt hat, wenn ein Agent einen Ticket-Fix in einer unbekannten Codebasis bekommt: Er liest die Datei, sucht mit grep nach Funktionsnamen, rät die Form eines Response-Body. Am Ende steht eine Änderung, die einen Endpoint referenziert, der im letzten Quartal stillgelegt wurde, oder die einen Service dupliziert, den jemand anderes schon gebaut hat. Der Agent ist nicht inkompetent. Ihm fehlt der Kontextgraph, den die Menschen im Team über Monate in ihren Köpfen aufgebaut haben.
Warum weder größere Modelle noch größere Kontextfenster reichen
Die erste Reaktion der meisten Teams war: mehr Kontext, also ein größeres Kontextfenster. Das hilft an den Rändern, beseitigt aber das Kernproblem nicht. Die Forschungslage ist inzwischen klar. Chromas Context-Rot-Studie aus dem Jahr 2025 hat 18 Frontier-Modelle getestet und bei allen bereits weit vor dem Fensterende nachlassende Qualität festgestellt. Die ältere Stanford-Arbeit „Lost in the Middle“ zeigte Genauigkeitsverluste von dreißig Prozent und mehr, wenn Informationen in der Mitte langer Prompts platziert wurden. Ein längerer Prompt ist nicht dasselbe wie bessere Informationsbeschaffung. Wer den Agenten mit dem gesamten Monorepo füttert, bekommt mehr Text, aber nicht mehr Verständnis.
Der Fehlermodus, den Kohan in der Praxis immer wieder sieht, ist auch kein Reasoning-Versagen, sondern ein Retrieval- und Grounding-Versagen. Der Agent weiß nicht, dass es einen Payments-Endpoint schon gibt, und erfindet einen neuen. Er weiß nicht, dass ein Team eine Bibliothek migriert hat, und schreibt Code gegen die alte API. Er weiß nicht, dass eine vorgeschlagene Änderung einen Endpoint berührt, der in einem Incident vor drei Monaten auftauchte. VentureBeats Berichterstattung über produktive KI-Coding-Agenten brachte es auf den Punkt: Agenten verlieren Kontext über große Codebasen, produzieren instabile Refactorings und haben keine operative Wahrnehmung. Operative Wahrnehmung ist das Graph-Problem. Es lässt sich nicht durch mehr Tokens lösen.
Die zweite Antwort, die laut Kohan tatsächlich funktioniert: den Graph extern aufbauen und vom Agenten abfragen lassen. Ownership, Service-Verträge, Deprecation-Status, Governance-Regeln, Incident-Historie. Nicht in den Prompt gestopft, sondern in einem abfragbaren System, an das der Agent herankommt. Genau das ist die gemeinsame Form all der katalogartigen Projekte, die im letzten Jahr konvergiert sind: Code-Graphen, API-Graphen, Ownership-Graphen, Governance-Graphen. Kein Dokumentenspeicher, sondern ein Graph.
Zwei Forschungsrichtungen lohnen die Lektüre für alle, die das Argument in der Tiefe verstehen wollen. Microsofts GraphRAG-Projekt zeigt, dass Graph-Traversal genau die Form von Reasoning über Entitäten hinweg unterstützt, die Vektor-Suche verpasst. CodexGraph, vorgestellt auf der NAACL 2025, belegt, dass ein LLM, der eine Graph-Datenbank des Repositories abfragen kann, bei Navigation und Codegenerierung bessere Ergebnisse liefert als reine Retrieval-Verfahren. Keiner der beiden Ansätze ist eine Universalwaffe. In Kombination zeigen sie in dieselbe Richtung: das Modell ist der falsche Ort, um fehlendes Wissen unterzubringen.
Was ein Kontextgraph konkret ist
Im Kern ist ein Kontextgraph eine Menge typisierter Entitäten und typisierter Beziehungen zwischen ihnen. Wer die RDF-1.2-Konzepte-Spec des W3C gelesen hat, kennt die Idee: Subjekt, Prädikat, Objekt. Jeder Fakt ist eine dreiteilige Aussage. Service X „exposes“ Endpoint Y. Endpoint Y „is owned by“ Team Z. Team Z „uses“ Auth Scheme A.
Für eine reale Codebasis umfassen die relevanten Entitäten Repositories, Pakete, Module und Funktionen, weiter Services, Endpoints und ihre OpenAPI-Spezifikationen, Teams und Code-Ownership, Umgebungen, Deployments, Laufzeitabhängigkeiten und Feature-Flags, Governance-Regeln, Deprecation-Markierungen und Approval-Status sowie frühere Incidents und Postmortems. Eine Entität in diesem Graph liegt als strukturierter Datensatz vor, mit Identifikator, Typ, Namen, Beschreibung, Tags, Status und einer Liste expliziter Beziehungen zu anderen Entitäten.
Mit einem solchen Datensatz beantwortet ein Agent Fragen, die grep nicht lösen kann: Gibt es bereits einen Endpoint, der das tut? Wer muss eine Änderung freigeben? Was bricht wahrscheinlich, wenn sich die Response-Form ändert? Welches Team sollte den Pull-Request bekommen? Das sind die Fragen, die eine Änderung, die es in Produktion schafft, von einer unterscheiden, die mit einem Kommentar zurückkommt, der mit „Eigentlich …“ beginnt.
Die API-Schicht ist ein Graph, den du schon hast
Wer beruflich mit APIs arbeitet, hat laut Kohan eine gute Nachricht: Teile dieses Graphen existieren bereits, nur unter anderem Namen. Eine OpenAPI-Spezifikation ist eine Menge typisierter Entitäten, nämlich Paths, Operations und Schemas, mit typisierten Beziehungen wie Referenzen, Security-Schemes und Tags. Ein Postman-Workspace mit Collections, Environments und Monitoren liefert Laufzeit-Fakten darüber, wie diese APIs sich verhalten. Wer Ownership, Approval-Status und Governance-Policy ergänzt, hat etwas, das ein Agent befragen kann.
An dieser Stelle wird der Beitrag endgültig zur Produktvorstellung in eigener Sache: Postman behandelt das, so Kohan, als Infrastruktur erster Klasse. Das Private API Network ist der Ort, an dem eine Organisation die APIs veröffentlicht, die sie für Menschen und Agenten auffindbar machen will. Die Postman API Governance hängt Regeln an diese APIs, sodass ein Agent erkennen kann, ob eine Änderung gegen eine Policy verstößt, bevor ein Pull-Request geöffnet wird. Ownership, Tags, Ordner, Versionen und Deprecation-Status sind Teil des Modells. Die Postman API legt das offen, sodass ein Agent den Graph programmatisch durchlaufen kann.
Der Graph endet nicht bei den eigenen APIs. Jedes Team, das Software ausliefert, läuft auf einem Geflecht aus Drittanbieter-Services: Stripe für Zahlungen, Okta für Identity, Twilio für Messaging, Salesforce für CRM-Daten, dazu eine lange Liste schmalerer Anbieter, die irgendwo im kritischen Pfad landen. Diese Integrationen produzieren dieselben Fehlermodi wie interne. Ein Agent, der nicht weiß, dass die eigene App einen v2-Endpoint eines Anbieters nutzt und nicht den stillgelegten v1, generiert Code für die falsche Version, und die falsche Annahme fällt erst auf, wenn das Rate-Limit zuschlägt oder die Rechnung kommt.
Auch hierfür hält der Hersteller die passenden Bausteine bereit: Das öffentliche Postman API Network veröffentlicht zehntausende Anbieter-APIs mit echten Spezifikationen und funktionierenden Collections. Das eigene Private API Network kann genau die Anbieter-APIs pinnen, die das Unternehmen tatsächlich nutzt, samt Ownership-Metadaten für jede Integration und der Umgebung mit den Credentials. Postman Flows geht noch weiter: Connector-Blöcke repräsentieren externe Dienste als typisierte Knoten, die ein Agent in einen Flow einbinden kann, ohne die Form jedes SDK auswendig zu kennen. Ein einfaches Beispiel zeigt, welche Frage ein Agent stellen kann, bevor er eine Zeile Code schreibt: Welche APIs sind im aktuellen Workspace veröffentlicht? Das ist kein roher Code und keine Liste von Dateinamen, sondern die Menge der Verträge, die das Unternehmen bereits vereinbart hat. Wenn der nächste Schritt des Agenten lautet, einen neuen POST /charges Endpoint zu schreiben, sagt ihm die Antwort auf diesen Aufruf, ob es diesen bereits gibt.
Den Graph befragen, nicht nur den Code durchsuchen
Das Problem, wenn ein Agent ein Monorepo mit grep durchkämmt, ist, dass grep Treffer zurückliefert, keine Bedeutung. Was du willst, ist, dass der Agent über eine wohldefinierte Schnittstelle an einen Graph gelangt und strukturierte Entitäten erhält. Genau dafür ist das Model Context Protocol da. MCP ist das offene Protokoll, mit dem KI-Agenten Werkzeuge und Datenquellen so zugänglich gemacht werden, dass sie sie befragen können. Der Postman MCP Server veröffentlicht den Postman-Graph als MCP-Tools: APIs durchsuchen, Collections inspizieren, Environments nachschlagen, Governance-Regeln prüfen. Ein Agent in einer IDE ruft diese Werkzeuge direkt auf.
Kohan zeigt das an zwei kurzen Skripten. Ein Pre-Request-Skript liest die Workspace-ID aus dem Environment, bricht mit einer Fehlermeldung ab, wenn sie dort fehlt, und legt sie als Variable für spätere Tools ab. Das zugehörige Test-Skript prüft, ob die Antwort der API-Suche den Status 200 trägt, ein Feld apis enthält, dieses ein Array ist und jeder Eintrag darin einen stabilen Identifikator und einen Namen hat. Der Punkt ist nicht das spezifische Skript. Der Punkt ist, dass der Agent eine typisierte Antwort auf die Frage „Was existiert?“ bekommt, und nicht bloß einen String-Match.
Die breitere Branchenbewegung läuft in dieselbe Richtung. Google hat kürzlich die Agentic Resource Discovery Specification veröffentlicht, die das Muster „einen Graph maschinenlesbarer Fähigkeiten veröffentlichen, damit Agenten sie finden“ auf Internetskala anwendet. Die interne Variante für das eigene Team ist der Graph, den man ohnehin schon besitzt.
Stolperfallen — und was Postman als erste Schritte empfiehlt
Ein paar Dinge sind es laut Kohan wert, im Blick zu behalten, sobald man den Graphen als Infrastruktur behandelt. Der Graph veraltet schnell. Wenn niemand die Ownership aktualisiert, wenn ein Team sich reorganisiert, pagt der Agent die falschen Leute. Graph-Updates gehören in dieselben Review-Workflows, die bereits Code-Änderungen mergen, nicht in ein separates Quartals-Cleanup.
Governance ohne Zähne ist schlimmer als keine Governance. Wenn der Graph weiß, dass ein Endpoint deprecated ist, der Agent aber trotzdem dagegen ausliefert, dann hat entweder der Agent keinen Zugriff auf diese Tatsache oder der Enforcement-Pfad ist kaputt. Beides ist behebbar. Der zweite Fall ist der schmerzhaftere, weil er meistens bedeutet: CI reparieren.
Kardinalität wird zum Problem. Ein Team von acht Leuten mit zwanzig Services lässt sich leicht modellieren. Ein Unternehmen mit fünfhundert Services, vierzig Teams und einem Jahrzehnt Geschichte hat Entitäten, die wie Duplikate aussehen und keine sind, sowie Duplikate, die verschieden aussehen und keine sind. Eng starten, mit öffentlichen APIs, aktiven Services und aktuellen Ownern, und von dort aus wachsen. Und: Discovery ist nur die halbe Miete. Ein Agent, der den richtigen Endpoint finden, aber nicht testen kann, bleibt trotzdem stecken. Collections und Environments neben den Spezifikationen zu veröffentlichen, das macht aus einem Graphen von Verträgen etwas, wogegen ein Agent tatsächlich laufen kann.
Für den Einstieg ohne halbjähriges Plattformprojekt schlägt Kohan drei Schritte vor — wenig überraschend führen alle drei in Postmans eigenes Ökosystem. Erstens: die APIs, die das Unternehmen bereits betreibt, mit echten Ownership-Metadaten im Private API Network veröffentlichen. Selbst ein teilweiser Graph schlägt einen Slack-Thread. Zweitens: API-Governance-Regeln mindestens für Deprecation und erforderliche Authentifizierung einschalten. Agenten greifen Verstöße dann zum Review-Zeitpunkt ab, statt erst, wenn ein Kunde es merkt. Drittens: einen Agenten, sei es Claude Code, ein interner Copilot oder was auch immer im Einsatz ist, an den Postman MCP Server anschließen, damit er den Graph befragen kann statt zu raten.
Das Eigeninteresse des Herstellers ändert nichts daran, dass der Kern der These trägt: Der Engpass heutiger Coding-Agenten liegt weniger im Modell als im Zugang zu strukturiertem Organisationswissen — und die Forschung von Chroma über GraphRAG bis CodexGraph stützt diesen Befund unabhängig von Postman. Ob der Kontextgraph am Ende in Postman, in einem Backstage-Katalog oder in einer eigenen Graph-Datenbank liegt, ist zweitrangig. Entscheidend ist, dass die ersten Entitäten und Beziehungen überhaupt in ein abfragbares System kommen, damit der Agent nicht länger im Nebel stochert.
Quelle: blog.postman.com
