zurück zur Blog-Übersicht

Dev-Logbuch: Refactoring/Neuentwicklung mit KI

Kurze Zusammenfassung eines eines Refactorings/Neuentwicklung mittels KI. Ausgangsbasis ist mein eigenes Zeiterfassungssystem, dass ich etwa 2021 entwickelt hatte.

Ausgangsbasis

Mit dem Tool kann man Kunden, Projekte und Zeitlogs anlegen und danach auch analysieren/Berichte erstellen. Das war für mich ein Übungsprojekt weil ich mal eine komplette, produktive SPA entwickeln wollte – zum Zweck des Erkenntnisgewinns.

  • Frontend (Quellcode src): 110 Dateien (.vue, .js)
  • Backend (lib): 20 Dateien (.php)
  • Aufwand von 2021 bis vor das Refactoring etwa 150 Stunden

Technologiestack

  • Frontend: Vue 2, Vuex, Vue Router, Vuetify 2, Axios, Vue i18n (de/en), billboard.js (Charts), date-fns, PWA via Workbox/Service Worker
  • Backend: PHP als WordPress-Plugin, REST-ähnliche API-Controller
  • Build: Vue CLI, Webpack, Sass, Bitbucket-pipelines

Ziel des Refactorings

  • Testen von Entwicklung mit KI (Copilot in VSCode)
  • Zeitgemäßer Frontend-Stack
  • Backend mit pocketbase
  • Docker-Setup
  • Funktionale Erweiterung (Möglichkeit Zeitlogs zu taggen und Projekte mittels Public Link bereitzustellen

Start

Ich hab mir durch Claude Code 4.6 das aktuelle Projekt beschreiben lassen. Herausgekommen ist eine markdown-Datei die das Projekt in groben Zügen aus technologischer Sicht beschreibt, aber auch schon ein paar simple Code-Richtlinien festgeschrieben hat. Leider hab ich die Markdown-Datei nicht mehr bzw. habe ich sie im neuen System aktualisieren lassen – letztendlich ist man da ständig im Prozess.

Setup des neuen Projektes

Die markdown-Datei aus dem alten Projekt habe ich in einen neuen Ordner kopiert und auch dort „/init“ ausgeführt (mit Claude Code 4.6) und ihr meinen Technologie-Vorgaben gegeben. Die KI erstellt dann eine „.github/copilot-instructions.md“. Zusätzlich habe ich noch 3 mcp-Server hinterlegt, welche die Dokumentation von vue, quasar und pocketbase nutzen sollte.

Was die KI beim Initialen Aufschlag analysiert hat, hatte ich noch im KI Chat-Archiv:

Technologie-Stack — Pocketbase, Vue 3, Quasar 2, Pinia, TypeScript, date-fns, Docker
Architecture — Verzeichnisstruktur mit backend/ und frontend/src/ samt allen Unterordnern
Data Model — 5 Collections mit Owner-basierter Zugriffskontrolle
Code Style & Conventions — Composition API mit <script setup>, Pinia Options-API, Singleton pb, Loading-Pattern, Namenskonventionen
Build & Run Commands — Docker Compose + Quasar Dev-Server
Key Patterns — Auth Guard, laufender Timer, Bulk-Ops, Analyse, Lösch-Schutz
Build Phases — 8-Phasen-Plan mit Verweis auf SETUP_NEW_PROJECT.md

Daraufhin hab ich sie mit der Umsetzung des vorgeschlagenen 8 Phasen Plans beauftragt. Die KI hat daraufhin meist einen Punkt pro Anfrage geschafft, wobei ich versucht habe mit einem kleinen Trick die Anfrage etwas zu verlängern.

Die KI hat nach jedem Schritt versucht den Code zu parsen/builden, und hat dann selbstständig nachgebessert bis zumindest keine Codefehler mehr vorhanden waren. Funktional bedienbar war das ganze aber allenfalls ab Schritt 6 oder so.

Nach der initialen Umsetzung musste ich der KI noch mal einige Todos geben (mit Claude Sonnet und GPT-5.3 Codex) um die groben Fehler auszumerzen. Einige Dinge habe ich auch selbst programmiert, allerdings muss man zugeben, dass die KI in der Regel schneller ist sobald man Änderungen über mehrere Dateien hinweg machen muss. Ich gehe davon aus das ich nach den „8 Phasen“ etwa noch vier bis fünf mal soviele Anfragen benötigt habe um die App in einen annehmbaren Zustand zu bringen.

Der Versuch die Kosten gering zu halten

Um die Kosten gering zu halten hab ich in die „.github/copilot-instructions.md“ so etwas geschrieben wie:

# Finish
Wenn du mit der Bearbeitung einer Anfrage fertig bist, führe 'cmd /c "sleep 0"' aus und überprüfe die Datei `special.log` auf weitere Todos, die ich möglicherweise gemeldet habe. Wenn es Todos gibt, setze sie um. Wenn es keine Todos gibt, beende die Anfrage mit "OK".

Wobei in der special.log nach den Todos der selbe Text steht – idealer Weise hätte ich die KI so endlos mit einer (bezahlten) Anfrage beschäftigen können.

Das funktioniert in Claude Opus 4.6 nur noch sehr eingeschränkt oder gar nicht. In Claude Sonnet und GPT-5.3 Codex hat das besser funktioniert. Generell habe ich die Grundlagen mit Claude Code 4.6 erstellt und bin dann aus Kostengründen auf Sonnet und Codex gewechselt.

Insgesamt lieferte Claude Opus 4.6 bei komplexeren Teilaufgaben durchweg bessere Ergebnisse. Komplex meint dabei das die gesamte Codebasis betrachtet werden muss. Für Änderungen an einer eingeschränkten Anzahl an Dateien hat Claude Sonnet / GPT Codex vergleichbare Ergebnisse gebracht.

Was hat richtig gut geklappt?

  • Da ich das ganze schon mal implementiert hatte, habe ich der KI zur Nachbesserung in einen „examples“ Ordner immer mal ein paar Dateien gepackt mit der sie sich bestimmte UX Pattern oder Funktionen abschauen sollte. Warum nicht gleich das ganze Projekt dort rein? Weil ich das ganz zu Beginn schon mal probiert hatte und das Refactoring da nur mäßig gute Qualität hatte – kurz: es hat überhaupt nicht funktioniert.
  • Die Datenmigration ließ sich sehr gut von der KI umsetzen. Sie hat mir ein Datenformat erstellt und dabei sogar nur einen einzige Variable vergessen. Danach habe ich mir einen Exporter und einen Importer schreiben lassen. Das hat ziemlich problemfrei funktioniert. Den Gesamtaufwand für so eine Migration sollte man trotzdem nicht unterschätzen, man muss dann das ganze eben doch noch einige Male testen, ggf. verbessern usw. aber der Initiale Aufschlag war sehr gut.
  • Aufgrund der Menge an Änderungen gewöhnt man es sich schnell ab den kompletten Code / die Änderung vollständig zu lesen. Meist kommt da auch recht guter Code raus – bisweilen auch Dinge an die man selbst nicht sofort gedacht hätte. Die Anzeige der Änderungen in VSCode ist auf jeden Fall ein echter Gewinn – man kann jede Änderung einzeln abwinken, oder ganze Dateien bestätigen.
  • Der KI eine Liste von etwa 5 Todos geben die sie abarbeiten soll. Diese können auch aus ganz unterschiedlichen Bereichen der App sein.
  • Grundlegend war ich von den vielen Vorschlägen der KI angetan. Einiges habe ich übernommen, vieles war noch nicht ausgereift, aber Grundlegend erst einmal neue Ideen/Sichtweisen auf sein Problem zu bekommen war super.

Was war nicht ideal

  • Das grundlegende „/init“ ist Gold wert die daraufhin erstellte „.github/copilot-instructions.md“ sollte alles enthalten auf das man Wert legt. Ich gehe davon aus dass ich zu einem besseren Ergebnis gekommen wäre, hätte ich mir zum Anfang mehr Zeit genommen die initiale Beschreibung zu verbessern: DRY-Code, bestimmte UX-Pattern, Architektur-Richtlinien, usw. Das muss man im Hinterkopf behalten wenn man die folgenden Punkte in der Liste liest. Allerdings hat die KI manchmal auch trotz präziser Beschreibung Anforderungen komplett ausgelassen oder dann selbst als ich es angegeben habe doch nicht immer DRY programmiert.
  • Die UX war initial sehr „Standard“, nicht optimiert auf den Workflow oder das Problem (sehr an die REST Datenstrukturen angelehnt). Wobei auch eine genauere Beschreibung oft nicht geholfen hat. Der Trick mit den Bestandsdateien im Examples-Ordner war dann das, womit ich einzelne UX Pattern doch noch in die neue Anwendung bekommen habe ohne es selbst programmieren zu müssen.
  • Insbesondere zu Beginn ist es wichtig sich die Architektur des Projektes genauer anzuschauen. Bei mir wurden z.B. die Pinia-Stores strukturell komplett falsch genutzt. Das ist lange nicht aufgefallen, bis es dann eben an allen möglichen Stellen zu seltsamen Problemen kommt.
  • Der Aufwand den man betreibt mit den Anfragen ist nicht zu unterschätzen. Mit 4-5 Anfragen an das KI-System ist meist eine Stunde weg. Da man sich ja auch immer noch angucken muss, ob es das gemacht hat und wie es bestimmte Dinge gelöst hat.

Daten Zielsystem

  • Frontend (src/): 82 Dateien (Vue, TS, SCSS)
  • Backend (backend): 11 Dateien (Migrations, Hooks, Docker)
  • Aufwand etwa 24-30 h – etwa 60-80 KI-Anfragen (zzgl. oben angesprochenen Hack mit der special.log)

Technologiestack

  • Backend: PocketBase ^0.26 (BaaS, Docker)
  • Frontend: Vue 3.5 · Quasar 2.17 · Vite 7 · TypeScript 5.9
  • State: Pinia 3 · Routing: Vue Router 5
  • API: PocketBase JS SDK
  • Dates: date-fns 4 · Charts: billboard.js 3 · i18n: vue-i18n 11

Grundlegender Aufbau

  • Backend: PocketBase als BaaS – 8 Migrations, Custom JS-Hooks für Public-Access-Endpunkte
  • Frontend SPA: Quasar-App mit zentralem API-Layer (api.ts)
  • Deployment: Docker Compose – PocketBase + nginx (statisches dist/)