Loop-Engineering: Iterative Zielentwicklung mit Claude Code

1. Das Problem: Warum “Frag-und-Vergiss” nicht funktioniert

Klassischer Workflow:

"Schreib mir einen REST API Endpoint mit Validation"
→ Claude generiert Code
→ 60% nutzbar, 40% Umbauten nötig
→ Frustration: Falsche Abstraktionen, fehlende Error-Handling, nicht testbar

Das Loop-Konzept löst das: Statt “einfach fragen”, folgen wir einem strukturierten Plan-Implement-Evaluate-Refine Zyklus, der sicherstellt, dass der generierte Code tatsächlich deinen Anforderungen entspricht.

2. Was ist Loop-Engineering?

Loop-Engineering = Iterative Zielentwicklung mit KI-gestütztem Code.

Die Anatomie eines Loops:

Goal Definition – Explizit, messbar, präzise (z.B. /goal in Claude Code)
Implementation – Claude generiert Code basierend auf dem Ziel
Evaluation – Du testest, verifizierst, erkennst Lücken
Feedback & Refinement – Du gibst strukturiertes Feedback, nächster Loop startet

Claude Code’s /goal Feature:

/goal Schreib einen Email-Validator mit Regex
Anforderungen:
- Valide Standard-Emails erkennen
- Reject: keine @, mehrere @, ungültige TLDs
- Mindestens 5 Unit Tests mit pytest

Dies ist besser als “schreib mal einen validator”, weil es der KI einen klaren Rahmen gibt.

3. DOs & DON’Ts: Praktische Richtlinien

✅ DOs

DO: SMART-Ziele formulieren
- Schlecht: “Mach ein Feature”
- Gut: “Schreib einen validator für email-addresses mit Unit-Tests, der RFC 5322 basic format validiert”
DO: Nach Implementation sofort testen
- Führe die generierten Tests aus
- Teste Edge Cases manuell
- Verifiziere gegen deine Anforderungen
DO: Feedback explizit machen
- Schlecht: “Das ist falsch”
- Gut: “Test schlägt fehl bei null-Input. Fehlerhaftung ist zu allgemein, muss distinguishable errors sein”
DO: Loops iterativ und modular halten
- Loop 1: Validierungs-Logik
- Loop 2: Unit Tests
- Loop 3: Integration in bestehendes System

❌ DON’Ts

DON’T: Vague Anforderungen
- Vage: “Mach da irgendwas mit Fehlerbehandlung”
- Sei spezifisch über Exception-Typen, Logging-Level, etc.
DON’T: Code annehmen ohne Verifikation
- Nimm den Code nicht einfach als “done”
- Unit Tests müssen grün sein
- Dein Review ist Teil des Loops
DON’T: Den Loop mit Off-Topic unterbrechen
- Loop: “Schreib einen Validator”
- Mittig: “Ach, und optimier mal meine Database-Query”
- → Neuer Loop! Beende den aktuellen erst.
DON’T: Zu große Ziele in einem Loop
- Zu groß: “Schreib eine ganze REST API mit Auth, Validierung, Logging und Monitoring”
- Besser: 4 separate Loops für Komplexität

4. How-To: Praktische Rezepte mit Code

Recipe 1: Python – Email-Validator (Einsteiger)

Ziel: Einfacher Email-Validator mit Tests

Goal Definition:

/goal Schreib einen Email-Validator in Python
Anforderungen:
- Validiert Standard-Email-Format (RFC 5322 simplified)
- Rejects: keine @, mehrere @, keine Domain nach @
- Gibt True/False zurück
- Mindestens 5 Unit Tests mit pytest
- Error handling für None/empty strings

Claude Code Workflow:

Starte Claude Code mit /goal
Claude generiert email_validator.py + test_email_validator.py
Du führst aus: pytest test_email_validator.py
Falls Fehler: Feedback geben, neuer Loop (Loop 2)

Erwarteter Output:

# email_validator.py
import re

def validate_email(email: str) -> bool:
    if not email or not isinstance(email, str):
        return False
    pattern = r'^[^@]+@[^@]+\.[^@]+$'
    return bool(re.match(pattern, email))

# test_email_validator.py
import pytest
from email_validator import validate_email

def test_valid_email():
    assert validate_email("user@example.com") == True

def test_no_at_symbol():
    assert validate_email("userexample.com") == False

# ... weitere Tests

Feedback-Zyklus (Loop 2): Wenn Tests fehlschlagen, z.B.:

/goal Verbessere den Email-Validator
Problem: Test für internationale Domains schlägt fehl
Anforderung: Support für umlauts in lokalteil

✓ Loop erfolgreich, wenn:

✅ Alle Tests grün
✅ Deine Anforderungen erfüllt
✅ Code ist lesbar und wartbar

Recipe 2: React – Todo-App State Management (Intermediate)

Ziel: Redux/Context-basiertes Todo-State mit Add/Delete/Filter

Warum mehrere Loops nötig sind:

Loop 1: State-Schema + Actions
Loop 2: Reducer-Logik + Tests
Loop 3: UI-Integration + LocalStorage

Loop 1 – State Schema:

/goal Design ein Redux State Schema für eine Todo-App
Anforderungen:
- Todos (array): { id, title, completed, createdAt }
- UI State: { filter: 'all' | 'active' | 'completed' }
- Actions: ADD_TODO, DELETE_TODO, TOGGLE_TODO, SET_FILTER
- Nutze Redux Toolkit (createSlice)

Erwarteter Output:

// todoSlice.js
import { createSlice } from '@reduxjs/toolkit';

const initialState = {
  todos: [],
  filter: 'all'
};

const todoSlice = createSlice({
  name: 'todos',
  initialState,
  reducers: {
    addTodo: (state, action) => {
      state.todos.push({
        id: Date.now(),
        title: action.payload,
        completed: false,
        createdAt: new Date()
      });
    },
    deleteTodo: (state, action) => {
      state.todos = state.todos.filter(t => t.id !== action.payload);
    },
    // ... weitere
  }
});

Loop 2 – Tests & Edge Cases:

/goal Schreib umfassende Jest Tests für den todoSlice
Anforderungen:
- Test ADD_TODO mit verschiedenen inputs
- Test DELETE_TODO für non-existent IDs
- Test FILTER_TODOS
- Edge cases: duplicate IDs, null titles, etc.

Loop 3 – UI Integration:

/goal Integrier den Redux State in die React Component
Anforderungen:
- TodoList Component (read from store)
- AddTodo Input + Button
- Filter buttons (All / Active / Completed)
- Persist state zu localStorage
- Tests mit React Testing Library

Feedback-Prozess hier: Nach Loop 3: “Der Filter funktioniert, aber das LocalStorage wird nicht auf init geladen” → Loop 4: Fix für Initialization.

Recipe 3: Rust – WebSocket Handler (Advanced)

Ziel: Async WebSocket Message Handler mit Fehlerbehandlung

Warum komplex:

Architecture (tokio runtime)
Async/await Patterns
Error Handling (mehrere Error-Types)
Broadcasting zwischen Clients
Graceful Shutdown

Loop 1 – Architecture & Basic Handler:

/goal Entwirf einen async WebSocket Handler in Rust mit tokio
Anforderungen:
- Nutze tokio für async runtime
- WebSocket library: tokio-tungstenite
- Basic Handler für einzelne Connection
- Logs mit tracing
- Error Handling mit thiserror
- Strukturiert mit Result<T, AppError>

Erwarteter Output:

use tokio::net::{TcpListener, TcpStream};
use tokio_tungstenite::accept_async;
use futures::{StreamExt, SinkExt};

#[tokio::main]
async fn main() {
    let listener = TcpListener::bind("127.0.0.1:8080").await.unwrap();
    while let (stream, _) = listener.accept().await.unwrap() {
        tokio::spawn(handle_connection(stream));
    }
}

async fn handle_connection(stream: TcpStream) {
    match accept_async(stream).await {
        Ok(ws_stream) => {
            let (mut ws_sender, mut ws_receiver) = ws_stream.split();
            while let Some(msg) = ws_receiver.next().await {
                // Handle message
            }
        },
        Err(e) => eprintln!("WS error: {}", e),
    }
}

Loop 2 – Broadcasting & Message Routing:

/goal Erweitere den Handler für Multi-Client Broadcasting
Anforderungen:
- Verwende Arc<Mutex<Vec<...>>> für Client Management
- Broadcast alle Messages zu allen Connected Clients
- Handle Disconnects gracefully
- Nutze tokio::sync::broadcast für efficiency (optional: erweitern)

Loop 3 – Comprehensive Error Handling:

/goal Hardene den Error Handling
Anforderungen:
- Custom Error Type mit thiserror
- Unterscheide: Connection Errors, Message Errors, Handler Panics
- Logging: Info für connects/disconnects, Error für failures
- Graceful degradation (ein client crash = keine server crash)
- Unit Tests für Error Paths

Feedback-Loop Beispiel: Nach Loop 3: “Wenn Client disconnect, hung der server kurz” → Loop 4: “Optimize client removal mit tokio::select! für timeout”

5. Best Practices & Fallstricke

Halluzinationen vermeiden

Problem: Claude generiert “sichere” Lösung, die beim Testen scheitert
Lösung: Spezifische, testbare Requirements im Loop
- Gut: “Muss alle RFC-5322 Cases behandeln, validiert mit diesen 5 Test-Cases”
- Schlecht: “Schreib einen guten Validator”

Loop-Breakdown

Wann funktioniert ein Loop nicht mehr?
- Ziel wird zu groß (~5+ Anforderungen gleichzeitig)
- Feedback ist zu vielschichtig (“Und auch Logging, und auch DB-Refactoring”)
- → Split in kleinere Loops

Token-Effizienz

Long Conversations ballastieren sich durch History
Best Practice: Nach ~10 Loops oder bei Context-Schwellenwert neue Conversation
Wichtige Erkenntnisse in Gist/File exportieren für nächste Conversation

Team-Kontext & Dokumentation

Loops als Dokumentation:
- Jeder Loop definiert explizit “was muss dieser Code tun”
- Ideal für Onboarding neuer Entwickler
- PR-Reviews können gegen Loop-Requirements validieren

Debugging Loops

Wenn Claude “hängt” im Loop:
- Ziel neu definieren (präziser, kleiner)
- Constraint hinzufügen (“Maximal 100 Zeilen Code”)
- Oder: Backup Strategy geben (“Falls das fehlschlägt, versuche Ansatz B”)

6. Integration in deinen Workflow

Claude Code & Windsurf

Claude Code: /goal Feature für explizite Loop-Definition
Windsurf: Ähnlich nutzbar, aber weniger structured; Loops manuell definieren

Vergleich zu anderen Agentic Patterns

Pattern	Ansatz	Einsatz
Loop-Engineering	Iterativ, Goal-fokussiert, Feedback-driven	Einzelne Features, Code-Quality kritisch
GSD (Graph State Decomposition)	Planungs-Graph, Multi-Step, strukturiert	Komplexe Multi-File Refactorings
Conductor	Orchestrierung mehrerer Agents	Team-Szenarien, parallele Tasks

Loop-Engineering ist ideal für:

Fachhochschul-Level Teaching (Feedback-Schleifen = Learning)
Einzelne, wohldefinierten Features
Code-Quality ohne explizites Planing-Tool nötig
Schnelle Iteration mit hoher Kontrolle

7. Ressourcen & weitere Schritte

Anthropic Dokumentation:

Claude Code Official Docs – /goal Feature & Best Practices
API Documentation – Batch Processing, Tool Use für Loops
Prompt Engineering Guide – Ziel-Definition optimieren

Deine nächsten Schritte:

Pick ein Recipe: Starte mit Recipe 1 (Email-Validator)
Try Loop-Engineering: Folge der /goal Struktur
Dokumentiere Feedback: Was funktioniert, was nicht
Skaliere: Integriere Loops in deine FFHS-Module

Fazit

Loop-Engineering ist keine komplexe Agentic-Architektur – es ist eine pragmatische Mindset-Shift:

Von “Frag die KI und hoffe” zu “Definiere ein Ziel, evaluiere, lerne, verfeinere”
Feedback ist nicht Störung, sondern Kernmechanismus
Skalierbar vom Einsteiger (Recipe 1) bis zum Advanced Developer (Recipe 3)

Für FFHS-Studenten bedeutet das: Sie lernen, mit KI-Tools wie mit einem Code-Review Partner zu arbeiten – nicht als Magic Box, sondern als iterativer Sparring Partner.

Autor: Daniel Senften, Talent Factory GmbH Letzte Aktualisierung: Juni 2026