Softwareentwicklung mit Devin: Versand einer vertikalen Scheibe (Teil 2)

Willkommen zurück! Im ersten Tutorium dieser Reihe hat Devin mein altes fp-ts-exercises Repo entstaubt und ein ordentliches dependency-upgrade PR eröffnet. In diesem zweiten Teil erhöhen wir den Schwierigkeitsgrad und bauen Full-Stack-Features.

Du kannst alle Tutorials der Devin-Serie hier aufrufen:

1. Einrichtung und erster Pull Request (Teil 1)
2. Eine vertikale Scheibe mit Devin verschiffen (Teil 2) 
3. Integration, Tests und CI/CD (Teil 3) 
4. Sicherheit, Einsatz, Wartung (Teil 4)

Wenn du bis zum Ende dieses zweiten Teils scrollst, hast du es geschafft:

• A Next.js 14 Spielplatz, wo die Lernenden den Code im Browser bearbeiten;
• Live-Vitest-Tests die in Echtzeit grün (oder rot) werden; und
• A NestJS mit SQL-Datenbank Backend, das den Fortschritt mit nichts weiter als einer anonymen UUID in localStorage speichert.

Auf dem Weg dorthin lassen wir Devin seine eigene Aufgabenliste erstellen, beobachten, wie er mit Front- und Back-End-Tickets jongliert, und greifen ein, wenn er über Konfigurationsfehler stolpert. Ich zeige dir, wo ich ACUs ausgegeben (und gespart) habe, was ich von Hand repariert habe und wie man Sitzungen effizient hält.

Rekapitulation und Voraussetzungen

In dieser Tutorial-Reihe arbeiten wir mit meinem (ehemals) aufgegebenen fp-ts-Übungsrepositorium.

Das Projekt ist eine Sammlung von kleinen Herausforderungen, die funktionale Programmierkonzepte (wie Option, Either usw.) in TypeScript vermitteln sollen. Im Moment ist es ein Clone-and-Run-Repo: Lernende ziehen es herunter, bearbeiten Dateien lokal und führen die Tests in ihrem eigenen Terminal aus.

Das Ziel ist es, diese Übungen in eine browserbasierte, interaktive Spielwiese zu verwandeln, auf der die Teilnehmer/innen die Erklärungen lesen, den Code in einem In-Page-Editor bearbeiten und sofort sehen können, ob die Tests bestanden wurden (oder nicht). Die Lernenden haben außerdem die Möglichkeit, sich einzuloggen und ihren Fortschritt zu speichern.

Was wir im ersten Teil erreicht haben

Erinnere dich daran, dass wir im ersten Lernprogramm:

• Das alte fp-ts Repo wurde modernisiert: neueste Abhängigkeiten, Linting, Typ-Prüfungen.
• Ich habe Devin mit GitHub verbunden und bewiesen, dass er eine saubere Pull-Anfrage öffnen kann.

Lokale Werkzeuge, die du für den zweiten Teil brauchst

Für dieses zweite Tutorial brauchen wir:

• Node 20+ und npm 10 (unterstützt Workspaces bereits ab Werk).
• Docker mit einem PostgreSQL-Container (oder einer lokalen PostgreSQL-Instanz).

Empfohlene Devin-Einstellungen

Ich empfehle die folgenden Einstellungen für Devin:

• Lege eine weiche Obergrenze von 5 ACUs pro Sitzung in Einstellungen > Nutzung & Grenzenein; wir starten für jede Phase eine neue Sitzung.
• Lass die Registerkarte "Zeitraffer" sichtbar, um Devin anzuhalten oder anzustupsen, wenn er ins Stocken gerät.

Lass Devin den Spielplan schreiben

Ich dachte, es wäre interessant, zunächst Devins Planungsfähigkeiten zu testen. Ich habe eine Eingabeaufforderung erstellt und Devin gebeten, mir mit der Funktion "Fragen" (derzeit kostenlos in der Beta-Phase) bei der Planung der Arbeit zu helfen, die wir heute machen werden.

Aufforderung:

Ich möchte mein bestehendes fp-ts-exercises Node + TypeScript Repo (derzeit Clone-and-Run CLI-Übungen) in eine browserbasierte Lernplattform verwandeln, die den Fortschritt verfolgt. 

Zielerfahrung: 

- Die Lernenden öffnen eine Next.js-Webanwendung, wählen eine Übung aus, bearbeiten den Code im Browser und sehen sofort, ob die Vitest-Tests bestanden haben oder nicht. 

- Der Fortschritt (abgeschlossene Slugs) wird serverseitig gespeichert und bei späteren Besuchen erneut geladen, aber wir fügen noch keine Benutzerkonten hinzu (wir verwenden eine anonyme UUID, die im Browser gespeichert ist). 

Die technischen Möglichkeiten, zu denen ich tendiere: 

- Frontend: Next.js 14 (React 18, App Router) 

- Code Editor & Runner: Sandpack + @vitest/browser 

- API: NestJS 13 mit @nestjs/graphql (Apollo-Treiber) 

- Datenbank: Prisma 5 mit PostgreSQL 

- Arbeitsbereich: einfache npm-Arbeitsbereiche (apps/web, apps/api, packages/exercises) 

Schlage einen schrittweisen Umsetzungsplan (Aufgabenliste) vor, der diesen vertikalen Abschnitt mit Leben füllt. Schätze die relativen ACU-Kosten für jede Aufgabe und kennzeichne alle langwierigen Schritte (z. B. große Migrationen oder Installationen mit vielen Abhängigkeiten).

Devin lieferte uns eine Liste mit sechs Aufgaben, für die er jeweils einen geschätzten ACU angab, und markierte die Schritte, die mit "starken Abhängigkeiten" verbunden waren.

Devins Antwort:

Phase 1: Arbeitsbereich einrichten (2-3 ACU)

• npm-Arbeitsbereichsstruktur initialisieren (1 ACU)
• erstellen. Apps/Web, apps/api, und packages/exercises Verzeichnisse
• Wurzel konfigurieren package.json mit Arbeitsbereich-Definitionen
• Verschiebe bestehende Übungsdateien nach packages/exercises/src/
• Next.js 14-Frontend einrichten (1-2 ACU - Langläufer: Abhängigkeitsinstallation)Initialisiere Next.js mit App Router in apps/webTypeScript und Tailwind CSS konfigurierenGrundlegende Routing-Struktur einrichten

Phase 2: Übungspaket Migration (3-4 ACU)

• Extrahiere Übungsinhalte in ein gemeinsames Paket (2 ACU)
• Erstelle Pakete/Übungen mit Extraktion von Übungsmetadaten
• Analysiere vorhandene Übungsdateien, um sie zu extrahieren:
• Anweisungen
• Starter Code
• Lösungen
• Definiere TypeScript-Schnittstellen für die Übungsstruktur
• Einführung eines Systems zur Entdeckung von Übungen (1-2 ACU)
• Dateisystem-Scanner erstellen (wie fs.readdirSync Logik in exercise.js:17-28)
• Exportiere die Metadaten der Übung: Titel, Beschreibung, Schwierigkeit, Tests

Phase 3: Backend API (4-5 ACU)

• NestJS API mit GraphQL einrichten (2 ACU - Langwierig: Abhängigkeiten installieren)
• Initialisiere das NestJS Projekt in apps/api
• Apollo GraphQL Server konfigurieren
• Grundlegende Endpunkte für Gesundheitschecks einrichten
• Prisma + PostgreSQL implementieren (2 ACU - Langfristig: Datenbankeinrichtung)
• Entwurfsschema für:
• Benutzer-Sitzungen
• Abgeschlossene Übungen
• Prisma-Client und Migrationen einrichten
• Lernpfad-Resolver erstellen
• Verwaltung anonymer Benutzersitzungen (1 ACU)
• UUID generieren und im Browser speichern localStorage
• Aktiviere die sitzungsbasierte Fortschrittspersistenz ohne Authentifizierung

Phase 4: Frontend-Kernfunktionen (5-6 ACU)

• Übungsbrowser-Schnittstelle (2 ACU)
• Übungen nach Kategorie auflisten (Option, entweder, Aufgabe, etc.)
• Fortschrittsindikatoren und Abschlussstatus anzeigen
• Aktiviere die Auswahl und Navigation von Übungen
• Sandpack Code-Editor-Integration (2-3 ACU - Langfristig: Sandpack-Setup)
• Sandpack mit TypeScript-Unterstützung konfigurieren
• Lade den Startcode und fp-ts Abhängigkeiten
• Dateisystem für Übungs- und Testdateien einrichten
• Vitest Browser Runner Integration (1 ACU)
• Ersetze execSync Vitest-Aufrufe (exercise.js:45-47) mit @vitest/browser
• Ermöglicht die Durchführung von Tests in Echtzeit und die Anzeige der Ergebnisse

Phase 5: Lernpfad (2-3 ACU)

• Client-seitige Fortschrittsverwaltung (1 ACU)
• Apollo Client für GraphQL einrichten
• Fortschritt mit Backend synchronisieren
• Erkennung des Übungsabschlusses (1-2 ACU)
• Bestehende Logik zur Erfolgserkennung anpassen (exercise.js:48-49)
• Backend-Fortschrittsaktualisierungen bei bestandenem Test auslösen

Phase 6: Polnisch & Einsatz (2-3 ACU)

• UI/UX Verbesserungen (1-2 ACU)
• Responsive Design sicherstellen
• Ladezustände und Fehlerbehandlung hinzufügen
• Verbessere die Anzeige der Übungsanweisungen
• Einrichtung des Produktionseinsatzes (1 ACU)
• Docker für beide Anwendungen konfigurieren
• Verwalten von Umgebungsvariablen
• Datenbankbereitstellung einrichten

Geschätzte Gesamtkosten: 18–24 ACU

Der Plan war insgesamt ziemlich gut. Ich habe einige Dinge geändert, vor allem in Phase sechs, da wir uns im vierten Tutorial mit dem Einsatz beschäftigen werden.

Phase 1: Arbeitsbereich & Front-End-Gerüst

Goal: Erstelle npm-Workspaces, verschiebe die Legacy-Dateien und bootstrappe eine leere Next.js 14-Shell.ACU burn: 3,66 (geplant 1-2).Ergebnis: Das Repo enthält nun /apps/web, packages/exercises und eine Tailwind-fähige Next.js-App, die auf localhost:3000 läuft.

Die Aufforderung

Ich habe Devin gebeten, den Plan zu erstellen, den er für die erste Phase gemacht hat. Agentic Devin hat keinen Kontext zu dem, was du vorher in der "Frag Devin"-Funktion gefragt hast, also musst du eine separate Anfrage erstellen und den Kontext angeben. 

Ich werde nicht alle Aufforderungen in diesem Artikel einfügen, aber hier ist die erste:

Aufforderung:

Aufgabe: Initialisiere die npm-Workspace-Struktur und das Next.js-Frontend für die Browser-Plattform fp-ts-exercisesContext:

Ich bin dabei, mein bestehendes CLI-basiertes Lernsystem fp-ts-exercises in eine browserbasierte Plattform umzuwandeln. Das aktuelle System hat die Übungen in 10-from-either.exercise.ts:1-3 mit der TypeScript-Konfiguration in tsconfig.json:88 und der Vitest-Einrichtung in vitest.config.ts:7 organisiert.

Anforderungen:

• Erstelle die Struktur des npm-Arbeitsbereichs:
• Root package.json mit Workspace-Konfiguration für apps/web, apps/api, packages/exercises
• Verschiebe bestehende Übungsdateien aus dem aktuellen src/ nach packages/exercises/src/
• Behalte die aktuelle Namenskonvention für Übungsdateien bei (.exercise.ts und .solution.ts)
• Initialisiere Next.js 14 frontend in apps/web:
• App Router verwenden (nicht Pages Router)
• Konfiguriere TypeScript mit ähnlichen strengen Einstellungen wie die aktuelle tsconfig.json:88
• Hinzufügen von Tailwind-CSS für das Styling
• Erstellen einer grundlegenden Routing-Struktur für das Durchsuchen von Übungen
• Kompatibilität aufrechterhalten:
• Sicherstellen, dass bestehende Übungsstrukturen und Importe weiterhin funktionieren
• Fp-ts-Abhängigkeiten über den Arbeitsbereich hinweg zugänglich halten
• Aktuelle Vitest-Konfigurationsmuster beibehalten

Ergebnisse:

• Workspace-konfigurierte package.json im Stammverzeichnis
• Next.js-App in apps/web/ mit TypeScript und Tailwind
• Migrierte Übungen in packages/exercises/
• Grundlegende Routing-Struktur (/Übungen, /Übungen/[Kategorie], /Übungen/[Kategorie]/[Slug])

Tech Stack:

• Next.js 14 mit App Router
• TypeScript (strenger Modus)
• Tailwind CSS
• npm-Workspaces (nicht yarn/pnpm)

Einreichung:

• Sicherstellen, dass Lint und Typecheck-Skript funktionieren
• Erstelle eine PR mit deinen Änderungen

Alle Aufforderungen, die ich daraufhin geschrieben habe, folgten demselben Muster: Aufgabenhighlight, Kontext, Anforderungen, Ergebnisse, technischer Hintergrund und Details zur Einreichung.

Was Devin tatsächlich getan hat

Es hat ziemlich lange gebraucht, um sich zu entscheiden (etwa vier Minuten), aber es hat funktioniert:

1. Das Skelett des Arbeitsbereichs erstellt
2. Alle Übungsordner wurden nach packages/exercises/src migriert.
3. Bootstrapped Next.js 14 mit dem App Router, TypeScript und Tailwind.
4. Lint- und Type-Check-Skripte zur Frontend-App hinzugefügt (nachdem ich sie angestupst hatte).

Warum die ACU-Kosten in die Höhe geschnellt sind

Die ACU-Kosten sind in die Höhe geschnellt, weil:

• Devin verbrachte eine ganze Minute damit, nach einer Zeitüberschreitung des Spiegels npm install zu wiederholen.
• Es wurde versucht, den Devs-Server und die Prozesse mit q in Vim zu stoppen, dann Ctrl-C, und beides schlug fehl. Ich habe dem Programm ein wenig Zeit gegeben, um es selbst zu reparieren, musste dann aber beide Male manuell eingreifen und die Prozesse beenden. Jede zusätzliche Minute bedeutete zusätzliche ACUs, und ich hätte dieses Problem nicht so schnell bemerkt, wenn ich Devins Aktionen nicht genau verfolgt hätte.

Menschliche Interventionen und Lektionen gelernt

Hier ist eine Zusammenfassung der Korrekturen, die ich vornehmen musste:

Das Verschieben großer Dateibäume geht von Hand schneller und ist viel günstiger, da Devin nach Zeit/Aufgabe abrechnet. Ich habe die Ordner verschoben, bestätigt und den Agenten die neue Struktur übernehmen lassen. Es konnte meine Änderungen problemlos übernehmen und selbständig zusammenführen!

Allerdings musste ich das Programm auffordern, die Skripte für Lint und Typprüfung auszuführen, auch wenn ich dies in der ersten Eingabeaufforderung angegeben hatte. Am Ende lief es für beide, aber sie scheiterten. Devin hielt es trotzdem für einen Erfolg und machte die PR mit.

Ich habe beide Probleme lokal behoben, die Skripte selbst ausgeführt und den neuen Webentwicklungsserver gestartet, um sicherzugehen, dass er wie vorgesehen startet, und den Commit veröffentlicht.

Phase 2: Verpacken der Übungen

Goal:  Extrahiere alle Challenge-Dateien in ein wiederverwendbares packages/exercises Paket und generiere Metadaten für jede Übung.ACU burn:  0,6 (geplant 2+).Outcome: Shared Package exportiert typisierte Metadaten, die die Web-App und die zukünftige API mit import { exercises } from '@exercises/registry' importieren können.

Was Devin tatsächlich getan hat

Devin hat es geschafft:

• Strukturierte TypeScript-Schnittstellen für Übungen, Metadaten, Kategorien und den Gesamtkatalog.
• Parser üben das:
• Extrahiert Metadaten aus Codekommentaren und Funktionssignaturen
• Analysiert Startercode, Lösungscode und Vitest-Testfälle
• Automatische Generierung von Tags aus der fp-ts Nutzung
• Konvertiert camelCase-Namen in lesbare Titel
• System zur Entdeckung von Übungen das:
• Durchsucht das Dateisystem nach .exercise.ts und .solution.ts Paaren
• Erstellt einen Slug-basierten Katalog (zum Beispiel option-01 )
• Organisiert Übungen nach Kategorien mit Zwischenspeicherung für mehr Leistung
• Bequeme Exporte zum Abfragen von Übungen und Kategorien:
• getExercises(), getExerciseBySlug(), getExercisesByCategory(), getCategories(), getCategoryBySlug()

Warum Devin unter dem Budget abschloss

Devin hat es geschafft, die Kosten für die ACU niedrig zu halten - hier siehst du, wie er das geschafft hat:

• Keine umfangreichen Installationen oder Netzwerkanrufe
• Das Verschieben von Dateien war einfach; Devin benutzte git mv (billig) anstelle von Copy-Paste plus Diff
• Die Erzeugung von Metadaten war reines TypeScript, schnell zu planen und auszuführen

Menschliche Interventionen

Dieses Mal nicht!

Aus dem letzten Mal habe ich gelernt und die Skripte in Devins Zweig lokal ausgeführt. Alles wurde kompiliert und die Registry exportiert saubere Typdefinitionen, was sie zum perfekten Eingabematerial für die UI und API macht, die wir als Nächstes bauen werden.

Phase 3: NestJS + GraphQL API

Goal: Richte einen NestJS 13-Dienst ein, der den Trainingsfortschritt über GraphQL darstellt und Daten in PostgreSQL mit Prisma persistiert.ACU burn: 4.2 (geplant 4).Outcome: apps/api boots on localhost:4000/graphql. Du kannst Fortschrittsdatensätze abfragen und ändern, die durch eine anonyme Sitzungs-ID gekennzeichnet sind.

Was Devin tatsächlich getan hat

Für die dritte Phase, Devin:

1. Erstelle eine vollständige NestJS API in apps/api mit TypeScript und Apollo GraphQL
2. PostgreSQL mit Prisma ORM integriert und ein Schema mit Session und CompletedExercise Modellen eingerichtet
3. Anonymes Sitzungsmanagement mit UUIDs implementiert (keine Anmeldung erforderlich)
4. GraphQL-Resolver für die Erstellung/Validierung von Sitzungen, Übungsabfragen und die Verfolgung des Fortschritts gebaut
5. Verbundenes Backend mit dem gemeinsamen Übungspaket (packages/exercises ) zur Datenermittlung
6. CORS konfiguriert, um die Kommunikation mit dem Next.js-Frontend zu unterstützen
7. Sicherstellung der Typkompatibilität zwischen dem GraphQL-Schema und bestehenden TypeScript-Schnittstellen
8. Einrichten von Entwicklungsskripten, Datenbankmigrationsfluss und Prisma Studio-Integration

Wo Devin gestolpert ist

Dies sind die Probleme, auf die ich in der dritten Phase gestoßen bin, und die Korrekturen, die ich vornehmen musste:

Gelernte Lektionen

Das sind meine Eindrücke:

• Config vs. Code: Devin ist sehr gut, wenn das Framework erst einmal steht, aber um Abhängigkeitsprobleme zu erkennen, braucht es immer noch ein menschliches Auge.
• Immer lokal ausführen: Ich hatte bereits eine lokale PostgreSQL-Datenbank auf meinem Rechner erstellt, und die PR-Anweisungen zum Ausführen der Prisma-Migration und zum Starten der Entwicklungsumgebung waren klar und einfach zu befolgen (siehe Abbildung unten). Devins Kommentar besagt, dass es gelungen ist, die API lokal auszuführen, doch npm run dev stürzte ab, bis reflect-metadata hinzugefügt wurde.

• Devin ist gut im Umgang mit PR-Kommentaren. Ich kommentierte den PR und erklärte Devin, dass ich versucht hatte, die API lokal auszuführen und dabei auf einen Fehler gestoßen war. Es gab mir sofort ein kleines Augen-Emoji, und die Sitzung wurde von selbst fortgesetzt, um den Fehler zu beheben, und ein paar Minuten später wurde ein Fix gepusht.

• Prüfe immer auf geheime Dateien: Devin hatte eine .env Datei mit einer DATABASE_URL Variable übergeben, die einen Dummy-Benutzernamen und ein Passwort enthielt. Nachdem ich sie lokal gezogen hatte, änderte ich den Benutzernamen und das Passwort in meine lokalen Datenbankkennungen und stellte sicher, dass die Datei aus dem Git-Tracking-System entfernt und zum .gitignore hinzugefügt wurde. Wir werden in zukünftigen Tutorials sehen, wie man sicher mit Geheimnissen umgeht.

Phase 4: Sandpack Spielplatz & Live Tests

Goal: Gib den Lernenden einen Browser-Editor, der fp-ts-Lösungen und Vitest-Checks in Echtzeit ausführt.ACU burn: 7.2 (geplant 3-4).Outcome: Der Besuch von /exercises/option-01 öffnet eine geteilte Ansicht: Der Sandpack-Editor auf der linken Seite, der Testtunnel auf der rechten Seite und eine Erfolgsmeldung, sobald alle Specs bestanden sind.

Was Devin tatsächlich getan hat

Hier ist, was Devin für die vierte Phase gemacht hat:

• Übungslisten und Navigationsseiten mit dynamischer Kategorie- und Slug-Unterstützung
• Integrierter Sandpack-Editor mit TypeScript-, fp-ts- und Echtzeit-Dateisystem-Unterstützung
• CLI Test Runner durch Vitest im Browser und Live-Feedback ersetzt
• Verbindung zwischen Frontend und Backend über Apollo Client für sitzungsbasierte Lernpfade
• Responsive UI mit Ladezuständen und Fehlerbehandlung implementiert

Wo Devin zusätzliche ACUs verbrannt hat

Devin hat in dieser Phase mehr ACUs verbrannt als erwartet - hier ist der Grund dafür:

Gelernte Lektionen

Meine Eindrücke sind dieses Mal:

• Schweigend zusehen = Geld verbrennen. Lass die Registerkarte "Zeitraffer" geöffnet und wenn Devin eine Schleife dreht, schiebe sie an oder halte sie an.
• Lösche toten Code frühzeitig. Devin löscht veralteten Code nicht wirklich von selbst, es sei denn, du sagst es ihm. Ich habe vorhin den Fehler gemacht, ihn zu bitten, Dateien zu verschieben, ohne ausdrücklich zu sagen, dass er sie löschen soll, und so hatten wir am Ende mehrere Einstiegspunkte, die den armen Devin in dieser Phase sehr verwirrten.

Devin hat sich hier etwas Zeit gelassen. Es drehte sich in einer Schleife und versuchte, die gleichen Probleme zu speichern, das Backend und das Frontend nicht richtig zu verbinden, Änderungen vorzunehmen, die Server neu zu starten, im Browser zu prüfen, ob es funktionierte, usw. Es war wie eine normale Entwicklungsarbeit, nehme ich an...

Wir haben jetzt eine funktionierende App. Ich konnte sowohl den API- als auch den Webserver starten, zu localhost navigieren, die Stub-Funktion bearbeiten, auf Speichern drücken und beobachten, wie das Testfenster von rot auf grün wechselte. Dann habe ich gemerkt, dass es die Arbeit nur zur Hälfte erledigt hat, und habe den Test und die Lösung der ersten Übung auf jeder Übungsseite fest eingefügt. Ich wies ihn darauf hin und nach mehreren Schleifen konnte er den Fehler korrigieren und seine Korrekturen veröffentlichen.