Das SliceOps-Manifest

Die Branche verbrachte zwei Jahre mit der Debatte, ob KI Entwickler ersetzt. Das ist die falsche Frage. Die richtige ist strukturell: Wie sieht Softwareentwicklung aus, wenn der Großteil des Tippens von Agenten und der Großteil der Urteilskraft von Menschen erbracht wird?

Sprints setzen Menschen voraus, die an Standups und Zwei-Wochen-Verpflichtungen gebunden sind. Agenten haben solche Grenzen nicht. Ein Slice braucht fünf Millionen Tokens und zehn Minuten, der nächste sechzig Millionen und einen Tag. Diese Geschwindigkeit in Rituale zu zwängen, die für Büroangestellte gedacht sind, ist, im Stillen, ein Anti-Pattern.

Multi-Agenten-Parallelität durchbricht eine zweite Annahme: dass ein Entwickler jeweils einen Branch bearbeitet. Lassen Sie ein Dutzend Agenten auf ein Repository los und, ohne explizite Abhängigkeiten und atomare Entscheidungszähler, wird aus der Parallelität, die sich verstärken sollte, die Parallelität, die kollidiert.

SliceOps ist das offene Framework und die Audit-Ebene für AI-first-Softwareentwicklung. Es ist kein Code-Editor. Es ist kein autonomer Agent. Es ist kein Werkzeug für Code-Qualität und keine nachträgliche Compliance-Plattform. Es ist die Ebene, die über all dem liegt.

Wenn Cursor, Claude Code, Devin und Copilot die Agenten-Runtimes sind, dann ist SliceOps das, was darüber läuft: das Ledger der Entscheidungen, die Einheit der Atomarität, der Abhängigkeitsgraph und die Audit-Ebene, die den gesamten Stack für einen menschlichen Prüfer, einen regulatorischen Auditor oder den nächsten frisch eintreffenden Agenten lesbar macht.

Es ist offen durch Design. Das Framework lebt in Markdown, die Werkzeuge leben in Python und TypeScript, die Regeln leben in der CI. Kein Vendor-Lock-in. Jeder kann es übernehmen. Jeder kann es forken.

Hier unterscheidet sich SliceOps am stärksten von allem anderen. SonarQube auditiert Code. Runtime-Werkzeuge auditieren die Ausführung. Vanta und Drata auditieren das Unternehmen, im Nachhinein. Credo AI auditiert Modelle. Alle notwendig. Keines davon auditiert die Ebene über dem Code.

Diese Ebene ist die Integrität architektonischer Entscheidungen: War der Slice konsistent mit der Spec des Abschnitts? War die Spec konsistent mit dem Plan? Waren die zitierten Entscheidungen jene, die die Änderung tatsächlich regieren? Ist ein slice-übergreifender Widerspruch aufgetreten, der aufgelöst werden muss?

Es ist die Ebene, die entscheidet, ob die von Agenten im großen Maßstab erzeugte Software ein wartbares System oder eine Schuldenbombe ist. Es ist die Ebene, die niemand sonst im Blick hat, und jene, die SliceOps in den Editor des Entwicklers legt statt in ein Compliance-Dashboard.

Klassische Softwareentwicklung bewahrte den Kontext in den Köpfen der Menschen. KI-Agenten sind gedächtnislos, jede Sitzung beginnt kalt. Also behandelt SliceOps das Korpus selbst als ihren geteilten Kontext: Grundlagen, Entscheidungen, Architektur und Specs werden zu einer einzigen, gesteuerten Quelle der Wahrheit, die jedem Agenten bei Bedarf zugeführt und über alle hinweg kohärent gehalten wird.

SliceOps nennt das Kontextdisziplin, und es ist der Teil, den kein klassischer SDLC je brauchte: Menschen trugen den Kontext in ihren Köpfen; gedächtnislose Agenten können das nicht. Ohne sie zerbrechen atomare Slices, die Audit-Ebene und das rekursive Lernen, denn jeder Agent würde von einem anderen, abdriftenden Bild des Systems aus arbeiten.

Es gibt eine Wendung, die es sich auszumustern lohnt (Compliance-Theater), und eine, die es sich lohnt, an ihre Stelle zu setzen: compliance-ready durch Konstruktion.

Wenn Sie SliceOps übernehmen, ist jede architektonische Entscheidung ein Record, der auf eine ISO-42001-Kontrolle, ein SOC-2-Kriterium oder eine Dokumentationsanforderung des EU AI Act abbildet. Sie schreiben diese Dokumente nicht, weil ein Auditor kommt. Sie schreiben sie, weil sie das Framework sind. Wenn der Auditor kommt, exportieren Sie das Ledger und sind fertig.

Artikel 50 des EU AI Act tritt am 2. August 2026 in Kraft. ISO 42001 ist bereits ein Procurement-Gate. Die Compliance-Roadmap ist kein separater Arbeitsstrang, sie ist das, was passiert, wenn Sie Slices liefern.

SliceOps wurde nicht in einer Whiteboard-Sitzung entworfen. Es wurde aus der Produktionsrealität gewonnen, Datta zu bauen (ein branchenübergreifendes Produkt für regulierte Märkte) mit einem kleinen Team und einer Flotte von Claude-Code-Agenten, gemessen an der Ausführungszeit, nicht an der Kalenderzeit.

Mehr als 800 Decision Records, flat-numbered und über den Lifecycle verfolgt. Ein Block, geliefert in vier Kalendertagen über neun atomare Slices, unter seiner Token-Prognose, mit 41 erfassten architektonischen Entscheidungen. Bis zu dreizehn Agenten, die parallel gegen ein Repository laufen. Ein Effizienz-Multiplikator von 2,5×, gemessen am äquivalenten API-Token-Verbrauch.

Das ist Dogfooding. SliceOps ist das System, dem genug vertraut wird, um einen regulierten Banking-Spin-off darauf zu setzen.

Probieren Sie das Framework an einem einzigen Slice in Ihrem nächsten Sprint aus. Deklarieren Sie einen Decision Record für eine Entscheidung, die Sie sonst informell getroffen hätten. Lassen Sie zu Beginn Ihres nächsten Blocks eine Prognose laufen und am Ende eine Retrospektive. Sehen Sie, wie sich die Artefakte anfühlen, und was Ihre Agenten damit tun, wenn sie sie lesen.

Bauen Sie mit Disziplin. Auditieren Sie Ihre Entscheidungen. Behandeln Sie Ihre Agenten so, wie Industrieingenieure ihre Maschinen behandeln: mit Telemetrie, Rückblick und der Annahme, dass das, was nicht gemessen wird, irgendwann kaputtgeht.