Factory AI: Was Droids für Entwicklerteams leisten

Was ist Factory AI?

Factory ist eine Plattform für Softwareentwicklung. Ihre Agenten heißen Droids: Sie können ein Repository untersuchen, einen Plan vorschlagen, Dateien ändern, Prüfungen ausführen und einen Pull Request vorbereiten – also ein prüfbares Änderungspaket, das anschließend in die Codebasis übernommen wird. Der Zugang erfolgt über das Terminal, eine integrierte Entwicklungsumgebung (IDE) oder die Desktop- und Weboberflächen von Factory. „Agent-native development“ bedeutet, ein Ergebnis vorzugeben und die ausgeführte Arbeit zu prüfen, statt jede einzelne Änderung anzufordern. Das Produkt verbindet Modelle und Entwicklungswerkzeuge. Es ist weder eine neue Programmiersprache noch ein Modell, das selbst trainiert werden muss. Diesen Funktionsumfang beschreibt die Produktseite von Factory.

Geprüft am 21. Oktober 2026 anhand der aktuellen Preisübersicht und Dokumentation von Factory. Diese Bewertung stützt sich auf die Dokumentation, ausgearbeitete Anwendungsbeispiele und Kostenrechnungen. Ein Coding-Benchmark oder eigener Praxistest wurde nicht durchgeführt.

Für wen lohnt sich Factory – und wann reicht der bisherige Agent?

Factory passt zu Entwicklungsverantwortlichen, die Aufgaben einheitlich delegieren möchten, obwohl das Team unterschiedliche Editoren nutzt. Ebenso interessant ist die Plattform, wenn sich der Modellanbieter wechseln lassen soll, ohne sämtliche Arbeitsabläufe neu aufzubauen. Weniger überzeugend ist sie für Gründer, deren bisheriger Agent Repository, Tests und Review-Prozess bereits mit wenig Aufsicht bewältigt.

Auf die engere Auswahlliste gehören Anthropic Claude Code, der Entwicklungsagent von Anthropic, OpenAI Codex, der Coding-Agent von OpenAI, sowie Cursor als Editor und Agentenplattform. Entscheidend im Vergleich ist, was sich durch den Kauf im Arbeitsalltag tatsächlich ändert.

Das sind Einschätzungen zur Kaufentscheidung, keine Benchmark-Ranglisten. Claude Code, Codex und Cursor bieten bereits mehr als ein einzelnes Chatfenster oder Terminal. Mehrere Oberflächen allein verschaffen Factory keinen Vorsprung.

Factory AI vs Claude Code: Wann lohnt sich die zusätzliche Plattform?

Factory ist einen Blick wert, wenn Claude-Modelle eine Option innerhalb eines umfassenderen Workflows sein sollen. Claude Code ist die einfachere Wahl, wenn im Unternehmen bereits brauchbare Anweisungen, Integrationen und Review-Verfahren dafür bestehen. Ein Claude-Modell in Droid zu nutzen, bildet Claude Code nicht nach: Werkzeuge, Kontextauswahl und Ausführungsverhalten werden vom jeweiligen Agentenprodukt bestimmt.

Ein Beispiel: In einem Team arbeiten die Backend-Entwickler mit JetBrains und die Frontend-Entwickler mit Cursor. Factory könnte hier eine gemeinsame Wartungswarteschlange übernehmen. Das wäre ein schlüssiger Grund, die Plattform hinzuzunehmen. Eine beeindruckende Demo mit einem anderen Modell ist dagegen kein guter Grund, alle zum Wechsel zu bewegen.

Factory vorerst auslassen, wenn das Hauptproblem unklare Anforderungen, unzuverlässige Tests oder Pull Requests sind, die niemand prüft. Diese Probleme begrenzen auch Droids. Claude Code, Codex oder Cursor können bleiben, während die Aufgaben besser überprüfbar werden. Der Vergleich Codex vs Claude Code behandelt diese engere Auswahl; die Übersicht der KI-Coding-Agenten ordnet das breitere Angebot ein.

Die folgende Bewertung orientiert sich an vier Kriterien: Qualität des Kontexts, Kontrolle über die Ausführung, Kontinuität zwischen den Oberflächen und Kosten bis zur angenommenen Änderung.

Factory AI Droid: Im vertrauten Editor Aufgaben klar eingrenzen

Factory Droid lässt sich im vorhandenen Editor nutzen. Ein kleiner Pilot ist dadurch ohne Editorwechsel möglich. In VS Code, Cursor und Windsurf stellt die Integration die aktive Datei, markierten Text, offene Dateien und Diagnosen bereit, also die Fehler- und Warnmeldungen des Editors. Auch die native Diff-Ansicht wird unterstützt. Dazu droid im integrierten Terminal starten und anschließend mit /ide die Verbindung prüfen. Die Einrichtung beschreibt Factorys Dokumentation zur IDE-Integration.

Angenommen, ein Backend-Verantwortlicher möchte ändern, wie eine Anwendung Kontoberechtigungen prüft. „Auth refaktorieren“ ist dafür keine brauchbare Aufgabenbeschreibung. Hilfreicher ist: alle Aufrufstellen ermitteln, das bisherige Verhalten für bestehende Nutzer beibehalten, die Reihenfolge der Migration vorschlagen und Tests benennen, die eine unbeabsichtigte Änderung der Zugriffsrechte erkennen würden.

Damit erhält der Agent klare Grenzen, und der Reviewer hat konkrete Kriterien, anhand derer er das Ergebnis ablehnen kann. Ein umfangreicher Diff allein belegt noch keine korrekte Migration.

Wie arbeitet Factory AI mit einer Spezifikation?

Factorys Spec Mode trennt Analyse und Planung von der Umsetzung. Der Agent liest den relevanten Kontext und schlägt einen Plan vor, bevor er um Freigabe bittet. In der CLI wechselt Shift+Tab zwischen Normal und Spec Mode. Die Autonomiestufe ist eine davon unabhängige Einstellung: Sie bestimmt, welche Aktionen ohne weitere Bestätigung ausgeführt werden dürfen. Die Dokumentation zum Modus grenzt beides ausdrücklich voneinander ab.

Bei der Berechtigungsmigration sollte der erste Schritt im Spec Mode erfolgen. Der Plan muss betroffene Dateien, Annahmen zur Kompatibilität und Prüfschritte benennen. Schlägt er Änderungen an Zugriffsregeln vor, ohne zu erklären, wie das bestehende Verhalten erhalten bleibt, ist er abzulehnen. Erst wenn diese Entscheidungen geklärt sind, sollte die Umsetzung freigegeben werden.

Ein praktikabler Ablauf:

1. Droid die Einstiegspunkte der Berechtigungsprüfung und die relevanten Tests suchen lassen.
2. Einen Plan anfordern, der das bisherige Verhalten beibehält und unklare Anforderungen benennt.
3. Den Plan prüfen und anschließend eine Autonomiestufe wählen, die zum erlaubten Arbeitsumfang passt.
4. Diff und Testergebnisse kontrollieren, bevor der Pull Request geöffnet oder angenommen wird.

Der Vorteil liegt im Prüfschritt, bevor der Agent größere Mengen Code erzeugt. Die Grenze: Auch ein plausibler Plan kann falsch sein. Abnahmekriterien müssen das Verhalten der Anwendung erfassen; vorhandene Tests allein reichen nicht.

Hinzu kommt eine Einschränkung je nach Editor: Laut Factory übermittelt die JetBrains-Integration offene Dateien, Markierungen und Diagnosen nicht automatisch und bietet keine nativen Droid-Diffs. Ein Rollout in einem Team mit unterschiedlichen Editoren muss diesen Unterschied berücksichtigen. Die Erfahrung aus VS Code lässt sich nicht einfach auf alle übertragen.

Modelle wechseln, ohne den Workflow neu aufzubauen

Factory ermöglicht die Auswahl zwischen Modellfamilien, während Droid-Oberfläche und Aufgabenstruktur erhalten bleiben. Das ist hilfreich, wenn ein Team Aufgaben einheitlich delegieren möchte, ohne jeden Arbeitsablauf an einen einzigen Modellanbieter zu binden.

Der aktuelle Modellkatalog von Factory führt unter anderem auf:

• Anthropic Claude Opus 5.5 und Claude Sonnet 5.5.
• OpenAI GPT-6.1 Sol und GPT-6 Astra.
• Google Gemini 3.1 Pro und xAI Grok 4.7.
• Offene Modelle wie Mistral Large 4, Kimi K3 und DeepSeek V4.1 Flash.

Das ist eine Auswahl unterstützter Modelle, keine Qualitätsrangliste. Ebenso wenig bedeutet sie, dass die Richtlinien jedes Kontos jedes Modell zulassen.

Als Beispiel eignet sich eine Warteschlange mit Abhängigkeitsupdates. Jedes Modell erhält dieselbe Änderung, dieselben Testanweisungen und dieselben Fertigstellungskriterien. Erfasst wird, ob das Update abgeschlossen wird, ob die Prüfungen bestehen und wie oft ein Reviewer eingreifen muss. Ein Modell mit geringerem Betreuungsbedarf kann einen höheren Verbrauch rechtfertigen. Ein günstigeres Modell, das wiederholt fehlschlagende Tests hinterlässt, möglicherweise nicht.

Aufgabe und Umgebung sollten beim Vergleich unverändert bleiben. Werden Modell, Repository-Anweisungen und Autonomiestufe gleichzeitig geändert, lässt sich das Ergebnis nicht mehr sinnvoll einordnen. Factorys Katalog enthält unterschiedliche Nutzungsmultiplikatoren und Reasoning-Einstellungen. „Gleich viele Prompts“ ist deshalb keine verlässliche Grundlage für einen Verbrauchsvergleich.

Bring your own key (BYOK) bedeutet, eigene Zugangsdaten zu einem Modellanbieter oder einen kompatiblen Endpunkt einzurichten. Factory unterstützt persönliche benutzerdefinierte Modelle, auch mit lokaler Konfiguration. Die BYOK-Dokumentation nennt jedoch eine wichtige Grenze: Diese persönlichen Modelle stehen in der CLI und Desktop-App zur Verfügung, nicht in den gehosteten Web- oder Mobiloberflächen.

Für die Kaufentscheidung heißt das: Factory kann den Modellwechsel innerhalb eines Workflows erleichtern. Trotzdem muss geprüft werden, ob das gewünschte Modell auf der Oberfläche verfügbar ist, über die die Arbeit ausgeführt werden soll. Ein erfolgreicher Pilot mit einem lokalen Modell belegt nicht automatisch, dass die Delegation über das Web funktioniert.

Desktop und Web erleichtern die Prüfung delegierter Arbeit

Factorys Desktop-App ist nützlich, wenn Ergebnisse direkt neben der Unterhaltung visuell geprüft werden sollen. Die Produktseite nennt Vorschauen für Code-Diffs, Dokumente, Präsentationen, Tabellen, PDFs und laufende Websites. Kommentare lassen sich an Codezeilen oder ausgewählten Elementen hinterlegen. Die App ist für macOS und Windows verfügbar. Factory Desktop beschreibt außerdem die Fortsetzung von Sitzungen über Desktop, Web, Mobilgeräte und CLI hinweg.

Für einen technisch versierten Gründer, der eine Kontoeinstellungsseite ändern möchte, ergibt sich ein einfacher Ablauf: das gewünschte Verhalten beschreiben, das gerenderte Ergebnis ansehen, Feedback am betreffenden Element hinterlegen und die Codeänderungen vor der Veröffentlichung prüfen. Visuelles Feedback hilft, eine Anforderung wie „Diese Fehlermeldung gehört neben das E-Mail-Feld“ eindeutig zu verorten. Es belegt aber weder, dass der Server eine ungültige Änderung ablehnt, noch, dass die Einstellungen anderer Nutzer unzugänglich bleiben.

Diese Unterscheidung ist beim Delegieren wichtig. Die Oberfläche kann von einer anderen Person freigegeben werden als das Anwendungsverhalten. Verlangt werden sollten deshalb sowohl die sichtbare Änderung als auch Nachweise dafür, dass das zugrunde liegende Verhalten funktioniert. Eine überzeugende Vorschau darf nicht das einzige Fertigstellungskriterium sein.

Factory nennt außerdem Konnektoren für Tools wie GitHub, Linear, Slack und Sentry. Sie können freigegebenen Kontext bereitstellen. Ein angebundenes Ticketsystem macht ein unklar formuliertes Ticket jedoch nicht präziser. Die Aufgabe braucht weiterhin eine verantwortliche Person, einen definierten Umfang und ein klares Ergebnis.

Bei der entfernten Ausführung kommt eine weitere Unterscheidung hinzu: Die Oberfläche zur Prüfung der Arbeit ist nicht der Rechner, auf dem sie läuft. Von Factory verwaltete Droid Computers sind persistente Umgebungen. Dateien, installierte Pakete, Dienste und Konfigurationen bleiben über Sitzungen hinweg erhalten. Für einen bereits selbst verwalteten Rechner dokumentiert Factory eine gesonderte Option namens Remote Control. Die Dokumentation zu Droid Computers beschreibt beide Möglichkeiten.

Ein dauerhafter Zustand ist hilfreich, wenn die Einrichtung aufwendig ist. Er braucht aber auch einen Verantwortlichen. Factory weist ausdrücklich darauf hin, dass ein Neuaufbau einer Umgebung (Environment) keinen Droid Computer aktualisiert, der zuvor aus dessen Snapshot erstellt wurde. Plattformverantwortliche sollten deshalb den Zustand des Rechners prüfen, bevor sie einen erfolgreichen Lauf als andernorts reproduzierbar ansehen.

KI-Softwareentwicklung automatisieren: Mit einer wiederholbaren Aufgabe beginnen

Factory wird interessanter, wenn Droid eine klar definierte Warteschlange abarbeitet, ohne dass ein Entwickler jede Unterhaltung manuell starten muss. Droid Exec ist der Modus für die Ausführung ohne interaktive Oberfläche: Ein nicht interaktiver Befehl erledigt eine Aufgabe und liefert eine Ausgabe für ein Skript oder ein System zur kontinuierlichen Integration (CI). Standardmäßig arbeitet er nur lesend. Änderungen und weitergehende Befehle erfordern ausdrückliche Autonomieeinstellungen. Die Exec-Dokumentation behandelt Ausgabeformate, Arbeitsverzeichnisse und isolierte Git-Worktrees.

Ein guter erster Workflow ist eine Repository-Analyse, deren Befunde ein Maintainer überprüfen kann. Nach Installation und Anmeldung bei Droid lässt sich folgender Befehl in einem Repository ausführen:

droid exec --output-format json \
  "Identify exported functions without direct test coverage. Return file paths, the evidence for each gap, and suggested test cases. Do not edit files."

Das ist ein Beispielaufruf, kein für diese Bewertung durchgeführter Testlauf. Er belegt für sich genommen keine Testabdeckung: Dynamische Aufrufe, Integrationstests und generierter Code können eine einfache Schlussfolgerung verfälschen. Die Ausgabe liefert dem Maintainer eine Liste möglicher Aufgaben zur Prüfung.

Im nächsten Schritt kann Droid eine freigegebene, klar eingegrenzte Teständerung auf einem eigenen Branch oder Worktree umsetzen und anschließend die Prüfungen des Repositorys ausführen. Die Abnahme muss unabhängig von der Beschreibung des Agenten erfolgen. Ob die Aufgabe abgeschlossen ist, sollten CI-Ergebnis und Reviewer entscheiden.

Eine leicht übersehene Automatisierungsgrenze: Eine wirksame Befehlsrichtlinie mit ask verlangt auch bei der Autonomiestufe High eine Freigabe. Ein einmalig ausgeführter Job kann diese interaktive Zustimmung nicht einholen. Eine höhere Autonomiestufe bringt einen blockierten Automatisierungslauf daher nicht zwangsläufig weiter. Mit dem dokumentierten Befehl droid rules check lassen sich Richtlinienentscheidungen vor der Ausführung prüfen. Das ist eine Konfigurationsfrage, die gezielt gelöst werden muss, kein Anlass, sämtliche Berechtigungsprüfungen abzuschalten.

Für umfangreichere Aufgaben koordiniert Mission Mode Worker und Validierung. Voraussetzung ist die Autonomiestufe High oder die dokumentierte unsichere Übersteuerung. Bei Einzeltarifen können Missions an Nutzungslimits pausieren. Bevor eine große Migration ohne Aufsicht zugesagt wird, sollten gewöhnliche, klar abgegrenzte Aufgaben den Anfang machen.

Der Nutzen liegt in der Wiederholbarkeit: stets derselbe Aufgabeneingang, dieselben Berechtigungsgrenzen und dieselben prüfbaren Nachweise. Die Grenze liegt in der Verantwortung für den Betrieb. Jemand muss Abhängigkeiten, Zugangsdaten, Aufgabenumfang und Fehlerbehandlung pflegen. Wenn diese Betriebsebene wichtiger ist als die einzelne Coding-Sitzung, hilft als Nächstes der Vergleich der Software-Factory-Plattformen.

Factory AI: Kosten und Tarife passend zum Workflow

Factory Teams ist die naheliegende Wahl für kleine Teams, die eine zentrale Abrechnung benötigen. Business wird relevant, wenn es um ein vertraglich geregeltes gemeinsames Nutzungskontingent, Identitätsverwaltung oder administrative Richtlinien geht. Der Wechsel von einem Einzeltarif zu Teams umfasst diese Funktionen nicht automatisch.

Die folgenden monatlichen Konditionen stammen von Factorys aktueller Preisseite, geprüft am 21. Oktober 2026:

Die Preisseite nennt keine Tokenkontingente. Die Nutzung wird ausschließlich als Vielfaches von Pro angegeben. Daraus ergeben sich weder garantierte Aufgabenzahlen noch eine belastbare Umrechnung in angenommene Pull Requests. Die Dokumentation zu Organisationstarifen stellt klar: Jeder Teams-Platz hat die Nutzungslimits von Pro. Business und Enterprise bieten gemeinsame Nutzung nach den jeweiligen Vertragsbedingungen.

Fünf Teams-Plätze kosten $260 im Monat: $60 + 5 × $40. Zehn kosten $460. Würde ein Team mit fünf Plätzen hypothetisch in einem Monat 20 Pull Requests von Droid annehmen, läge der reine Abonnementanteil bei $13 pro angenommenem Pull Request. Das ist eine Rechnung, keine Kapazitätsprognose. Für einen Gesamtkostenvergleich kommen zusätzliche Nutzung, Rechenressourcen und Review-Zeit hinzu.

Oft liegt das Problem darin, dass der Tarif den vorgesehenen Workflow nicht abdeckt. Pro bietet nicht die unter Business aufgeführten Unternehmensfunktionen. Teams wird nicht mit dem Plus-Nutzungsumfang für jeden Platz beworben. Zudem ordnet die Dokumentation für Einzeltarife verwaltete Droid Computers Pro zu, während die kommerzielle Preisseite sie erst ab Plus nennt. Für die Budgetplanung sollte die Preisseite maßgeblich sein. Bevor der Workflow auf verwaltete Rechenressourcen angewiesen ist, muss der tatsächliche Leistungsanspruch geklärt werden.

Welche Grenzen können den Rollout stoppen?

Die folgenreichsten Einschränkungen von Factory betreffen Unterschiede zwischen Oberflächen und Tarifen. Sie können einen Rollout verhindern, selbst wenn eine einzelne Coding-Sitzung überzeugt.

Unterstützte Editoren bieten nicht dieselben Funktionen. Bei JetBrains fehlt die automatische Übermittlung von Dateien, Markierungen und Diagnosen, die für Editoren aus der VS-Code-Familie beschrieben wird. Das Agent Panel von Zed stellt frühere Factory-Droid-Sitzungen nicht wieder her. Auch ein Team, das sich auf Droids als Standard festlegt, braucht deshalb eine editorspezifische Einführung und einen Weg, Kontext wiederherzustellen. Factory dokumentiert diese Unterschiede.

Persönliches BYOK steht in gehosteten Web- und Mobiloberflächen nicht zur Verfügung. Ein lokal eingerichtetes Modell kann für Kosten oder Datenverarbeitung ausschlaggebend sein. Diese Konfiguration lässt sich jedoch nicht auf jeder Factory-Oberfläche nutzen. Vor einer Kaufentscheidung auf Grundlage einer lokalen Demo sollte der vorgesehene Weg zur entfernten Ausführung geprüft werden. Die Einschränkung wird ausdrücklich genannt.

Nutzungsmultiplikatoren ergeben keine verlässlich planbare Kapazität. Die Dokumentation für Einzeltarife beschreibt voneinander unabhängige gleitende Zeitfenster von 5 Stunden, 7 Tagen und 30 Tagen. Ein größeres Abonnement macht daraus weder ein veröffentlichtes Tokenkontingent noch eine Fertigstellungsgarantie. Hängt ein Kundentermin von unbeaufsichtigter Ausführung ab, sollte die Kapazität vertraglich geklärt werden, statt sie aus einem kurzen Pilotprojekt hochzurechnen. Factorys Nutzungsregeln für Einzeltarife halten außerdem fest, dass Missions beim Erreichen eines Nutzungslimits pausieren.

Der Anspruch auf verwaltete Rechenressourcen muss bestätigt werden. Der Widerspruch zwischen Pro und Plus ist für Gründer relevant, die Aufgaben unabhängig vom eigenen Laptop ausführen lassen möchten. Grundlage der Tariftabelle in dieser Bewertung ist die aktuelle Preisseite. Die abweichende Dokumentation belegt kein kostenloses Upgrade. Auch die Konditionen für Rechenressourcen sollten getrennt von der Modellnutzung geprüft werden. „Cloud-Agenten“ bedeutet nicht automatisch, dass die gesamte benötigte Infrastruktur abgedeckt ist.

Berechtigungsregeln ersetzen keine Isolation auf Betriebssystemebene. Darauf weist Factory in der eigenen Dokumentation zur Autonomie hin. Ein erlaubter Befehl ist nicht zwangsläufig harmlos. Ebenso schafft die Anweisung in natürlicher Sprache, Produktionssysteme zu meiden, keine Netzwerkgrenze. Für einen Pilotversuch sollten Zugriff und Umgebung zur jeweiligen Aufgabe passen. Für die unternehmensweite Durchsetzung von Vorgaben sind die Kontrollfunktionen der Tarife mit individuellem Angebot zu prüfen.

Diese Grenzen sprechen für eine schrittweise Einführung mit engem Umfang. Factory sollte zunächst einen Workflow übernehmen, dessen Umgebung, Modell, Berechtigungen und Reviewer feststehen. Wer vorher auf sämtliche Repositorys ausweitet, erzeugt Koordinationsaufwand, der den Gewinn durch Delegation wieder aufzehren kann.

Factory AI bewertet: Woran die Entscheidung hängen sollte

Factory lohnt sich, wenn weniger menschliche Arbeit nötig ist, um aus einer klar definierten Aufgabe eine angenommene Änderung zu machen. Modellwahl, mehrere Oberflächen und entfernte Ausführung sind nur dann hilfreich, wenn sie dieses Ergebnis verbessern.

Als Ergänzung zum bisherigen Agenten einsetzen, wenn für eine gemeinsame Warteschlange, einen editorübergreifenden Workflow oder einen gezielten Modellvergleich bisher eine zufriedenstellende Lösung fehlt. Den bisherigen Agenten für diese Aufgabenart erst ersetzen, wenn vergleichbare Arbeit weniger Review-Aufwand oder niedrigere Gesamtkosten bei gleichwertiger Abnahme zeigt. Factory auslassen, wenn es lediglich einen Workflow doppelt abbildet, den Claude Code, Codex oder Cursor bereits gut bewältigt.

Der konkrete Einstieg für Montag ist eine kleine Evaluation mit einer verantwortlichen Entwicklungsleitung:

Factory ist ein ernst zu nehmender Kandidat für diese Evaluation. Die Dokumentation beschreibt ein breites, konfigurierbares Agentensystem. Sie belegt jedoch nicht, dass ein Entwicklungsteam bessere Arbeit abliefert, nur weil es seinen vertrauten Agenten durch Droid ersetzt.

Häufige Fragen

Die AI Business Workflow Audit Checklist gibt es über den Newsletter. Sie hilft, Aufgabe, Berechtigungen, Review-Verantwortung und Betriebskosten festzuhalten, bevor der Einsatz von Agenten ausgeweitet wird.