In diesem Beitrag
Tencent Octop im Review: Was Entwickler tatsächlich kostenlos bekommen
Octop verschafft einem kleinen technischen Team einen ernstzunehmenden Vorsprung beim Aufbau eines selbst gehosteten KI-Assistenten. Das TencentCloud-Projekt verbindet Benutzerkonten, mehrere Agenten, ein Web-Dashboard, eine Kommandozeile, Messaging-Kanäle, geplante Aufgaben, Wissensabruf, Plugins, Browser-Automatisierung und persistente Speicherung in einer Anwendung. Der Code steht unter der MIT-Lizenz.
Das ist ungewöhnlich großzügig. Es ist aber nicht dasselbe wie ein fertiges Produkt ohne Betriebskosten. Das Team bleibt für Modellzugang, Deployment, Netzwerksicherheit, Identitätsregeln, Backups, Updates, Evaluation und Support verantwortlich.
Recherchestand: . Dies ist eine Quellenanalyse von Octop 1.0.1, kein praktischer Penetrationstest und kein Produktionsbenchmark. Geprüft wurden Repository, Lizenz, Paketdefinition, Architekturentscheidung, Konfigurationsleitfaden, Sicherheitsrichtlinie und aktuelle Version. TencentCloud Octop Repository und Dokumentation
Diese Seite besitzt eine bewusst enge Suchintention: Was Tencent Octop enthält, was die MIT-Lizenz erlaubt und welchen Betrieb ein Unternehmen weiterhin selbst übernehmen muss. Für die Wirtschaftlichkeit eines internen Wissensassistenten gibt es unseren Kostenleitfaden für interne KI-Assistenten. Einen browserzentrierten KI-Kollegen mit Policy-Gateway behandeln wir im OpenBot Review. Allgemeine Laufzeitkontrollen erklärt der Leitfaden für Agent Harness Engineering.
Was ist Tencent Octop?
Octop ist eine selbst gehostete Multi-User- und Multi-Agent-Plattform für Einzelpersonen, Haushalte und kleine Teams. Dashboard, API, CLI, Messaging-Integrationen und Scheduler laufen in einem Python-Prozess. Der Control-Plane-Zustand liegt standardmäßig in SQLite oder optional in PostgreSQL.
Der praktische Wert ist kein neuartiges Modell. Octop bildet die Anwendungsschicht rund um Modelle: Personen können sich anmelden, getrennte Agenten erstellen, Provider wählen, Wissen anbinden, Tools konfigurieren, Chat-Kanäle verbinden und wiederkehrende Arbeit ausführen, ohne zuerst jede administrative Oberfläche selbst zu bauen.
| Fähigkeit | Vorhandener Ausgangspunkt | Was das Team weiterhin entscheidet |
|---|---|---|
| Identität | JWT-Authentifizierung für mehrere Nutzer, Admin-Rolle und Ersteinrichtung | SSO-Eignung, Lifecycle, Least Privilege und Zugriffsreviews |
| Agentenlaufzeit | Mehrere Agenten pro Nutzer, Provider, Tools, Skills, Memory und Checkpoints | Prompts, Rechte, Modellrouting, Evaluation und Eskalation |
| Oberflächen | React-Dashboard, CLI, HTTP, SSE, WebSocket und Messaging-Kanäle | Welche Oberflächen erreichbar sind und wer sie verwenden darf |
| Wissen | Dokument-Upload und semantischer Abruf über einen privaten Korpus | Quellenverantwortung, Aktualität, Rechte und Antwortprüfung |
| Automatisierung | Cron-Jobs, Browser-Automatisierung, Terminal-Aktionen, Plugins und ACP | Freigaben, Sandbox, Egress-Grenzen und Fehlerbehandlung |
| Speicherung | SQLite als Standard, optional PostgreSQL und eigene Workspaces pro Agent | Verschlüsselung, Backup, Wiederherstellung, Aufbewahrung und Kapazität |
Für ein kleines Unternehmen kann sich der erste Meilenstein dadurch von „eine Assistentenplattform bauen“ zu „einen nützlichen Workflow beweisen“ verschieben. Ein sinnvoller Einstieg wäre etwa ein wöchentlicher Betriebsbericht, ein interner Wissenshelfer oder eine geplante Support-Triage. Der Vorteil ist schneller Zugang zu einem testbaren System, nicht die Erlaubnis, Produkt- und Sicherheitsarbeit zu überspringen.
Darf Octop verändert und kommerziell genutzt werden?
Ja. Die MIT-Lizenz von Octop erlaubt Nutzung, Kopieren, Verändern, Zusammenführen, Veröffentlichen, Verteilen, Unterlizenzieren und Verkaufen der Software. Voraussetzung ist, dass Copyright- und Lizenzhinweis in Kopien oder wesentlichen Teilen erhalten bleiben. Die Software wird außerdem ohne Gewährleistung bereitgestellt und die Haftung der Urheber wird begrenzt. MIT-Lizenz von Octop
Ein Entwickler kann die Anwendung also forken, die Oberfläche ändern, einen vertikalen Workflow ergänzen und ein darauf aufbauendes Produkt verkaufen, sofern die Lizenzbedingungen eingehalten werden. Die Lizenz verspricht keinen Support, kein Service-Level-Agreement, keine Modellguthaben, kein Hosting, keine Datenrechte, keine regulatorische Konformität und auch keine Befreiung von den Lizenzen und Bedingungen der Abhängigkeiten, Modelle und verbundenen Dienste.
„Kostenlos“ hat deshalb zwei getrennte Bedeutungen:
- Freiheit bei der Beschaffung: Der Octop-Code kann geprüft und angepasst werden, ohne eine proprietäre Anwendungslizenz zu kaufen.
- Verantwortung im Betrieb: Infrastruktur, Inferenz, Speicherung, Integrationen, Wartung, Sicherheitsarbeit und menschliche Kontrolle verursachen weiterhin Aufwand.
Die kommerzielle Chance ist real, weil der Ausgangspunkt wiederverwendbar ist. Die Kosten verschwinden nicht. Sie verlagern sich vom Kauf eines geschlossenen Produkts hin zum Betrieb und zur Differenzierung eines kontrollierbaren Codebestands.
Ist Octop wirklich der gesamte KI-Assistenten-Stack?
Octop ist ein breiter Anwendungsstack, aber „der gesamte Stack“ wäre zu absolut formuliert. Das Repository enthält Octop Control Plane, Dashboard-Quellcode, API, CLI, Nutzer- und Agentenverwaltung, Datenbankmigrationen, gebündelte Experten, Plugins und Deployment-Dateien. Die Paketdefinition bindet zusätzlich separate Laufzeitabhängigkeiten wie orcakit-harness-agent, harness-memory, harness-gateway und harness-browser sowie FastAPI, LangChain-Komponenten, Playwright und weitere Bibliotheken ein. Paketdefinition und Abhängigkeitsliste von Octop
Laut README werden die zugehörigen harness-*-Projekte für eine separate Open-Source-Veröffentlichung vorbereitet. Die präzise Aussage lautet daher: Die Octop-Anwendung ist MIT-lizenziert und liefert eine umfangreiche, funktionsfähige Control Plane, aber nicht jede zur Laufzeit ausgeführte Codezeile liegt in diesem einen Repository.
Bevor aus einem Fork ein Produkt wird, sollte ein Software Bill of Materials entstehen und vier Fragen beantwortet werden:
- Welche Backend- und Frontend-Pakete werden in der ausgelieferten Version installiert?
- Welche Lizenz und welche Quellcodeverfügbarkeit gilt für jede Abhängigkeit?
- Welche Versionen sind fixiert und wie werden Sicherheitsupdates getestet und ausgerollt?
- Was geschieht, wenn ein Paket, Modellprovider oder Connector API oder Bedingungen ändert?
Das ist normale Open-Source-Due-Diligence und kein Grund, Octop abzulehnen. Es ist der Unterschied zwischen „wir haben ein Repository geklont“ und „wir können ein daraus abgeleitetes Produkt verlässlich betreuen“.
Wie reduziert die Octop-Architektur den Einrichtungsaufwand?
Octop entscheidet sich bewusst für einen einzelnen Prozess statt für ein verteiltes Service-Mesh. Ein von Uvicorn bereitgestellter Python-Prozess hostet FastAPI-Anwendung, Nutzer- und Agentenlaufzeiten, Messaging-Gateways und Cron-Scheduler. SQLite im WAL-Modus ist die Standard-Control-Plane, PostgreSQL ist optional. Redis, RabbitMQ oder eine Celery-Queue sind nicht erforderlich.
Der Architekturentscheid erklärt den Grund: Octop richtet sich an Self-Hosting-Nutzer, für die ein Prozess, ein Port und ein nach einem Neustart aus der Datenbank rekonstruierbarer Zustand vorteilhaft sind. Die Grenzen werden ebenfalls klar genannt. Die Architektur skaliert vertikal auf einer Maschine, CPU-intensive Arbeit kann den Event Loop blockieren und horizontale Worker-Skalierung erfordert später das Herauslösen der Worker plus Queue. ADR 001: Ein Prozess ohne externe Queue
| Designentscheidung | Vorteil für ein kleines Team | Produktionsgrenze |
|---|---|---|
| Ein Prozess | Einfache Installation, lokale Entwicklung und nachvollziehbarer Neustart | Ein Prozess bildet auch einen größeren gemeinsamen Ausfallbereich |
| Keine externe Queue | Weniger Dienste, Zugangsdaten und Fehlerbilder im Betrieb | Keine eingebaute horizontale Worker-Flotte oder Queue-Isolation |
| SQLite als Standard | Schneller lokaler Start mit einer Datenbankdatei | Backup, Gleichzeitigkeit und Failover bleiben Betreiberaufgaben |
| PostgreSQL optional | Externalisierter Zustand und vertraute Betriebsdatenbank | Die Architektur verspricht weiterhin keinen Multi-Instance-Schreibbetrieb |
| Gemeinsame Laufzeit | Dashboard, CLI, Messaging und Cron nutzen dieselben Agenten | Jede freigegebene Oberfläche erweitert Rechte- und Testmatrix |
Das passt gut zu einem Pilotprojekt, einer Haushaltsinstallation oder einem kleinen internen Team. Für ein Multi-Region-SaaS, harte Echtzeitanforderungen oder getrennt skalierende Ausführungspools ist diese Topologie nicht automatisch geeignet.
Macht Self-Hosting Octop privat und kostenlos im Betrieb?
Self-Hosting gibt Kontrolle über Anwendung und Datenpfad, macht aber nicht jeden Modellaufruf lokal und nicht jede Kostenposition null. Octop speichert den Prozesszustand unter ~/.octop/, bindet standardmäßig an 127.0.0.1, unterstützt lokale oder entfernte Workspaces und kann OpenAI-kompatible APIs, DashScope, Ollama sowie weitere Provider-Voreinstellungen verwenden. Bei einem entfernten Modell verlässt weiterhin jener Kontext die Umgebung, den die Konfiguration mitsendet.
Der Konfigurationsleitfaden zeigt außerdem die operative Oberfläche: JWT-Secrets, Provider-Zugangsdaten, Agenten-Workspaces, Plugins, Logs, optionales TLS, CORS-Einstellungen, Upload-Limits, Datenbankzugänge und Umgebungsdateien. Eine Bindung an 0.0.0.0 ermöglicht LAN- oder externen Zugriff, verändert aber gleichzeitig das Bedrohungsmodell. Octop Konfiguration und Datenverzeichnis
| Kostenbereich | Typischer Treiber | Sinnvolle Messgröße |
|---|---|---|
| Inferenz | API-Tokens oder Hardware für lokale Modelle und Embeddings | Kosten pro akzeptiertem Ergebnis statt pro Rohaufruf |
| Compute | Host, Container, Browser-Sitzungen und Dokumentverarbeitung | Spitzenlast bei Speicher, CPU und gleichzeitigen Jobs |
| Speicherung | Datenbank, Workspaces, Anhänge, Wissenskorpus und Logs | Wachstum, Aufbewahrung und Wiederherstellungszeit |
| Sicherheit | TLS, Secrets, Netzwerkregeln, Patches und Zugriffsreviews | Vorfälle, überfällige Updates und Rechteausnahmen |
| Betrieb | Monitoring, Backups, Upgrades, Connector-Brüche und Support | Engineering-Stunden und Wiederherstellungsziele |
| Qualität | Evaluation, menschliche Prüfung, Retries und falsche Aktionen | Akzeptierte Abschlussrate und Review-Minuten |
Eine brauchbare Budgetkennzahl ist gesamte monatliche Betriebskosten / akzeptierte Geschäftsergebnisse. Damit wird die Arbeit sichtbar, die eine freie Lizenz nicht abdeckt. Unser Kostenleitfaden für selbst gehostete LLMs behandelt Modell und Infrastruktur. Das Kostenmodell pro Agentenaktion zeigt, warum Retries und Review mehr kosten können als Tokens.
Ist Octop produktionsreif und sicher?
Octop bringt nützliche Sicherheitsmechanismen mit, aber Produktionsreife hängt weiterhin von Deployment und Governance ab. Dokumentiert sind JWT-Authentifizierung, Eigentumsprüfung auf Zeilenebene, Admin-Zugriff, Tool-Freigaben, Guardrails für Shell-Befehle, PII-Redaktion, Login-Sperren und Secrets im Octop-Datenverzeichnis. Das sind wertvolle Bausteine. Sie sind keine unabhängige Zertifizierung und kein Beweis, dass jede Installation sicher ist.
Die eigene Sicherheitsrichtlinie weist dem Betreiber ausdrücklich die Verantwortung für Host- und Netzwerkabsicherung, Rotation von JWT-Secrets und Admin-Zugängen, Prüfung der Tool-Regeln sowie Schutz der Modell- und Messaging-Zugangsdaten zu. Unterstützt wird die aktuelle Version auf main; ältere Releases erhalten Best-Effort-Support. Octop Sicherheitsrichtlinie und Betreiberpflichten
Auch der Reifegrad zählt. Version 1.0.0 wurde am 14. September 2026 als GA veröffentlicht. 1.0.1 folgte mit Korrekturen an Authentifizierung, Dashboard, PostgreSQL und Konfiguration. Ein schnell entwickeltes Projekt kann rasch besser werden, doch jedes Upgrade braucht Backup, Migrationsprüfung und Regressionstest. Release-Datensatz von Octop 1.0.1
| Kontrollbereich | Mindestevidenz |
|---|---|
| Netzwerk | Private Standardbindung, TLS, eingeschränkter Ingress und dokumentierter Fernzugriff |
| Identität | Namentliche Nutzer, Least Privilege, getrennte Administration, Offboarding und Token-Rotation |
| Tools | Allowlists pro Tool, Freigabe für folgenreiche Aktionen und getestete Ablehnungspfade |
| Secrets | Keine Zugangsdaten in Prompts oder Repositories, geschützte Dateien und Rotationsverfahren |
| Daten | Quellenrechte, Aufbewahrungsregeln, verschlüsselte Backups und getesteter Restore |
| Modelle | Dokumentierte Region, Bedingungen, Logging, Aufbewahrung und Fallback-Verhalten |
| Qualität | Fixes Evaluationsset, Fehlerschwellen, menschliche Eskalation und Rollback |
| Updates | SBOM, fixierte Versionen, Release-Review, Staging und Wiederherstellungsplan |
Bei Workflows mit hoher Auswirkung gehört Octop in ein größeres Kontrollsystem. Unsere Checkliste für Agenten-Evaluation und Sandbox-Sicherheit behandelt Rechte, adversariale Tests und Rollback-Evidenz.
Wer sollte auf Octop aufbauen?
Octop ist besonders attraktiv für ein kleines technisches Team, das Anpassbarkeit braucht und den Betrieb übernehmen kann. Ein guter Ausgangspunkt ist es, wenn mehrere der folgenden Bedingungen zutreffen:
- Mehrere Nutzer oder Agenten werden benötigt, nicht nur ein lokales Chatfenster.
- Interne Dokumente, geplante Arbeit, Messaging-Kanäle oder eigene Tools sollen angebunden werden.
- Quellcodezugriff ist wichtig, weil Workflow oder Oberfläche Teil der Produktdifferenzierung sind.
- Ein Engineer kann Sicherheitsupdates, Backups, Integrationen und Evaluation verantworten.
- Der Start erfolgt mit einem begrenzten Workflow statt mit breiter Autonomie am ersten Tag.
Ein Managed Assistant oder eine engere Integration ist sinnvoller, wenn niemand die Plattform besitzen kann, ein Anbieter-SLA zwingend ist, der Anwendungsfall austauschbar ist oder die erwartete Einsparung die langfristige Wartung nicht rechtfertigt. Eine individuell komponierte Plattform passt besser, wenn Octops Oberflächen oder Single-Process-Architektur zentrale Anforderungen verletzen.
| Ausgangspunkt | Gute Eignung | Hauptnachteil |
|---|---|---|
| Managed Assistant | Schneller Rollout, Standardabläufe und wenig Plattformpersonal | Provider-Grenzen, laufender Preis und begrenzte Anpassbarkeit |
| Octop Fork | Kleines technisches Team mit Bedarf an einer breiten, veränderbaren Basis | Deployment, Sicherheit, Updates und Produktverantwortung gehen auf das Team über |
| Individuelle Komposition | Einzigartige Anforderungen an Skalierung, Policy, Mandantenfähigkeit oder Produktarchitektur | Mehr Engineering, bevor Nutzer einen Wert erhalten |
Die Frage lautet nicht „Ist Open Source besser?“, sondern „Schafft der Besitz dieser Schicht genug Produkt- oder Betriebsvorteil, um ihren gesamten Lebenszyklus zu verantworten?“ Unser Vergleich von Individualsoftware und Standardsoftware liefert den breiteren Entscheidungsrahmen.
Wie sollte ein kleines Unternehmen Octop pilotieren?
Octop sollte den Weg zu Evidenz verkürzen und nicht den ersten Scope vergrößern. Ein zweiwöchiger Pilot muss einen Workflow, eine Datengrenze und einen Wiederherstellungspfad beweisen.
| Phase | Arbeit | Abschlussevidenz |
|---|---|---|
| Tag 1 bis 2 | Lokal oder isoliert deployen, Versionen festhalten und jeden externen Dienst erfassen | Architektur- und Datenflussdiagramm |
| Tag 3 bis 4 | Testnutzer, einen Agenten, einen Provider und Least-Privilege-Zugänge anlegen | Zugriffsmatrix und Widerrufstest |
| Tag 5 bis 7 | Einen begrenzten Workflow mit klaren Eingaben, Ausgaben und verbotenen Aktionen umsetzen | Akzeptanzkriterien und Baseline-Beispiele |
| Tag 8 bis 10 | Wissen oder Tools ergänzen und Prompt Injection, Tool-Ablehnung, Cross-User-Zugriff sowie Wiederherstellung testen | Sicherheits- und Regressionsbericht |
| Tag 11 bis 12 | Repräsentative Aufgaben ausführen und akzeptierte Abschlüsse, Review-Zeit, Latenz und Kosten messen | Vergleich mit dem heutigen Prozess |
| Tag 13 bis 14 | Backup, Restore, Credential-Rotation und Rollback üben | Go-, Eingrenzungs- oder Stop-Entscheidung mit Owner |
Erfolg darf nicht nur an der Qualität des Chats gemessen werden. Zu zählen sind akzeptierte Geschäftsergebnisse, Korrekturen, unerlaubte Versuche, Review-Minuten, Integrationsfehler und Wiederherstellungszeit. Eine elegante Antwort ist wertlos, wenn der Agent die falsche Aktion ausführt oder Daten verwendet, die er nicht sehen durfte.
Wavects Engineering für KI-Agenten kann aus einem vielversprechenden Open-Source-Stack ein kontrolliertes internes Produkt machen. Vor dem Launch hilft die Software-QA-Checkliste. Alternativ kannst du uns Workflow, Repository und Betriebsgrenzen schicken.
Unser Fazit: Das wertvolle Geschenk ist der Vorsprung
TencentCloud hat die schwierigen Teile des Betriebs eines KI-Produkts nicht entfernt. Es hat aber einen großen Teil der undifferenzierten Anfangsarbeit vorweggenommen.
Octop liefert Entwicklern eine prüfbare, veränderbare Anwendung, in der Identität, Agenten, Oberflächen, Automatisierung und Speicherung bereits verbunden sind. Die MIT-Lizenz schafft echte kommerzielle Freiheit. Die Single-Process-Architektur macht den ersten Betrieb zugänglich. Gleichzeitig bestehen ausreichend Austauschpunkte für Provider, Speicher und Workflows.
Die verantwortungsvolle Einordnung ist ebenso wichtig. Nicht jede Laufzeitkomponente liegt im Octop-Repository. Self-Hosting bedeutet nicht automatisch vollständig lokal. Eingebaute Guardrails beseitigen kein Deployment-Risiko. Eine freie Lizenz bezahlt weder Modellrechnung noch Wartung des Forks.
Für ein kleines technisches Team mit einer klar begrenzten internen Assistentenidee oder einem vertikalen Produkt kann es trotzdem ein hervorragender Deal sein: Mit Octop starten, den Workflow beweisen, jede Abhängigkeit erfassen, den Datenpfad absichern und nur dort Engineering investieren, wo Eigentum einen Vorteil schafft.
Senior Product- und Tech-Führung
Du brauchst technische Führung, bevor ein Vollzeit-Hire Sinn ergibt? Wavect gibt Gründern CTO-, CPO- und Delivery-Urteil, solange sich das Produkt noch schnell bewegt.
Sinnvolle Wege:
Häufige Fragen zu Tencent Octop
Was ist Tencent Octop?
Octop ist eine MIT-lizenzierte, selbst gehostete KI-Assistenten-Anwendung aus der TencentCloud GitHub-Organisation. Sie verbindet mehrere Nutzer und Agenten mit Dashboard, CLI, Messaging-Kanälen, geplanten Aufgaben, Wissensabruf, Plugins, Browser-Automatisierung und persistenter Speicherung.
Darf Octop kommerziell genutzt werden?
Ja. Die MIT-Lizenz des Repositories erlaubt kommerzielle Nutzung, Veränderung, Verteilung, Unterlizenzierung und Verkauf, sofern Copyright- und Lizenzhinweis erhalten bleiben. Abhängigkeiten, Modelle, Daten und verbundene Dienste behalten ihre eigenen Bedingungen.
Liegt jeder Teil von Octop im GitHub-Repository?
Nein. Das Repository enthält Octop-Anwendung und Dashboard, während die Paketdefinition zusätzliche Harness- und Drittanbieterabhängigkeiten installiert. Vor einem abgeleiteten Produkt sollte deshalb der vollständige Dependency-Baum geprüft werden.
Enthält Octop ein kostenloses Sprachmodell?
Nein. Octop kann OpenAI-kompatible APIs, DashScope, Ollama und weitere Provider ansprechen. Das gewählte Modell, die Embedding-Lösung und verwendete Hardware oder API bestimmen Kosten und Datenpfad.
Bleiben durch Self-Hosting alle Octop-Daten lokal?
Nicht automatisch. Anwendung, Datenbank und Workspaces können auf eigener Infrastruktur laufen. Entfernte Modell-APIs, Messaging-Kanäle, OAuth-Connectoren und andere Dienste können dennoch Daten erhalten. Jeder ausgehende Datenfluss muss bewusst erfasst und konfiguriert werden.
Ist Octop produktionsreif?
Octop 1.0.1 ist eine umfangreiche, funktionsfähige Plattform mit nützlichen Sicherheitskontrollen. Produktionsreife hängt trotzdem von Deployment, Zugriffsregeln, Evaluation, Monitoring, Backups, Dependency-Management und dem Risiko des Workflows ab. Diese Quellenanalyse ist kein unabhängiges Sicherheitsaudit.
Was ist ein guter erster Octop-Anwendungsfall?
Geeignet ist ein häufiger, begrenzter und reversibler interner Workflow, etwa ein wöchentlicher Bericht aus freigegebenen Quellen oder Fragen über ein kontrolliertes Dokumentenset. Breite Tool-Rechte sollten erst nach Tests von Rechten, Evaluation und Wiederherstellung folgen.
Was sollte ein Octop-Pilot messen?
Gemessen werden sollten akzeptierte Aufgabenabschlüsse, Review-Minuten, Korrekturen, Latenz, Modell- und Infrastrukturkosten, abgelehnte Aktionen, Cross-User-Isolation, Integrationsfehler und Wiederherstellungszeit. Erst der Vergleich mit dem heutigen Prozess rechtfertigt eine Erweiterung.
Fazit
Octop ist wertvoll, weil sich die erste Frage von ‚Wie bauen wir jede Oberfläche eines Assistenten?‘ zu ‚Welchen Workflow lohnt es sich zu besitzen?‘ verschiebt. Die MIT-lizenzierte Anwendung gibt einem kleinen Team echten Hebel, aber nur dann, wenn es auch Sicherheit, Qualität und Betrieb übernimmt.
Nutze den Code als Vorsprung und nicht als Beweis für ein fertiges Produkt. Beweise einen Workflow, prüfe Abhängigkeiten und Datenpfad, miss akzeptierte Ergebnisse und erweitere erst, wenn das Betriebsmodell hält.
