Mehrere Entwickler arbeiten mit Agenten.
Prompts und Ergebnisse sollen nicht von persönlicher Erfahrung abhängen, sondern durch Regeln im Repository reproduzierbar werden.
Alle Leistungen
Claude Code einführen
Ihr Team schreibt jetzt dreimal so viel Code. Die Frage ist, wer ihn noch prüft.
Claude Code ist in vielen Teams längst da, meist ohne Entscheidung. Der Ausstoß steigt sofort, und mit ihm etwas, das erst später auffällt: Kein einzelner Commit ist offensichtlich falsch, aber nach drei Wochen importiert ein Domain-Objekt aus der Infrastrukturschicht und eine Modulgrenze, an der Ihr Team ein halbes Jahr gearbeitet hat, hat ein stilles Loch. Bessere Prompts beheben das nicht. Struktur schon.
Spec-SchichtArchitekturregelnTests als BedingungEinstieg 2.400 €
Was Sie bekommen
- Spec-Schicht für Ihr Repository, nicht für ein Beispielprojekt
- Architekturregeln, die der Agent nicht umgehen kann
- Tests als Bedingung im Ablauf, nicht als Vorsatz im Prompt
- Ein Beispielvorgang von der Spec bis zum zusammengeführten Zweig
- Einweisung Ihres Teams, an Ihrem Code
- Was danach gilt, schriftlich: wer prüft was, und woran man Drift erkennt
Umfang & Zusammenarbeit
Einstieg zum Festpreis an Ihrem Repository. Kein Lizenzverkauf, keine Toolschulung: Es geht um die Struktur, in der das Werkzeug arbeitet.
Remote aus Deutschland. Direkt mit mir, ohne Agentur dazwischen.
Die Ausgangslage
Das Problem ist nicht das Modell.
Die meisten Teams optimieren beim Einsatz von Agenten das Falsche. Sie wollen schnellere Erzeugung, also schreiben sie längere Prompts, geben mehr Kontext dazu und hoffen, dass der Ausstoß näher an dem liegt, was gebraucht wird. Wenn nicht, wird von Hand nachgebessert und es erneut versucht. Das Muster ist aus zwanzig Jahren Entwicklung bekannt und gilt für Menschen wie für Agenten: Ein undisziplinierter Ablauf erzeugt unvorhersehbaren Ausstoß.
Der Ausfall, über den dabei niemand spricht, ist kein Absturz. Der Agent liefert funktionierenden Code, die Tests laufen durch, der Linter ist zufrieden, es wird zusammengeführt. Drei Wochen später greift ein Domain-Objekt direkt auf die Infrastrukturschicht zu. Ein Zahlungsvorgang macht Datenbankaufrufe, von denen er nichts wissen sollte. Kein einzelner Schritt war offensichtlich falsch, aber die Summe hat die Architektur ausgehöhlt.
Das ist auch der Grund, warum Zufriedenheit und Ausstoß auseinanderlaufen können: Teams liefern mehr und trauen dem Ergebnis weniger. Die Struktur, die dagegen hilft, liegt nicht im Prompt, sondern eine Ebene darüber, in dem, was der Agent überhaupt tun darf und woran sein Ergebnis gemessen wird.
Kommt Ihnen etwas davon bekannt vor?- Der Ausstoß ist gestiegen, aber das Review kommt nicht mehr hinterher.
- Niemand kann sagen, welcher Teil des Codes von wem oder was stammt.
- Architekturentscheidungen aus dem letzten Jahr lösen sich still auf.
- Jeder im Team arbeitet anders mit dem Agenten, mit sehr verschiedenen Ergebnissen.
- Tests entstehen nach dem Code, wenn überhaupt, und prüfen was da ist statt was gefordert war.
- Ein Audit fragt, wie KI im Entwicklungsprozess eingesetzt wird, und niemand hat eine Antwort.
Für wen das passt
Für Engineering-Teams, die mit KI schneller werden – ohne Kontrolle über den Code zu verlieren.
Das Angebot richtet sich an CTOs, Engineering-Manager und Tech Leads, deren Entwickler Claude Code bereits nutzen oder zeitnah verbindlich einsetzen sollen. Der Engpass ist nicht der Zugang zum Modell, sondern ein gemeinsamer Qualitätsrahmen.
Die Codebasis hat echte Leitplanken.
Architektur, Security und Tests dürfen durch höheres Umsetzungstempo nicht zu individuellen Auslegungsfragen werden.
Die Einführung soll im Alltag halten.
Ihr Team braucht Specs, Prüfungen und Arbeitsweisen, die nach dem Workshop bei echten Tickets weiterverwendet werden.
Was ich mache
Was dabei passiert
01
Erst der Bestand, dann das Werkzeug
Wie arbeitet Ihr Team heute mit dem Agenten, wo entsteht der meiste Nachbesserungsaufwand, und welche Architekturgrenzen sind bereits durchlässig geworden. Das ist die Ausgangsmessung, gegen die sich später vergleichen lässt.
02
Die Spec-Schicht
Zwischen Absicht und Erzeugung kommt eine Ebene, die festhält, was gebaut werden soll, in welchen Grenzen und woran das Ergebnis gemessen wird. Drei Typen für drei Größenordnungen, als Vorlagen in Ihrem Repository, nicht als Theorie.
03
Architekturregeln, die der Agent nicht umgehen kann
Modulgrenzen, erlaubte Abhängigkeitsrichtungen und Schichtenregeln gehören in die Spec, nicht in den Prompt. Ein Prompt ist eine Bitte, eine Regel im Ablauf ist eine Bedingung. Nur das Zweite hält, wenn zwanzig Vorgänge am Tag laufen.
04
Tests als Bedingung, nicht als Vorsatz
Der Agent schreibt den Test vor der Umsetzung, und der Test muss zuerst fehlschlagen. Das ist keine Frage der Vorliebe, sondern die einzige Bedingung, die verhindert, dass ein Test entsteht, der beschreibt, was der Code zufällig tut.
05
Ein Vorgang von Anfang bis Ende
Statt einer Schulung ein echter Durchlauf an Ihrem Code: von der Spec über die Umsetzung bis zum zusammengeführten Zweig, gemeinsam mit den Leuten, die danach damit arbeiten. Was dabei auffällt, kommt in die Vorlagen.
06
Was danach gilt
Wer prüft was, welche Regeln gelten für zusammengeführte Zweige, und woran erkennt man Drift, bevor er drei Wochen alt ist. Schriftlich, kurz, und an einer Stelle, die im Alltag gelesen wird.
Schreibt Ihr Team schneller, als es prüfen kann?
Schicken Sie mir die Eckdaten. Sie bekommen eine Einschätzung, was die Struktur bei Ihnen bedeutet, bevor Sie etwas beauftragen.
Ablauf
Wie das abläuft
Vier Schritte, und nach dem zweiten liegt etwas in Ihrem Repository, das ohne mich weiterläuft.
SCHRITT 01
Gespräch, 30 Minuten
Wie viele arbeiten mit dem Agenten, an welchem Code, und was ist bisher schiefgegangen. Danach sage ich Ihnen, ob sich der Aufwand bei Ihnen lohnt. Wenn nicht, sage ich das auch.
SCHRITT 02
Bestand und Spec-Schicht
Zugriff auf ein Repository genügt. Die Vorlagen entstehen an Ihrem Code, mit Ihren Modulgrenzen und Ihren Konventionen, nicht an einem Beispiel.
SCHRITT 03
Ein Vorgang gemeinsam
Eine echte Aufgabe von der Spec bis zum zusammengeführten Zweig, mit den Leuten, die danach damit arbeiten. Aufzeichnung auf Wunsch.
SCHRITT 04
Regeln festhalten und übergeben
Was gilt, kommt schriftlich ins Repository. Ab dann läuft es ohne mich, und ich schaue nur wieder rein, wenn Sie es wollen.
Die andere Seite
Was der heutige Zustand kostet.
Die Summe steht unten nicht, weil ich sie nicht kenne. Die Posten kenne ich, und sie fallen bei Agenten schneller an als bei Menschen, weil mehr Code in weniger Zeit entsteht.
- 01NachbesserungWie viel Zeit geht heute dafür drauf, erzeugten Code zu reparieren, und wie viel davon war die Ersparnis?
- 02Review, das nicht hinterherkommtWie viele Zusammenführungen gehen durch, weil niemand mehr Zeit hat, sie wirklich zu lesen?
- 03Drift in der ArchitekturWas hat es beim letzten Mal gekostet, eine aufgeweichte Modulgrenze wieder herzustellen?
- 04Unterschiedliche ArbeitsweisenWie weit liegen die Ergebnisse zweier Leute im Team auseinander, und was kostet die Angleichung?
Der Einstieg unten kostet ungefähr so viel wie zwei Wochen Nachbesserung an erzeugtem Code. Er ersetzt keine dieser Zahlen, aber er hört auf, sie größer werden zu lassen.
Einstieg
Spec-Schicht in Ihrem Repository. Festpreis 2.400 €
Festpreis. Weitere Repositories oder Teams werden nach Umfang angeboten, bevor es beginnt.
Kein Vortrag über Agenten, sondern eine Struktur in Ihrem Code: Nach einer Woche liegt die Spec-Schicht in Ihrem Repository, die Architekturregeln greifen, und ein Vorgang ist gemeinsam durchgelaufen.
Was Sie bekommen
- Bestandsaufnahme: wie Ihr Team heute arbeitet und wo der Nachbesserungsaufwand entsteht
- Spec-Vorlagen für drei Größenordnungen, angelegt in Ihrem Repository
- Architekturregeln aus Ihren Modulgrenzen, als Bedingung im Ablauf statt als Bitte im Prompt
- Tests als Bedingung eingerichtet, mit Fehlschlag vor der Umsetzung
- Ein echter Vorgang gemeinsam, von der Spec bis zum zusammengeführten Zweig
- Review-Regeln und Merkmale für Drift, schriftlich im Repository
Was Sie nicht bekommen
- Keine Lizenzberatung und keine Beschaffung, das klären Sie direkt mit dem Anbieter
- Keine Schulung im Bedienen des Werkzeugs, dafür gibt es die Dokumentation
- Keine Bewertung, ob KI im Entwicklungsprozess rechtlich zulässig ist
- Keine Umsetzung Ihrer Vorhaben, es geht um die Struktur, nicht um Funktionen
- Keine laufende Begleitung ohne eigene Vereinbarung
- Zugriff auf ein Repository und ein bis zwei Termine mit den Leuten, die täglich damit arbeiten
- Was entsteht, liegt in Ihrem Repository und gehört Ihnen, auch wenn Sie danach anders arbeiten
- Preis netto, zuzüglich Umsatzsteuer
- Bei mehreren Repositories oder Teams über acht Personen wird der Umfang vorher abgestimmt
- Sie sind zu nichts verpflichtet. Manche Teams übertragen die Vorlagen danach selbst auf weitere Projekte, und das ist ein gültiges Ergebnis
Das Ergebnis
Was danach anders ist
Die Architektur hält
Abhängigkeitsrichtungen und Modulgrenzen stehen als Regel im Ablauf, nicht als Bitte im Prompt. Ein Verstoß fällt beim Zusammenführen auf und nicht drei Wochen später.
Gleiche Ergebnisse im ganzen Team
Ob jemand seit einem Jahr mit Agenten arbeitet oder seit einer Woche, macht für das Ergebnis weniger aus als vorher. Die Struktur trägt, nicht die Übung im Formulieren.
Tests, die etwas aussagen
Ein Test, der vor der Umsetzung entstanden ist und zuerst fehlschlug, prüft die Anforderung. Einer, der danach entstand, prüft den Code. Der Unterschied zeigt sich beim ersten echten Fehler.
Eine Antwort für das Audit
Wie KI im Entwicklungsprozess eingesetzt wird, wer prüft und woran, steht schriftlich fest. Das beantwortet die Frage, bevor sie gestellt wird.
Eingesetzte Technologien
Womit ich arbeite
Agenten
- Claude Code
- Superpowers
- MCP
- Subagents
Spec-Schicht
- Spec-Templates
- Akzeptanzkriterien
- Architecture Constraints
Tests
- Test zuerst
- PHPUnit
- Vitest
- Go testing
Analyse
- PHPStan
- Psalm
- Rector
- Statische Analyse
Sprachen
- PHP 8
- Golang
- Python
- TypeScript
Pipeline
- GitHub Actions
- GitLab CI
- Prüfungen als Bedingung
Prüfung
- Abhängigkeitsregeln
- Modulgrenzen
- Review-Regeln
Betrieb
- Docker
- AWS
- Terraform
- OpenTelemetry
Zum Weiterlesen
Artikel · Agentic Coding
Agentic Coding mit Spec-Driven Development: Warum Ihr KI-Agent Struktur braucht
Der Failure Mode, über den niemand spricht, die Spec-Schicht mit drei Vorlagen, warum Architekturregeln in die Spec gehören und nicht in den Prompt, und wo die Grenzen des Ansatzes liegen. Das Vorgehen dieser Seite, im Einzelnen aufgeschrieben.
Artikel lesenEbenfalls aus echten Projekten
Artikel
Ein Agent ist so gut wie sein Kontext
Die Ebene unter der Spec-Schicht: wie ich mein eigenes Wissen so abgelegt habe, dass Agenten damit arbeiten können. Mit den beiden Lehren, die diese Seite trägt: Eine Regel, die kein Mechanismus prüft, hält nicht, und eine Prüfung, die still grün meldet, ist schlechter als keine.
Artikel lesen
Mit wem Sie es zu tun haben
Direkt mit mir als Freelancer. Keine Agentur dazwischen.
Ich bin Tim Rutte. Über 20 Jahre Softwareentwicklung, und ich arbeite selbst täglich mit Agenten, an Systemen, die in Produktion laufen. Sie sprechen mit der Person, die Ihren Code anfasst, vom ersten Gespräch bis zur Übergabe.
- 20+Jahre Softwareentwicklung
- 50+erfolgreiche Projekte
- 2003seit diesem Jahr remote im Einsatz
Häufige Fragen
Häufige Fragen zur Einführung
Wir nutzen Claude Code schon. Ist das dann noch etwas für uns?
Das ist der Normalfall. Die Werkzeuge sind meist längst da, oft ohne Entscheidung, und die Frage stellt sich erst danach: Der Ausstoß ist gestiegen, das Review kommt nicht hinterher, und in der Architektur zeigen sich Stellen, die niemand so beschlossen hat. Genau dort setzt das an, nicht bei der Installation.
Warum reichen bessere Prompts nicht?
Weil ein Prompt eine Bitte ist. Er wirkt in einem Vorgang, nicht in zwanzig am Tag, und er wirkt bei der Person, die ihn geschrieben hat, nicht im ganzen Team. Was hält, sind Bedingungen im Ablauf: eine Spec mit Akzeptanzkriterien, Architekturregeln, die geprüft werden, und ein Test, der vor der Umsetzung fehlschlagen muss.
Funktioniert das nur mit Claude Code?
Der Ansatz nicht, die Vorlagen teilweise. Spec-Schicht, Architekturregeln und die Test-Bedingung sind unabhängig vom Werkzeug; wie sie eingebunden werden, unterscheidet sich. Wenn Sie mehrere Werkzeuge im Einsatz haben, sagen Sie es vorher, dann wird es entsprechend zugeschnitten.
Was kostet die Einführung von Claude Code?
Der Einstieg kostet 2.400 Euro netto zum Festpreis. Innerhalb einer Woche liegt die Spec-Schicht in einem Repository, inklusive eines gemeinsamen Durchlaufs. Weitere Repositories oder größere Teams werden nach Umfang angeboten, bevor es beginnt. Zum Vergleich: Das entspricht etwa zwei Wochen Nachbesserung an erzeugtem Code, und die fallen jeden Monat wieder an.
Bremst das unsere Entwickler nicht aus?
Die Erzeugung wird tatsächlich nicht schneller, das ist auch nicht das Ziel. Schneller wird der Weg von der Erzeugung bis zum zusammengeführten Zweig, weil weniger nachgebessert wird und Review weniger findet. Wer nur auf die Zeit bis zum ersten Ergebnis schaut, misst die falsche Größe.
Wie messen wir, ob es etwas gebracht hat?
An drei Dingen, die vorher aufgenommen werden: Wie viel Zeit auf Nachbesserung entfällt, wie viele Anmerkungen ein Review im Schnitt erzeugt, und wie oft eine Architekturregel verletzt wird. Die dritte Zahl ist die interessanteste, weil sie vorher meist gar nicht erhoben wird.
Was ist mit Code, den wir nicht offenlegen dürfen?
Die Arbeit findet in Ihrer Umgebung statt, an Ihrem Repository, mit Ihren Zugängen. Wenn bestimmte Bereiche für externe Werkzeuge gesperrt sind, gehört genau das in die Regeln, die dabei entstehen. Was dabei nach draußen geht und was nicht, ist Teil der Aufnahme, nicht eine Frage danach.
Machen Sie auch die Umsetzung mit den Agenten?
Ja, aber als eigenes Vorhaben. Bei einer Modernisierung oder einer Übernahme setze ich dieselbe Struktur ein, dort ist sie Teil der Arbeit und kein eigenes Angebot. Diese Seite ist für Teams, die selbst weiterarbeiten wollen.
Weitere Leistungen
Womit ich sonst helfe.
KI-Integration
Die Infrastruktur hinter produktiven KI-Systemen: MCP-Server, sichere Tool-Anbindung, LLM-Integration mit Zugriffsschutz und Kostenkontrolle.
Mehr erfahrenMCP-Server entwickeln
MCP-Server, die in Produktion tragen: Identität des Nutzers statt eines technischen Sammelkontos, Werkzeuge mit Grenzen, vollständiger Audit-Trail und ein Kostendeckel je Anwendungsfall.
Mehr erfahrenLLM-Kosten senken
FinOps für Inferenz: Kosten je Vorgang und je Nutzer sichtbar machen, Modelle nach Aufgabe wählen, Kontext und Wiederholungen begrenzen. Erst messen, dann handeln.
Mehr erfahren