Infopool / Thought Leadership
Thought Leadership

AI-native — warum ich meine Firma anders baue.

Andreas Martens August 2026

Die klassische Firmenlogik geht so: Je mehr Business, desto mehr Leute. Je mehr Leute, desto schwerer die Kultur. Das war jahrzehntelang der Deal — Wachstum bezahlt mit Kulturverlust. Ich glaube: dieser Deal gilt seit ungefähr zwei Jahren nicht mehr. Und wer ihn heute noch akzeptiert, baut ein Unternehmen für die letzte Ära.

Ich baue qurix bewusst als eine AI-native Firma. Das ist keine Marketing-Etikette und auch keine Tool-Wahl — es ist eine Betriebslogik. Sie verändert, wen ich einstelle, wie viele, was ich von ihnen erwarte, welche KPIs ich ernst nehme, welche ich ignoriere. Sie verändert vor allem, wie schnell wir für Kunden liefern können. Ich schreibe hier weniger einen Essay als eine Sammlung der Prämissen, an denen ich meine eigenen Entscheidungen ausrichte.

Die Umkehr der Skalierungslogik

Die alte Frage war: „Wie viele Leute brauche ich, um das zu bauen?" Meine neue Frage ist eine andere: „Wie wenige Leute reichen, um das zu bauen — und wie viel Wirkung kann jeder von ihnen entfalten, wenn er die richtige Umgebung hat?" Der Unterschied ist nicht kosmetisch. Er entscheidet, welche Firma in zwei Jahren noch existiert und welche Ballast mit sich schleppt.

Für mich ergibt das eine radikale Konsequenz: Ich stelle nicht mehr auf Kapazität ein. Ich stelle auf Qualität ein. Der nächste Mensch, der bei qurix anfängt, ist die Person, ohne die etwas Wichtiges nicht existieren würde — kein „extra Paar Hände". Und dieser Mensch muss so eingestellt sein, dass eine Person tatsächlich ein ganzes Thema autonom trägt. Keine Abteilungen, keine Weiterleitung, keine Meeting-Ketten. Ein Thema, eine Person, ganze Verantwortung.

Ich hätte am liebsten Leute in meiner Firma, die selbst CEOs oder Gründer sein könnten. Nicht als Vanity-Metrik. Sondern weil das Kalibre, das autonom eine Sache trägt, ohne Rückfrage, ohne Absicherung — genau das ist der Hebel, der AI-native Arbeit erst möglich macht.

Sieben Prinzipien, an denen ich qurix ausrichte

Keine Vollständigkeit, keine Checkliste. Nur die Prämissen, die für mich jeden Tag Entscheidungen treffen — und die ich in jeder Person, die ich einstelle, in jedem Prozess, den ich designe, wiederfinde.

01

Superstars, keine Anzahl Jede Neu-Person kostet viel — und ist 100× wertvoller als die nächste

Priorität Nummer eins beim Aufbau: die Qualität der Menschen. Alles andere folgt daraus.

Ich rekrutiere nicht auf offene Positionen, ich rekrutiere auf Menschen. Wenn ich jemanden treffe, der ein ganzes Thema bewegen kann, mache ich einen Weg. Wenn ich niemanden finde, stelle ich niemanden ein — auch nicht als Notlösung. Eine falsch besetzte Rolle kostet in einer kleinen AI-native Firma ein Vielfaches dessen, was sie in einer Konzernstruktur kosten würde: sie zieht die Geschwindigkeit runter, ohne dass ein Puffer da wäre, der das abfedert.

02

Ein Thema, eine Person, volle Autonomie Keine Abteilungen, keine Hierarchie

Der Hebel entsteht dort, wo eine Person eigenständig entscheidet — nicht dort, wo drei sich abstimmen.

Für jedes Thema in der Firma gibt es genau eine Person, die es besitzt. Diese Person entscheidet — nicht ein Komitee. Ich verzichte bewusst auf Abteilungen und Hierarchie, weil beide zu Rückfrage-Ketten führen, die die Geschwindigkeit halbieren, ohne die Qualität zu erhöhen. Autonomie ist der Preis dafür, dass jeder gute Mensch bleibt und weiter besser wird.

03

Vertrauen als Design-Prinzip Wenn ich Superstars einstelle, muss ich ihnen auch glauben

Ich brauche schlaue Menschen — und ich muss dem vertrauen, was sie sagen. Sonst brauche ich sie nicht.

Das ist ein systemischer Punkt, kein Weichspüler-Wert. Wenn ich Menschen mit dem Kaliber einstelle, das autonom ein Thema trägt, muss ich ihnen den Vertrauensvorschuss geben, den diese Autonomie erst funktional macht. Kontrollstrukturen erzeugen genau die Rückfrage-Ketten, die ich mit Autonomie loswerden wollte. Die einzige Absicherung, die ich behalte, ist die Auswahl vorne: sehr genau schauen, wen ich einstelle. Danach: laufen lassen.

04

90 % Claude-Code-Zeit Automatisieren, was automatisierbar ist — inklusive der eigenen Arbeit

Ich erwarte, dass meine Leute die meiste ihrer Zeit mit Agenten arbeiten — und sich selbst wegautomatisieren, wo es geht.

Konkret: ich erwarte, dass jede Person ~90 % ihrer produktiven Arbeitszeit mit Claude Code oder Claude arbeitet. Das ist keine Fleißmetrik — es ist die Grundlage dafür, dass eine Einzelperson die Wirkung einer klassischen Kleingruppe hat. Wer die Werkzeuge nicht so tief nutzt, dass die eigene Arbeit sich in Teilen selbst automatisiert, arbeitet nicht AI-native — er nutzt AI als Beilage.

05

Anthropic ist unser Betriebssystem Klare Wahl, klarer Stack, keine Zaudern-Debatten

Wir sind auf den Schienen von Anthropic aufgebaut. Das ist eine bewusste, produktive Verengung.

Wir sind AI-native auf Anthropic-Basis. Claude ist unser Standardmodell, Claude Code unsere Engineering-Umgebung, das MCP-Ökosystem unser Integrations-Fabric. Diese Verengung kostet uns Optionalität, aber sie bringt uns Fokus und Geschwindigkeit. Wir müssen keine Debatten führen, welches Modell heute vorne liegt — wir wählen eine Achse und optimieren auf ihr. Wechselkosten sind da, aber niedriger als der Preis für ständiges Vergleichen.

06

Fast alles wird generiert Code, Content, Kontext, Text

Nahe 100 % unseres Quellcodes ist agent-generiert. Das gilt zunehmend auch für Texte, Kontext, Kommunikation.

Fast der komplette Code, den wir produzieren, wird von Agenten generiert — überwacht, geprüft, kuratiert, aber nicht von Hand getippt. Das gleiche gilt zunehmend für Content: Landing-Pages, Präsentationen, Kunden-Kommunikation. Der Skill ist nicht mehr Schreiben oder Coden — es ist Spezifizieren, Kontext-Kuratieren, Ergebnis-Prüfen. Der Baustein, an dem eine AI-native Firma sich unterscheidet, ist ihre Fähigkeit, das gut zu tun.

07

Geschwindigkeit ist die Metrik Nicht Umsatz-pro-Kopf. Nicht NPS. Sondern: Releases pro Tag.

Die Frage, die ich mir stelle: Wie kommen wir von 10 Releases pro Tag auf 50 — und danach auf 500?

Wenn ich eine einzige Zahl wählen müsste, an der sich alle anderen ausrichten sollen, dann diese: wie viele Software-Änderungen bringen wir pro Tag in Produktion. Nicht als Selbstzweck. Sondern weil Release-Geschwindigkeit die genaueste Näherung dafür ist, wie schnell Kunden-Wünsche zu Kunden-Lösungen werden. Wer 500 Releases pro Tag schafft, hat einen ganz anderen Firmenzustand als wer bei einem Release pro Sprint ist.

Der Test, an dem sich alles entscheidet: 6 Stunden

Meine liebste Frage, um zu prüfen ob wir wirklich AI-native arbeiten, ist eine sehr konkrete: Ein Kunde ruft um 9 Uhr morgens an und sagt: „Ein Feature funktioniert nicht so, wie ich es haben möchte." Wie lange brauchen wir, bis die neue Version live ist?

Mein Anspruch ist: sechs Stunden. Anruf um 9. Lösung live um 15 Uhr desselben Tages. Nicht als Ausnahme, sondern als Regelfall. Diese Zahl ist keine Übertreibung — sie ist der Test. Wenn eine Firma diesen Zyklus in sechs Stunden schließen kann, dann funktioniert alles andere, was ich hier beschrieben habe. Wenn sie zwei Wochen braucht, dann sind die sieben Punkte oben Poesie.

Das ist der Grund, warum ich so radikal auf Autonomie, Qualität der Menschen, generierten Code und den Anthropic-Stack setze. Nicht als Selbstzweck. Sondern weil das die einzige Konfiguration ist, in der sich ein Sechs-Stunden-Zyklus realistisch fahren lässt. Klassische Setups — mit Change-Boards, Sprint-Planungen und Cross-Team-Abstimmungen — können das strukturell nicht. Nicht weil die Menschen dort schlechter sind, sondern weil die Struktur den Zyklus streckt.

* * *

Was das für Kunden bedeutet

Der Vorteil, wenn man mit einer AI-native Firma arbeitet, ist nicht: „Ihr habt cooles KI-Tooling". Der Vorteil ist: eure Fristen sind unsere Fristen. Der Feature-Wunsch, der bei einer klassischen Delivery-Struktur zu einem Change-Request wird, der bei uns zu einer Lösung wird — im selben Arbeitstag. Die Anpassung, für die andere ein Sprint-Planning brauchen, die bei uns zwischen Kaffee und Mittag passiert.

Das ist kein Marketing-Punkt, das ist ein Struktur-Punkt. Wir können das nicht, weil wir clever sind. Wir können das, weil wir bewusst darauf verzichtet haben, größer, hierarchischer und langsamer zu werden. Und wenn wir irgendwann größer werden — was passieren wird — muss diese Struktur mitwachsen, sonst wird sie sofort schlechter. Skalierung heißt für uns nicht „mehr Personal", es heißt „gleiche Prinzipien auf mehr Themen".

AI-native ist keine Tool-Wahl. Es ist die Frage, ob dein Unternehmen morgens noch dasselbe ist, das gestern Feierabend gemacht hat — oder ob es die Nacht durchgearbeitet hat, während du geschlafen hast.

Für uns ist die Antwort klar. Für viele Unternehmen wird sie in den nächsten zwei Jahren zur Existenzfrage. Nicht weil sie zwingend „AI-native werden" müssen — sondern weil ihre Wettbewerber es tun. Und weil Kunden sich sehr schnell an sechs-Stunden-Zyklen gewöhnen.

Wie würden Sie Ihre Firma bauen, wenn Sie sie heute anfangen?

Genau die Frage stellen wir uns jeden Tag — für uns selbst und für unsere Kunden. Wenn Sie an demselben Punkt sind, sprechen wir gerne.

Gespräch vereinbaren