Vibe-Codierungshype endet, weil es riesige Einschränkungen für das gibt, was große Sprachmodelle erreichen können. Trotz dieser Codierungsagenten werden ziemlich gut. Sie können neue Frontend-Seiten aufstellen, APIs wire up, und sogar CI/CD-Konfigurationen erstellen. Aber jeder weiß, wie inkonsistent sie sind. Der gleiche Anruf kann einmal funktionieren und die nächste brechen. Sie vergessen Teile Ihrer Codebasis, mischen erschöpfte SDKs oder erstellen einfach Dinge. Das Problem ist nicht, dass das Modell schlecht ist - es ist, dass es nicht Hier ist der Beweis - Jemand schrieb eine Programmiersprache rein mithilfe des Codierungsagenten. Kennen Sie Ihren Kontext https://cursed-lang.org/ Um eine zuverlässige Ausgabe zu erhalten, können Sie nicht nur besser anrufen. Der Agent arbeitet – formen Sie seine Inputs, geben Sie ihm Struktur und setzen Sie die richtigen Grenzen. . engineer the environment context engineering LLMs denken nicht wie Ingenieure LLMs "verstanden" den Code nicht so, wie wir es tun. Sie prognostizieren Token basierend auf Mustern in der vorherigen Eingabe, nicht auf App-Builds oder Strukturen.So können selbst kleine Änderungen in den Anweisungen oder umgebenden Dateien die Ausgabe ändern. Ohne Struktur sind sie wie Praktikanten, die Ihren Stapel aus dem Gedächtnis erraten. Du kannst das nicht beheben, indem du auf das Modell schreist. (Ich kann sagen, ich habe es versucht) Du behebst es, indem du es richtig machst. - die Einschränkungen und Umgebungen, die ihn jedes Mal zu einem gültigen Code führen. scaffolding Einschränkungen machen Code vorhersehbar Wenn Sie möchten, dass sich der Agent konsequent verhält, Sie schrumpfen den Raum für mögliche Ausgänge und zwingen das Modell, mit Ihrem Setup ausgerichtet zu bleiben. constraints are your friend Einige nützliche Einschränkungen: Typen – Wenn Sie TypeScript- oder JSON-Schemata verwenden, kann der Agent genau sehen, welche Formen folgen müssen. Lint + Formatregeln - Prettier, ESLint oder Codegen Regeln machen die Ausgabe konsistent, ohne zusätzliche Anregungen. Kleinere Aufgaben – Anstelle von „Build me a backend“, fragen Sie „Add this route to src/api/user.ts.“ Lokaler Bereich = weniger Überraschungen. Konfigurationen und Vorlagen – Tools wie Typeconf und Varlock können Umgebungsvariablen, SDKs oder Konfigurationsmuster vordefinieren, die der Agent befolgen muss. Der Trick besteht darin, sicherzustellen, dass Sie immer Code mit starken Typen schreiben. Sie verlieren keine Flexibilität - Sie fangen nur Fehler früher und machen das Verhalten wiederholbar. 3. Bauen Sie Systeme als Grundwahrheit auf Selbst wenn der Code gut aussieht, bricht er oft bei der Build-Zeit, weil der Agent falsch erraten hat, wie Dinge gekabelt sind. Zum Beispiel: Sie bitten es, Tests auszuführen, es schreibt npm-Test - aber Ihr Repo verwendet pnpm oder nx. Es versucht, eine Dockerfile zu erstellen, die nicht einmal Ihre tatsächliche Umgebung existiert. Es importiert ein Paket, das nicht einmal installiert ist. Die Fixierung ist die Geben Sie dem Agent ein klares Bild davon, wie Code erstellt, getestet und eingesetzt wird. Denken Sie daran als zusätzliches Agent-Tool für die Umgebung Ihres Projekts. abstract the build system Sobald der Agent weiß, was „bauen“ in Ihrer Welt bedeutet, kann er dieses Wissen anstelle von Vermutungen verwenden. Bazel, Buck, Nx oder sogar ein gut strukturierter package.json sind bereits gute Grundlagen. Je mehr Sie diese Informationen überblicken, desto weniger Halluzinationen werden Sie haben. Wenn Sie weiter gehen möchten, können Sie Ihre eigenen Tool-Haken schreiben, um zu verhindern, dass der Agent das falsche Build-System anruft, schauen Sie sich den Claude Code-Anleitung an: . https://docs.claude.com/en/docs/claude-code/hooks-guide 4. Das Problem mit veraltetem Training Die meisten codierenden Agenten sind auf Daten ausgebildet, die ein oder zwei Jahre alt sind. sie werden gerne APIs verwenden, die nicht mehr existieren, oder Codemuster, die jeder vor Jahrhunderten aufgegeben hat. Sie haben wahrscheinlich Sachen gesehen wie: Alte Lebenszyklusmethoden React Nicht vorhandene Bibliotheksfunktionen Entfernung von Next.js APIs NPM-Befehle für Bibliotheken, die zu neuen Versionen verschoben wurden Sie müssen Ihren eigenen Kontext mitbringen – echte Dokumente, echte Code, echte Konfigurationen. Einige Möglichkeiten, die Lücke zu schließen: Feeds in der Bibliothek doc, zum Beispiel über MCPs wie Context7. Lassen Sie den Agent die tatsächlichen Code-Dateien und Abhängigkeiten lesen - weisen Sie ihn auf node_modules zu lesen, Sie würden überrascht sein, wie oft es helfen würde, die API zu reparieren. Fügen Sie benutzerdefinierte Anweisungen zu AGENTS.md hinzu, die dem Modell mitteilen, um das wiederholende problematische Muster zu vermeiden, das es zu verwenden versucht. Wenn das Modell weiß, was wirklich da ist, hört es auf zu halluzinieren. 5. Lagen des Kontextes Ein guter Coding-Agent liest nicht nur Ihren Anruf - er liest die ganze Situation. Sie können den Kontext in drei Schichten betrachten: Static context Projektstruktur, Dateilayout, Typen, Konfigurationen, Build-Befehle und Abhängigkeiten. Dynamic context Die aktuelle Aufgabe, geöffnete Datei, Fehlermeldungen, Testergebnisse, Laufzeitprotokolle. External context Dokumente, SDK-Referenzen, ChangeLogs oder Snippets aus dem Web, wenn nötig. Kombinieren Sie alle drei, und der Agent beginnt, wie jemand zu handeln, der tatsächlich an Ihrer Codebasis angeschlossen ist - kein zufälliger Freelancer, der aus dem Gedächtnis vermutet. 6. Beispiele aus der realen Welt Als ich begann, die WorkOS AuthKit-Integration zu automatisieren, hier ist die nicht erschöpfende Liste der Probleme, die das Modell für mich generiert hat: Begonnen mit der Verwendung der deprecated withAuth und getUser APIs; Gemischte Frontend- und Backend-Logik (wie die Verwendung von UseState auf Server-Seite-Komponenten) Generierte falsche Umweltvariablen; das falsche Paket installiert haben; Es ist selbstverständlich, dass das Modell auch durch alle Paketmanager, manchmal npm, manchmal pnpm, was für das Modell zu einer Zeit am interessantesten war. Nachdem ich Einschränkungen hinzugefügt habe, direkt angegeben, was der Agent verwenden sollte, mit der neuesten API geliefert, begann das Modell, den Integrationskode zu generieren . consistently Der Unterschied liegt nicht im Modell - es liegt in dem, was es sieht. 7. Kontext ist die neue Schnittstelle Die meisten Menschen denken immer noch an Codierungsagenten wie Chatbots: Geben Sie einen Anruf, erhalten Sie eine Antwort. Die wahre Magie geschieht im Kontext - die Dateien, Typen, Befehle und Feedback-Loops, auf die der Agent zugreifen kann. In der Zukunft werden wir nicht nur mit codierenden Agenten "sprechen" - wir werden sie in unsere Build-Systeme drücken. sie werden unser repos verstehen, unsere Tools kennen und die gleichen Regeln wie jeder andere Teil des Stacks befolgen. Schlussfolgerung Coding-Agenten scheitern nicht, weil sie dumm sind, sondern weil sie blind arbeiten. Wenn Sie möchten, dass sie zuverlässige Teamkollegen sind, geben Sie ihnen Struktur: Einschränkungen, die definieren, wie sie kodiert werden sollten; Erstellen Sie Abstraktionen, die zeigen, wie Ihr Projekt tatsächlich läuft; Aktueller Kontext, damit sie aufhören, alte Muster zu verwenden; Je besser der Kontext, desto besser der Code. Du wirst nicht nur einen neuen Ingenieur in deinen Repo werfen und sagen: „Figure it out.“ Du bist an Bord von ihnen.
