So reduzieren Sie Overengineering durch KI-Codeassistenten
ИИ-ассистенты для кодапромпт-инжинирингуправление контекстом
Eine kurze Rolle, sauberer Kontext und rechtzeitige Resets
Ich würde Overengineering nicht mit einem weiteren riesigen Prompt bekämpfen, sondern mit drei einfachen Begrenzungen: einer engen Rolle, wenig aktivem Kontext und einem Reset für eine aus dem Ruder gelaufene Sitzung. Die Primärquelle ist hier weder eine Unternehmensankündigung noch eine Modellkarte, sondern ein bereitgestellter Austausch unter Entwicklern. Er ist nicht datiert, daher handelt es sich um eine praktische Auswertung von Beobachtungen und nicht um eine aktuelle Release-Meldung.
Die erste Methode klingt beinahe zu einfach: Geben Sie dem Assistenten die Rolle eines strikten Minimalisten. In der Diskussion wurde eine Formulierung verwendet, die das Ziel ausdrücklich auf die kleinstmögliche Zahl geänderter Dateien und Zeilen begrenzte. Das ist hilfreicher als die vage Bitte, es nicht zu kompliziert zu machen: Das Modell erhält ein überprüfbares Kriterium, anhand dessen sich der vorgeschlagene Patch bewerten lässt. Eine Aufgabe, die einfachste korrekte Lösung und keine begleitenden Umbauten ohne ausdrückliche Anforderung.
Die zweite Methode betrifft lange Sitzungen. Ein Teilnehmer merkt an, dass merkwürdiges Verhalten meist beginnt, sobald sich viel Kontext angesammelt hat, selbst wenn Regeln im Prompt und in AGENTS.md stehen. Sein Vorgehen: Eine Sitzung mit einer kleinen typischen Aufgabe starten, prüfen, ob der richtige Stil gewählt wurde, und den erfolgreichen Zustand anschließend für ähnliche Folgeaufgaben und Forks nutzen.
Die dritte Methode ist strenger, aber klarer: Bei ungeeigneten Änderungen verwerfen Sie die Anpassungen und beginnen die Aufgabe neu. In die neue Sitzung kommen nur die Rolle, die Aufgabe selbst und die wichtigsten Regeln. Die Bitte an das Modell, Vergangenes zu vergessen, kann Teil eines solchen Neustarts sein. Technisch zuverlässiger ist es jedoch, den alten Verlauf nicht mitzunehmen. Sonst bleibt das Rauschen Rauschen, nur mit einer neuen Anweisung darübergelegt.
Was das für die tägliche Codearbeit verändert
Die wichtigste Erkenntnis lautet: Zuverlässigkeit hängt nicht nur vom gewählten Modell ab, sondern auch vom Lebenszyklus der Sitzung. Ein kurzer Prompt setzt Grenzen, ein kleiner Kontext verringert zufällige Annahmen, und ein Reset verhindert, dass sich eine falsche Richtung in späteren Antworten festsetzt.
Besonders deutlich wird das beim Aufräumen von Code. Das Ziel ist meist lokal, weshalb ein unerwarteter Architekturumbau das Review teurer macht und die ursprüngliche Aufgabe verdeckt. Ich würde zuerst die Größe des Diffs, die Zahl der betroffenen Dateien und Änderungen prüfen, die gar nicht angefordert wurden. Werden die Grenzen erneut überschritten, ist ein sauberer Neustart oft sinnvoller als das Gespräch fortzusetzen.
Die Rolle des Minimalisten ist allerdings keine Garantie: In derselben Diskussion beschwert sich jemand, dass der Assistent sowohl den Prompt als auch AGENTS.md ignoriert. Der Prompt bleibt also eine weiche Begrenzung; Revert, Fork und eine neue Sitzung werden zu Bestandteilen der Qualitätssicherung. Zuverlässigkeit beginnt nicht mit der perfekten Formulierung, sondern mit der Bereitschaft, beschädigten Kontext zu verwerfen.