KI als persönlicher DevEx Engineer

Warum ich Agents die Werkzeuge für ihre eigene Arbeit bauen lasse

Ich habe eine Liste mit kleinen Tools, die ich schon lange gern hätte. Nichts davon wäre ein großes Produkt. Eher Dinge, die mitten in der Arbeit fehlen: ein schnellerer Weg, etwas zu finden, Daten in ein brauchbares Format zu bringen oder eine wiederkehrende Prüfung auszuführen. Früher wurde diese Liste länger. Inzwischen wird sie kleiner.

Der Grund ist meine tägliche Arbeit mit Coding Agents. Wenn mir ein Werkzeug fehlt, gebe ich dessen Bau als Nebenaufgabe an einen Agenten und arbeite an meiner eigentlichen Aufgabe weiter. Später schaue ich mir das Ergebnis an, probiere es aus und verbessere es mit ihm. So entstehen Tools, für die ich mir früher kaum einen ganzen Nachmittag genommen hätte.

Mit dieser Beobachtung bin ich nicht allein. Phill Johntony beschreibt, wie Ideen aus einer jahrelang liegen gebliebenen Liste mit Coding Agents zu persönlichen Anwendungen wurden. Keegan Donley geht noch einen Schritt näher an meinen Arbeitsalltag heran: Er lässt sich während des Arbeitstags neue Entwicklerwerkzeuge und MCP-Server bauen. An dieser Stelle wird es für mich spannend. Manche dieser Tools erfüllen nicht nur einen alten Wunsch, sondern verbessern direkt die Arbeit des nächsten Agents.

Ein guter Prompt ersetzt kein passendes Werkzeug

Bei KI-gestützter Entwicklung sprechen wir viel über Prompts: Welche Anweisung bringt den Agenten dazu, ein Problem richtig zu verstehen? Das ist wichtig. Aber wenn er dieselbe Information bei jeder Aufgabe erneut aus einer Codebasis zusammensuchen und interpretieren muss, stößt auch eine gute Anweisung an Grenzen.

In einem Projekt standen wir genau vor dieser Situation. Die Codebasis war in RPG geschrieben, einer Sprache, für die es in unserem Fall keine passenden Analysewerkzeuge von der Stange gab. Wir entwickelten deshalb spezialisierte Parser, die den Quelltext in einen durchsuchbaren Graphen überführen. Der Agent kann nun gezielt nach erfassten Strukturen und Beziehungen suchen, statt sie für jede Frage wieder aus vielen Dateien herzuleiten.

Der Parser nimmt dem Agenten eine klar umrissene Arbeit ab. Bei gleicher Eingabe liefert er nach denselben Regeln dieselbe Struktur. Der Agent bleibt für die Fragen zuständig, die Interpretation brauchen: Welche Stelle ist für die Aufgabe relevant? Was bedeutet ein gefundener Zusammenhang für die geplante Änderung? Der Graph liefert dafür eine Grundlage, die sich gezielt abfragen und prüfen lässt. Natürlich muss auch der Parser korrekt sein und bei Änderungen an der Codebasis erneut laufen. Aber seine Regeln lassen sich testen; wir müssen die Strukturerkennung nicht jedem Agenten neu erklären.

Das kann Kontext und Tokens sparen: Eine präzise Graphabfrage kann dem Modell weniger Quelltext liefern als eine breite Suche. Wie groß die Ersparnis tatsächlich ist, hängt von den Abfragen und ihren Ergebnissen ab. Der wichtigere Gewinn ist für mich, dass eine wiederkehrende Analyse nicht in jeder Session neu improvisiert werden muss.

Ein CLI, das Frontmatter durchsucht

Dasselbe Prinzip funktioniert auch im Kleinen und für private Projekte. Zusammen mit einem Coding Agent habe ich für meine Markdown-Notizen ein CLI-Tool entwickelt, das die Frontmatter-Daten großer Obsidian-Vaults durchsucht. Es kann vorhandene Felder und Werte auflisten und Notizen nach mehreren Metadaten filtern. Bei jedem Aufruf liest es den aktuellen Stand; ein dauerhafter Index ist dafür nicht nötig. Für einen Agenten ist das ein präziser Zugriff auf strukturierte Daten: Er kann sich etwa passende Dateipfade oder JSON ausgeben lassen, statt viele Notizen zu öffnen und deren Frontmatter selbst zu vergleichen. Ob ich die Ergebnisse anschließend selbst nutze oder an einen Agenten weitergebe, entscheidet die Aufgabe.

Manchmal muss auch gar kein neues Tool entstehen. Es fehlt nur ein verlässlicher Weg, ein vorhandenes Programm in der täglichen Arbeit zu benutzen. Dank Coding Agents habe ich dafür inzwischen ein eigenes zusätzliches Nix-Paket-Repository. Darin paketisiere ich Programme, die ich nutzen möchte und die in meinen üblichen Paketquellen fehlen. Die Paketdefinition hält fest, woher ein Tool kommt und wie es gebaut oder gestartet wird. Ist es einmal eingebunden, können auch meine Agents denselben Befehl verwenden, statt bei jeder Aufgabe wieder eine Installation zusammenzusetzen.

Kleine Tools verändern die Rechnung

Genau hier wird KI für mich zu einer Art persönlichem DevEx Engineer. Sie hilft beim Bauen und Bereitstellen der Werkzeuge, die das Entwickeln angenehmer und verlässlicher machen: Parser, Suchwerkzeuge, Konverter oder Checks für wiederkehrende Regeln. Manche sind so spezifisch, dass es dafür kein fertiges Produkt gibt. Andere existieren bereits, müssen aber erst in die eigene Arbeitsumgebung passen. Beides blieb früher oft auf der Wunschliste liegen.

Unmesh Joshi beschreibt einen ähnlichen Ausgangspunkt: Er wollte PlantUML-Diagramme Schritt für Schritt abspielen, wurde aber vom Aufwand für Parser, Build und Oberfläche ausgebremst. Mit einem Coding Agent entstand die Erweiterung trotzdem. Seine Fallstudie zeigt auch die Arbeit, die bleibt: Die sinnvolle Syntax auswählen, Fehler erkennen und den entstandenen Code strukturieren.

Ich muss also weiterhin entscheiden, welches Tool sich lohnt, seine Ergebnisse prüfen und es bei Bedarf pflegen. Donley fragt in seinem Artikel zu Recht, ob man wirklich jede jetzt umsetzbare Idee auch bauen sollte. Für mich ist ein guter Kandidat eine Reibung, die wiederkehrt und sich in klare Regeln übersetzen lässt. Dann kann ein kleines Tool diese Regeln einmal ausführen, statt dass Mensch und Agent sie immer wieder durchgehen.

Nicht jedes Werkzeug muss dauerhaft bleiben. Ashley Raiteri baute zwei winzige Hilfen für seinen Agentenworkflow: eine für Screenshots, eine für die Zwischenablage. Später wurden beide durch bessere Abläufe überflüssig. Das ist kein Fehlschlag. Wenn die Reibung verschwunden ist, hat das Tool seinen Zweck erfüllt.

Vielleicht ist das die Veränderung, die mich am meisten überrascht: Meine Wunschliste schrumpft nicht, weil mir weniger einfällt. Sie schrumpft, weil aus kleinen Reibungen während der täglichen Arbeit benutzbare Werkzeuge werden. Und wenn ein Werkzeug dem Agenten eine wiederkehrende, klar definierte Aufgabe abnimmt, profitiert auch die nächste Aufgabe davon.