Autocomplete beschleunigt das Tippen einzelner Zeilen, verändert aber den Engpass nicht: Verstehen, Prüfen und Ausführen bleiben vollständig beim Entwickler. Der Durchsatz des Teams steigt dadurch kaum.
Kontrollierte agentische Softwareentwicklung
Ihr Auto fährt teilautonom.Ihre Softwareentwicklung nicht.
HEPHAUSTOS baut kontrollierte Software-Fabriken, in denen Coding Agents Aufgaben selbstständig bearbeiten, bauen, testen und reparieren. Für sensible Umgebungen kann die Verarbeitung vollständig lokal stattfinden. Die letzte Freigabe bleibt beim Menschen.
Level 3.5
Autonome Ausführung. Getrennte Prüfung. Menschliches Gate.
Souverän betreibbar. Modellunabhängig. Menschlich freigegeben.
Für wen
Für Teams, die KI-gestützte Entwicklung wollen, aber die Cloud-Tools der anderen nicht einsetzen dürfen.
HEPHAUSTOS richtet sich an Entwicklungsteams in regulierten oder IP-sensiblen Umgebungen. Quellcode darf das Haus nicht verlassen, Compliance schließt die üblichen Cloud-Werkzeuge aus, und die Systeme sind gewachsen statt Greenfield. Genau dort setzt die kontrollierte Fabrik an.
Autonomiestufen
Autonomes Fahren hat Stufen. Autonomes Entwickeln auch.
Die entscheidende Grenze liegt nicht bei mehr Autonomie um jeden Preis, sondern dort, wo Ausführung, Prüfung und Verantwortung sauber getrennt bleiben.
Der generierte Code entsteht ohne Zugriff auf den echten Projektkontext. Übertragung, Anpassung und Prüfung bleiben Handarbeit. Mit jedem Copy-Paste wächst das Risiko, dass Code und Projektzustand auseinanderlaufen.
Der Agent bearbeitet einen zusammenhängenden Arbeitslauf selbstständig. Die Ausführung allein schafft jedoch noch keine vom Agenten getrennte Prüfebene.
Zusätzlich zur autonomen Ausführung existiert eine vom Arbeitsbereich des Agenten getrennte Prüfebene. Geschützte Holdouts und Freigaberegeln können vom Agenten nicht verändert werden. Danach entscheidet ein Mensch über die Übernahme.
Das ist nicht der Zielbereich von HEPHAUSTOS.
Viele Agentenansätze zielen auf maximale Autonomie. HEPHAUSTOS setzt bewusst vorher eine Grenze.
Wie die Factory arbeitet
Vier Schritte. Drei laufen ohne Sie.
Die Factory strukturiert Kontext, führt Aufgaben aus und trennt Prüfmaterial vom normalen Arbeitsbereich des Agenten.
Wissensbasis
Projektdokumentation und strukturierte Quellen werden in ein lokales Wiki überführt. Bereits implementiert ist ein Plugin, das Postman-Collections deterministisch in Wiki-Inhalte übersetzt. Weitere Quellen können über Plugins ergänzt werden.
Werkbank
Ein Markdown-Task startet einen autonomen Arbeitslauf. Der Agent bearbeitet den Code, baut das Projekt, wertet Fehlermeldungen aus und versucht selbstständig Reparaturen. Aider übernimmt die Codebearbeitung; LiteLLM routet die Modellaufrufe.
Verdeckte Schranke
Prüfmaterial und geschützte Holdouts liegen außerhalb des normalen Arbeitsbereichs des Agenten. Dadurch kann der Agent seine Lösung nicht einfach durch Veränderung der Prüfkriterien passend machen.
Freigabe
Ein Mensch prüft und entscheidet. Die Übernahme in Ihr Versionsverwaltungssystem erfolgt bewusst und nach Ihren Regeln. Kein automatischer Commit in ein Kundenrepository.
Was HEPHAUSTOS nicht ist
Keine Tool-Schulung. Eine Fabrik.
Wer Ihnen Copilot oder Claude Code zeigt, macht Ihre Entwickler schneller, aber innerhalb derselben Grenzen. HEPHAUSTOS baut die Ebene darüber.
-
01
LLM-agnostisch
Lokale, selbst gehostete und Frontier-Modelle laufen über dasselbe Gateway und lassen sich unter identischen Fabrikbedingungen austauschen und vergleichen.
-
02
Harness Engineering
Die Fähigkeit steckt nicht im Modell allein, sondern im Harness aus Kontext, Werkzeugen und Feedbackloop.
-
03
Fabrik statt Agent
Ein deterministisch erzeugtes LLM-Wiki auf Basis des von Google Cloud veröffentlichten Open Knowledge Format (OKF), Markdown-Tasks und strukturierte Events schaffen reproduzierbare Produktion statt einzelner Chat-Sitzungen.
-
04
Holdout-Prüfung
Der Agent sieht die Prüfkriterien nie und kann seine Lösung deshalb nicht auf den Test hin optimieren.
-
05
Eskalationsstufen
Löst ein Modell eine Aufgabe nicht autark, eskaliert die Fabrik automatisch innerhalb der vorab freigegebenen Vertrauensgrenze auf stärkere Modellstufen und protokolliert den Wechsel.
PoC 01 / Harness Engineering
Nicht das Modell ist die Factory.
HEPHAUSTOS stellte einem austauschbaren Open-Weight-Modell den relevanten Kontext, kontrollierte Werkzeuge und einen begrenzten Feedbackloop bereit. Der Lauf zeigt, was diese Fabrik unter klar beschriebenen Bedingungen leisten konnte.
Vom API-Vertrag zum laufenden C#-Client, ohne manuellen Eingriff über vier selbstständige Reparaturiterationen.
Dies ist ein technischer Proof of Concept, kein allgemeiner Produktivitätsbenchmark. Die Brownfield-Erprobung ist der nächste, noch offene Nachweis.
Leistungen
Drei Bausteine für kontrollierte Agenten-Loops.
Audit, Ausführung und geschützte Prüfung lassen sich einzeln betrachten, bilden aber gemeinsam die Level-3.5-Architektur.
PROMETHEUS AUDIT
Potenzialanalyse
Analyse von Toolchain, Repository, Build, Tests, Dokumentation, Freigabeprozess, Automatisierungspotenzial sowie Datenschutz- und Betriebsanforderungen.
Ergebnis: Eine belastbare Einschätzung, welche Aufgaben sich sinnvoll in Agenten-Loops überführen lassen und welche nicht.
HEPHAUSTOS ENGINE
Ausführungsinfrastruktur
Aufbau der Infrastruktur für agentische Entwicklungsaufgaben. Modelle werden über ein zentrales Gateway angebunden. Abhängig von den Anforderungen können lokale Modelle oder explizit freigegebene externe Endpunkte eingesetzt werden.
Vertrauensgrenze: Für Umgebungen, in denen Quellcode das Kundennetz nicht verlassen darf, ist ein vollständig lokaler Betrieb vorgesehen.
DAEDALUS SHIELD
Prüfschranken & Governance
Autonome Agenten dürfen ihre eigenen Prüfbedingungen nicht kontrollieren. DAEDALUS trennt geschützte Holdouts, Prüfschritte und Freigaberegeln vom normalen Arbeitsbereich des Agenten.
Ergebnis: Jede Änderung besitzt einen nachvollziehbaren Ausführungs- und Prüfpfad.
Datenschutz & Souveränität
Sie bestimmen die Vertrauensgrenze.
HEPHAUSTOS schreibt kein Betriebsmodell vor. Datenflüsse und Modellendpunkte werden für das jeweilige Projekt bewusst festgelegt.
Vollständig lokal möglich
Quellcode, Dokumentation, Wiki und Modellinferenz können vollständig innerhalb der Kundenumgebung betrieben werden.
Modell-Gateway statt Vendor Lock-in
Die Factory ist nicht an einen einzelnen Modellanbieter gekoppelt. Modellendpunkte werden zentral geroutet und können projektabhängig freigegeben oder gesperrt werden.
Secrets und Holdouts geschützt
Zugangsdaten, geschützte Dateien und Prüfinhalte werden vom normalen Arbeitsbereich des Agenten getrennt.
Nachvollziehbare Runs
Strukturierte Events dokumentieren Modellwechsel, Reparaturversuche sowie Build-, Test- und Ausführungsstatus.
Eskalation innerhalb der Grenze
Löst ein lokales Modell eine Aufgabe nicht autark, kann die Factory automatisch auf stärkere, vorab freigegebene Modellstufen eskalieren. Welche Stufen freigegeben sind, bestimmen Sie. Jede Eskalation bleibt innerhalb Ihrer Vertrauensgrenze und wird protokolliert.
Nächste Erprobung
Vom Greenfield-PoC zur bestehenden Codebasis.
Der erfolgreiche Greenfield-Test belegt den technischen Ablauf unter isolierten Bedingungen.
Als nächster Schritt werden dieselben Verfahren auf einer gewachsenen Codebasis erprobt: Legacy-Software, bestehende Buildstrecke und vorhandene Freigaberegeln. Dieser Brownfield-Test ist noch kein abgeschlossener Nachweis.
So starten wir
Technische Einordnung vor Infrastruktur.
-
01
Gespräch
30 Minuten zur Ausgangslage, den Systemgrenzen und dem konkreten Entwicklungskontext.
-
02
Audit
Toolchain, Aufgabenklassen, Datenflüsse, Prüf- und Freigaberegeln werden technisch bewertet.
-
03
Abgegrenzter Lauf
Ein kontrollierter Aufgabenbereich dient als erster überprüfbarer Einsatzfall.
-
04
Übergabe
Infrastruktur, Dokumentation und Freigabeprozess bleiben nachvollziehbar betreibbar.
Entwickelt von
Christian Binder
Wer dahintersteht
Senior Software Engineer & Applied AI Engineer
Ich entwickle seit rund 20 Jahren produktive Softwaresysteme und arbeite seit 2019 selbstständig. Mein Hintergrund liegt in .NET-/Enterprise-Entwicklung, Legacy-Integration, datenintensiven Systemen, CI/CD und Applied AI. HEPHAUSTOS entstand aus der Frage, wie Coding Agents in genau den Umgebungen zuverlässig eingesetzt werden können, in denen ein Demo-Repository nicht ausreicht.
Mehr über Christian BinderHEPHAUSTOS verbindet Hephaistos, den göttlichen Schmied und Erbauer technischer Helfer, mit Faust, der nicht aufhören konnte zu fragen.
Häufige Fragen
Was vor dem ersten Einsatz geklärt werden muss.
Ein Agent kann Änderungen erzeugen und selbstständig reparieren. Diese Änderungen werden aber nicht automatisch in das Kundenrepository übernommen. Prüfungen und menschliche Freigabe liegen zwischen Agent und Übernahme.
Nein. HEPHAUSTOS unterstützt vollständig lokale Modellinferenz. Wenn ein Projekt externe Modelle erlaubt, können freigegebene Endpunkte über das zentrale Modell-Gateway verwendet werden. Welche Daten die Vertrauensgrenze verlassen dürfen, wird bewusst festgelegt.
Lokale Modelle sind interessant, wenn Sourcecode oder Systemwissen die eigene Umgebung nicht verlassen dürfen. Leistungsfähigere externe Modelle können dort eingesetzt werden, wo Richtlinien und Projektanforderungen das erlauben. HEPHAUSTOS soll diese Entscheidung nicht vorwegnehmen, sondern technisch kontrollierbar machen. Die Fabrik kann dabei automatisch eskalieren: zuerst lokal und nur wenn nötig innerhalb der von Ihnen vorab freigegebenen Stufen auf leistungsfähigere Endpunkte. Jede Eskalation bleibt innerhalb der Vertrauensgrenze und wird protokolliert.
HEPHAUSTOS entfernt die menschliche Verantwortlichkeit nicht. Änderungen werden vor der Übernahme freigegeben. Die konkreten vertraglichen Verantwortlichkeiten werden wie bei anderen Entwicklungsprojekten im jeweiligen Auftrag geregelt.
HEPHAUSTOS richtet sich an Umgebungen, in denen eine Änderung nicht allein deshalb produktiv gehen darf, weil ein Agent sie für fertig hält. Deshalb endet die Automatisierung vor der endgültigen menschlichen Freigabe.
Genau dort sind strukturierter Kontext, reproduzierbare Builds und explizite Freigaberegeln besonders wichtig. Die Eignung einzelner Aufgaben wird vorab im Audit geprüft; eine bestehende Codebasis ist der nächste geplante Erprobungsschritt.
Technisches Erstgespräch
Wenn Ihre Entwicklung sich anfühlt wie Handarbeit, dann ist sie es noch.
30 Minuten. Technische Einordnung statt Produktdemo.