Software aus der Fertigungsstraße.
Ein umrissenes Vorhaben in Ihrer Codebasis — ein Feature, ein Refactor, ein Fix. Sie beschreiben, was herauskommen soll; wir fahren unsere Fertigungsstraße darüber und liefern einen Pull-Request auf Ihren Ziel-Branch: geplant, gebaut und über mehrere Modelle gegengeprüft, jeder Lauf von uns begleitet. Gemerged wird bei Ihnen.
Was Sie mitbringen müssen.
Das Angebot setzt zwei Dinge voraus: eine bestehende Codebasis und jemanden bei Ihnen, der den Pull-Request prüft und merged.
Wer eine Idee hat, aber weder Repo noch Entwicklungsteam, wird hier heute nicht bedient — das sagen wir lieber vorher als nach einer Stunde Lektüre. Wenn Sie unsicher sind, ob Ihr Fall dazugehört: schreiben Sie uns, wir sagen Ihnen offen, ob wir passen.
Von Prosa zum geprüften Pull-Request.
Sie beschreiben, was herauskommen 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.
Eine Staffel von Reviewern.
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.
Verlässlich im Parallelbetrieb.
Die Fabrik fährt mehrere isolierte Fertigungsbänder gleichzeitig. Damit wir dabei den Überblick behalten, hält ein kompakter Status-Bus den Stand 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 steckt bei uns in 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 für die Aufgabe.
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 abgesichert.
Ihr Code ist Ihr Kapital. Deshalb bauen wir Vertrauen 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.
Wer Ihren Auftrag fährt.
Andreas Korol, Senior-Entwickler. Er nimmt Ihren Auftrag an, orchestriert die Prüfkette und ist Ihr Ansprechpartner von der ersten Frage bis zum Pull-Request. Kein Ticket-System, kein wechselnder Bearbeiter.
Und wenn er ausfällt?
Der Code liegt in Ihrem Repository. Ihre CI prüft ihn, Sie entscheiden, was übernommen wird. Der gelieferte Code baut und läuft in Ihrer eigenen CI — ohne irgendetwas von uns; Ihre IT kann das selbst nachprüfen. Läuft hier nichts mehr, arbeiten Sie mit jedem anderen Entwickler weiter.
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, keine Rechenzeit: 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 in Ihrer Codebasis — ein Feature, ein Refactor oder ein Fix, 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, ein Refactor oder ein Fix, klar umrissen, mit einer eindeutigen Abnahme-Definition.
Wir liefern
Sie erhalten einen Pull-Request auf Ihr Ziel-Repo — als Vorschlag zu Ihrer Prüfung, der Nacharbeit brauchen kann. 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.
Das Audit der 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, offen benannt.
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, ein Refactor oder ein Fix, 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 Aufgabe, Repo und Kontext ein, wir bringen die Fertigungsstraße ein — und wir schneiden den Umfang gemeinsam zu. Vom einzelnen Piloten bis zur laufenden Zusammenarbeit an Ihrer Codebasis: industrielle Lieferlogik, die Entscheidung bleibt bei Ihnen.