Software aus der Fertigungsstraße.
Sie beschreiben die Produktabsicht in Prosa. Unsere KI-Fertigungsstraße macht daraus geprüfte Software — geplant, gebaut, mehrfach gegengeprüft und als Pull-Request in Ihrem Repo zur Freigabe. Gemerged wird bei Ihnen.
Von Prosa zum geprüften Pull-Request.
Ein Mensch beschreibt, was das Produkt leisten soll. Daraus entsteht ein maschinenlesbarer Vertrag — Ziele, Grenzen, Akzeptanzkriterien. Die Umsetzung läuft in kleinen Bauschritten durch harte Gates. Jede kritische Stufe prüft ein anderes Modell, bevor Code in den Merge darf.
Mehr als ein Reviewer — eine Staffel.
Schon vor dem Bauen prüft ein deterministisches Code-Gate den Planvertrag — jeder Baustein muss seine Inputs und Outputs sauber auflösen, ohne Orphans, ohne Vorwärtsreferenzen, ohne LLM-Ermessensspielraum. Wo es um Korrektheit statt Urteil geht, gewinnt das harte Gate gegen die Wahrscheinlichkeit.
Jeder Bauschritt durchläuft mehrere Rollen mit wachsendem Blickwinkel: ein Qualitäts-Scan, dann mehrere adversariale Runden über bewusst diverse Modelle — von verwandten Modellen einer Familie über fremde Anbieter bis zu externen Cloud-Bots —, und zum Abschluss ein Integrations-Architekt. Cross-Layer-Änderungen bekommen einen zweiten Architekten-Durchlauf obendrauf.
Danach laufen die Tests. Jede Änderung wird nach Art und Tragweite klassifiziert (Surface-Klasse) und nimmt dynamisch die passende Route durch die Pipeline: eine kleine Textänderung den kurzen Weg, eine sicherheitskritische den langen mit zusätzlichen, gestaffelten Prüf-Runden. Genau diese Modell-Diversität ist tragend, nicht dekorativ: verschiedene Systeme sehen verschiedene Fehler.
Skaliert verlässlich, nicht nur schnell.
Die Fabrik fährt mehrere isolierte Fertigungsbänder gleichzeitig — unbeaufsichtigt, aber nicht unkontrolliert: ein kompakter Status-Bus hält den Überblick ohne Log-Flut, und ein fail-closed Abgleich lässt nur ein echtes, geprüftes Ergebnis als „fertig" gelten. Gescheiterte Läufe werden gesichert und aufgearbeitet — nie still verworfen.
Aus Reibung werden Regeln.
Jeder Lauf hinterlässt mehr als ein Produkt: aus Reibung werden Lehren, aus Lehren werden maschinenlesbare Betriebs-Regeln, die jeden folgenden Lauf steuern. Die Regel-Basis wächst mit jedem Lauf, und die Straße wird besser, ohne dass sich das Modell dafür ändern muss.
Entscheidungen unter Gegenstimmen.
Wird der Orchestrator bei einer Architektur- oder Taktik-Entscheidung unsicher, rät er nicht — gekoppelt an seine eigene Konfidenz holt er ein Gremium unabhängiger Modelle hinzu, das abstimmt; bei Patt eskaliert es selbsttätig in eine weitere Runde. Der Aufwand wächst mit der Tragweite — vom schnellen Cross-Check bis zur breit-diversen Runde. Unsicherheit wird nicht versteckt, sondern ausgespielt.
Vielfalt mit Methode.
Effizienz ist bei uns kein nachträgliches Sparprogramm, sondern Teil der Bauweise der Straße. Eine gute Fertigungsstraße setzt jede Ressource genau dort ein, wo sie zählt — und vergeudet kein Material.
Das richtige Modell, nicht das teuerste.
Wir setzen gezielt verschiedene Modelle ein — jedes dort, wo es am stärksten ist, nach Eignung statt nach Preisschild. Grundlage ist keine Annahme, sondern ausführliche Modell-Evaluation pro Rolle und Aufgabe.
Prompts auf den Punkt.
Jede Rolle arbeitet mit einer präzise zugeschnittenen Arbeitsanweisung — exakt für ihre Aufgabe, ohne Kontext-Ballast. Klare Instruktion statt mitgeschlepptem Rauschen.
Stetig besser.
Kontext und Memory werden kontinuierlich verfeinert — leise, im Hintergrund. Mal nach Stunden, mal nach Tagen: klarere Übergaben, weniger Reibung, besser nutzbares Wissen aus den vorherigen Schritten.
Vier Säulen, die ineinandergreifen.
Rollen
Der Mensch verantwortet Konzept, Priorität und Richtung; die Maschine die disziplinierte Ausführung.
Verträge
Produktabsicht wird in maschinenlesbare Vorgaben übersetzt — Bau und Prüfung laufen auf derselben Grundlage.
Gates
Plan, Bau, Audit und Merge laufen über feste Prüfpunkte mit eindeutigen Bestehen-Kriterien — deterministisch ausgewertet, nicht nach Einschätzung einer KI.
Modell-Diversität
Kein Modell prüft seine eigene Arbeit: kritische Gegenprüfungen laufen bewusst provider- und modellübergreifend.
Vertrauen mechanisch — nicht per Zusage.
Ihr Code ist Ihr Kapital. Deshalb bauen wir Vertrauen nicht in Versprechen, sondern in die Fertigungsstraße selbst: Jeder Lauf ist pro Kunde dateisystem-getrennt, läuft in einer netz-dichten Zelle und endet in genau einem Pull-Request, den Ihr Team prüft und merged. Was mechanisch abgesichert ist, sagen wir; was noch fehlt, auch.
Netz-dicht — und per Canary bewiesen.
Jeder Befehl und jeder Datei-Zugriff des Agenten läuft in einer abgeschotteten Zelle ohne Netzausgang: frisches Netz-Namespace, geleerte Umgebung, nur-lesbare Werkzeuge, keine sensiblen Zugangspfade eingebunden. Die Dichtheit ist kein Versprechen, sondern geprüft — mit einem Canary, einer markierten Zeichenfolge, die gezielt auszubrechen versucht und nachweislich nirgends ankommt. Der Test ist jederzeit wiederholbar.
Nur ein PR — Ihr Merge ist der Gate.
In der abgeschotteten Bau-Zelle laufen Befehle und Datei-Zugriffe ohne Netz und ohne Zugangsdaten — dort kann nichts in Ihre Systeme geschrieben werden. Den fertigen Diff übergibt die Zelle an einen separaten, vertrauenswürdigen Abschluss-Schritt außerhalb der Sandbox. Nur dieser besitzt ein Token — ein von Ihnen ausgestelltes, minimal berechtigtes (nur Ihr Ziel-Repo, nur Branch + Pull-Request, ablaufend) — und nutzt es ausschließlich, um den Branch zu pushen und einen Pull-Request zu öffnen. Mergen kann er nicht; das entscheiden Sie.
Pro Kunde abgeschottet — mit abbrechendem Wächter.
Jeder Lauf-Zustand — Bau-Verzeichnis, Logs, Audit, Zugangsdaten — liegt unter einem eigenen Mandanten-Root. Vor jedem Lauf prüft ein mechanischer Wächter, dass Arbeitskopie, Logs, Audit und Ziel unter demselben Kunden-Bereich liegen. Bei jedem Quer-Bezug bricht er ab und protokolliert die Abweisung.
Ehrlich benannt.
Für die Denk- und Modell-Aufrufe verlässt Code die Zelle: Code-Ausschnitte und Aufgabenkontext gehen an Anthropic und OpenAI — nie an Ihre Systeme. Das ist der Kern des Verfahrens, und wir sagen es offen. Auf allen Anbieter-Konten ist das Training deaktiviert (aktiv gesetztes, überprüfbares Opt-out); die Aufbewahrungsdauer legen wir pilot-spezifisch transparent offen.
Eine Rechenart. Offen gerechnet.
Auf den gemessenen Aufwand legen wir einen festen, offen genannten Faktor — und schreiben nichts obendrauf: keine zweite Rechnung für Management oder Orchestrierung. Zuschnitt, Prüfrunden und Freigabe stecken in diesem Faktor. Die Rechenart steht fest, bevor wir starten; der Betrag folgt dem gemessenen Aufwand.
So entsteht Ihr Preis.
Der Preis ergibt sich aus dem verifizierten Fertigungsaufwand Ihres Projekts: gemessen am tatsächlichen Token-Verbrauch je Modell, bewertet zu aktuellen API-Preisen, multipliziert mit einem festen Faktor — verifizierter Fertigungsaufwand × 3. Sie kaufen ein Ergebnis; der Verbrauch ist das Maß, nicht die Ware.
Sicherheitskritische Auth-Umstellung
Selbstregistrierung, E-Mail-Verifikation und Passwort-Reset — inklusive Sitzungs-Entwertung beim Zurücksetzen, gedrosselter Anfragen und Mails in zwei Sprachen.
~€1.400 · ~2 Tage
Zahlungsanbieter-Anbindung
Abos, Sitzplatz-Grenzen und Webhooks beim Zahlungsanbieter; USt-ID gegen das Steuerland abgeglichen; Buchungs- und Buchhaltungs-Export bis zur geprüften Abrechnung.
~€3.300 · ~3 Tage
Bugfix mit Refactoring und Testabdeckung
Ein klar umrissener Fix, der die Ursache aufräumt statt sie zu überkleben — samt Tests, durch dieselben Prüfpunkte wie alles andere.
~€280 · am selben Tag
Vom Gespräch zum geprüften Pull-Request.
Sie beauftragen uns mit einer klar abgegrenzten Aufgabe — ein Feature oder ein Refactor, einzeln beauftragt und klar abgenommen. Nach der Abnahme entscheiden Sie frei, ob und wie es weitergeht.
Gespräch
Wir klären gemeinsam Aufgabe, Repo, Ziel-Branch und Ihre Anforderungen — technisch, sicherheitsseitig, rechtlich.
Umfang festlegen
Ein Feature oder Refactor, klar umrissen, mit einer eindeutigen Abnahme-Definition.
Wir liefern
Sie erhalten einen Pull-Request auf Ihr Ziel-Repo — als Vorschlag zu Ihrer Prüfung, nicht als fertiges Ergebnis. Und auf Anfrage das Audit der Freigabe- und Abweisungs-Entscheidungen (siehe unten).
Sie entscheiden
Sie prüfen, mergen und entscheiden über eine Fortsetzung. Was noch fehlt, benennen wir offen.
Nicht nur das Ergebnis — auch die Entscheidungen.
Auf Anfrage erhalten Sie den Audit-Bericht zu Ihrem Mandanten: welche Aufgaben ein Verantwortlicher freigegeben und für die netz-dichte Zelle bestimmt hat — und welche vor dem Bau abgewiesen wurden, mit dem Prüfpunkt im Klartext, etwa „Ziel außerhalb des freigegebenen Umfangs" oder „nicht freigegebene Instruktionsdatei im Arbeitsverzeichnis". Gelesen wird strikt aus Ihrem Mandanten-Bereich: ein Pfad, der dort hinausführt, bricht den Bericht ab, statt ihn zu füllen.
Und was dieser Bericht nicht ist, sagen wir gleich mit. Er enthält keinen Fließtext der Reviewer — gerendert wird ausschließlich eine feste Liste bekannter Felder, damit nichts herausfällt, was Sie nichts angeht. Er ist ein Protokoll der Entscheidungen, keine lückenlose Ereignis-Bilanz: dass eine Aufgabe freigegeben wurde, heißt, dass sie freigegeben wurde — nicht, dass danach alles durchgelaufen ist. Und die Netz-Dichtheit steht darin als Nachweis über die Bauweise (route-lose Zelle, per Canary geprüft), nicht als Liste einzelner abgewehrter Verbindungsversuche — die ist geplant, und bis sie da ist, behaupten wir sie nicht. Was bleibt, ist das, wofür Sie ihn lesen: er führt Sie an die Stellen, an denen etwas abgewiesen wurde, bevor Sie die erste Zeile des Diffs aufschlagen.
Ihre Review-Zeit — benannt, nicht weggerechnet.
Der Betrag auf der Rechnung misst unseren Aufwand. Ihrer steht nicht darauf, und er ist trotzdem real: jemand aus Ihrem Team liest den Pull-Request und verantwortet den Merge. Das nehmen wir Ihnen nicht ab — der Merge ist Ihr Gate, und genau das ist der Punkt.
Was wir tun, ist die Prüfung klein zu halten. Der Zuschnitt ist eng: ein Feature oder ein Refactor, einzeln beauftragt, mit einer eindeutigen Abnahme-Definition — kein Sammel-PR über drei Themen.
Was wir nicht tun: Ihnen eine Stundenzahl versprechen. Wir messen Ihre Review-Zeit nicht und haben keine belastbare Zahl dazu; wer Ihnen an dieser Stelle eine nennt, hat sie erfunden. Messen Sie sie im Piloten selbst — genau dafür ist ein Pilot klein und einzeln beauftragt: Sie bekommen Ihre eigene Zahl, bevor Sie über mehr entscheiden.
Lassen Sie uns zusammenarbeiten.
Sie bringen Produktabsicht und Kontext ein, wir bringen die Fertigungsstraße ein — und wir schneiden den Umfang gemeinsam zu. Vom Piloten über das komplette Produkt bis zur laufenden Produkt-Partnerschaft: enge Zusammenarbeit mit industrieller Lieferlogik, die Entscheidung bleibt bei Ihnen.