Git Gud: Warum AI-Coding wie Dark Souls ist

Einleitung: Das Problem sitzt vorm Computer

Produktivität ist komplex (aber trotzdem real)

You Died

Die zwei Welten

“Je weniger Zeit ich mir für Details und Prozesse nehme, desto weniger ich mich selbst dazu zwinge, mich an diese zu halten – desto mehr Scheiße kommt am Ende dabei raus. Und der Zusammenhang ist nicht linear, der ist exponentiell.”

Patterns, keine Regeln

Pattern 1: Scout Before You Prompt

Pattern 2: Requirements ≠ Engineering Context

“Anforderungen reichen nicht, ein gutes Ergebnis mit KI zu produzieren. Du kannst noch so viel Kontext bereitstellen auf einer Anforderungsebene. Aber solange Du nicht in die Engineering-Ebene wechselst, ist die Wahrscheinlichkeit hoch, dass am Ende aus den Anforderungen kein kohärentes Gesamtbild entsteht.”

Pattern 3: Sokrates, nicht Befehl

Pattern 4: Kontext ist König

Pattern 5: The Starting Stats Test

Pattern 6: Eine Rolle zur Zeit

“Ich hab alle Aufgaben einfach über den Zaun geworfen und gesagt: Du bist Requirements Engineer, Du bist Architekt, Du bist Coder, Du bist Business Analyst. Und das sind alles Aufgaben, die auch in Software Teams nicht die gleiche Person durchführt.”

Pattern 7: User Story Level, nicht Epic Level

“Prompt User Story Level. Man muss aus dem Kontext heraus Aufgaben schneiden, die die Möglichkeit von Unklarheiten und undefinierten Zuständen maximal reduziert.”

Pattern 8: Sequencing & Dependencies

“In dem Moment wo ich versuche, einen kompletten Durchstich in einem System herzustellen, bekomm ich nach links und rechts Ausreißer. Das ist fast unvermeidbar.”

Pattern 9: Reduce Undefined States to Zero

Pattern 10: Erwartungen vor Code

{
  month: "2025-11",  totalIncome: 5000,  totalExpenses: 3200,  categoryBreakdown: [
    { category: "Food", amount: 800 },    { category: "Rent", amount: 1500 },    { category: "Transport", amount: 200 }
  ],  netBalance: 1800}

Pattern 11: Verständnis-Validierung vor Code

“Davon auszugehen, dass etwas klar ist, funktioniert auch in der menschlichen Kommunikation nicht. Wenn ich einem Engineer sage, was ich brauche, dann haue ich denen nicht drei Sätze an den Kopf, referenziere auf irgendeine Datei, und gehe dann davon aus, dass das verstanden wurde.”

Pattern 12: Code Reflection Test

“Ich habe die Requirements definiert. Habe in den Code reingeschaut und habe nicht greifen können, was es hier geht. Die Features haben nicht das widergespiegelt, was ich glaube, reingegeben zu haben.”

Pattern 13: Stop Loss Rules

“Ich glaube, das aufzuräumen, dauert länger als von vorne anzufangen. Und das ist genau, wo viele sagen: AI Coding lohnt sich nicht, weil ich habe am Ende in zwei Stunden einen Haufen Code produziert und eine Woche lang gesessen, das wieder zu fixen. App hätte ich in der Zeit aber selber geschrieben.”

“Man muss das einmal gesehen haben, was dann passiert, zu verstehen, was es braucht, das zu verhindern.”

Der Prozess: Wie Patterns zusammenwirken

Phase 1: Foundation

Phase 2: Context Building

# Architektur## Layer- Data Access: Repository Pattern
- Business Logic: Service Layer mit DI
- API: REST Endpoints mit DTOs
- Frontend: React + TypeScript + Zustand
## Patterns- Repository Pattern für alle Entities
- Service Layer für Business Logic
- DTOs als API Contracts
- Result<T> für Error Handling
## Data FlowRequest → API → Service → Repository → Database

# Requirements V1## Core Features- User Authentication (Login/Register, keine Password Reset)
- Transaction Tracking (date, amount, category, description)
- Categories (Food, Rent, Transport, Utilities) - fixe Werte
- Monthly Reports (Summen pro Kategorie)
## Out of Scope V1- Password Reset
- OAuth Integration
- Recurring Transactions

# Tech Decisions- Framework: React 18 + TypeScript
- State: Zustand (nicht Redux - zu overhead für V1)
- Styling: Tailwind CSS
- Database: PostgreSQL
- Backend: Node.js + Express
- Auth: JWT (nicht Session-based)

Phase 3: Implementation

{ email: string, password: string }

{
  success: true,  data: {
    token: "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...",    user: {
      id: "uuid",      email: "[email protected]",      createdAt: "2025-11-09T10:00:00Z"    }
  }
}

Phase 4: Integration & Review

test('User Registration Flow', async () => {
  const response = await api.post('/auth/register', {
    email: '[email protected]',    password: 'Test1234'  });  expect(response.status).toBe(200);  expect(response.data.token).toBeDefined();  expect(response.data.user.email).toBe('[email protected]');  // Verify user in DB  const user = await db.users.findByEmail('[email protected]');  expect(user).toBeDefined();  expect(user.passwordHash).not.toBe('Test1234'); // hashed});

Case Study: Manufacturing Projekt

Case Study: Finance App

“Man muss das einmal gesehen haben, was dann passiert, zu verstehen, was es braucht, das zu verhindern.”

Pattern Cheatsheet: Quick Reference

Git Gud

Nachwort