2026 steht auf jeder zweiten Agentur-Startseite „Wir setzen KI ein”. Der Satz kostet nichts und belegt nichts. Uns war ein anderer Weg wichtiger: die Werkzeuge selbst zu schreiben, sie offenzulegen und sie im echten Betrieb laufen zu lassen. Dann muss man nicht behaupten, dass man es kann — man kann es zeigen.
Was offenliegt
Unser Werkzeugverzeichnis zeigt öffentliche Repositories mit Status und vorhandenen Lizenzangaben. Zum eigenen Werkzeugbestand gehören unter anderem:
- nerve — ein KI-Coding-Assistent in Rust mit Terminal-Integration. Der bisherige öffentliche Repository-Link ist derzeit nicht abrufbar; sein Quellcode wird hier deshalb nicht als öffentlich zugänglicher Nachweis angeboten.
- fleetdeck — automatisiert das Ausrollen von Docker-Compose-Diensten samt Reverse-Proxy, in Go.
- granit — ein terminal-natives Wissenssystem auf Markdown-Basis.
- forge-ai — orchestriert mehrere KI-Assistenten in einem Ablauf.
Dazu kommt trendradar für die Auswertung offener Daten und openwhistle, eine self-hosted Plattform für die EU-Hinweisgeberrichtlinie. Die öffentlich geprüften Repositories sind keine Forks. Ein öffentlich lesbares Repository allein gewährt aber noch keine Open-Source-Nutzungsrechte: Bei fleetdeck, trendradar und openwhistle war im überprüften öffentlichen Bestand keine Lizenz ausgewiesen. Für granit und forge-ai ist MIT ausgewiesen (Stand 3. Oktober 2026). Die Forschungsrepos und Experimente daneben stehen im Labor.
Der Unterschied: sie tragen echten Betrieb
Der entscheidende Satz steht nicht in der Sternzahl. Er lautet: Wir verwenden nerve für die Entwicklung und fleetdeck für die Bereitstellung von MealTime. Der dokumentierte Stand ist ein Pilotbetrieb; Umfang und Reifegrad stehen auf dem Projektblatt. Ein Entwicklungswerkzeug ist dabei nicht mit der laufenden Fachanwendung gleichzusetzen.
Ein Werkzeug, das den eigenen Produktivbetrieb trägt, ist eine andere Art von Beleg als eines, das in einem Demo-Video läuft. Ausfälle eines Entwicklungswerkzeugs und Ausfälle der Fachanwendung haben unterschiedliche Folgen. Für den Anwendungsbetrieb brauchen wir unabhängig davon Sicherungen, Überwachung und Wiederherstellungswege.
Warum Code veröffentlichen?
Für die Veröffentlichung sprechen drei Gründe:
Öffentlich einsehbarer Code ist prüfbar. Wer wissen will, ob wir sauber arbeiten, muss uns nicht glauben — er kann nachsehen. Für Auftraggeber im öffentlichen Bereich, die Sorgfalt belegen müssen, ist das ein ergänzender Nachweis. Zertifikate, Referenzen und eine technische Prüfung beantworten jeweils andere Fragen.
Wir bauen schneller, weil wir die Werkzeuge kennen. Wer sein Werkzeug selbst geschrieben hat, wartet nicht auf den Hersteller, wenn etwas fehlt — er ergänzt es. Diese Geschwindigkeit landet im Angebot.
KI dort, wo die Daten bleiben müssen. Weil wir eigene Werkzeuge haben, können wir Modelle lokal und self-hosted betreiben — ohne Umweg über einen amerikanischen Anbieter. Bei personenbezogenen Daten müssen zusätzlich Zweck, Rechtsgrundlage, Zugriffe und alle Datenübermittlungen geprüft werden. Ein lokales Modell allein belegt keine Datenschutzkonformität.
Was das für einen Auftrag bedeutet
Sie bekommen keine Blackbox. Bei individueller Entwicklung vereinbaren wir Quellcodeübergabe, Nutzungsrechte und Datenexport. Produkte und Fremdkomponenten haben eigene Lizenzbedingungen. Offene Werkzeuge erleichtern Nachvollziehbarkeit; eine spätere Übernahme braucht zusätzlich Dokumentation und passende Kenntnisse. Wer bleibt, soll bleiben, weil die Arbeit stimmt.
Wenn Sie technisch tiefer einsteigen wollen: Die verfügbaren Quellcode-Nachweise und Grenzen stehen im Werkzeugverzeichnis. Sehen Sie hinein, bevor Sie uns beauftragen. Wir finden, so herum gehört es.