The Last Algorithm

Wenn du nur eine Sache aus diesem Text mitnimmst: Das mächtigste KI-Setup ist oft kein neues Modell — sondern ein banaler Loop mit brutal guter Verifikation. Wie ein Hamster im Rad, der nicht schneller rennt, sondern lernt, wo der Notausgang ist.

TL;DR (für Menschen mit Kalendern)

• Modelle werden besser und austauschbarer.
• Schleifen (Goal → Execute → Verify → Learn) werden der echte Multiplikator.
• Verifikation ist der Hebel: Autonomie ist eine Folge von Prüfbarkeit.
• Wer 2026 gewinnt, baut nicht „die beste KI“, sondern die besten Verifier Packs.

Prolog: Der peinlich einfache Trick, der plötzlich nach Zukunft riecht

Stell dir vor, du bist auf einer Tech-Konferenz. Jemand fragt mit dieser Stimme, die schon nach VC-Deck klingt: „Wie bauen wir das nächste große KI-Ding?“

Die Menge erwartet Quanten, Neuronen, Matritzen, mindestens drei griechische Buchstaben.

Du sagst: „Eine while-Schleife.“

Erst lachen alle. Dann wird es still. Nicht weil du deep bist – sondern weil es unangenehm plausibel ist.

Denn was gerade passiert, ist weniger „Magie“ und mehr Industrialisierung von Iteration: Nicht ein perfekter Output. Sondern viele Versuche, Feedback, Budgetgrenzen, Tests, Abbruchbedingungen.

Das Meme dafür heißt „Ralph Wiggum Loop“ – benannt nach dem Simpsons-Ralph („I’m in danger!“), der in Endlosschleifen stolpert. Der Witz ist: In Software wirkt dieses Stolpern plötzlich wie Superkraft, wenn du es richtig verifizierst.

1) Ralph, Sisyphos, Groundhog Day: Der Loop als Held (und manchmal als Bösewicht)

Der „Ralph“-Loop ist in seiner Grundform banal:

• Agent arbeitet (Text/Code/Plan).
• Scheitert (oder ist nur „meh“).
• Bekommt Feedback.
• Versucht es erneut.
• Wiederholt, bis Erfolg oder Circuit Breaker.

Das ist Groundhog Day als Engineering-Prinzip: Du musst nicht „klüger“ werden, du musst besser zurückkoppeln.

Warum das so mächtig ist: Iteration verändert die Unit Economics von Problemlösung

Klassisches Denken: „Wir brauchen den perfekten Wurf.“ Loop-Denken: „Wir brauchen einen Prozess, der aus Fehlschlägen Fortschritt presst.“

Wenn du einen verlässlichen Verifier hast, wird das Modell zu einem Bauteil – wichtig, aber nicht exklusiv.

Warum das auch gefährlich ist

Loops verstärken nicht nur Fortschritt. Sie verstärken auch:

• schlechte Ziele,
• schlechte Metriken,
• blinde Flecken,
• „kreative“ Optimierung (Goodhart lässt grüßen).

Ein Loop ist ein Verstärker. Und Verstärker machen Lärm wie Musik – abhängig davon, was du einspeist.

2) Der Foundational Algorithm: Außen Schleife, innen Wissenschaft

Nenn es „Foundational Algorithm“ oder „Last Algorithm“. Die Mechanik:

1. Outer Loop: Current State → Desired/Ideal State
2. Inner Loop: Iterieren wie eine operationalisierte wissenschaftliche Methode

Die Pointe:

Das Modell ist der Motor. Der Loop ist das Fahrzeug. Verifikation ist die Straße.

Du kannst den besten Motor haben – wenn du keine Straße hast, fährst du trotzdem ins Gebüsch.

3) Outer Loop: Current → Ideal (oder: Warum „Ziel“ ein Ingenieursproblem ist)

„Ziel“ klingt nach Management-Folie. In der Praxis ist es ein Design-Artefakt, das entscheidet, ob deine Iteration Sinn ergibt.

Der entscheidende Unterschied:

• „Korrekt“ ist billig.
• „Euphoric Surprise“ ist ein Engineering-Problem.

Beispiel:

• Schlecht: „Schreib einen Blogpost über Loops.“
• Besser: „Schreib einen Blogpost, der einem technischen Leser ein neues Denkwerkzeug gibt, das er morgen im Team nutzen kann – ohne Buzzword-Kater.“

Drei Dinge, die dein Zielbild enthalten muss

1. Outcome: Was soll nachher anders sein?
2. Verifier: Woran erkennst du „gut genug“?
3. Anti-Kriterien: Was darf nicht passieren?

Wenn du (2) nicht hast, hast du keine Schleife. Du hast Hoffnung mit Tastatur.

4) Inner Loop: Eine wissenschaftliche Methode, die man deployen kann

Eine robuste innere Schleife sieht so aus:

OBSERVE → THINK → PLAN → BUILD → EXECUTE → VERIFY → LEARN

Das ist kein Buzzword-Bingo, sondern eine Produktionspipeline.

• OBSERVE: Kontext, Constraints, Datenlage, Baseline
• THINK: Hypothesen, Ursachen, Tradeoffs
• PLAN: Schritte, Risiken, Abhängigkeiten, Budget
• BUILD: Entwurf/Implementierung
• EXECUTE: In der Realität (oder Simulation) laufen lassen
• VERIFY: Checks, Tests, Rubrics, Reviews
• LEARN: Update von Prompts, Regeln, Daten, Verifiern, Prozess

Wenn du willst, ist das:

• PDCA mit schärferer Verifikation
• OODA ohne Romantik
• Scientific Method als Deployable System

Und ja: Ralph würde es falsch benutzen. Aber genau deshalb ist Verifikation der Bossfight.

5) Der Hebel heißt Verifizierbarkeit

Warum funktionieren Loops in Code so gut?

Weil Code relativ gut verifizierbar ist:

• kompiliert?
• Tests grün?
• Output stimmt?

Das führt zur Kernregel:

Autonomie ist keine Eigenschaft des Modells. Autonomie ist eine Funktion der Verifikation.

Je besser du prüfen kannst, desto mehr darf die Maschine alleine.

Wenn du wenig prüfen kannst, brauchst du:

• stärkere Reviews
• strengere Anti-Kriterien
• engere Budgets
• mehr Beobachtbarkeit (Logs, Traces, Audits)

6) Die Verifizierbarkeits-Leiter (und wie man „weich“ härter macht)

Nicht jede Domäne ist „Unit Tests und fertig“. Aber du kannst Prüfbarkeit hochziehen.

Stufe 1: Deterministisch (hart)

• Compiler, Unit Tests, Linter, Schema-Validation Beispiele: JSON Schema, type checks, invariants

Stufe 2: Messbar, aber stochastisch

• Benchmarks, A/B-Tests, Regressionen Beispiele: Conversion, Fehlerrate, Latenz

Stufe 3: Rubric-basiert (semi-objektiv)

• Kriterienkatalog + Scoring + Gate Beispiele: Klarheit, Vollständigkeit, Quellenhygiene, Stil

Stufe 4: Menschliche Urteilskraft (subjektiv, aber steuerbar)

• Expert Review, Redaktion, Nutzertests Beispiele: „Würde ich das teilen?“ „Ist das wirklich hilfreich?“

Wie du „weich“ härter machst (Praktische Patterns)

• Gold Samples: 10–30 Beispiele für „so sieht gut aus“
• Anti-Samples: typische Failure Modes („so sieht Halluzination aus“)
• Weighting: nicht alles zählt gleich (z. B. Wahrheit > Humor)
• Canary Checks: schnell + billig (pro Iteration)
• Deep Checks: selten, aber gründlich (pro Meilenstein)
• Multi-Verifier: mehrere Perspektiven statt One-Metric-Gott

Wenn du nur eine Metrik hast, fütterst du Goodhart wie ein Tamagotchi.

7) Verifier Packs: Das eigentliche Produkt

Ein Verifier Pack ist ein Set aus:

• Checkliste (binär)
• Rubric (Scoring)
• Red-Team-Prompts (Angriffe auf Schwachstellen)
• Beispiele (Gold/Anti)
• Abbruchregeln (Circuit Breaker)

Das Pack ist nicht „nice to have“. Es ist der Unterschied zwischen:

• „Agent schreibt irgendwas“
• und „System produziert zuverlässig brauchbare Artefakte“

8) Beispiele außerhalb von Code (ohne Buzzword-Disneyland)

Marketing

• Verifier: Claim-Check, Tonalität, „keine unbelegten Superlative“, Zielgruppenfit
• Metriken: CTR/CR mit Guardrails (Bounce, Complaints, Brand Safety)

Customer Support

• Verifier: Policy-Konformität, Quellenpflicht, „kein erfundener Prozess“
• Metriken: First-contact resolution, Escalation Rate, CSAT

Produkt/Strategy

• Verifier: Annahmen explizit, Alternativen, Risiken, „Decision-Ready Output“
• Review: Entscheider-Readout („kann ich damit entscheiden?“)

Operations

• Verifier: SLA, Runbook-Korrektheit, Rollback-Plan
• Metriken: MTTR, Incident Rate, Change Failure Rate

Die Form ist immer dieselbe:

Goal Spec + Loop + Verifier Pack + Budget + Logs.

9) Architektur: Wie sieht so ein Loop als System aus?

Minimal brauchst du:

1. Goal Spec (Ideal-State-Brief)
2. Planner
3. Executor (Modell + Tools)
4. Verifier Pack
5. Memory (was wurde probiert, was gelernt)
6. Budget & Circuit Breaker
7. Governance (Rechte, Logs, Freigaben)

Pseudocode:

state = observe()
goal  = ideal_state_brief()

for i in 1..N:
  plan   = make_plan(state, goal)
  draft  = execute(plan)
  score  = verify(draft, goal.verifiers)

  if score.pass:
     return draft

  state = learn(state, draft, score.feedback)

abort("budget/time exceeded")

Die Magie ist nicht execute(). Die Magie ist verify() — plus die Disziplin, es wirklich zu verwenden.

10) Design-Hygiene: Goodhart, Circuit Breaker, Security (die Teile, die aus „cool“ „professionell“ machen)

Goodhart-Gefahr

Wenn eine Kennzahl zum Ziel wird, wird sie manipulierbar.

Gegenmittel:

• mehrere Checks
• Anti-Kriterien
• Random Audits
• qualitative Reviews als Gate

Circuit Breaker

Definiere:

• max Iterationen
• max Kosten
• max Zeit
• Abbruch bei „keine Verbesserung über X Iterationen“

Verifikation vor Autonomie

Je weniger verifizierbar die Domäne, desto mehr:

• Human-in-the-loop
• Freigaben
• Rollback
• Audit Logs

Und ja: Das ist weniger sexy als „Agentic Future“. Es ist aber der Teil, der verhindert, dass dein Loop nachts um 03:00 Uhr kreativ wird.

11) Ideal-State-Brief (Template) + Blog-Verifier Pack (kopierbar)

Ideal-State-Brief (Template)

1. Auftrag / Problem: Was soll gelöst werden?

2. Kontext: Zielgruppe, Umfeld, vorhandene Assets, Vorversuche

3. Constraints: Zeit, Budget, Tonalität, Compliance, No-Gos

4. Erfolgskriterien (verifizierbar):

   • Output: Format, Struktur, Muss-Elemente
   • Qualität: Klarheit, Genauigkeit, Neuheitswert

5. Anti-Kriterien: Was darf nicht passieren?

6. Checks: Tests, Rubrics, Reviews, Benchmarks

7. Definition of Done: Woran ist es „fertig“?

Blog-Verifier Pack (Beispiel)

Checkliste (binär)

• Begriffe erklärt (Outer/Inner Loop, Verifier, Goodhart)
• Mindestens 5 konkrete Beispiele
• Mindestens 1 Template + 1 Rubric
• Keine überstarken Claims ohne Einordnung/Quelle
• Risikoabschnitt: Goodhart, Breaker, Governance

Rubric (0–5)

• These & Struktur: __
• Konkretheit (Beispiele/Patterns): __
• Verifikation (wie prüfbar gemacht): __
• Klarheit (keine Nebelwörter): __
• Unterhaltung (humorvoll, nicht albern): __

Red-Team-Prompt „Finde die drei größten Logik-Lücken und die zwei größten Übertreibungen. Welche Begriffe sind unklar? Wo fehlt ein Verifier?“

Epilog: Die Frage für 2026

Wenn diese Intuition stimmt, lautet die relevante Frage 2026 nicht: „Welches Modell gewinnt?“

Sondern: „Wer baut die besseren Schleifen — mit besserer Zieldefinition, besserer Verifikation und besserem Lernen?“

Weil am Ende nicht das Modell dein Produkt ist. Dein Produkt ist die Maschine, die aus Versuchen Ergebnisse macht.

Appendix: Mini-Glossar

• Outer Loop: Zielbild + Erfolgskriterien
• Inner Loop: Iteration nach Scientific-Method-Logik
• Verifier: Prüfer (Tests, Rubrics, Reviews)
• Rubric: Scorecard mit Kriterien + Gewichtung
• Goodhart: „Wenn Metrik Ziel wird, wird sie kaputtoptimiert“
• Circuit Breaker: Stop-Knopf gegen Endlosschleifen