Powered by Claude Haiku + Supabase pgvector. Keine Chatverläufe gespeichert. Datenschutz

↓ scroll to see posts

Posts

Warum ich vier Coding-Agents gleichzeitig nutze
Claude Code, Codex, Antigravity, OpenCode. Alle vier parallel im Einsatz. Keiner allein reicht. Warum die Kombination entscheidet und ohne meinen Vault jeder Wechsel ein Kaltstart wäre.
Was mein Obsidian Vault mit dem Teamwork Graph gemeinsam hat
Zwei Knowledge Graphen, ein Prinzip. Fast 400 Connections privat, Millionen im Unternehmen. Warum Kontext wichtiger ist als das Modell.
64 Job-Analysen später: Warum ich lieber baue als rede
Warum ich auf greifbare Projekte setze anstatt auf undurchdachtes Bewerben. Und was ich alles daraus lerne.
← Zurück zu allen Posts

Warum ich vier Coding-Agents gleichzeitig nutze

Ich arbeite aktuell mit vier verschiedenen Coding-Agents parallel. Claude Code, Codex, Antigravity und OpenCode. Nicht weil ich mich nicht entscheiden kann. Sondern weil keiner allein reicht.

Gefühlt wird jede Woche ein neues Feature geshipped. Die Tools entwickeln sich so schnell, dass sich die Rollen regelmäßig verschieben. Was vor zwei Monaten noch der beste Ansatz war, ist heute überholt. Wer nur ein Tool nutzt, verpasst das.

Das Ganze funktioniert nur, weil alle auf die gleiche Wissensbasis zugreifen: meinen Obsidian Vault. Dort dokumentiere ich Skills, Workflows und Projekt-Kontexte. Lokale Skills in Claude Code gehen verloren, sobald ich in einer Cloud-Session arbeite. Also liegt alles im Vault. Egal welchen Agent ich öffne: der Kontext ist schon da.

Claude Code macht die Hauptarbeit

Das Setup für diesen Blog kam komplett von Claude Code. Chatbot, Embedding-Pipeline, Edge Functions, Chat-Widget. Genauso meine Career Pipeline Webapp: 207 aktive Jobs, Claude vergleicht mein Profil automatisch mit Stellenangeboten und scored sie. Oder die Landingpages, die ich für lokale Unternehmen baue: Google Maps scrapen, Leads bewerten, Claude generiert in zehn Minuten eine fertige Seite. Headless CMS drauf, deployen, fertig.

Alles Claude Code. Aber es hat einen blinden Fleck: Es fällt ihm selten auf, wenn er selbst etwas falsch gemacht hat.

Codex als Auditor

Genau dafür nutze ich Codex. Triangulation zwischen Modellen. Ich lasse Codex den Output von Claude Code auditen. Codex findet Fehler, die Claude übersieht. Und umgekehrt.

Ein einzelnes Modell prüft sich selbst schlecht. Zwei Modelle, die sich gegenseitig kontrollieren, sind deutlich zuverlässiger. Das merke ich jedes Mal, wenn Codex einen Bug findet, den Claude dreimal überlesen hat.

Antigravity für Recherche

Nach dem 2.0 Update nutze ich Antigravity vor allem für Deep Research, zusammen mit Perplexity. Wenn ich ein Thema wirklich verstehen will, bevor ich baue. Manchmal schreibe ich auch Code damit. Pragmatisch ist es auch eine Frage der Token: mit dem Pro-Abo bei Claude stoße ich regelmäßig ans Limit. Da hilft ein zweiter starker Agent.

OpenCode für die Routinearbeit

OpenCode hat bei mir keine starken Modelle angeschlossen. Das ist Absicht. Ich nutze es für Aufgaben, für die ich nicht meine guten Token verschwenden will: Obsidian Cleanup, Transkripte prüfen, kleine Skripte. Für meine Bachelorarbeit habe ich einen eigenen Audit-Prompt gebaut, der erkennt wenn KI-generierter Text in generischen Ton abrutscht. Prüfen statt umschreiben. Das kann auch ein schwächeres Modell.

Nicht das Tool, die Kombination

Die Diskussion „Welches Coding-Tool ist das beste?" geht am Punkt vorbei. Claude Code schreibt den besten Code, aber prüft sich selbst schlecht. Codex ist ein starker Auditor, aber nicht mein Go-to fürs Bauen. Antigravity recherchiert tief, OpenCode erledigt die Routine.

Die eigentliche Stärke liegt nicht in einem einzelnen Tool. Sie liegt darin, dass alle auf den gleichen Kontext zugreifen und ich die Rollen anpassen kann, sobald sich die Tools weiterentwickeln. Ohne meinen Vault wäre jeder Wechsel ein Kaltstart. Mit ihm ist es ein System.

← Zurück zu allen Posts

Was mein Obsidian Vault mit dem Teamwork Graph gemeinsam hat

Ich pflege aktuell zwei Knowledge Graphen parallel. Einen privaten in Obsidian. Einen im Unternehmen über den Atlassian Teamwork Graph.

Mein Obsidian Vault ist mein persönliches Wissenssystem. Jede Notiz hat Metadaten, Tags und Wikilinks. Projekte verlinken auf Quellen, Quellen auf Analysen, Analysen auf Tasks. Für meine Bachelorarbeit allein habe ich über 50 Quellen fest verknüpft. Insgesamt fast 400 Connections zwischen Themen.

Obsidian Graph View — Mein Knowledge Graph mit fast 400 Connections

Ich baue Apps, die direkt auf diesen Vault zugreifen. Jeder Output fließt zurück in die gleiche Struktur. Wenn ich Claude morgens um 06:30 nach meinem aktuellen Stand frage, ist die Antwort in unter einer Minute da. Nicht weil das Modell so gut rät. Sondern weil der gesamte Kontext schon da ist: Deadlines, offene Tasks, letzte Änderungen, verlinkte Quellen.

Mittlerweile arbeiten mehrere Agentic AIs gleichzeitig auf dem Vault. Die Tags an meinen Notizen helfen beim Clustern: #project, #intelligence, #blog. So hat jeder Agent weitere Hints, um den richtigen Kontext zu finden. Ohne dass ich alles manuell steuern muss.

Gleiche Architektur, anderer Maßstab

Im Unternehmen sieht das Prinzip identisch aus. Ich schreibe gerade meine Bachelorarbeit bei Uhlmann. Wir sind ein führendes produzierendes ISO-Unternehmen, alles bis aufs kleinste Detail dokumentiert. Der Atlassian Teamwork Graph verbindet Personen, Projekte, Dokumente und Entscheidungen zu einem Netzwerk mit Millionen Connections. Dazu kommen Rechte- und Compliance-Layer, die im persönlichen Vault nicht nötig sind.

Auf der TEAM26 hat Atlassian den Teamwork Graph als zentralen Context Layer für alle KI-Features positioniert. Rovo-Agenten durchsuchen mehrere Wissensbasen gleichzeitig. Der dazu gekaufte Browser Dia ist an den Teamwork Graph angeschlossen und kann zusätzlich das Web durchsuchen. Mehr Kontext, besserer Output.

Strukturell funktionieren mein Vault und der Teamwork Graph gleich: Knoten (Personen, Projekte, Dokumente) verbunden durch Beziehungen. Tags clustern thematisch. Je dichter und sauberer das Netzwerk, desto besser die Ergebnisse für die KI. Der Unterschied ist Skalierung. Das Prinzip dahinter ist dasselbe. Zumindest von dem was ich mitbekommen habe ;)

Pflege ist der eigentliche Job

Der Teil, der keinen Spaß macht, ist bei beiden identisch: Pflege.

In meinem Vault heißt das wöchentlich Verknüpfungen prüfen, Tags setzen, neue Versionen aufbereiten. Ich mache das, damit der Inhalt im Knowledge Graph aktuell und auffindbar bleibt. Sobald ich das schleifen lasse, arbeiten meine AIs mit veralteten Infos oder finden relevante Notizen gar nicht mehr. Bei mehreren Agents gleichzeitig merke ich das sofort.

Im Unternehmen muss das Team seine Tickets, Confluence-Seiten und Freigaben aktuell halten. Sonst liefert Rovo Antworten auf Basis veralteter Daten. Garbage in, garbage out. Das gilt bei 50 verlinkten Quellen genauso wie bei Millionen Connections.

Nicht das Modell ist der Flaschenhals

Ich habe über 40 Rovo-Agenten für Prozessautomatisierung, Ticket-Analyse und Wissenssuche erstellt, getestet und deployed. Trotz bester Datengrundlage waren die Outputs oft noch ausbaufähig. Bei uns limitieren aktuell die Agenten-Fähigkeiten, nicht die Daten.

Bei den meisten Unternehmen ist es umgekehrt. Sie scheitern an der Kontext-Qualität, obwohl die Modelle längst stark genug wären.

Die Tags an diesem Post — blog, atlassian, context, obsidian — helfen übrigens auch beim Clustern. Nicht nur für mich. Auch für die AIs, die auf meinen Vault zugreifen.

Wer seine KI verbessern will, sollte nicht beim Modell anfangen. Sondern beim eigenen Knowledge Graph.

← Zurück zu allen Posts

64 Job-Analysen später: Warum ich lieber baue als rede

Ich habe gerade 207 aktive Jobs in meiner Pipeline. 64 davon habe ich mir schon im Detail angeschaut. Jetzt geht's erst ans eigentliche Bewerben.

Das klingt erst mal nicht nach Fortschritt. Für mich war es genau das.

Man muss dazu wissen: Ich finde Gefallen an extrem vielen Themen. Am liebsten würde ich mich einmal durch alle Tech- und KI-bezogenen Jobs durchprobieren. Das einzige Problem dabei: In meinem Studium (Management, Communications, IT) haben wir zwar die Basics vom Programmieren mitbekommen, aber eben nicht so deep wie ich es manchmal gerne hätte.

Gefühlt jede zweite Stellenausschreibung fordert Python-Kenntnisse, Know-how über Vektor-Datenbanken, Chunking und Co.

Dieser Text liegt in Chunks

Tadaaa. Und jetzt kannst du hier mit meinem Chatbot schreiben. Beim Bauen lasse ich mir die Themen einfach direkt erklären: Warum teile ich meine Texte in Chunks auf? Wie schaffe ich es, dass das System sicher ist und nicht ein einziger User meine ganzen Token in einer Session verbraucht? Am Ende verstehe ich die theoretischen Anforderungen dadurch als anwendbare Lösung.

Der Text, den du gerade liest, liegt übrigens in Supabase. Du müsstest dich gerade zwischen dem ersten und zweiten Chunk befinden. Wenn du mit dem Chatbot schreibst, vergleicht das Modell die Patterns des Chunks hier mit der Anforderung deines Prompts. Bei einer Übereinstimmung nutzt es diesen Abschnitt als Kontext, anstatt mit einfachen SQL-Anfragen nach gezielten Wörtern zu suchen. Und falls du versuchst, alle meine Token leerzusaugen: Viel Glück, ich nutze Upstash fürs Ratelimiting. ;)

Business trifft Code

Jetzt, wo das Erstellen von Apps und Software spürbar einfacher geworden ist, kann ich meine Lücken in der reinen Programmierung ziemlich gut ausgleichen. Und plötzlich lohnt sich auch der ganze Rest des Studiums: die Grundlagen von BWL, Recht, Prozess- und Projektmanagement, Marketing und vor allem die Praxisprojekte direkt mit Unternehmen.

Ich kann erkennen, wo ein System uns weiterbringt und meine eigenen Prozesse unterstützt. Und ich verstehe, wie wichtig die systemseitige und rechtliche Absicherung ist. Für dieses Business-Wissen muss ich jetzt „nur" noch das jeweils richtige Tool oder die passende technische Lösung finden.

Diese Learnings bleiben bei mir hängen. Innerhalb weniger Stunden, direkt am Projekt. Schließlich liegt mein Hauptfokus gerade eigentlich auf meiner Bachelorarbeit. Der Rest sind late night Projekte.

Projekte statt Bewerbungen

Deshalb setze ich auf greifbare Projekte statt auf massenhafte Bewerbungen.

Ich will nicht in ein Interview gehen und sagen: „Ja, ich habe im Studium mal was von RAG-Architekturen und APIs gehört." Ich will sagen: „Schau dir kilianwarmdt.de an. Versuch mal, den Chatbot auszutricksen."

Ein weiteres Beispiel ist meine Career Pipeline Webapp. 207 aktive Jobs, 64 detailliert evaluierte Stellen. In Notion hätte ich das nie gepflegt. Also habe ich mir ein eigenes System gebaut: Claude vergleicht mein Profil direkt mit den Stellenangeboten und legt sie in meiner App ab. Von dort schiebe ich die Angebote wie in einem CRM in die nächsten Stages. Gleichzeitig updatet sich mein Obsidian Vault. Damit hat meine AI immer den aktuellen Stand und ich habe alle Daten für eine Deep Analysis bereit.

Das schätze ich am praktischen Umsetzen: Ich lerne extrem viel in kurzer Zeit und optimiere gleichzeitig meine eigenen Alltagsprobleme.

Und vielleicht bringt es ja auch einen echten Vorteil in einem Jobmarkt, der für junge Menschen gerade nicht leicht ist. Alle behaupten, sie könnten mit KI arbeiten. Ich möchte lieber anhand meiner Beispiele zeigen, dass ich es kann.