FAQ

Häufige Fragen

Diese Seite beantwortet typische Fragen zu Idee, Nutzen, Architektur, Bedienung und Zielgruppe der Agentic Software Factory.

Gibt es weiterführende technische Hintergrundinformationen zur Softwarefabrik?

Ja. Als Architektur-Deep-Dive gibt es ein eigenes Whitepaper, das die architektonischen Grundlagen agentischer Softwareentwicklung beschreibt: Referenzarchitektur, Agenten-Orchestrierung, AI-Guardrails, Shared Knowledge Stores und die Integration in den Software Development Lifecycle. Es ergänzt diese Produktwebsite um die konzeptionelle Tiefe, auf der die Softwarefabrik aufsetzt. Eine Übersicht findest du auf der Whitepaper-Seite, das PDF (76 Seiten) ist dort kostenlos und ohne Registrierung abrufbar.

Was passiert, wenn ich offline arbeite?

Die Antwort hängt vom Tier ab:

Welche Daten werden an den Lizenzserver übertragen?

Enterprise Air-Gap: keine Datenübertragung, da kein Netzwerk-Kontakt stattfindet. Details im Transparenz-Dokument.

Was sind die Limits der Community-Version?

Funktioniert das im Air-Gap-Netzwerk?

Ja, mit einer Enterprise-Air-Gap-Lizenz.

Welche LLMs unterstützt die Softwarefabrik?

Die LLM-Auswahl ist Kunden-Entscheidung und wird im Client konfiguriert. Für Air-Gap-Betrieb sind nur on-prem-LLMs möglich.

Wie funktioniert die Enterprise-Lizenzierung technisch?

Kann ich zwischen den Tiers wechseln?

Was ist die Agentic Software Factory?

Die Agentic Software Factory ist eine lokale Control Plane für AI-gestützte Softwareentwicklung. Sie verbindet strukturierte Projekterfassung, automatisch erzeugte Markdown-Artefakte, Run-Orchestrierung, Git- und Build-Transparenz sowie nachvollziehbare Freigaben in einer Webanwendung.

Was ist der Hauptunterschied zu Claude Code direkt in der Shell?

Bei direkter Shell-Nutzung müssen Projektdefinition, Leitplanken, Freigaben, Git-Disziplin und Statusüberwachung weitgehend manuell organisiert werden. Die Software Factory macht genau diese Aspekte sichtbar und wiederverwendbar.

Für wen ist die Plattform gedacht?

Primär für Softwarearchitekten, Lead Developer, technische Projektleiter und Teams, die AI-gestützte Entwicklung kontrollierter und reproduzierbarer durchführen wollen. Sie ist nicht als Massen-Consumer-Produkt gedacht, sondern als produktive Arbeitsoberfläche für technische Verantwortungsträger.

Welche Probleme löst die Plattform?

Warum wird mit Markdown-Artefakten gearbeitet?

Dateien wie PROJECT.md oder INSTRUCTIONS.md sind leicht versionierbar, für Menschen lesbar und für AI-gestützte Tools gut nutzbar. Sie bilden den Arbeitsvertrag zwischen Nutzer, Plattform und Agent.

Warum setzt Version 1 auf Spring Boot und Thymeleaf statt auf Angular?

Version 1 soll den Schwerpunkt auf Orchestrierung, Run-Modell, Git-/Build-Integration und Nachvollziehbarkeit legen. Eine serverseitige UI mit Spring Boot und Thymeleaf reduziert Komplexität und macht den Produktkern schneller belastbar.

Ist die Plattform schon ein echtes Multi-Agent-System?

Noch nicht vollständig. Version 1 bereitet Rollen, Teams und Workflow-Strukturen dafür vor, setzt aber zunächst auf einen ausführenden Adapter. Das Ziel ist ein sauberer Ausbaupfad, nicht maximale Komplexität im ersten Schritt.

Welche Agentenrollen sind vorgesehen?

Typisch vorgesehen sind Architect, Developer, Reviewer, QA, Security Reviewer, Documentation und Merge/Release. Diese Rollen können als fachliches Modell gespeichert und später zu Teams zusammengestellt werden.

Wie läuft ein typischer Arbeitsablauf ab?

  1. Projektidee erfassen
  2. Projektfelder ausfüllen
  3. Markdown-Artefakte generieren
  4. Team und Ziel definieren
  5. Run anlegen und starten
  6. Logs, Git und Build prüfen
  7. bei Bedarf Folge-Run oder Korrektur starten

Welche technischen Komponenten gehören zur Plattform?

Welche Informationen sieht man während eines Runs?

Typischerweise Status, aktuelle Phase, Logs, Commit-Historie, Working-Tree-Zustand, Build-Ergebnisse, Freigabeentscheidungen und die zugehörigen Artefakte. Das Ziel ist, dass der Nutzer den Run nicht als Black Box erlebt.

Kann man die Plattform auch ohne Claude Code nutzen?

Ja, jedenfalls konzeptionell. Die Architektur sollte Adapter sauber kapseln. Deshalb kann in frühen Phasen auch mit einem Mock-Adapter oder einem später austauschbaren Ausführungsadapter gearbeitet werden.

Ist die Plattform für Behörden oder regulierte Umfelder geeignet?

Ja, sie ist dafür grundsätzlich gut anschlussfähig, weil sie auf Nachvollziehbarkeit, Struktur, Dokumentation, Git-Disziplin und explizite Freigaben setzt. Die konkrete Härtung und organisatorische Einbettung hängt aber vom späteren Einsatzumfeld ab.

Wie steht es um Sicherheit und Datenschutz?

Die Plattform ist auf datensparsame und nachvollziehbare Nutzung ausgelegt. Wichtige Leitlinien sind: keine Secrets im Code, keine Tokens oder Session-IDs im Log, nachvollziehbare Freigaben, kontrollierte Adapter und klare technische Gates.

Kann ich mehrere Projekte parallel verwalten?

Ja. Genau dafür gibt es Projektdefinitionen, Statusmodelle, Artefaktversionen und Run-Listen. Projekte und Runs sollen unabhängig voneinander nachvollziehbar bleiben.

Wie entsteht Wiederverwendbarkeit?

Durch standardisierte Projektfelder, konsistente Markdown-Artefakte, gespeicherte Agentenrollen, Team-Vorlagen und dokumentierte Freigabe- und Build-Regeln. Dadurch wird aus Einzelerfahrung ein wiederholbarer Prozess.

Wie starte ich am besten?

Am besten mit einem kleinen internen Beispielprojekt, einem klaren Zielbild und dem Mock-Adapter. Erst wenn Wizard, Artefakt-Erzeugung, Run-Modell und Logs sauber funktionieren, sollte der echte Claude-Code-Adapter produktiv eingebunden werden.