← From Zero to Deployed Alle LektionenAll lessons Setup ModelleModels

Phase 2 · Bauen mit Agenten

14 · Echtes Projekt von null

Du kannst eine App gerüsten, Funktionen ergänzen und Fehler beheben — geführt vom Agenten.

Phase 2 · Building with agents

14 · Real project from scratch

You can scaffold an app, add features, and fix bugs — guided by the agent.

Hier fügt sich alles zusammen: von einem leeren Ordner zu einer laufenden App. Als Leitbeispiel bauen wir einen kleinen Instagram-Klon — du baust parallel deine eigene Idee (Medizin, Landwirtschaft, Bau, was dich interessiert) mit denselben Schritten.

Die Idee

Bau ein Haus in kleinen Schritten: erst das Gerüst, dann eine Tür, dann ein Fenster — und nach jedem Schritt schaust du, ob es steht. Genauso baust du die App: Schritt, prüfen, weiter.

Für den Instagram-Klon heißt das: erst überhaupt eine Seite, die lädt; dann ein Beitrag, der sich speichern lässt; dann ein Feed, der ihn zeigt. Kein Sprung ins Fertige.

So funktioniert es

Die Schritte am Instagram-Beispiel:

  1. Gerüst: Frontend-Seite, kleines Backend, ein Platz für Daten. Erst mal irgendetwas zum Laufen bringen.
  2. Speichern: Endpunkt POST /api/posts, um einen Beitrag anzulegen; Post-Knopf verbinden.
  3. Anzeigen: Endpunkt GET /feed, Beiträge als Feed darstellen (neueste oben).
  4. Echte Datenbank: von Zwischenspeicher auf die posts-Tabelle aus Lektion 05 wechseln.
  5. Nach jedem Schritt committen.
flowchart LR
    G[Gerüst] --> S[POST /api/posts
speichern] --> F[GET /feed
anzeigen] --> D[(Datenbank)] --> C[commit]

Debuggen ist normal: Fehlermeldung kopieren, dem Agenten geben, beschreiben, was du getan hast — Fix lesen, anwenden, erneut testen.

So steuerst du es

Arbeite in kleinen, prüfbaren Schritten und teste wirklich (Beitrag posten, neu laden, ist er noch da?). „Kompiliert“ heißt nicht „funktioniert“. Lies mit, was der Agent schreibt („Was macht diese Datei?“) — du musst nicht selbst tippen, aber du solltest folgen können.

So sagst du es dem Agenten:

„Erstelle das Gerüst einer Three-Tier-App für Instagram-Beiträge und bring es lokal zum Laufen, bevor wir Funktionen ergänzen.“

„Füge POST /api/posts und GET /feed hinzu; teste, dass ein geposteter Beitrag nach dem Neuladen noch da ist.“

„Hier ist die Fehlermeldung: … Das habe ich getan: … Finde die Ursache und schlage einen Fix vor.“

Typische Fehler: zu große Sprünge ohne Zwischentest; „läuft“ mit „funktioniert“ verwechseln; oder Änderungen ohne Commit stapeln.

Kurz-Check

  1. Was baust du zuerst — und warum?
  2. Woran erkennst du, dass ein Schritt wirklich funktioniert?
  3. Warum kleine Schritte statt großer Sprünge?
Antworten anzeigen
  1. Das Gerüst — erst etwas Lauffähiges, dann Funktionen; so hat man früh einen Stand zum Prüfen.
  2. Durch echtes Benutzen: posten, neu laden, prüfen ob der Beitrag bleibt — nicht nur „es startet“.
  3. Bei einem Fehler weißt du sofort, welcher kleine Schritt ihn verursacht hat.

Here everything comes together: from an empty folder to a running app. As the running example we build a small Instagram clone — you build your own idea alongside (medicine, agriculture, construction, whatever interests you) with the same steps.

The idea

Build a house in small steps: first the frame, then a door, then a window — and after each step you check that it stands. You build the app the same way: step, check, continue.

For the Instagram clone that means: first a page that even loads; then a post that can be saved; then a feed that shows it. No leap straight to the finished thing.

How it works

The steps, on the Instagram example:

  1. Scaffold: frontend page, small backend, a place for data. Get something running first.
  2. Save: endpoint POST /api/posts to create a post; wire up the post button.
  3. Show: endpoint GET /feed, render posts as a feed (newest on top).
  4. Real database: switch from temporary storage to the posts table from lesson 05.
  5. Commit after each step.
flowchart LR
    G[Scaffold] --> S[POST /api/posts
save] --> F[GET /feed
show] --> D[(Database)] --> C[commit]

Debugging is normal: copy the error, give it to the agent, describe what you did — read the fix, apply it, test again.

How you steer it

Work in small, checkable steps and test for real (post something, reload, is it still there?). "Compiles" is not "works". Read what the agent writes ("what does this file do?") — you do not have to type it yourself, but you should be able to follow.

How to tell the agent:

"Scaffold a three-tier app for Instagram posts and get it running locally before we add features."

"Add POST /api/posts and GET /feed; test that a posted item is still there after a reload."

"Here is the error: … This is what I did: … Find the cause and propose a fix."

Common mistakes: leaps too big without an intermediate test; confusing "runs" with "works"; or stacking changes without a commit.

Quick check

  1. What do you build first — and why?
  2. How do you know a step really works?
  3. Why small steps instead of big leaps?
Show answers
  1. The scaffold — something runnable first, then features; you get an early state to check.
  2. By using it for real: post, reload, check the item persists — not just "it starts".
  3. On a bug you immediately know which small step caused it.