Vibe-Coder, Reviewer oder Skeptiker? Dein KI-Arbeitstyp als Entwickler
Der eine lässt Copilot Zeile für Zeile vervollständigen und schreibt den Rest selbst. Die andere gibt Cursor oder Claude Code ein ganzes Ticket und schaut erst wieder hin, wenn der Diff steht. Beide nennen es „mit KI arbeiten“ — und meinen völlig verschiedene Dinge. Zwischen Tab-Taste und Agent-Run liegt ein ganzes Spektrum, und wo du darauf stehst, prägt deinen Alltag inzwischen mehr als dein Stack.
Kognit macht dieses Spektrum sichtbar. Der Test misst dein Verhalten auf vier Achsen — wie viel du delegierst, wie streng du prüfst, wofür du KI einsetzt und wie du sie steuerst — und verdichtet es zu einem von 16 Arbeitstypen. 24 Fragen, rund 4 Minuten, kostenlos. Kein Persönlichkeitstest über dein Innenleben, sondern ein psychologisches Modell aus vier Verhaltensachsen, das beschreibt, was du beim Coden tatsächlich tust.
Das Ergebnis ist mehr als ein Label. Es zeigt dir, wo du in der Pipeline sitzt — vor dem Commit, im Review oder erst kurz vor dem Merge — und welche Fallen zu deinem Stil gehören. Wer weiß, dass er grünen Tests zu schnell glaubt, reviewt anders. Wer merkt, dass er jeden Agent-Output Zeile für Zeile nachliest, kann gezielt entscheiden, wo Loslassen sicher wäre.
Woran sich dein KI-Arbeitstyp entscheidet.
Vier Verhaltensachsen, durch die Software-Entwicklung-Linse gelesen. Dein 4-Buchstaben-Code ergibt sich aus deiner Position auf jeder Achse.
Tab-Taste oder ganzes Ticket
Die erste Achse fragt, wie groß die Häppchen sind, die du abgibst. Am einen Pol steht der Assistent: Du schreibst selbst und lässt dir Signaturen, Testfälle oder den nächsten Block vervollständigen. Am anderen der Autopilot: Der Agent bekommt das Ticket samt Akzeptanzkriterien und meldet sich erst mit fertigem Branch zurück. Beides ist legitim — aber wer abends zehn Tickets abräumt und wer zehnmal Tab drückt, arbeitet in zwei verschiedenen Berufen.
Liest du den Diff wirklich
Was du delegierst, musst du irgendwie absichern — die Frage ist, wie gründlich. Der Prüfer liest jeden Diff Zeile für Zeile, zieht den Branch lokal und testet die Edge Cases von Hand. Der Vertrauer sieht grüne CI, überfliegt die Änderungen und merged. Spannend wird es, wenn Delegation und Kontrolle auseinanderlaufen: Wer ganze Tickets abgibt und trotzdem alles nachliest, hat den Flaschenhals nur verschoben — von der Tastatur ins Review.
Sparringspartner oder Code-Generator
Die dritte Achse trennt, wofür du KI überhaupt öffnest. Der Denkpartner diskutiert Architektur-Entscheidungen, lässt sich Trade-offs zwischen zwei Datenbank-Schemata erklären oder formuliert Debugging-Hypothesen, bevor er eine Zeile ändert. Der Macher lässt produzieren: Migrations, Testabdeckung, Boilerplate, das CRUD fürs neue Feature. Viele Entwickler leben auf der Macher-Seite, ohne es zu merken — und verschenken den Teil, in dem KI vor dem ersten Commit am meisten spart: das Durchdenken.
CLAUDE.md oder einfach drauflos
Die vierte Achse zeigt, wie du steuerst. Der Architekt baut Systeme: eine gepflegte CLAUDE.md oder .cursorrules mit Konventionen, wiederverwendbare Prompts für Tests und Reviews, klare Regeln, welche Dateien der Agent anfassen darf. Der Improvisierer steuert im Dialog — er promptet, schaut, korrigiert, promptet nach. Zusammen mit den anderen drei Achsen ergibt das deinen Vier-Buchstaben-Code: kein Urteil über gut oder schlecht, sondern eine Landkarte, wo du stehst und was daneben liegt.
Drei Typen, die dir in Software-Entwicklung ständig begegnen.
Der Produzent
„Baut Pipelines und prüft die Ausfahrt.“
In Teams mit reifem CI/CD oft der natürliche Endzustand: ganze Tickets an den Agenten, aber nichts geht ohne Review und Pipeline durch. Du erkennst den Produzenten an der gepflegten Agent-Konfiguration, an Branches, die wie am Fließband entstehen — und daran, dass er den Diff trotzdem liest, bevor er merged.
Der Feinmechaniker
„Handwerk mit KI, kontrolliert und in Serie.“
Häufig bei Entwicklern, die KI ernst nehmen, aber die Hand am Code behalten wollen — gern in Codebases, in denen ein falscher Merge teuer wird. Der Feinmechaniker delegiert klein und systematisch: erprobte Prompts für Unit-Tests, Refactorings, Doku. Jede Vervollständigung wird gelesen, nichts landet ungeprüft im Commit.
Der Generalist
„Viel, schnell, geprüft, egal was reinkommt.“
Der Typ, der montags die Migration, dienstags das Frontend-Feature und mittwochs das Deploy-Skript an den Agenten gibt — ohne großes Setup, einfach im Dialog. Schnell und pragmatisch, aber mit Disziplin an der entscheidenden Stelle: Gelesen wird trotzdem, bevor etwas auf main landet. Häufig bei Fullstack-Entwicklern und in kleinen Teams.
Ehrlich: Diese Verteilung ist eine plausible Modell-Annahme, noch keine gemessenen Nutzerdaten. Sobald genug Menschen aus der Rolle den Test gemacht haben, wird sie echt.
Wo KI-Nutzung in Software-Entwicklung typischerweise kippt.
Grüne Tests, die nichts beweisen
Wenn der Agent Code und Tests im selben Lauf schreibt, testen die Tests oft nur, was der Code ohnehin tut — Mocks überall, Assertions aufs Offensichtliche, Edge Cases ausgespart. Die CI wird grün, das Feature ist trotzdem kaputt. Gegenzug: Review die Tests vor dem Code. Oder schreib die entscheidenden Testfälle selbst und lass den Agenten dagegen implementieren.
Review-Müdigkeit bei sauberen Diffs
KI-Code sieht idiomatisch aus: konsistente Namen, ordentliche Struktur, plausible Kommentare. Genau das schläfert das Review ein — nach dem zehnten 400-Zeilen-Diff der Woche liest du nur noch quer und approvest auf Optik. Gegenzug: Diff-Größe deckeln und nach Risiko statt nach Stil reviewen — Auth-Pfade, Datenbankzugriffe und Fehlerbehandlung zuerst. Was du nicht ernsthaft lesen kannst, forderst du in kleineren Stücken an.
Abhängigkeiten, die es nicht gibt
Modelle erfinden gelegentlich Bibliotheken und API-Methoden, die plausibel klingen, aber nicht existieren — oder in der installierten Version anders heißen. Wer den Vorschlag durchwinkt, installiert im schlimmsten Fall ein Paket, das jemand genau unter diesem halluzinierten Namen registriert hat. Gegenzug: Jede neue Dependency vor dem Install kurz nachschlagen — Registry, Downloads, Repo — und API-Aufrufe gegen die Doku der Version prüfen, die wirklich im Lockfile steht.
Architektur-Drift durch tausend kleine Ja
Jeder einzelne Agent-Vorschlag ist lokal vernünftig — und nach drei Monaten hat die Codebase vier Arten, HTTP-Fehler zu behandeln, und zwei parallele Utils-Ordner. Niemand hat das entschieden, es ist passiert. Gegenzug: Konventionen dahin schreiben, wo der Agent sie liest — CLAUDE.md, .cursorrules, Lint-Regeln — und im Review nicht nur fragen „funktioniert das?“, sondern „gehört das so in dieses System?“.
Bevor du loslegst.
Ich nutze KI nur als Autocomplete — ist der Test dann überhaupt für mich?
Gerade dann. Der Test misst ein Spektrum, keine Mindestanforderung — wenig zu delegieren ist eine Position auf der Achse, kein Defizit. Interessant wird es, wenn du siehst, welcher Buchstabe bei dir aus Überzeugung dort steht und welcher nur aus Gewohnheit.
Ist das seriös oder ein Horoskop für Entwickler?
Kognit behauptet nicht, ein validiertes Testverfahren zu sein — es ist ein psychologisches Modell aus vier Verhaltensachsen. Der Unterschied zum Horoskop: Es beschreibt beobachtbares Verhalten, das du gegen deine eigene Praxis prüfen kannst — deine PRs, deine Commits, dein Review-Verhalten. Wenn das Ergebnis nicht passt, merkst du das sofort.
Was bekomme ich kostenlos — und wofür sind die 14 €?
Der Test selbst ist komplett kostenlos: 24 Fragen, rund 4 Minuten, am Ende dein Vier-Buchstaben-Typ mit Kurzprofil. Der volle Report kostet einmalig 14 € — kein Abo — und schlüsselt deine Position auf allen vier Achsen auf, samt der blinden Flecken, die zu deinem Typ gehören. Erst testen, dann entscheiden — die Reihenfolge ist bewusst so gebaut.
Finde deinen KI-Arbeitstyp.
Wie viel du dem Agenten gibst und wie genau du hinschaust, entscheidest du ohnehin bei jedem Ticket — meist unbewusst. 24 Fragen, rund 4 Minuten, kostenlos: Danach hat dein Stil einen Namen.
Test starten — kostenlos