Was KI Code in Python ohne Regeln kostet

Ein Regelwerk für die Zusammenarbeit mit KI Coding Agents im eigenen Projekt. Dazu gehören Rules Dateien wie AGENTS.md, eine Spezifikation je Änderung, Tests als Abnahmekriterium und automatische Prüfungen in der Pipeline. Ziel ist Code, der zum bestehenden Projekt passt und sich genauso reviewen und warten lässt wie handgeschriebener.

Dort besonders. In gewachsenen Codebasen liegen Skripte, Jobs und Services mit unterschiedlichem Alter nebeneinander, und ohne Vorgabe greift ein Agent gern das erstbeste Muster auf, das er findet. Mit klaren Regeln und einer Testbasis an den kritischen Stellen wird die Arbeit daran wieder planbar.

Ruff für Linting und Formatierung, mypy für die Typprüfung, pytest für Tests. Alles Open Source und alles im Repository. Dazu ein Agent eurer Wahl, meist Claude Code oder OpenCode, bei Bedarf mit lokalen Modellen über Ollama. Mehr braucht es für den Anfang nicht.

15 bis 30 Tage bis zum ersten belastbaren Stand: Regeln stehen, die ersten Gates laufen, der Agent arbeitet im Alltag mit. Am unteren Ende liegen Projekte mit Versionskontrolle, Tests und laufender Pipeline. Fehlen Tests und CI komplett, wird daraus ein längeres Vorhaben. Danach folgen ein paar Tage pro Monat für die Pflege.

Ja. Alle Artefakte sind offene Dateien im Repository. AGENTS.md wird von den meisten Agents gelesen, Claude Code nutzt zusätzlich CLAUDE.md. Spezifikationen, Tests und Pipeline arbeiten ohnehin unabhängig vom Werkzeug. Ein Wechsel des Agenten oder des Modells lässt die Guidelines unberührt.

Ja, und das ist der häufigste Ausgangspunkt. Wir typisieren nicht flächendeckend, sondern zuerst die Ränder: Eingaben von außen, Rückgabewerte öffentlicher Funktionen, die Stellen, an denen künftig KI Code entsteht. mypy läuft dabei zunächst nur über diese Bereiche und wächst mit.

Projektstruktur und Modulschnitt, die gesetzte Paketverwaltung und wie Abhängigkeiten dazukommen, der Umgang mit Konfiguration und Secrets, das Fehlerkonzept und die Testpflichten. Dazu die Verbote: welche Pakete nicht mehr verwendet werden und welche Bereiche der Agent nicht anfassen soll.

Notebooks sind für Agenten schwieriges Terrain, weil Reihenfolge und Zustand nicht im Code stehen. Wir ziehen deshalb die Grenze: Im Notebook wird exploriert, alles, was mehrfach gebraucht wird, wandert als getestete Funktion in ein Modul. Der Agent arbeitet an den Modulen, nicht an den Notebooks.

Auf Ebene des guten Willens gar nicht, denn ein Agent hält Regeln mal ein und mal nicht. Deshalb steht hinter jeder wichtigen Regel eine automatische Prüfung. Ruff, mypy und pytest laufen in der Pipeline, und was dort durchfällt, wird nicht gemergt.

Nein, sie verkürzen es. Formatierung, Typfehler und Standardverstöße fängt die Pipeline ab, bevor jemand hinschaut. Im Review bleibt die fachliche Frage, ob die Lösung richtig ist und ob die Entscheidung zum Projekt passt. Dafür ist dann mehr Zeit da.

Nicht pauschal. mypy ist ausgereift und läuft überall, ty ist deutlich schneller, aber noch in der Beta. Wenn die Prüfzeit bei euch heute wehtut, lohnt ein Versuch im Parallelbetrieb: beide laufen lassen, Ergebnisse vergleichen, erst danach entscheiden. Ein Wechsel des Prüfers lässt die Regeln unberührt.

Derselbe Aufbau, andere Schwerpunkte. Wichtig sind hier die Datenregeln: Der Agent arbeitet gegen Testdaten, nicht gegen echte Bestände, und Zugriffe laufen über definierte Werkzeuge statt über freie Verbindungen. Beim Testen zählt weniger die Abdeckung als die Frage, ob Ergebnisse reproduzierbar sind.

Ja. Eine schlanke Basisdatei liegt auf Wurzelebene, je Paket kommen eigene Regeldateien dazu. Der Agent lädt dann nur, was zum aktuellen Verzeichnis passt. Genauso wichtig: Prüfungen und Testsuite laufen je Paket, damit ein Fehler zeigt, wo er entstanden ist.

Wir arbeiten ohne Festpreise und ohne Pakete. Am Anfang steht ein kostenloses Kennenlernen, in dem wir euer Projekt und euer Ziel verstehen. Danach schätzen wir den Aufwand ein und rechnen minutengenau ab, sodass jederzeit nachvollziehbar bleibt, wofür ihr zahlt.

Ja. Der Aufbau ist sprachunabhängig, es wechseln nur die Werkzeuge. Für PHP und Symfony gibt es die NCA PHP AI Coding Guidelines mit PHPStan, Rector und PHPUnit, für Astro, React und Vue die Variante für TypeScript. Das sprachneutrale System hinter allen dreien sind die NCA Agentic AI Coding Guardrails.

Ja. Wir arbeiten selbst täglich mit Ollama und Modellen wie Qwen3 Coder auf eigener Hardware. Die Guidelines sind reine Dateien im Repository, denen es gleichgültig ist, welches Modell sie liest. Für Teams mit strengen Vorgaben ist das der Weg, bei dem kein Quellcode das eigene Netz verlässt.

Nein. Es gibt drei Wege: lokale Modelle über Ollama, gehostete Inferenz bei einem europäischen Anbieter oder eine Cloud eurer Wahl. Bei hohen Anforderungen arbeiten wir mit unserem Duisburger Netzwerkpartner Conversis zusammen, der gehostete Inferenz nach DSGVO Vorgaben anbietet.

Über LiteLLM als Proxy vor den Modellen. Jeder Aufruf läuft darüber, lokal wie in der Cloud, und landet mit Verbrauch und Kosten auf einem Dashboard. Darauf setzen Budgets je Nutzer, Team oder Projekt: Ist der Topf leer, leitet der Proxy nicht mehr weiter. Damit fällt ein durchlaufender Agent Loop sofort auf statt erst auf der Monatsrechnung.

Zentral über dieselbe Stelle. Wer welchen MCP Server erreichen darf, wird einmal vergeben statt in jeder lokalen Konfiguration einzeln gepflegt. Neue Kollegen bekommen den passenden Satz an Werkzeugen freigeschaltet, ohne dass Zugangsdaten per Chat weitergereicht werden.

So streng, wie die Codebasis es heute trägt, und dann schrittweise strenger. Ein Projekt sofort auf vollständige Prüfung zu zwingen erzeugt eine Fehlerliste, die niemand abarbeitet, und ein Gate, das dauerhaft rot steht. Solche Gates werden erfahrungsgemäß ignoriert.

Wir starten mit dem Standardsatz und nehmen gezielt dazu, was zum Projekt passt, etwa Regeln gegen stille Fehlerbehandlung oder gegen veraltete Schreibweisen. Was nur Lärm erzeugt, schalten wir bewusst ab und schreiben den Grund dazu. Eine Regel ohne Begründung wird beim nächsten Konflikt einfach wieder entfernt.

An der Grenze wird abgeschnitten. Externe Aufrufe laufen über eine schmale Schicht, die im Test ersetzt wird, damit die Suite ohne Netz läuft und reproduzierbar bleibt. Für den Ernstfall bleibt eine kleine Zahl an Tests gegen die echte Schnittstelle, die seltener läuft.

An Zahlen, die ohnehin vorliegen. Wie viele Kommentare hängen an einem Merge Request, wie lange bleibt er offen, wie oft geht ein Feature zurück in die Entwicklung, wie entwickelt sich die Testabdeckung. Wir sehen uns diese Werte vorher an, damit der spätere Vergleich etwas aussagt.

Euch. Alle Artefakte liegen als offene Dateien in eurem Repository, die Werkzeuge dahinter sind Open Source. Es gibt keine Plattform und keinen Zugang, der ablaufen kann. Ihr könnt das Ergebnis jederzeit ohne uns weiterentwickeln.

Immer dann, wenn sich eine Architekturentscheidung ändert oder ein neues Muster Einzug hält. In der Praxis sind das ein paar Zeilen pro Quartal. Wichtig ist, dass die Pflege im Team verankert ist, deshalb zeigen wir in den Sessions, wie eine Regel entsteht und wie sie wieder verschwindet.

Der Agent schreibt Migrationen, führt sie aber nicht gegen echte Bestände aus. Gearbeitet wird gegen eine lokale Entwicklungsumgebung mit Testdaten. Wo ein Agent an ein echtes System muss, läuft der Zugriff über definierte Werkzeuge statt über freien Datenbankzugang.

Die Regeln und Gates gelten für alle gleich, weil sie im Repository liegen und in der Pipeline laufen. Beim Agenten selbst hat jeder die freie Wahl. Wichtig ist nur, dass lokal dieselben Prüfungen laufen wie in der CI, sonst verschiebt sich die Fehlersuche in den Merge Request.

Beides. Der größte Teil läuft remote über Pair Programming Sessions und gemeinsame Reviews, was für die meisten Teams am besten funktioniert. Für Workshops und intensive Startphasen kommen wir auch vor Ort, von Duisburg aus in den gesamten DACH Raum.