Softwareentwicklung bei Idego
Sechs Phasen. Gemeinsame Prüfungen. Menschliche Freigaben.
Agenten implementieren, testen und prüfen. Menschen genehmigen den Umfang und führen Änderungen in main zusammen. Spezifikationen, Prüfungen und Prozess liegen im Projekt-Repository.
Ein KI-nativer SDLC ist ein Softwareentwicklungsprozess, den Agenten ausführen und Menschen steuern. Spezifikationen, Tests, Review-Regeln und Freigaben werden im Projekt-Repository versioniert.
KI-Unterstützung hilft Menschen bei einzelnen Aufgaben. Ein KI-nativer Prozess verbindet diese Aufgaben durch gemeinsame, verbindliche Prüfungen und dokumentiert, was geändert wurde, welche Prüfungen bestanden wurden und wer die Arbeit freigegeben hat.
Assistenten können Tests schreiben und Code prüfen. Entscheidend ist, ob das Team einen gemeinsamen Prozess hat, der diese Schritte verbindlich vorgibt.
| Bereich | KI-unterstützte Entwicklung | KI-native Entwicklung |
|---|---|---|
| Wo der Prozess liegt | Kann von persönlichen Gewohnheiten und Anweisungen abhängen. | Versionierte Standards, Spezifikationen und Skills liegen im Repository. |
| Spezifikation vor Code | Eine Spezifikation kann optional sein oder außerhalb des Ablaufs liegen. | Vor Code ist eine umsetzungsbereite Spezifikation erforderlich. Eine dokumentierte Ausnahme gilt nur für Dokumentation oder Prozessarbeit. |
| Tests vor Implementierung | Assistenten können Tests schreiben, ohne dass die Reihenfolge verbindlich ist. | Jedes Verhalten beginnt mit einem fehlschlagenden Test und einer vorgeschriebenen Matrix für Randfälle. |
| Automatische Reviews | Prüfungen können davon abhängen, wer sie anfordert und auswählt. | Vier Prüfer bewerten Sicherheit, Fehler, Standards und Spezifikationen sowie Wartbarkeit. |
| Schweregrade und Zurückstellungen | Gemeinsame Schweregrade und dokumentierte Zurückstellungen können fehlen. | Kritische und schwerwiegende Befunde müssen behoben werden. Mittlere und geringe Befunde dürfen nur mit schriftlicher Begründung im PR zurückgestellt werden. |
| Grenzen für Wiederholungen | Wiederholungen können ohne gemeinsame Grenze oder Eskalationsregel erfolgen. | Der zweite Fehlschlag stoppt die Schleife und erstellt einen Lückenbericht für einen Menschen. |
| Menschliche Freigaben | Freigaben können von der persönlichen Arbeitsweise abhängen. | Menschen genehmigen den Umfang, wählen Issues aus, bestätigen Commits und führen Änderungen in main zusammen. |
| Übertragbarkeit zwischen Werkzeugen | Anweisungen können sich je nach Werkzeug unterscheiden. | Dieselben Skills laufen in Cursor, Claude Code und Codex. Eine Prüfung kontrolliert ihre Übereinstimmung. |
| Nachvollziehbarkeit nach dem Merge | Verbindungen zwischen Anforderungen, Tests und Entscheidungen können lückenhaft sein. | Issues verweisen auf Spezifikationen, Tests, PRs und archivierte Anforderungen, die das gelieferte System beschreiben. |
Einfach gesagt: Jede Änderung durchläuft sechs Phasen und kann erst zur nächsten Phase übergehen, wenn ihre Prüfungen bestanden sind. Jede Phase endet mit einer Prüfung, die bei Fehlern die weitere Arbeit blockiert. Die Umsetzung eines einzelnen Issues (/deliver-issue) umfasst die Phasen von Start bis Archivierung. Die Umsetzung eines Meilensteins (/deliver-milestone) bearbeitet Issues in parallelen Gruppen, jeweils in einem isolierten Arbeitsverzeichnis, führt ihre PRs in einem Integrationsbranch zusammen und öffnet einen übergeordneten Entwurfs-PR nach main. Ein Mensch führt den abschließenden Merge nach main aus.
ErgebnisIssues und Meilenstein
Wir vereinbaren einen klaren, prüfbaren Umfang, bevor die Umsetzung beginnt.
Ein gezieltes Gespräch und die Untersuchung des Repositorys zerlegen die Idee in durchgängige Funktionsabschnitte für jeweils einen PR, mit prüfbaren Abnahmekriterien und Abhängigkeiten. Bei mindestens drei Issues hält ein Meilenstein die Reihenfolge fest; alternativ erstellt eine Analyse ohne Codeänderungen einen priorisierten Verbesserungsmeilenstein mit Labels.
ErgebnisBranch, Entwurfs-PR und Spezifikation
Wir erstellen für das ausgewählte Issue eine umsetzungsbereite Spezifikation.
Ein Issue erhält einen gh-<n>-Branch und einen Entwurfs-PR mit Closes #<n>; unklarer Umfang wird präzisiert, Entscheidungen und Begriffe werden dokumentiert. Vor Code erstellt der Agent einen OpenSpec-Vorschlag, einen Entwurf, Szenarien und Aufgaben oder dokumentiert spec:skip für reine Dokumentations- oder Prozessarbeit.
ErgebnisCode, Tests und Prüfergebnisse
Wir implementieren ein Verhalten nach dem anderen, mit Tests und den erforderlichen Prüfungen.
Vorabprüfungen zu Bereitschaft, Spezifikation, Architekturgrenzen, Sicherheit und Dokumentation müssen bestehen, bevor ein Unteragent pro Aufgabengruppe testgetrieben arbeitet: fehlschlagender Test, minimaler Code, Refactoring. Die Randfallmatrix umfasst leere und ungültige Eingaben, Grenzen, Vorrangregeln, Vererbung, Isolation und Asymmetrie; Abschlussprüfungen umfassen Lint, Typprüfung, Unit- und Integrationstests, Produktionsbuild und jedes Spezifikationsszenario.
ErgebnisReview-Bericht und Testplan
Wir prüfen die Änderung parallel und beheben blockierende Befunde.
Vollständige Verifikation und vier parallele Prüfer liefern Befunde mit Schweregraden; kritische und schwerwiegende Befunde müssen behoben, mittlere und geringe Zurückstellungen im PR schriftlich begründet werden. Nach höchstens zwei Review-Runden führen offene kritische oder schwerwiegende Befunde zu NOT DONE und einer Eskalation an einen Menschen.
ErgebnisAktualisierte Systemspezifikationen
Wir aktualisieren die laufend gepflegten Spezifikationen, damit sie dem verifizierten Code entsprechen.
Bei Änderungen mit erforderlicher Spezifikation führt der Agent die Änderungsspezifikationen mit der aktuellen Spezifikationsbibliothek zusammen. Er speichert die aktualisierten Spezifikationen in einem Commit, damit sie das gebaute System beschreiben.
ErgebnisMenschlich genehmigter Merge
Ein Mensch genehmigt die abgeschlossene Änderung und führt sie zusammen.
Ein Mensch prüft die abgeschlossene Arbeit und führt sie in main zusammen. Das Zusammenführen von Issue-PRs in einem Integrationsbranch ist ein eigener Schritt und erlaubt Agenten keinen Merge nach main.
Agenten führen die Arbeit aus und liefern Nachweise. Menschen geben die Richtung vor und behalten die Kontrolle über unumkehrbare Entscheidungen.
Jede wesentliche Änderung beginnt mit einer umsetzungsbereiten Spezifikation, bevor Code entsteht. Ihre Szenarien legen fest, was Tests und abschließende Verifikation nachweisen müssen.
OpenSpec hält die Änderungsdokumente im Repository. Entscheidungsprotokolle erklären die gewählten Ansätze, ein Glossar definiert Fachbegriffe und archivierte Spezifikationen beschreiben das aktuelle System.
Eine dokumentierte Anwendbarkeitsprüfung kann spec:skip für reine Dokumentations- oder Prozessarbeit erlauben. Sie befreit keine Codeänderungen von der Spezifikation und erlaubt nicht, erforderliche Prüfungen zu überspringen.
Die Startkriterien legen fest, ob Arbeit beginnen kann. Die Abschlusskriterien prüfen, ob sie fertig ist. Testgetriebene Entwicklung, die Randfallmatrix und bestandene Prüfungen sind für die weitere Umsetzung verbindlich.
Prüft Sicherheitsrisiken und die Sicherheitsregeln des Projekts.
Prüft Korrektheit, Fehlerpfade und Randfälle.
Prüft Repository-Regeln und jedes vorgegebene Szenario.
Hinterfragt unnötige Komplexität und schwer änderbaren Code.
Das Repository enthält die Regeln und Nachweise, mit denen Ihr Team Agentenarbeit steuert. Diese Kontrollen machen den Prozess prüfbar und wiederholbar.
Standards für Bereitschaft, Abschluss, Tests, Sicherheit, Reviews, Code und Koordination haben einen zentralen Index. Ein Unit-Test lässt CI fehlschlagen, wenn ein Standard ohne Aktualisierung des Index hinzugefügt oder entfernt wird.
Testgetriebene Arbeit und die Randfallmatrix sind Pflicht. Agenten verwenden UI-Grundbausteine aus dem Designsystem-Register; eigene Nachbauten sind nicht erlaubt. PR-Labels und Conventional Commits sind verbindlich; CI erzwingt gh-<n>-Branchnamen.
Das Repository verbindet Issues, Spezifikationen, Tests, PRs und archivierte Anforderungen. Entscheidungsprotokolle und ein Fachglossar bewahren die Gründe für die Arbeit.
Review-Runden, Wiederholungen fehlschlagender Tests und erneute Verifikation haben ein Budget von zwei Fehlschlägen. Der zweite stoppt die Schleife mit BLOCKED und einem Lückenbericht. Jeder Phasenbericht enthält eine Loops:-Zeile mit Runden, Versuchen, Delegierungen und Zurückstellungen.
Dieselben Skills laufen in Cursor, Claude Code und Codex. Eine Prüfung auf Skill-Parität kontrolliert ihr übereinstimmendes Verhalten; der Prozess hängt nicht von einem bestimmten Modell ab.
Menschen genehmigen den Umfang, wählen Issues aus, bestätigen Commits und mergen nach main. Agenten melden Blockaden und Eskalationen, damit ein Mensch über den nächsten Schritt entscheidet.
Wir arbeiten mit Entwicklungsteams im Vereinigten Königreich und in ganz Europa. Für Unternehmen, die Agenten die Umsetzung anvertrauen, klare Kontrolle behalten und den Prozess im eigenen Team weiterführen wollen.
Sie erhalten von Anfang an ein Projekt-Repository mit Spezifikationen, Umsetzungsregeln und Agenten-Skills. Berichte zeigen, welche Prüfungen bestanden wurden und wo noch eine Entscheidung nötig ist.
Geben Sie Agenten einen gemeinsamen Prozess mit verbindlichen Tests, Reviews und menschlichen Freigaben, statt den Ablauf jedem Entwickler einzeln zu überlassen.
Der gleiche Prozess bleibt in Ihrem Repository. Verfolgen Sie jedes Issue über Spezifikation, Tests und PR bis zu den archivierten Anforderungen und nutzen Sie den Ablauf für die nächste Änderung.
Es ist ein Softwareentwicklungsprozess, den Agenten ausführen und Menschen steuern. Das Repository enthält Spezifikationen, Standards, Skills und Qualitätsprüfungen sowie Berichte und Freigaben.
Ein Coding-Assistent kann beim Schreiben, Testen und Prüfen von Code helfen. KI-native Entwicklung verbindet diese Tätigkeiten in einem gemeinsamen, verbindlichen Prozess mit Spezifikationen vor Code, Review-Regeln, Wiederholungsgrenzen und menschlichen Freigaben.
Agenten mergen niemals nach main. Für einen Meilenstein können sie Issue-PRs in einem Integrationsbranch zusammenführen und einen übergeordneten Entwurfs-PR öffnen. Ein Mensch genehmigt und übernimmt den abschließenden Merge nach main.
Automatische Schleifen stoppen nach dem zweiten Fehlschlag mit BLOCKED und einem Lückenbericht für einen Menschen. Reviews sind auf zwei Runden begrenzt; offene kritische oder schwerwiegende Befunde führen dann zu NOT DONE und einer Eskalation.
Der Prozess ist modellunabhängig. Dieselben Skills laufen in Cursor, Claude Code und Codex. Eine Prüfung im Ablauf kontrolliert die Skill-Parität zwischen diesen Werkzeugen.
Vor Code steht eine umsetzungsbereite OpenSpec-Änderung, deren Szenarien die Verifikation vollständig prüft. Danach übernimmt die Archivierung die Änderungsspezifikationen in die aktuelle Anforderungsbibliothek. Nur eine dokumentierte Prüfung für reine Dokumentations- oder Prozessarbeit erlaubt spec:skip.
Ja. Prozess, Standards, Spezifikationen und Agenten-Skills bleiben im Projekt-Repository. Ihr Team kann denselben Ablauf ausführen und Entscheidungen sowie Ergebnisse jeder gelieferten Änderung nachvollziehen.
Die Sicherheitsgrundlagen gehören zu den Vorabprüfungen. Ein eigener Sicherheitsprüfer arbeitet parallel zu den Prüfern für Fehler, Standards und Spezifikation sowie Wartbarkeit. Kritische und schwerwiegende Befunde müssen behoben werden; mittlere und geringe Zurückstellungen brauchen eine schriftliche Begründung im PR.
Beginnen Sie mit dem Prozess, nicht mit dem Werkzeug. Legen Sie Spezifikationen, Tests und Review-Regeln im Repository ab, damit alle Agenten und Entwickler dieselben Prüfungen durchlaufen. Setzen Sie Agenten klare Grenzen, lassen Sie Menschen den Umfang und die Zusammenführung von Änderungen freigeben und erproben Sie den Prozess an einem echten Projekt. Sobald er funktioniert, übergeben Sie ihn dem Team, das ihn täglich betreiben wird.
Messen Sie die Ergebnisse der Softwarelieferung, nicht persönliche Eindrücke. Erfassen Sie zunächst die Durchlaufzeit von Änderungen, die Deployment-Häufigkeit, den Anteil fehlerhafter Änderungen und die Review-Zeit. Vergleichen Sie diese Werte nach der Einführung. Selbsteinschätzungen können täuschen: In einer METR-Studie von 2025 waren erfahrene Entwickler bei den untersuchten Aufgaben mit KI-Werkzeugen 19% langsamer, glaubten aber, 20% schneller gewesen zu sein.
Spezifikationsgetriebene Entwicklung bedeutet, vor dem Schreiben von Code festzulegen, was eine Änderung leisten muss. Eine kurze Spezifikation dokumentiert das Problem, den Umfang, die Entwurfsentscheidungen und die Szenarien, die Tests nachweisen müssen. Für KI-Programmieragenten ist die Spezifikation die Arbeitsanweisung und die Vereinbarung, die Tests und Reviews überprüfen. Bei Idego liegen Spezifikationen mit OpenSpec im Repository.
Ja, wenn Governance von Anfang an Teil des Prozesses ist. Unternehmen brauchen als Code definierte Standards, verbindliche Arbeitsregeln, Spezifikationen im Einklang mit dem System und eine nachvollziehbare Historie der Änderungen und Freigaben. Agenten führen Änderungen niemals selbstständig mit main zusammen. So behalten Menschen die Kontrolle über jedes Release.
Sprechen Sie mit uns über Ihre Entwicklungsziele, Freigaberegeln und die Übergabe an Ihr Team. Gemeinsam grenzen wir die Arbeit ein und zeigen, wo Agenten passen.