Ich habe ein System gebaut, das relevante Anforderungen aus früheren Interaktionen automatisch entdeckt, verifiziert und anwendet, ohne den Nutzer zu fragen, woher sie stammen.

Die zentrale Lektion: Nur die vergangene Historie hervorzuholen ist nicht dasselbe wie zu wissen, was tatsächlich noch korrekt ist. Ein einfaches Such-Setup erfasste nur 57% der Anforderungen, die ein Coding-Agent benötigte. Das Hinzufügen einer Verifikationsschicht brachte das auf 100%.

Von 8 Aufgaben bekam die Baseline null richtig hin, die einfache Suche 4, und die intent-bewusste Suche traf alle 8. Ich habe all das mit null Embeddings, null Vektordatenbanken und absolut keinen LLM-Aufrufen in der Pipeline gemacht.

Ich richtete einen Coding-Agenten-Workflow ein, der anfangs perfekt funktionierte. Aber sobald ein Projekt lang genug wurde, begann er Probleme zu verursachen. Wenn ein Projekt ein paar Dutzend Schritte überschritt, begannen Kernregeln zu verschwinden. Niemand hatte sie gelöscht. Das Kontextfenster war nicht voll. Diese Regeln befanden sich technisch gesehen noch in den Chat-Protokollen. Sie fielen einfach vom Radar, weil neue Anfragen den Agenten nicht dazu veranlassten zu prüfen, ob eine ältere Entscheidung noch von Bedeutung war.

Zum Beispiel könnten Sie dem Agenten am ersten Tag sagen, niemals interne Datenbank-IDs in API-Antworten preiszugeben. Sechzig Nachrichten später bitten Sie ihn, einen neuen Authentifizierungsablauf zu erstellen. Diese neue Anfrage sagt nichts über IDs. Da dem Agenten ein klarer Grund fehlt, zurückzublicken, überspringt er diesen Schritt und liefert einen Endpunkt aus, der genau die Daten preisgibt, die Sie zu schützen versuchten.

Dies ist kein erfundenes Szenario. Es ist der tatsächliche Testfall, den ich für diesen Artikel verwendet habe. Im Folgenden zeige ich Ihnen, wie drei verschiedene Methoden mit genau diesem Problem umgehen.