Company as Code – Warum dein Unternehmen ein Repository braucht

Die Diskussion um KI-Agents dreht sich meist um Technologie: Welches Modell? Welcher Prompt? Wie viel Autonomie? Dabei liegt das eigentliche Problem woanders.

Der Flaschenhals ist nicht der fehlende Agent. Es sind aufgeschobene Entscheidungen und fehlende Dokumentation.

Das eigentliche Problem

Ein Agent kann nur so gut arbeiten wie die Informationen, auf die er zugreifen kann. Und hier wird es bei den meisten Unternehmen dünn.

Frag dich: Wo liegt eigentlich dokumentiert...

...was die strategischen Ziele für dieses Jahr sind?
...welche Kundenprobleme Priorität haben?
...warum ihr Feature X baut und nicht Feature Y?
...was euer USP ist und wie ihr euch vom Wettbewerb unterscheidet?

In den meisten Unternehmen ist dieses Wissen verteilt auf:

Köpfe von Gründern und Führungskräften
Slack-Threads aus 2023
Ein Notion-Board, das niemand mehr pflegt
PowerPoint-Decks für Investoren
"Das weiß der Thomas"

Kein Agent der Welt kann daraus sinnvolle Arbeit machen. Nicht weil die Technologie fehlt – sondern weil das Wissen oft nicht erfasst oder nicht zugänglich ist. Zudem drücken sich viele Unternehmer:innen um unbequeme Entscheidungen und das Tagesgeschäft ist durch unvorhergesehene Probleme auch oft fordernd genug.

Company as Code: Die Idee

Was wäre, wenn dein gesamtes Unternehmenswissen an einem Ort läge? Versioniert, durchsuchbar, maschinenlesbar?

Entwickler kennen das Konzept: Infrastructure as Code hat die DevOps-Welt revolutioniert. Server-Konfigurationen, die früher in den Köpfen von Admins steckten, liegen jetzt als Code im Repository. Nachvollziehbar, reproduzierbar, reviewbar - auch von den Entwicklern (und KI-Agenten), die damit in die Lage versetzt werden die Software passend zur Infrastruktur zu entwickeln und Probleme gemeinsam zu lösen bevor sie entstehen.

Company as Code überträgt diese Idee auf das gesamte Unternehmen:

/company
  strategy.md         # Vision, Mission, Jahresziele
  competitors.md      # Wettbewerbsanalyse, Differenzierung
  personas.md         # Wer sind unsere Kunden?
  brand.md            # Wie kommunizieren wir?
  
/product
  roadmap.md          # Was bauen wir wann?
  /prds               # Feature-Spezifikationen
  
/engineering
  technology.md       # Tech Stack, Coding Guidelines
  architecture.md     # System-Design, ADRs

Keine Notion-Datenbank. Kein Confluence-Wiki. Kein SharePoint. Einfache Markdown-Dateien in einem Git-Repository. für alle – zur Not mit automatisierten Exporten aus allen Systemen, die regelmäßig in einer Build-Pipeline laufen.

Warum Git?

Git ist nicht nur für Code. Git ist das beste Werkzeug für kollaboratives Wissen:

Versionierung – Jede Änderung ist nachvollziehbar. Wer hat wann warum die Strategie angepasst? Git weiß es.

Review-Prozesse – Strategische Änderungen können per Pull Request diskutiert werden. Keine spontanen Edits im Wiki, die niemand mitbekommt.

Single Source of Truth – Es gibt genau eine aktuelle Version. Nicht drei Notion-Seiten mit widersprüchlichen Informationen.

Agent-Ready – Ein Agent kann ein Repository klonen und hat sofort Zugriff auf alles. Kein Login bei fünf verschiedenen Tools. Kein "frag mal den Thomas".

Monorepo vs. verteiltes Repo-Chaos – der heimliche Showstopper

In klassischen Unternehmen ist Wissen über Dutzende Systeme verteilt: Code in GitHub, Docs in Confluence, Tickets in Jira, Strategie in PowerPoint, Brand-Guidelines als PDF auf dem Sharepoint-Server. Jedes System hat eigene Logins, eigene Suchfunktionen, eigene Versionshistorien.

Ein Agent müsste sich in fünf Tools einloggen, fünf APIs ansprechen, fünf Datenformate verstehen – und dann noch herausfinden, welche Information aktuell ist.

Die Lösung: Ein Monorepo. Code, Hosting & Betrieb, Dokumentation, Specs, Strategie – alles was zum Betrieb des Unternehmens nötig ist an einem Ort. Ein git clone, und der Agent hat Zugriff auf das gesamte Unternehmenswissen. Eine Suche findet Code und Kontext. Ein Commit kann Feature, PRD und Architektur-Update zusammen erfassen.

Das ist kein Nice-to-have. Es ist der Turbo-Boost für KI-gestütztes Unternehmertum.

Warum Markdown?

Die bewusste Entscheidung für einfache Textdateien ist kein Verzicht – sie ist ein Feature.

Null Vendor Lock-in – Markdown ist ein offener Standard. Kein Abo, keine API-Änderungen, keine Migrations-Projekte, wenn der Anbieter die Preise erhöht oder eingestellt wird.

Maximale Portabilität – Jeder Editor kann Markdown öffnen. VS Code, Obsidian, Notion (Import), sogar Notepad. Dein Wissen gehört dir, nicht einem Tool.

Maschinenlesbar – Agents können Markdown-Dateien direkt lesen und verstehen. Kein Scraping von Web-UIs, keine API-Integration, keine Authentifizierung. Die Datei ist die Schnittstelle.

Fokus auf Inhalt – Keine Ablenkung durch Formatierungs-Optionen, Widgets, Datenbank-Views. Du schreibst auf, was wichtig ist. Fertig.

Langlebigkeit – Textdateien aus den 80ern sind heute noch lesbar. Deine Notion-Datenbank in 10 Jahren? Ungewiss.

Der Einwand kommt sofort: "Aber Notion kann doch so viel mehr!" Stimmt. Die Frage ist: Brauchst du das? Oder lenkt es ab vom eigentlichen Ziel – Wissen zugänglich zu machen?

Bonus: Automatisierte Exporte – Du musst nicht alles manuell pflegen und auch nicht alle heute genutzten Tools wegwerfen. Viele Tools haben APIs, aus denen sich Markdown einfach generieren lässt. Projekte aus Linear, Tickets aus Jira, Docs aus Notion – ein Skript in der CI-Pipeline hält das Repository aktuell. Das Fremdsystem bleibt die Quelle, aber das Repository wird zur einheitlichen Schnittstelle für Agents.

Der eigentliche Gamechanger: Entscheidungen treffen

Hier wird es unbequem.

Ein Repository anzulegen ist einfach. Es mit Inhalt zu füllen, erfordert etwas, das viele Unternehmen vermeiden: Entscheidungen treffen und aufschreiben.

Was ist unser USP? (Nicht drei, einer.)
Welches Kundenproblem hat dieses Quartal Priorität?
Welche Features bauen wir nicht – und warum?
Wie sprechen wir? Formell oder informell? Du oder Sie?

Solange diese Fragen nicht beantwortet sind, kann kein Agent helfen. Er kann nicht priorisieren, wenn du keine Prioritäten definiert hast. Er kann nicht in deiner Stimme schreiben, wenn du keine Stimme dokumentiert hast.

Company as Code zwingt zur Klarheit. Nicht weil Git das verlangt – sondern weil leere Dateien auffallen.

Das erfordert auch den Mut, Nein zu sagen. Nicht jedes Feature, nicht jeder Kundenwunsch, nicht jede Idee schafft es in die Roadmap. Gutes Produktmanagement – mit priorisiertem Kunden-Feedback und klaren Kriterien – hilft enorm. Wer weiß, was wichtig ist, kann auch dokumentieren, was nicht wichtig ist. Und ein Agent, der beides kennt, trifft automatisch bessere Entscheidungen.

Was Agent-Ready wirklich bedeutet

"Agent-Ready" ist kein technisches Feature. Es bedeutet:

1. Wissen ist zugänglich Nicht in Köpfen, nicht in Meetings, nicht in Slack-Threads. In durchsuchbaren, maschinenlesbaren Dokumenten.

2. Entscheidungen sind dokumentiert Nicht nur was entschieden wurde, sondern warum. Ein Agent, der den Kontext kennt, trifft bessere Micro-Entscheidungen.

3. Prioritäten sind klar Was ist wichtiger: Geschwindigkeit oder Stabilität? Neue Features oder technische Schulden? Ohne diese Information optimiert ein Agent auf das Falsche.

4. Es gibt eine einzige Quelle Keine fünf Tools mit unterschiedlichen Versionen der gleichen Information. Ein Repository, eine Wahrheit.

Die Magie entsteht durch Kontext

Stell dir vor, ein Agent hat Zugriff auf:

Eure Unternehmensstrategie und Jahresziele
Die aktuelle Wettbewerbsanalyse
Eure Personas und deren Pain Points
Die Produkt-Roadmap mit Prioritäten
Den Tech Stack und die Coding Guidelines

Was wird möglich?

Strategisches Arbeiten: "Analysiere unsere Roadmap gegen die Jahresziele. Welche geplanten Features zahlen auf welches Ziel ein? Wo fehlt Alignment?"

Outcome-Driven Development: "Implementiere dieses Feature. Beachte, dass wir laut Persona-Doc vor allem mobile Nutzer mit wenig Zeit haben. Optimiere auf schnelle Ladezeit."

Konsistente Kommunikation: "Schreibe Release Notes für dieses Feature. Nutze die Tonalität aus brand.md und referenziere den Pain Point aus der Persona."

Das ist keine Zukunftsmusik. Das ist das, was passiert, wenn ein Agent echten Kontext hat.

Der Anfang ist simpel

Du brauchst keine komplexe Tool-Landschaft. Du brauchst:

1. Ein Repository (GitHub, GitLab – egal)

2. Eine Handvoll Markdown-Dateien:

Datei	Beantwortet
strategy.md	Wo wollen wir hin? Was hat Priorität?
personas.md	Für wen bauen wir? Was sind deren Probleme?
brand.md	Wie kommunizieren wir?
technology.md	Wie bauen wir technisch?

3. Die Disziplin, Entscheidungen aufzuschreiben

Das ist der schwierige Teil. Nicht das Tooling.

Fazit

Die meisten Unternehmen suchen nach dem perfekten Agent, dem perfekten Prompt, der perfekten Automatisierung. Dabei fehlt die Grundlage: dokumentiertes Wissen, getroffene Entscheidungen, klare Prioritäten.

Company as Code ist keine neue Software. Es ist eine Denkweise:

Behandle Unternehmenswissen wie Code
Versioniere Entscheidungen
Mache Kontext maschinenlesbar
Zwinge dich zur Klarheit

Der Flaschenhals für KI im Unternehmen ist selten die Technologie. Es ist die Bereitschaft, Dinge aufzuschreiben, die bisher nur in Köpfen existieren.

Ein Agent kann dir dabei helfen, schneller zu arbeiten. Aber er kann dir nicht abnehmen zu entscheiden, wohin die Reise geht.

Weiterführend

Supervised Autonomy – Wie du Agents sicher und kontrolliert einsetzt