Wie ich als Full-Stack-Entwicklerin KI nutze: mein echter Automatisierungs-Stack

Man stellt mir eine Version derselben Frage: „Du baust Websites und KI-Lösungen — wie viel von deiner eigenen Arbeit macht die KI eigentlich?" Die ehrliche Antwort ist mehrschichtig. KI schreibt einen großen Teil des ersten Entwurfs meines Codes. Sie trifft keine der Urteilsentscheidungen. Sie fährt ganze Pipelines in diesem Projekt unbeaufsichtigt. Sie rührt Produktion nie an, ohne dass zuerst ein Mensch den Diff gelesen hat. Unten ist der tatsächliche Stack, nicht die Pitch-Version.

1. Code: Pair Programming, kein Autopilot

Der Großteil meiner täglichen KI-Nutzung ist Claude Code, das neben mir im Terminal sitzt, direkt in diesem Repository. Ich beschreibe eine Komponente, einen Bug, ein Refactoring über die sieben Sprachordner unter src/app hinweg, und es entwirft die Änderung. Ich lese jeden Diff, bevor er landet — genauso, wie ich den PR eines Juniors reviewen würde. KI ist sehr gut in „wende dieses Muster konsistent auf 40 Dateien an" und merklich schlechter in „entscheide, ob dieses Muster überhaupt existieren sollte". Diesen zweiten Job behalte ich also.

Die konkreten Gewinne: einmal eine neue Page-Factory aufbauen und die KI daraus jede Locale-Variante verdrahten lassen, den ersten Durchgang einer Vitest-Suite für eine neue lib-Funktion schreiben, einen Stack Trace in eine klare Root-Cause übersetzen, bevor ich selbst zu graben anfange, und Commit-Messages aus einem Diff entwerfen, damit ich nicht auf einen leeren Cursor starre.

2. Content- und i18n-Pipelines, die ohne mich laufen

Diese Site liefert jeden Blogpost in bis zu sieben Sprachen aus: en, ua, de, fr, es, it, tr. Die englische und die ukrainische Version schreibe ich von Hand — dieser Teil bleibt meiner, weil Ton und technische Präzision wichtig sind und ich keine maschinenübersetzte Stimme als meine eigene will. Die übrigen Sprachen füllen Skripte in scripts/, die den lokalisierten Content-Baum durchlaufen und für jedes Feld ohne Locale eine Übersetzungs-API aufrufen, das Ergebnis cachen, damit erneute Läufe nicht für Strings zahlen, die ich schon habe, und laut fehlschlagen statt still einen leeren String in eine Seite zu schreiben.

Derselbe Automatisierungsinstinkt zeigt sich auch außerhalb des Blogs: sitemap.ts regeneriert beim Build jede Route über jede Locale hinweg, statt dass ich eine Liste von Hand pflege, der RSS-Feed und die Dateien llms.txt / llms-full.txt werden aus denselben Post-Daten abgeleitet, sodass sie nicht aus dem Takt mit dem tatsächlich Veröffentlichten geraten können, und CI fährt bei jedem Push den vollen Test- und Lint-Durchlauf, bevor irgendetwas den nextjs.yml-Deploy-Workflow erreicht.

3. KI innerhalb des Produkts, nicht nur drumherum

Die andere Hälfte von „KI in meinem Workflow" ist das, was ich für GEO ausliefere — generative engine optimization, ein Site so lesbar für ein LLM zu machen, wie SEO sie für einen Suchcrawler lesbar macht. Konkret: llms.txt und llms-full.txt beschreiben diese Site in einem Format, das ein Agent direkt parsen kann, JSON-LD-strukturierte Daten auf Service- und Blogseiten, damit ein Modell Fakten extrahiert statt aus Prosa zu raten, und eine Schema-Markup-Komponente, die mit dem tatsächlichen Seiteninhalt synchron bleibt statt ein statischer Block, den jemand zu aktualisieren vergessen hat.

Das ist die Grenze, die mich tatsächlich interessiert: KI, die mir hilft, die Site zu bauen, ist für eine Besucherin unsichtbar. KI, die hilft, dass die Site selbst von anderer KI verstanden wird, ist ein Feature, das ich explizit baue und teste — es gibt eine eigene Vitest-Suite für die GEO-Feed-Helfer, genau damit das nicht still verrottet, wie es eine ungetestete Integration irgendwann tut.

4. Wo ich den menschlichen Platz behalte

Nichts davon bedeutet, dass KI entscheidet, was ausgeliefert wird. Sie wählt nicht die Informationsarchitektur, sie wählt nicht, welche Service-Seiten existieren, sie entscheidet nicht, dass ein Kontaktformular eine Validierungsregel mehr statt drei Felder weniger braucht — dieses Urteilsvermögen ist die eigentliche Arbeit, und genau dafür bezahlen Kund:innen, wenn sie eine Entwicklerin statt eines Generators einstellen. KI entwirft; ich merge. KI übersetzt; ich schreibe die Quelle. KI schlägt ein Refactoring vor; ich entscheide, ob die Abstraktion ihren Platz verdient — nach derselben Disziplin, keine Struktur hinzuzufügen, die die Codebasis noch nicht braucht.

Wenn Sie herausfinden wollen, wo KI in einem echten Produkt wirklich Zeit spart — im Gegensatz zu dort, wo sie nur die Review-Last verschiebt —, ist das meist die richtige Frage, bevor man irgendetwas automatisiert: Welche Entscheidung nehme ich einem Menschen tatsächlich ab, und bin ich damit einverstanden, dass diese Entscheidung ein Skript trifft?

Soll das auch für Ihr Projekt aufgesetzt werden?

Diese Art von KI-unterstütztem, automatisierungsorientiertem Workflow baue ich auch in Kundenprojekte ein — von CI-gated Deploys bis zu GEO-bereiter Content-Struktur. Melden Sie sich über das Kontaktformular und sagen Sie mir, welcher Teil Ihres Prozesses Ihnen noch die Woche frisst.