Wie ich baue.
Ich bin kein klassischer Entwickler. Ich kann keinen Code schreiben auf dem Level, auf dem diese Produkte gebaut sind.
Trotzdem baue ich Softwareprodukte. Nicht, weil AI alles alleine macht, sondern weil sich die Arbeit anders verteilt. Ich muss nicht jede Zeile Code selbst schreiben. Ich muss verstehen, was gebaut werden soll, wie das Produkt funktionieren muss, wie ein Interface sich anfühlen soll, wo Fehler entstehen können und wann ein Ergebnis nicht gut genug ist.
Mein Alltag besteht deshalb weniger aus Tippen und mehr aus Steuern, Prüfen und Nachschärfen.
Vier Dinge kombiniere ich fast täglich:
Claude Code war lange mein primärer Implementer. Ich gebe Scope, Produktlogik, UI-Verhalten, Datenstrukturen und Fehlfälle vor. Claude setzt große Teile davon direkt im Code um. Mit Opus 4.5 hat sich das teilweise extrem stark angefühlt. Später wurde es für mich deutlich unzuverlässiger. Deshalb ist Claude heute nicht mehr automatisch gesetzt, sondern ein Werkzeug unter mehreren.
Codex nutze ich als Kontrollinstanz und zweiten Blick. Es prüft Implementierungen, findet Logikfehler, erkennt unsaubere Stellen und hilft mir einzuschätzen, ob ein Output wirklich tragfähig ist. Gerade weil ich kein klassischer Entwickler bin, ist dieser Review-Layer wichtig. Ein Agent baut, ein anderer prüft. Ich entscheide, was davon übernommen wird.
Obsidian ist mein Gedächtnis. Dort liegen Specs, Produktentscheidungen, Prompts, Feature-Ideen, Architektur-Notizen und offene Fragen. Ohne diese Dokumentation würde der Kontext zwischen Sessions verloren gehen. Mit ihr können Agents deutlich besser arbeiten, weil sie nicht jedes Mal bei null anfangen.
Sprachinput hilft mir beim Durchsatz. Ich diktiere Specs, Prompts, Dokumentation und Kommentare, statt alles zu tippen. Das ist kein eigenes Kern-Tool in meiner Positionierung, sondern ein Arbeitsmodus, mit dem ich länger und genauer formuliere.
Ich nutze diese Arbeitsweise nicht nur für klassischen Produktcode. Ich baue damit auch Websites, Interfaces, Landingpages, interne Tools und Automations.
Gerade bei Automations hat sich für mich viel verändert. Früher war der natürliche Weg für Nicht-Entwickler oft eine No-code-Plattform wie n8n. Das ist weiterhin nützlich, aber nicht mehr automatisch notwendig. Viele Workflows, für die man früher visuelle Automations zusammengeklickt hätte, kann ich heute direkt als kleine interne Tools, Edge Functions, Scripts oder API-Logik bauen lassen. Das ist oft flexibler, sauberer versionierbar und näher am eigentlichen Produkt.
Die Konsequenz ist keine magische Abkürzung. Ich muss trotzdem sauber denken. Wahrscheinlich sogar sauberer als vorher, weil schlechte Anweisungen sofort in schlechten Outputs enden.
Meine Rolle ist nicht: Ich schreibe Code.
Meine Rolle ist: Ich manage Agents, Kontext und Qualität.
Ich schneide Aufgaben klein genug, liefere den nötigen Kontext, prüfe Ergebnisse, erkenne Fehlentwicklungen und entscheide, was in die echte Codebase darf. Wenn etwas nicht funktioniert, muss ich herausfinden, ob das Problem im Prompt liegt, im Modell, in der Architektur oder in meiner eigenen Beschreibung.
Dieser Tool-Stack ist nur der aktuelle Stand. Vor einiger Zeit war ChatGPT für viele Aufgaben mein stärkster Startpunkt. Dann war Claude lange vorne. Aktuell schaue ich stärker auf Codex, Kimi, Gemini und andere Systeme, weil sich die Qualität ständig verschiebt.
Deshalb versuche ich, mich nicht zu sehr an ein einzelnes Tool zu hängen. Was bleibt, ist die Arbeitsweise: Kontext sauber dokumentieren, Agents gezielt einsetzen, Outputs kritisch prüfen und schnell wechseln, wenn ein Werkzeug nicht mehr gut genug ist.