<\/p>\n
Der gr\u00f6\u00dfte Kostenhebel bei AI Engineering ist nicht das Modell, es ist die Disziplin<\/p>\n
<\/h1><\/div>
Seit Monaten dreht sich die Diskussion um AI-Coding-Tools fast ausschlie\u00dflich um eine Frage: Welches Modell ist das beste? Claude Opus oder Sonnet? GPT-5.4 oder GPT-5.3-Codex? Haiku f\u00fcr einfache Aufgaben? Das ist die falsche Frage.<\/p>\n\n\n\n
Das richtige Modell zu w\u00e4hlen ist ein Hebel. Aber es ist nicht der<\/em> Hebel. Wer agentische Sessions wie Chats f\u00fchrt, kann sich durch Modellwahl nicht aus dem Problem optimieren \u2013 egal wie g\u00fcnstig Haiku ist. Der eigentliche Kostenhebel ist Disziplin: wie man Aufgaben spezifiziert, wie man Context kontrolliert, und wie man Sessions f\u00fchrt.<\/p>\n\n\n\n Dieser Post erkl\u00e4rt, warum \u2013 und was man konkret tun kann.<\/p>\n\n\n\n Inhalt<\/p>\n\n\n\n <\/p>\n\n\n\n Der Markt kippt. Innerhalb weniger Monate hat fast jeder relevante Anbieter auf Token-basierte Abrechnung umgestellt oder k\u00fcndigt es an. GitHub Copilot wechselt zum 1. Juni 2026 von Request-basierter auf Token-basierte Abrechnung<\/a>. Claude Code ist bereits dort. OpenAI und Cursor \u2013 gleiches Bild.<\/p>\n\n\n\n Das ist kein Zufall. Es ist die logische Konsequenz der Adoption-Kurve: 84% der Entwickler nutzen AI-Tools<\/a>, 41% des Codes ist bereits AI-assistiert<\/a>, 90% der Fortune-100-Unternehmen zahlen f\u00fcr AI-Coding-Tools. Bei dieser Nutzung k\u00f6nnen Anbieter keine Flatrate-Subventionen mehr aufrechterhalten.<\/p>\n\n\n\n Was das praktisch hei\u00dft: GitHub schreibt in der Ank\u00fcndigung des neuen Abrechnungsmodells, es sei \u201ecommon for a handful of requests to incur costs that exceed the plan price”. Das ist kein Ausnahmefall f\u00fcr Heavy User \u2013 das ist die neue Normalit\u00e4t f\u00fcr jeden, der Agents ernsthaft einsetzt.<\/p>\n\n\n\n Die gute Nachricht: Aus unserer Projekterfahrung entstehen ein erheblicher Teil dieser Kosten durch vermeidbare Patterns. Nicht durch die Aufgabe, sondern durch die Art wie man arbeitet.<\/strong><\/p>\n\n\n\n Hier liegt der Kern des Problems \u2013 und er ist den meisten Entwicklern nicht intuitiv klar.<\/p>\n\n\n\n Das mentale Modell der meisten Entwickler ist von ChatGPT gepr\u00e4gt: ein offener Tab, stundenlang offen, Frage rein, Antwort raus, neue Frage. Lange Sessions sind harmlos. Kosten sind linear. Agentische Sessions funktionieren anders. Im Chat-Modell ist jede Antwort unabh\u00e4ngig. Eine Frage kostet einen festen Betrag, die n\u00e4chste genauso viel. Der Verbrauch ist linear und vorhersehbar.<\/p>\n\n\n\n Im Agent-Modell liest jeder Turn die gesamte bisherige History als Input neu. Der Agent erinnert sich nicht \u2013 er liest den gesamten Verlauf neu. Das hat konkrete Folgen:<\/p>\n\n\n\n Was dabei in den Context wandert, ohne dass man es aktiv entscheidet: der System-Prompt, AGENTS.md, alle MCP-Tool-Schemas, jeder gelesene File-Inhalt, jede Terminal-Ausgabe (npm test mit 200 Tests produziert tausende Zeilen), jeder Git-Diff, jeder Tool-Output. Allein f\u00fcnf angebundene MCP-Server k\u00f6nnen laut Anthropic bis zu 18.000 Token Overhead erzeugen \u2013 pro Turn, auch wenn kein einziges Tool aufgerufen wird.<\/p>\n\n\n\n Was das konkret kostet: Anthropic ver\u00f6ffentlicht in den Claude Code Cost Docs<\/a> reale Enterprise-Durchschnittswerte: Rund 13 Dollar pro Entwickler pro aktivem Tag, 150 bis 250 Dollar pro Monat. Ein GitHub Copilot Business Seat kostet 19 Dollar pro Monat \u2013 und enth\u00e4lt 19 Dollar in AI Credits. Bei 13 Dollar pro aktivem Tag reicht dieses Budget f\u00fcr anderthalb Arbeitstage. Den Rest des Monats zahlt man on top. Mit Disziplin \u2013 k\u00fcrzere Sessions, sauberere Specs, kontrollierterer Context \u2013 sinkt dieser Tageswert drastisch, und das Inklusiv-Budget reicht tats\u00e4chlich f\u00fcr einen Monat.<\/p>\n\n\n\n Der Unterschied ist nicht das Modell. Es ist, wie man arbeitet.<\/strong><\/p>\n\n\n\n Die drei Disziplinen sind keine unabh\u00e4ngigen Tipps \u2013 sie greifen ineinander. Spec-Driven Development reduziert, was \u00fcberhaupt in eine Session geht. Context Engineering reduziert, was pro Turn in den Context geladen wird. Session-Disziplin begrenzt, wie lange eine Session l\u00e4uft, bevor der Context exponentiell teuer wird. Zusammen adressieren sie alle drei Phasen desselben Problems.<\/p>\n\n\n\n Das Gegenteil von Spec-Driven Development hei\u00dft Vibe Coding: einen Agent auf ein vage definiertes Ziel loszuschicken \u2013 ohne Anforderungen, ohne Constraints, ohne klare Erfolgskriterien.<\/p>\n\n\n\n Vibe Coding funktioniert f\u00fcr Wegwerf-Prototypen. F\u00fcr Production-Code ist es teuer. Ohne pr\u00e4zise Spec exploriert der Agent: er scannt das Repository nach Orientierung, trifft eigene Annahmen \u00fcber Framework-Wahl, Datenmodell und Error-Handling, iteriert mehrfach in die falsche Richtung und erzeugt dabei deutlich mehr Token-Verbrauch als eine gezielte Implementation. Das Ergebnis l\u00e4uft vielleicht \u2013 aber es verletzt nicht ausgesprochene Anforderungen oder trifft Architekturentscheidungen, die nie abgesegnet wurden.<\/p>\n\n\n\n Spec-Driven Development verwandelt Spezifikationen von passiver Dokumentation in ausf\u00fchrbare Contracts. Eine gute Spec hat sechs Elemente:<\/p>\n\n\n\n Der eigentliche Token-Spareffekt kommt aus dem Workflow, der daraus folgt: Der Workflow trennt zwei Schritte, die die meisten Teams vermischen: Denken und Umsetzen.<\/p>\n\n\n\n Zuerst entsteht die Spec \u2013 und das mit einem leistungsstarken Modell. Der Aufwand lohnt sich: Ein starkes Modell produziert einen Plan mit echtem Tiefgang, der Abh\u00e4ngigkeiten erkennt, Scope-Fallen benennt und die Implementierungsschritte so klar formuliert, dass wenig Interpretationsspielraum bleibt. Das Ergebnis sind drei Dokumente: proposal.md<\/em> f\u00fcr Was, Warum und Scope, design.md<\/em> f\u00fcr das technische Design mit betroffenen Dateien und APIs sowie tasks.md<\/em> als sequenzierter Implementierungsplan mit pr\u00fcfbaren Akzeptanzkriterien. Dann folgt Human Review \u2013 ein Mensch pr\u00fcft den Plan und gibt ihn frei.<\/p>\n\n\n\n Erst danach beginnt die Implementierung. Und das mit einem g\u00fcnstigeren Modell in einem frischen Agent mit frischem Context. Der entscheidende Effekt: Ein pr\u00e4zise ausgearbeiteter Scope l\u00e4sst sich von einem leichteren Modell in hoher Qualit\u00e4t ausf\u00fchren. Der Agent muss nicht explorieren, nicht raten, nicht iterieren. Er arbeitet einen klaren Plan ab. Die gesamte Explorations-History der Planungsphase wird weggeworfen \u2013 was bleibt, sind die Ergebnisse. Damit startet die Implementierung mit einem Bruchteil der Input-Tokens, die ein direkt gestarteter Agent-Run ohne vorherige Spec verbraucht h\u00e4tte.<\/p>\n\n\n \u201eContext ist King” ist ein verbreiteter Ratschlag. Er ist halb richtig. Zu wenig Context und der Agent trifft falsche Annahmen. Zu viel Context erzeugt Rauschen, das die Reasoning-Qualit\u00e4t senkt und dabei jeden Turn teurer macht. Der pr\u00e4zise Satz lautet: Der richtige Context ist King.<\/p>\n\n\n\n Die zentrale Struktur ist eine Hierarchie:<\/p>\n\n\n\n Immer geladen \u2013 AGENTS.md<\/strong>: Einmalinvestition pro Repository. Enth\u00e4lt Projektstruktur (verhindert Discovery-Loops durch das ganze Repo), Build- und Test-Commands und Konventionen, die vom Standard abweichen. Wird gecacht \u2013 Cache-Hits kosten beim erneuten Lesen nur 10 Prozent des normalen Input-Preises.<\/p>\n\n\n\n Was nicht<\/em> in AGENTS.md geh\u00f6rt: allgemeine Projektdokumentation, Feature-Beschreibungen, alles was sich \u00f6fter als monatlich \u00e4ndert. Das Pr\u00fcfkriterium f\u00fcr jede Zeile: Weicht diese Regel vom Default-Verhalten ab, und ist sie f\u00fcr mehr als 30 Prozent der t\u00e4glichen Tasks relevant? Wenn nein \u2013 raus, oder in einen Skill.<\/p>\n\n\n\n Bei Bedarf geladen \u2013 Skills und Prompt Files<\/strong>: GitHub Copilot unterscheidet zwischen zwei Mechanismen f\u00fcr on-demand Context:<\/p>\n\n\n\n Beides trennt, was immer geladen wird von dem was nur bei Bedarf in den Context kommt. Es geht noch granularer: Custom Instructions lassen sich mit VS Code Erweiterungen und offene Tabs pr\u00fcfen:<\/strong> Zwei oft \u00fcbersehene Context-Aufbl\u00e4her: installierte VS Code Erweiterungen und ge\u00f6ffnete Tabs. Viele Erweiterungen injizieren automatisch Instruktionen, Workspace-Informationen oder Tool-Definitionen in den Agent-Context \u2013 ohne aktive Konfiguration. Gleichzeitig landen alle ge\u00f6ffneten Dateien bei jedem Copilot-Request im Context, unabh\u00e4ngig davon ob sie f\u00fcr die aktuelle Aufgabe relevant sind. Es lohnt sich beides zu pr\u00fcfen: Erweiterungen deaktivieren die keinen Beitrag leisten, und nicht ben\u00f6tigte Tabs schlie\u00dfen. Besonders in Enterprise-Umgebungen mit standardisierten Workstations summiert sich das schnell.<\/p>\n\n\n\n Session-spezifisch<\/strong>: Explizit referenzierte Dateien (@datei.ts statt #codebase), die aktuelle Spec, konkrete Fehlerausgaben. Direkte Referenzierung statt Repository-Discovery vermeidet, dass der Agent die halbe Codebase scannt, um den Einstiegspunkt zu finden.<\/p>\n\n\n\n Die dritte Disziplin ist die einfachste zu verstehen \u2013 und die schwerste gegen die eigene Gewohnheit durchzusetzen.<\/p>\n\n\n\n Eine Session = eine abgegrenzte Aufgabe<\/strong>. Kein offener Tab f\u00fcr den ganzen Tag. Kein \u201elass mal den Agent auch noch das pr\u00fcfen”. Bei Themenwechsel: Proaktives Compacting: Sub-Agents f\u00fcr parallele Workstreams: Statt einem gro\u00dfen Agent f\u00fcr ein ganzes Feature \u00fcbernehmen spezialisierte Agents mit eigenem, frischem Context:<\/p>\n\n\n\n Ein Orchestrator koordiniert die Ergebnisse \u2013 bekommt aber nur kompakte Zusammenfassungen, nicht die vollst\u00e4ndige Chat-History jedes einzelnen Agents.<\/p>\n\n\n\n Explizite Bounds setzen:<\/strong> Agentische Loops iterieren bis das Ziel erreicht ist \u2013 oder bis das Token-Budget aufgebraucht ist. Explizite Stop-Bedingungen verhindern das: Steering-Disziplin:<\/strong> Beaufsichtigte Sessions erlauben fr\u00fche Korrekturen \u2013 bevor ein Fehlverst\u00e4ndnis 20 teure Turns tief geht. Overnight-Runs sind kein Zeitsparer per se, sondern ein bewusster Trade-off. Ohne sehr gute Spec und explizite Bounds kann ein Overnight-Run mehr Tokens verbrennen und mehr Rework produzieren als eine beaufsichtigte 2-Stunden-Session.<\/p>\n\n\n\n Modellwahl ist real relevant \u2013 aber sie repariert keine schlechte Disziplin. Eine 30-Turn-Endlos-Session mit Haiku ist nicht g\u00fcnstig, sie ist nur langsam teuer.<\/p>\n\n\n\n Die Drei-Tier-Logik hat trotzdem ihren Platz:<\/p>\n\n\n\n\n
Warum das gerade jetzt relevant wird<\/h3>\n\n\n\n
Warum Agent-Sessions strukturell anders sind<\/h3>\n\n\n\n
\n
![\"\"](\"https:\/\/whiteduck.de\/wp-content\/uploads\/chart_agent_context-1024x499.png\")
Drei Disziplinen, die den Unterschied machen<\/h3>\n\n\n\n
1. Spec-Driven Development: Erst denken, dann coden lassen<\/h4>\n\n\n\n
\n
![\"\"](\"https:\/\/whiteduck.de\/wp-content\/uploads\/diagram_sdd_workflow-1024x1002.png\")
2. Context Engineering: Das Richtige rein, nicht alles<\/h4>\n\n\n\n
\n
.github\/prompts\/*.md<\/code>) sind der zweite Mechanismus: vordefinierte Workflows f\u00fcr repetitive Aufgaben wie \u201ecreate a unit test” oder \u201ewrite a PR description”, die explizit aufgerufen werden. <\/li>\n<\/ul>\n\n\n\napplyTo<\/code>-Globs auf bestimmte Dateimuster einschr\u00e4nken: applyTo: \"**\/*.test.ts\"<\/code>. Das bedeutet: Testing-Konventionen landen nur im Kontext, wenn Testdateien bearbeitet werden. Das eliminiert das h\u00e4ufigste Anti-Pattern: alle MCP-Tool-Schemas von Beginn an laden, auch wenn die Mehrheit nie aufgerufen wird.<\/p>\n\n\n\n3. Session-Disziplin: Das Anti-Chat-Verhalten<\/h4>\n\n\n\n
\/clear<\/code>. Wenn der Agent in einer Sackgasse steckt: stoppen, Roll-back auf den letzten sauberen Commit, pr\u00e4zisere Spec \u2013 nicht \u201efix das mal” als n\u00e4chsten Turn.<\/p>\n\n\n\n\/compact<\/code> aktiv am Ende eines Subtasks nutzen, nicht auf das automatische Compacting bei 95 Prozent Context-F\u00fcllstand warten. Wichtig: die produzierte Zusammenfassung pr\u00fcfen. Kritische Architektur-Entscheidungen und Konventionen geh\u00f6ren in AGENTS.md \u2013 nicht in den Verlauf, der beim Compacting verloren geht.<\/p>\n\n\n\n\n
max_attempts: 2<\/code> in der Agent-Konfiguration, oder eine klare Instruktion im Prompt wie \u201estoppe nach dem ersten gr\u00fcnen Testlauf”. Ohne diese Bounds kann ein einzelner Agentic-Run unkontrolliert eskalieren.<\/p>\n\n\n\nModellwahl: Ein Hebel, nicht der Hebel<\/h3>\n\n\n\n