Agentic Coding aus Anwender-Sicht — Erfahrungen: Die Arbeit verschwindet nicht, sie verlagert sich

Veröffentlicht 05.09.2026
von

Seit dem Frühjahr 2026 entstehen zwei Projekte mit demselben Coding-Agenten: ein ETL-Generator auf Next.js und PostgreSQL und dieser Blog. Der Agent vervollständigt keine Zeilen, er arbeitet Aufträge im Repository ab. Dieser Artikel sammelt meine Erfahrungen mit Agentic Coding aus Anwender-Sicht. Ich entwickle Datenbanken, ETL-Prozesse und das Framework dahinter und nutze den Agenten als Werkzeug, ohne selbst an KI zu forschen oder KI-Werkzeuge zu bauen.

Lohnt sich das? Ja. Ich habe jahrelang Client-Server-Anwendungen mit VB.NET und C# gebaut und baue jetzt eine TypeScript-Anwendung, ohne TypeScript zu beherrschen. Das ist der sichtbare Gewinn. Der weniger sichtbare Teil ist, dass sich die Arbeit verlagert hat: vom Programmieren zum Strukturieren. Regeln und Skills für den Agenten, Feature-Specs, Bug-Dateien, Testfälle, Dokumentation. Diese Arbeit haben in meinem Berufsleben bisher andere geliefert, eine Projektleitung zum Beispiel, und ich habe sie als Entwickler konsumiert. Ihren Umfang habe ich unterschätzt.

Das Wichtigste vorab:

  • Lohnt sich das? Ja: Eine TypeScript-Anwendung mit Frontend, Tests und CI, gebaut von jemandem, der TypeScript nicht beherrscht, aber Datenbanken, ETL und .NET kennt.
  • Die Arbeit ist nicht weg, sie hat sich verlagert: Regeln, Skills, Specs, Bug-Dateien, Testfälle, Dokumentation. Das haben früher Projektleitung und Team geliefert.
  • Die Vorgabe lebt im Repo, nicht im Prompt: Die Prompts sind kurz, weil Regel-Dateien und Specs die Arbeit tragen. Das gilt auch für Zwischenstände.
  • Die Infrastruktur war die größte Hürde: ein Server mit vier Umgebungen, eigene Identity, Container, TLS, ohne Cookie-Banner, weil die Architektur keinen braucht.
  • Kontrolle ist eine Schleife: Ein Agent erweitert den Radius dessen, was ich bauen kann, nicht den Radius dessen, was ich beurteilen kann. Was ich nicht beurteilen kann, läuft deshalb durch wiederkehrende Kontrollen, die der Agent ausführt. Ein grünes Signal ist dabei kein Beleg.
  • Dieser Artikel ist selbst ein Beispiel: Der Entwurf stammt vom Agenten, Auswahl, Korrekturen und Veröffentlichung sind meine Arbeit.

Voraussetzung: keine. Wer tiefer einsteigen will, findet am Ende den Weg in die technischen Artikel dieses Blogs.

Inhalt

Was Agentic Coding hier meint

Ein Coding-Agent ist ein Sprachmodell, das mit Werkzeugzugriff in einem Repository selbstständig mehrere Schritte hintereinander ausführt: Dateien lesen, Kommandos starten, Code ändern, Tests laufen lassen, committen. Der Unterschied zur Autovervollständigung liegt nicht in der Qualität einzelner Zeilen, sondern im Arbeitsmodus. Ich formuliere einen Auftrag, der Agent arbeitet ihn ab und meldet ein Ergebnis.

In beiden Projekten ist das Werkzeug Claude Code, im Terminal und in VS Code. Die Beobachtungen hängen aber nicht am Produkt, sondern daran, dass ein Agent Zugriff auf Repository, Shell und Datenbank hat und ein Mensch entscheidet, was damit passiert. Die Mechanik hinter Regel-Dateien, Skills und Sub-Agenten beschreibt der Hub-Artikel KI-gestützte SQL-Entwicklung mit Claude Code. Hier geht es um das, was sie in meinem Alltag verändert hat.

Fallstudie 1: Eine TypeScript-Anwendung ohne TypeScript-Kenntnisse

Das App-Projekt heißt DI² und ist ein ETL-Generator auf Next.js und PostgreSQL. Die Datenbank-Schicht besteht aus mehr als 150 DDL-Dateien, das Repository ist privat, und ich arbeite allein daran. ETL-seitig bauen die Werkzeuge der App auf einem eigenen Framework auf, das ich schrittweise auf GitHub veröffentliche.

Von .NET zu TypeScript

Was ich mitbringe, sind Datenmodelle, SQL, ETL-Prozesse und Jahre mit Client-Server-Anwendungen in VB.NET und C#. Ich weiß, wie eine Anwendung mit Datenbank, Geschäftslogik und Oberfläche geschnitten wird, wo Zustand lebt und wo Fehler entstehen. Was ich nicht mitbringe, ist die Sprache. TypeScript, das React-Ökosystem und die Test-Werkzeuge der Web-Welt kannte ich vorher nicht, und ich kann eine Datei dieser Anwendung bis heute nicht so lesen wie eine gespeicherte Prozedur.

Das Frontend, die CI-Pipeline und die Test-Infrastruktur sind trotzdem entstanden. Am deutlichsten zeigt es das Node-Skript mit 241 Zeilen, das die SQL-Konventionen des Projekts prüft und das ich nicht hätte schreiben können. Meine Rolle war eine andere: Ich kannte die Konventionen, konnte ein Finding als richtig oder falsch beurteilen und habe die Rahmen-Entscheidungen getroffen. Die Abnahme lief über Läufe, nicht über das Lesen des Codes, wie der Artikel zum Guard zeigt. Ein Agent erweitert den Radius dessen, was ich bauen kann. Er erweitert nicht den Radius dessen, was ich beurteilen kann. Wo beides auseinanderfällt, braucht die Abnahme ein Kriterium, das ohne Code-Verständnis prüfbar ist.

Konventionen im Repo statt im Kopf

In einem klassischen Solo-Projekt stehen die Konventionen im Kopf des Entwicklers. Mit einem Agenten, der jede Session ohne den Verlauf der vorherigen beginnt, funktioniert das nicht. Im DI²-Projekt sind daraus 27 Regel-Dateien geworden, inzwischen 28, eine pro Konvention, jede mit Begründung. Features und Bugs bekommen eigene Dateien mit fortlaufender ID, bevor eine Zeile Code entsteht. Wie ein solches Regelwerk aus dem Bestand entsteht, beschreibt der Generate-Refine-Derive-Loop. Was es kostet, wenn Regeln allein nicht reichen, zeigen 799 hartkodierte Schriftgrößen trotz eindeutiger Design-Regel.

Eine zweite Hälfte dieser Regel habe ich erst im Schadensfall bemerkt. Ich beendete versehentlich eine Session mitten in einem Bugfix und bat in einer neuen darum, dort weiterzumachen. Der Agent fand keine Reste, weder im Arbeitsbaum noch im Stash. Dass der Wiedereinstieg trotzdem nur Minuten dauerte, lag an der Bug-Datei im Repository: Fehlerbeschreibung, Datenbank-Beleg, Reproduktionsschritte und drei benannte Hypothesen samt Prüfreihenfolge. Der Zwischenstand lebt im Repo, oder er lebt nicht.

Die Infrastruktur war die größte Hürde

Der Teil des Projekts, der mich am meisten Zeit gekostet hat, ist keine Zeile Anwendungscode, sondern die Infrastruktur darunter. Die Anwendung läuft auf einem einzelnen VPS bei Hetzner, und auf dieser Maschine leben vier Umgebungen: Entwicklung, Integration, Test und Produktion, jede mit eigenem Checkout, eigener Datenbank und eigenem Port. Dazu kommen ein selbst betriebener Keycloak als Identity Provider und ein nginx, der TLS terminiert und Anfragen nach Hostname verteilt. Gut ein Dutzend Container laufen dort. All-Inkl, der Hoster dieses Blogs, spielt nur zwei Nebenrollen: DNS und Postfächer. Eine der ersten Lektionen war, dass der VPS-Anbieter ausgehende Mail-Ports blockt.

Die Identität selbst zu betreiben war die größte Einzel-Hürde: ein Realm je Umgebung, ein Login-Theme in zwei Sprachen, die Migration vom Passwort-Login zum externen Identity Provider und vom Zwei- zum Vier-Rollen-Modell. Die Provisionierung erledigt heute ein Skript von knapp 500 Zeilen Bash, das beliebig oft laufen kann, ohne beim zweiten Mal etwas zu ändern. Ich habe davon keine Zeile geschrieben. Ich habe entschieden, dass es einen Server gibt statt vier, eine eigene Identity statt eines Cloud-Dienstes und einen Standort in der EU.

Hinter diesen Entscheidungen steht ein Designziel, auf das ich besonderen Wert gelegt habe: Die Anwendung soll ohne Cookie-Banner auskommen. Das geht nur, wenn sie keine Einwilligung braucht, also keine Tracker, keine Drittanbieter-Skripte und keine Analyse-Dienste im Browser. Übrig bleiben drei technisch notwendige Cookies: Session-Token und CSRF-Token des Logins sowie ein Sprach-Cookie für die öffentlichen Seiten. Für Cookies, die für den ausdrücklich gewünschten Dienst unbedingt erforderlich sind, verlangt § 25 Abs. 2 Nr. 2 TDDDG keine Einwilligung, und die Datenschutzerklärung benennt sie einzeln. Dieselbe Regel gilt für diesen Blog. CI-Pipeline und Datenbank-Deploy beschreibt der Blog bereits im Lebenszyklus von Datenbank-CI/CD, im Deploy per GitHub Actions und im Schema-Deploy ohne Migrations-Tool. Die Infrastruktur dahinter bekommt einen eigenen Artikel.

Lesen ist keine Kontrolle mehr

Zwei Dinge zusammen haben meine Arbeitsweise verändert. Das erste ist die Sprache: Wer die Sprache seines Codes nicht liest, kann ihn nicht durch Lesen kontrollieren. Das zweite ist die Menge. Der Agent schreibt in kurzer Zeit so viele Zeilen, dass ein vollständiges Lesen und Verstehen auch dann nicht möglich wäre, wenn ich die Sprache beherrschte. Das vollständige Lesen des eigenen Codes, wie ich es aus meinen .NET-Projekten kannte, fällt damit als Kontrolle aus. Das ist kein Offenbarungseid, sondern eine zwangsläufige Änderung der Arbeitsweise. Wenn Lesen als Kontrolle ausfällt, muss etwas anderes an seine Stelle treten.

Die Kontroll-Schleife

Die Kontrolle, die ich selbst nicht leisten kann, muss an anderer Stelle stattfinden: in einer Schleife aus Kontrollen, die der Agent ausführt, deren Maßstab aber nicht sein eigenes Urteil ist, sondern Regeln, Tests und Prüfberichte. Sie läuft nicht einmal, sondern wiederkehrend. Nach jedem Feedback wird eine Regel nachgeschärft. Für wiederkehrende Prüfungen gibt es Skills, also versionierte Prompts im Repository, darunter einen für Sicherheits-Audits und einen für Update-Prüfungen. Unit-Tests habe ich nachträglich unter bestehenden Code schieben lassen, das Fundament dafür entstand erst im Juli 2026, inzwischen sind es über 700 Tests. Seit Ende August gibt es einen Katalog manueller Testfälle mit Abnahme-Kriterien. Insgesamt tragen 14 Skills und 28 Regel-Dateien diese Schleife.

Sie hat Dinge gefunden, die ich beim Lesen nicht gefunden hätte. Eine Drossel-Regel im Webserver zeigte seit dem Wechsel des Identity Providers auf einen Endpunkt, den es nicht mehr gab, und sah monatelang wie Schutz aus. Ein anderer Fall begann mit einem vagen Satz von mir, die Seite reagiere kaum. Der Agent verglich alle vier Umgebungen, fand die Produktion ebenso betroffen, obwohl sie den neuen Stand gar nicht hatte, und entdeckte 2,9 GB im Swap. Der Identity-Dienst lag auf der Platte, daher 9,6 Sekunden für den ersten Login und 0,19 Sekunden für jeden weiteren. Kein Anwendungscode war beteiligt. Diese Fehlersuche bekommt einen eigenen Artikel.

Eine Lehre ist mir wichtiger als jede Zahl: Ein Erfolgssignal ist kein Beleg. Eine Test-Suite war vier Wochen grün, während drei Fix-Anläufe an einem Scroll-Fehler vorbeigingen, weil der Test genau den Wert gestubt hatte, dessen Falschheit den Fehler ausmachte. Ein Prüfbericht meldete „bestanden“, und erst meine Rückfrage zeigte, dass der entscheidende Klick-Pfad nie ausgeführt worden war. Beide Signale bezeugen, dass ein Vorgang gelaufen ist, nicht, dass eine Wirkung eingetreten ist. Verifizieren heißt seither, einen zweiten, unabhängigen Weg zur selben Frage zu suchen. Wie man Testfälle schreibt, die das leisten, wird ein eigener Artikel behandeln.

Fallstudie 2: Einen Blog mit einem Agenten schreiben

Dieser Blog wird seit Mai 2026 mit demselben Werkzeug redaktionell betrieben. Damals wurden die Artikel aus WordPress in ein Repository überführt, ein Ordner pro Thema mit deutscher und englischer Fassung. Heute sind es 65 Themen, 55 davon in beiden Sprachen live. Was der Agent hier tut, unterscheidet sich vom App-Projekt weniger, als ich erwartet hätte.

Spec, Runden, Bearbeitungs-Log

Vor jedem Artikel steht eine Spec: Rolle im Themen-Cluster, Zielgruppe, Suchintention, Gliederung, Abgrenzung zu Nachbar-Artikeln. Dann läuft der Artikel durch feste Runden, von der Kritik des Bestands über Struktur und Stil bis zur englischen Fassung. Jede Runde bekommt einen Eintrag in einem Bearbeitungs-Log und einen eigenen Commit. Neun Regel-Dateien tragen die Konventionen, darunter Stil-Heuristiken gegen typische Marker KI-geschriebener Texte: kein Semikolon in der Prosa, höchstens ein Gedankenstrich pro Absatz, keine Wir-Form. Jede dieser Heuristiken ist aus einem Feedback von mir entstanden. Der Agent schreibt Entwürfe, ich korrigiere, und die Korrektur wird zur Regel für den nächsten Artikel.

Der Weg auf die Live-Site bleibt Handarbeit. Ich kopiere den Text in den WordPress-Block-Editor, setze Bilder und SEO-Felder und veröffentliche. Danach verifiziert der Agent remote über Live-HTML und REST-API. Beim Artikel über die funktionale Ästhetik von SQL fand er so vier Defekte in den beiden Sprachfassungen, die im Repository unsichtbar sind, weil sie erst im Editor entstehen: ein Bild, das seit Monaten auf die Datei eines anderen Artikels zeigte, einen SEO-Titel, dem beim Einfügen der letzte Buchstabe fehlte, einen Sprunglink, der wegen eines alten HTML-Ankers ins Leere lief, und in der englischen Fassung einen Link auf den Artikel zu den SSMS-Editor-Optionen, der auf die deutsche statt auf die englische Fassung zeigte. Diesen Link korrigierte ich im Block-Editor zweimal, und zweimal blieb er falsch. Der Agent las den Änderungs-Zeitstempel des Posts über die REST-API aus: Er hatte sich bei keinem der beiden Versuche bewegt, meine Speichern-Klicks waren also keine gewesen. Die Ursache war der Link-Dialog des Editors. Wer die neue URL eintippt und dann außerhalb des Dialogs klickt, statt sie mit Enter oder „Anwenden“ zu bestätigen, verwirft die Änderung, auch wenn er danach „Aktualisieren“ drückt. Beim dritten Anlauf saß der Link. Der Befund steht seither als Hinweis in der Regel-Datei für die Live-Verifikation.

Der Review kommt aus einer frischen Session

Ein Sprachmodell kann einen Text auch bewerten, und ich nutze das von Anfang an. Die Methodik musste ich allerdings selbst entwickeln. Beim Review eines Artikels fiel mir auf, dass ein Modell innerhalb derselben Chat-Session auf seinen früheren Urteilen ankert: Erstbewertung etwa 8 von 10, nach mehreren Überarbeitungen in derselben Session 9,7, in einer frischen Session wieder deutlich kritischer. Die hohen Werte waren nicht Qualität, sondern Verlauf. Seither läuft jeder Review in einer frischen Session eines Modells eines anderen Anbieters, mit einem eingefrorenen Standard-Prompt. Der Score ist Diagnose, nicht Ziel.

Das Ergebnis gebe ich als Roh-Paste an den Agenten zurück, und der sortiert es in drei Kategorien: übernehmen, Geschmackssache, schon adressiert. Erfahrungswert aus über zwanzig Reviews: 30 bis 50 Prozent der Punkte sind valide. Der Review ist bewusst kontextfrei, und genau deshalb braucht er als Gegenstück den Agenten mit Repo-Kontext, der im Bearbeitungs-Log nachsehen kann, dass ein Vorschlag Monate zuvor schon verworfen wurde. Ein Review ist ein Finder, kein Beleg. Als einer eine Aussage als „zu absolut“ flaggte, ergab die Gegenprobe des Agenten, dass sie nicht zu absolut, sondern falsch war. Entschieden hat am Ende ein Test gegen laufende Datenbank-Container. Diese Review-Erfahrungen bekommen einen eigenen Artikel.

Was sich verallgemeinern lässt

Die Erfahrungen mit Agentic Coding in beiden Projekten haben dieselben Muster hervorgebracht. Vier davon tragen meinen Alltag.

Die Vorgabe lebt im Repo, nicht im Prompt. Regel-Dateien, Specs, Bug-Dateien und Bearbeitungs-Logs sind die eigentliche Arbeit. Die Prompts benennen nur Einstiegspunkt und Auftrag. Auch der Zwischenstand gehört dorthin: Was ein Agent erarbeitet hat, wird zeitnah als Commit oder Notiz in der Vorgangs-Datei festgehalten. Sprachmodelle leben vom Text. Was nicht geschrieben steht, existiert für die nächste Session nicht.

Die Struktur-Arbeit ist der Preis des Radius-Gewinns. Ich bekomme eine Anwendung, die ich allein nicht gebaut hätte, und einen Blog, den ich allein nicht durchhalten würde. Dafür übernehme ich Rollen, die in einem Team verteilt sind: Anforderungen schreiben, Abnahme-Kriterien formulieren, Testfälle deklarieren, Dokumentation pflegen.

Das Repo lernt, nicht der Agent. Jede Session beginnt ohne den Verlauf der vorherigen. Was aus einem Fehler gelernt wurde, existiert für die nächste Session nur, wenn es geschrieben steht: als Regel oder Prüfpunkt im Repository. Das gilt auch rückwärts: Viele Defekte, die ich heute in alten Artikeln korrigiere, waren beim Entstehen noch keine Verstöße, weil die Regel erst danach entstand. Der Bestand altert relativ zu den Regeln, die aus ihm gelernt wurden.

Lernen bleibt Pflicht. Dieser Blog vertritt die These, dass Formatieren Lernen ist: Wer ein Statement von Hand einrückt, baut das mentale Modell der Daten auf. Für Agentic Coding gilt das verschärft. Wer nur noch abnimmt, verliert mit der Zeit das Modell, das er zum Abnehmen braucht.

Wo es hakt: Grenzen aus Anwender-Sicht

Die Grenzen sind der Teil meiner Erfahrungen mit Agentic Coding, der die meiste Zeit gekostet hat.

Code-Drift trotz Regeln

Eine begründete Regel verbessert die Trefferquote, garantiert die Einhaltung aber nicht, und bei hohem Volumen wird jede Restquote zu messbarer Drift. Der Frontend-Fall mit 799 hartkodierten Schriftgrößen ist der Beleg, und die Antwort war keine bessere Regel, sondern eine Prüfung, die nicht müde wird. Die Redaktion des Blogs kennt denselben Effekt: Trotz Stil-Heuristiken enthält jede Erstfassung des Agenten Semikola oder Kompakt-Notation, und ich erkenne KI-geschriebenen Text an genau diesen Mustern. Was in den Regeln steht, muss trotzdem geprüft werden, nur wandert die Prüfung vom Lesen zum Zählen.

Kollateralschaden im Arbeitsbaum und auf meiner Maschine

Sobald mehr als eine Session im selben Repository arbeitet, oder eine Session neben mir, entsteht eine Fehlerklasse, die im Einzelbetrieb nicht existiert. Innerhalb von gut einer Woche hat ein Agent mit git add -A fremde Arbeit in einen Commit mit anderem Thema gezogen, eine andere Session hat mit einzeln benannten Dateien committet und trotzdem fremde Änderungen aus dem geteilten Index mitgenommen, und eine dritte hat Dateien einer parallelen Session für ihre eigene Nebenwirkung gehalten und gelöscht. Belastbar ist erst git commit --only mit expliziten Pfaden. Die Lehre aus dem ersten Fall hätte den zweiten nicht verhindert, und das ist der eigentliche Punkt.

Eine Ressource, die in Erfahrungsberichten selten vorkommt, ist meine eigene Maschine. Um einen sporadischen Testfehler unter Last zu belegen, startete ein Agent 220 Endlosschleifen und ließ die Test-Suite zwölf Minuten darunter laufen. Ich merkte es daran, dass mein Rechner nicht mehr reagierte. Der Agent sieht Exit-Codes, keine ruckelnde Oberfläche. Ob eine Maschine zwölf Minuten unbenutzbar sein darf, entscheidet ihr Besitzer, vorher. Beide Fehlerklassen bekommen einen eigenen Artikel.

Man kann nur abnehmen, was man beurteilen kann

Der Review-Aufwand ist der neue Engpass. Die Antwort ist nicht, schneller zu lesen, sondern die Abnahme zu verlagern: auf Läufe statt Lesen, auf Kriterien statt Eindruck, auf externe Reviews statt eigenes Wohlwollen. Jede dieser Verlagerungen setzt voraus, dass ich die Kriterien formulieren und ein Ergebnis als richtig oder falsch erkennen kann. Beim Node-Guard konnte ich das, weil ich die SQL-Konventionen kannte. Bei einem Skript, dessen Fachlogik ich nicht beurteilen könnte, wäre dieselbe Arbeitsteilung ein Risiko.

Dazu kommt eine Schwäche, die zur Stärke des Werkzeugs gehört. Ein Agent prüft Hypothesen in der Regel systematisch mit Messungen, und genau deshalb fällt kaum auf, wenn er einmal aus unvollständigen Indizien eine kohärente Geschichte baut. Bei einer Fehlersuche formulierte der Agent eine stimmige Ursache, als wäre sie gemessen. Sie war es nicht. Seither frage ich bei jedem Befund, welcher Teil davon gemessen ist.

Arbeits-Prompts als Beispiel

Die Prompts in beiden Projekten sind kurz, weil die Vorgabe im Repository liegt. Drei Beispiele zeigen, was ein Prompt dann noch leisten muss.

Eine Überarbeitungs-Serie starten. Wörtlich, nur die internen Bezeichner sind durch ihre Bedeutung ersetzt:

lass uns mit der triage des alt-bestands beginnen. alle relevanten änderungen
in den artikeln bzw. die erfahrungen aus der überarbeitung sind in dem artikel
über agentic coding zu berücksichtigen

Zwei Zeilen genügen, weil Spec, Arbeitsliste und Regel-Dateien versioniert vorliegen. Der Agent las sie, führte den ersten Qualitäts-Pass aus und etablierte die Material-Sammlung für diesen Artikel als Nebenpflicht der Serie.

Einen Artikel extern bewerten lassen. Dieser Prompt geht in einer frischen Session an ChatGPT, also an ein Modell eines anderen Anbieters. Er ist versioniert und seit August 2026 eingefroren, hier gekürzt:

Du bist ein kritischer, unabhängiger Fach-Lektor für einen technischen Blog über
SQL Server, Postgres, Datenqualität und ETL. Du kennst weder den Autor noch frühere
Versionen des Textes und hast keinen Grund zur Milde.

Bewerte den Artikel in vier Dimensionen mit je einem Score von 1 bis 10:
Fachliche Korrektheit, Struktur & Lesbarkeit, SEO-Tauglichkeit, Sprache & Stil.

Pflichten: Jeder Kritikpunkt zitiert die Fundstelle wörtlich. Zu jedem Punkt ein
konkreter Verbesserungsvorschlag. Keine Gefälligkeits-Punkte. Am Ende Gesamt-Score
und die fünf wichtigsten Punkte, priorisiert nach Wirkung.

--- ARTIKEL ---

Der wichtigste Satz ist der zweite. Ohne ihn bewertet das Modell den Verlauf statt den Text. Die Pflicht zur wörtlichen Fundstelle macht das Ergebnis sortierbar, denn ein Punkt ohne Fundstelle lässt sich weder umsetzen noch begründet ablehnen.

Eine wiederkehrende Prüfung als Skill. Ein Skill ist ein versionierter Prompt, den ich per Schrägstrich-Befehl aufrufe. So beginnt die Beschreibung des Skills, der Updates prüft, wörtlich bis auf die ersetzten Dateipfade:

Prüft Updates für Dev-Dependencies (npm, Docker-Image-Deklarationen, GitHub Actions)
UND für die Komponenten, die auf dem VPS tatsächlich laufen (OS-Pakete, Docker Engine,
Nginx, laufende Container-Tags, Certbot). Schreibt Befunde in die Update-Doku und in
einen datierten Security-Report. Führt eine Historie über angewendete/verschobene
Updates. Modifiziert nichts von selbst.

Der Skill legt fest, was geprüft wird, wohin das Ergebnis geht und was der Agent nicht darf. Für die Server-Seite erzeugt er eine Checkliste aus reinen Lese-Kommandos, die ich selbst ausführe. Das Abnahme-Kriterium ist die Historie, an der ich beim nächsten Lauf sehe, was liegen geblieben ist.

Wie dieser Artikel entstanden ist

Dieser Artikel handelt von Transparenz, also muss er sie selbst einlösen. Der Text ist ein Entwurf des Agenten, entstanden aus einer Spec und einer Material-Datei, die Agenten-Sessions über sechs Wochen geführt haben. In diese Datei schrieb die jeweils arbeitende Session auf meine Anweisung, was während der Arbeit passierte, die eigenen Fehler eingeschlossen. Die erste Fassung war doppelt so lang und in der dritten Person geschrieben. Dass sie kürzer wurde, in der ersten Person steht und die Infrastruktur überhaupt vorkommt, ist das Ergebnis einer Diskussion, in der ich den Agenten gebeten habe, erst zuzuhören, bevor er umschreibt.

Meine Rolle ist dieselbe wie in beiden Fallstudien. Ich habe entschieden, dass es diesen Artikel gibt und was er trägt. Ich lese den Entwurf, verwerfe, kürze, korrigiere und gebe frei. Ich lasse ihn in einer frischen Session eines anderen Modells bewerten, übertrage ihn von Hand in WordPress und prüfe die Links. Was ich nicht tue, ist den Text selbst schreiben. Und was ich nicht kann, steht im Text: ein Node-Skript schreiben, eine Wirkung im Swap sehen, einen Datenpunkt aus einer verlorenen Session zurückholen. Ich hatte vorher keine Erfahrung damit, was bei dieser Arbeitsweise auf mich zukommt. Unterschätzt habe ich nicht das Werkzeug, sondern den Anteil an Regeln, Specs, Testfällen und Dokumentation, den ich bisher von anderen bekommen hatte.

FAQ

Merkt man einem Text an, dass er KI-gestützt entstanden ist?

Häufig ja. Solche Texte verraten sich an wiederkehrenden Mustern. Im Deutschen sind das nach meiner Erfahrung vor allem Semikola in der Prosa, Nachsätze ohne Verb hinter einem Gedankenstrich, Klammern, in die eine ganze Information gepackt wird, und abstrakte Begriffe, die als Satz-Subjekt auftreten und dort handeln wie eine Person. Ich habe diese Muster in einer Regel-Datei festgehalten, und jeder Entwurf wird vor der Veröffentlichung dagegen gelesen. Ob man einem Text seine Entstehung anmerkt, hängt deshalb weniger vom Modell ab als vom Korrektur-Pass, den ein Mensch mit einer konkreten Liste macht.

Kann man ohne TypeScript-Kenntnisse eine TypeScript-Anwendung bauen?

Ja, unter Bedingungen. Man braucht ein Modell davon, wie eine Anwendung geschnitten ist, wo Zustand lebt und wo Fehler entstehen. In meinem Fall kam das aus Jahren mit .NET und Datenbanken. Man braucht Abnahme-Kriterien, die ohne Lesen des Codes prüfbar sind: Läufe, Tests, Audits. Und die Infrastruktur darunter bleibt eine eigene Hürde, die keine Programmiersprache kleiner macht.

Wie kontrolliert man, was man selbst nicht beurteilen kann?

Nicht durch Lesen, sondern durch eine Schleife aus Kontrollen, die ohne Code-Verständnis funktionieren: Regeln, die nach jedem Feedback nachgeschärft werden, Skills für wiederkehrende Prüfungen, Tests, die auf dem alten Stand rot sein müssen, und Audits mit Bericht. Die Schleife ersetzt kein Verständnis, aber sie ersetzt das Lesen. Jedes Verdikt muss seine offenen Punkte als Bedingung nennen, sonst reist ein „bestanden“ weiter als sein Vorbehalt.

Womit fängt man als Anwender an?

Mit einer einzigen Konvention, die im Repository steht, und einem Auftrag, der ein Abnahme-Kriterium hat. Nicht mit einem großen Regelwerk, denn das entsteht aus Feedback. Wer ein Datenbank-Projekt mit Claude Code aufsetzen will, findet im Artikel zum offenen Starter-Kit einen konkreten Einstieg, die Mechanik dahinter erklärt der Hub-Artikel des Clusters.

Lohnt sich der Aufwand für ein Solo-Projekt?

Nach meinen Erfahrungen mit Agentic Coding in beiden Projekten ja. Der Zeitgewinn beim Programmieren wird zu einem großen Teil von der Struktur-Arbeit aufgezehrt. Was bleibt, ist ein Radius-Gewinn: eine TypeScript-Anwendung samt Infrastruktur, die ich allein nicht gebaut hätte, und ein Blog mit Spec, Review-Protokoll und Bearbeitungs-Log, den ein Einzelner ohne Agent nicht durchhalten würde. Die Bedingung ist, dass man die Rollen übernimmt, die sonst Projektleitung und Team tragen.

Verwandte Artikel

Hub:

Infrastruktur und Deploy:

Regeln, Drift, Guard:

Einstieg:

Nebenan: