Test Driven Development mit Codex: Erst Tests, dann Code – so funktioniert TDD mit KI

KI kann heute in wenigen Sekunden ganze Funktionen entwickeln. Ein kurzer Prompt genügt, und schon entstehen Python-Skripte, JavaScript-Komponenten oder komplette Backend-Endpunkte.

Das Problem: Nur weil KI-generierter Code funktioniert, bedeutet das noch lange nicht, dass er korrekt, sicher oder dauerhaft wartbar ist.

Genau hier kommt Test Driven Development (TDD) ins Spiel. Statt einer KI einfach zu sagen „Schreibe mir diese Funktion", drehen wir den Entwicklungsprozess um: Zuerst definieren wir, was funktionieren muss. Danach lassen wir Codex den passenden Code entwickeln.

Diese Vorgehensweise verändert die Zusammenarbeit zwischen Mensch und KI grundlegend. Aus einem reinen Codegenerator wird ein Entwicklungsassistent, dessen Ergebnisse anhand überprüfbarer Anforderungen kontrolliert werden können.

In diesem Artikel erfährst du, wie Test Driven Development mit Codex funktioniert, warum der Test-First-Ansatz besonders für KI-generierten Code sinnvoll ist und wie du einen vollständigen TDD-Workflow in der Praxis umsetzt.

Was ist Test Driven Development (TDD)?

Test Driven Development ist eine Methode der Softwareentwicklung, bei der automatisierte Tests geschrieben werden, bevor der eigentliche Programmcode entsteht.

Das Prinzip ist einfach: Ein Test beschreibt zunächst das erwartete Verhalten einer Funktion. Anschließend wird nur so viel Code entwickelt, wie notwendig ist, um diesen Test erfolgreich auszuführen.

Der Zyklus wird für jede neue Anforderung wiederholt.

Phase 1: RED – Einen fehlschlagenden Test erstellen

Bevor eine Funktion existiert, wird ein Test geschrieben, der ihr erwartetes Verhalten beschreibt. Der Test muss zunächst aus dem richtigen Grund fehlschlagen – beispielsweise weil die Funktion noch nicht implementiert wurde.

Phase 2: GREEN – Nur den notwendigen Code entwickeln

Jetzt entsteht die eigentliche Implementierung. Ziel ist nicht sofort die eleganteste Lösung, sondern die kleinste sinnvolle Implementierung, die den Test erfolgreich bestehen lässt.

Phase 3: REFACTOR – Den Code verbessern

Erst wenn die Tests erfolgreich sind, wird der Code überarbeitet. Dabei können beispielsweise Funktionen aufgeteilt, doppelte Logik entfernt oder Bezeichnungen verbessert werden. Wichtig: Nach jeder Änderung müssen die Tests weiterhin erfolgreich sein.

Warum ist TDD gerade bei KI-generiertem Code wichtig?

Traditionell schreiben Entwickler Code und überprüfen anschließend dessen Funktion. Mit KI-Coding-Agenten verändert sich die Situation: Ein Agent kann innerhalb kurzer Zeit mehrere Dateien erstellen, bestehende Funktionen verändern und neue Abhängigkeiten hinzufügen. Dadurch steigt nicht automatisch die Softwarequalität. Im Gegenteil: Fehler können schneller entstehen und sich über mehrere Komponenten verteilen.

Typische Probleme bei KI-generiertem Code sind:

• Funktionen berücksichtigen wichtige Grenzfälle nicht.
• Der Code erfüllt eine ungenau formulierte Anforderung nur teilweise.
• Bestehende Funktionen werden durch Änderungen beschädigt.
• Tests prüfen lediglich den erfolgreichen Standardfall.
• Der KI-Agent verändert Anforderungen oder Tests, damit seine Implementierung erfolgreich erscheint.

Mit Test Driven Development lassen sich diese Risiken reduzieren. Der entscheidende Unterschied: Die Anforderungen werden vor der Implementierung in ausführbare Tests übersetzt. Ein Test ist damit nicht nur eine technische Prüfung, sondern gleichzeitig eine konkrete Beschreibung des erwarteten Verhaltens.

Allerdings gilt: Auch Tests können Fehler enthalten. Ein erfolgreicher Testlauf beweist deshalb nicht automatisch, dass eine Anwendung vollständig korrekt oder sicher ist.

Was ist Codex und welche Rolle übernimmt der KI-Agent?

OpenAI Codex ist ein KI-gestützter Coding-Agent, der Entwickler bei der Arbeit an Softwareprojekten unterstützt. Je nach verwendeter Umgebung kann Codex unter anderem bestehende Projektdateien analysieren, Quellcode bearbeiten, Tests erstellen, Befehle ausführen und Änderungen überprüfen.

Für TDD sind insbesondere vier Fähigkeiten interessant:

• Anforderungen analysieren: Codex kann aus einer Funktionsbeschreibung überprüfbare Testfälle ableiten.
• Tests implementieren: Der Agent erstellt beispielsweise pytest-, Jest- oder Vitest-Tests.
• Code entwickeln: Anschließend implementiert er die notwendige Funktionalität.
• Testergebnisse auswerten: Fehlgeschlagene Tests können zur gezielten Fehlerkorrektur verwendet werden.

Der größte Vorteil entsteht allerdings nicht dadurch, dass Codex sämtliche Schritte unkontrolliert ausführt. Sinnvoller ist ein klar definierter Workflow, bei dem der Mensch Anforderungen und Akzeptanzkriterien vorgibt.

Praxisbeispiel: Test Driven Development mit Codex und Python

Wir entwickeln eine kleine Python-Funktion zur Berechnung eines Rechnungsbetrags inklusive Mehrwertsteuer. Die Funktion soll folgende Anforderungen erfüllen:

• Ein Nettobetrag wird übergeben.
• Der Mehrwertsteuersatz ist konfigurierbar.
• Negative Nettobeträge werden abgelehnt.
• Ungültige Steuersätze werden abgelehnt.
• Das Ergebnis wird kaufmännisch auf zwei Nachkommastellen gerundet.

Für dieses Beispiel verwenden wir Python und pytest.

Schritt 1: Projekt vorbereiten

Erstelle zunächst ein neues Projektverzeichnis.

mkdir codex-tdd-demo
cd codex-tdd-demo

python3 -m venv .venv
source .venv/bin/activate

python -m pip install pytest

Unter Windows erfolgt die Aktivierung der virtuellen Umgebung beispielsweise mit:

.venv\Scripts\Activate.ps1

Anschließend legen wir folgende Projektstruktur an:

codex-tdd-demo/
├── src/
│   ├── __init__.py
│   └── invoice.py
├── tests/
│   └── test_invoice.py
└── pytest.ini

Die Datei invoice.py bleibt zunächst ohne Implementierung. In pytest.ini tragen wir ein:

[pytest]
pythonpath = .
testpaths = tests

Schritt 2: Codex ausschließlich Tests schreiben lassen

Jetzt kommt der wichtigste Teil des TDD-Workflows. Wir geben Codex einen klaren Auftrag: Er soll zunächst ausschließlich die Tests erstellen.

Arbeite nach Test Driven Development (TDD).

Erstelle ausschließlich pytest-Tests für eine Funktion
calculate_gross(net_amount, tax_rate) in src/invoice.py.

Anforderungen:
- Verwende Decimal für Geldbeträge.
- Berechne den Bruttobetrag inklusive Mehrwertsteuer.
- Unterstütze Steuersätze zwischen 0 und 1 einschließlich.
- Lehne negative Nettobeträge ab.
- Lehne ungültige Steuersätze ab.
- Runde kaufmännisch auf zwei Nachkommastellen.
- Teste Normalfälle, Nullwerte, Grenzfälle und ungültige Eingaben.

WICHTIG:
- Implementiere die Funktion noch nicht.
- Verändere keine bestehenden Anwendungstests.
- Führe pytest aus und dokumentiere, warum die neuen
  Tests fehlschlagen.
- Beende deine Arbeit nach der RED-Phase.

Dieser Prompt enthält eine wichtige Einschränkung: Codex darf noch keinen produktiven Code schreiben. Damit verhindern wir, dass der Agent den Test-First-Ansatz überspringt.

Schritt 3: Die Tests überprüfen

Ein möglicher Test sieht folgendermaßen aus:

from decimal import Decimal
import pytest

from src.invoice import calculate_gross

def test_gross_amount():
    result = calculate_gross(Decimal("100.00"), Decimal("0.19"))
    assert result == Decimal("119.00")

def test_zero_amount():
    result = calculate_gross(Decimal("0.00"), Decimal("0.19"))
    assert result == Decimal("0.00")

def test_negative_amount():
    with pytest.raises(ValueError):
        calculate_gross(Decimal("-10.00"), Decimal("0.19"))

def test_invalid_tax_rate():
    with pytest.raises(ValueError):
        calculate_gross(Decimal("100.00"), Decimal("1.50"))

Diese Tests prüfen unterschiedliche Situationen. Besonders interessant ist der letzte Test: Er überprüft die Ablehnung eines ungültigen Steuersatzes. Gerade bei Finanzberechnungen ist es wichtig, Rundungs- und Validierungsregeln ausdrücklich festzulegen.

Schritt 4: RED – Die Tests müssen fehlschlagen

Führe jetzt die Tests aus:

python -m pytest -v

Da die Funktion noch nicht existiert, schlägt bereits der Import fehl. Eine mögliche Fehlermeldung lautet:

ImportError: cannot import name 'calculate_gross' from 'src.invoice'

Das ist in dieser Phase erwünscht. Der Fehler bestätigt, dass die erwartete Funktion noch nicht implementiert ist. Wichtig ist jedoch, den Fehler richtig einzuordnen: Ein fehlgeschlagener Import ist noch kein Beweis dafür, dass sämtliche Testfälle korrekt formuliert wurden. Nach dem Anlegen der Funktion müssen die einzelnen Tests tatsächlich ausgeführt werden können.

Schritt 5: GREEN – Codex entwickelt die Implementierung

Jetzt darf Codex den eigentlichen Code schreiben. Der nächste Prompt lautet:

Implementiere jetzt ausschließlich die Funktion calculate_gross()
in src/invoice.py. Verwende Decimal und ROUND_HALF_UP. Ändere keine
Tests. Implementiere nur die notwendige Logik, damit alle zuvor
erstellten Tests erfolgreich sind. Führe anschließend pytest aus
und zeige das Ergebnis.

Eine mögliche Implementierung:

from decimal import Decimal, ROUND_HALF_UP

def calculate_gross(net_amount: Decimal, tax_rate: Decimal) -> Decimal:
    if not isinstance(net_amount, Decimal):
        raise TypeError("net_amount must be Decimal")
    if not isinstance(tax_rate, Decimal):
        raise TypeError("tax_rate must be Decimal")
    if not net_amount.is_finite():
        raise ValueError("Invalid net amount")
    if not tax_rate.is_finite():
        raise ValueError("Invalid tax rate")
    if net_amount < 0:
        raise ValueError("Negative amounts are not allowed")
    if not Decimal("0") <= tax_rate <= Decimal("1"):
        raise ValueError("Invalid tax rate")

    gross = net_amount * (Decimal("1") + tax_rate)
    return gross.quantize(Decimal("0.01"), rounding=ROUND_HALF_UP)

Die Funktion validiert zunächst die Eingaben, berechnet anschließend den Bruttobetrag und rundet das Ergebnis auf zwei Nachkommastellen. Bei einem Nettobetrag von 100 Euro und 19 Prozent Mehrwertsteuer ergibt sich ein Bruttobetrag von 119,00 Euro.

Nach der Implementierung führen wir die Tests erneut aus. Bei korrekter Einrichtung und unveränderten Beispieltests sollte das Ergebnis folgendermaßen aussehen (Beispielausgabe, kein hier tatsächlich ausgeführter Testlauf):

================ test session starts ================
collected 4 items

tests/test_invoice.py ....                     [100%]

================= 4 passed ==========================

Damit ist die GREEN-Phase erreicht.

Schritt 6: REFACTOR – Codex verbessert den Code

Nachdem die Tests erfolgreich sind, kann Codex die Implementierung verbessern. Beispielsweise könnte der Agent wiederholte Validierungslogik in eine Hilfsfunktion auslagern. Der passende Prompt:

Analysiere die bestehende Implementierung auf Lesbarkeit,
Wartbarkeit und unnötige Wiederholungen. Refaktoriere den Code,
ohne das beobachtbare Verhalten zu verändern. Bestehende Tests
dürfen nicht angepasst werden. Führe anschließend die vollständige
Testsuite aus und dokumentiere die Änderungen.

Entscheidend ist, dass das Refactoring keine neuen fachlichen Anforderungen einführt. Der Code soll verbessert werden, ohne sein bisheriges Verhalten zu verändern.

Codex TDD-Workflow: So sollte ein KI-Agent arbeiten

In größeren Projekten reicht ein einzelner Prompt häufig nicht aus. Hier empfiehlt sich eine feste Arbeitsanweisung, die Codex für jede neue Funktion befolgen soll.

Du arbeitest strikt nach Test Driven Development (TDD).

1. Analysiere zunächst die Anforderungen und bestehenden Tests.
2. Formuliere überprüfbare Akzeptanzkriterien.
3. Schreibe neue Tests vor der Implementierung.
4. Führe die Tests aus und dokumentiere die RED-Phase.
5. Implementiere die kleinstmögliche sinnvolle Lösung.
6. Führe alle relevanten Tests aus und dokumentiere GREEN.
7. Refaktoriere ohne Verhaltensänderung.
8. Führe erneut die gesamte relevante Testsuite aus.
9. Verändere niemals Tests nur, damit fehlerhafter Code besteht.
10. Melde unklare Anforderungen und nicht ausführbare Tests
    ausdrücklich.

Arbeite in kleinen, nachvollziehbaren Schritten. Berichte
abschließend über Änderungen, Testbefehle, Testergebnisse und
verbleibende Risiken.

Diese Anweisung lässt sich beispielsweise als Projektregel in einer AGENTS.md-Datei hinterlegen, sodass Codex bei späteren Entwicklungsaufgaben auf dieselben Arbeitsregeln zurückgreifen kann. Wie sich eine solche AGENTS.md sinnvoll von einer CLAUDE.md für Claude Code abgrenzen lässt, erklärt AGENTS.md vs. CLAUDE.md: Welche Datei braucht dein KI-Coding-Projekt? (Zum Artikel).

Allerdings sind solche Projektanweisungen keine unveränderbaren technischen Sicherheitsgrenzen. Für verbindliche Prüfungen sollten zusätzlich CI-Pipelines, Berechtigungen und Branch-Schutzregeln eingesetzt werden.

Welche Testarten kann Codex erstellen?

Test Driven Development beschränkt sich nicht auf einfache Unit Tests. Je nach Projekt können unterschiedliche Testarten sinnvoll sein.

Ein praktisches Beispiel: Wenn Codex eine REST-API entwickelt, können zuerst Tests für erfolgreiche Antworten, ungültige Eingaben, fehlende Berechtigungen und Fehlerfälle entstehen. Erst danach implementiert der Agent die entsprechenden Endpunkte. So wird das erwartete API-Verhalten vor der eigentlichen Entwicklung festgelegt.

TDD mit Codex in bestehenden Projekten einsetzen

Besonders interessant ist Test Driven Development bei der Weiterentwicklung bereits vorhandener Anwendungen. Angenommen, ein bestehendes Flask-Backend soll eine neue API-Funktion erhalten. Ohne Test-First-Ansatz könnte Codex direkt mehrere Dateien verändern.

Mit TDD erfolgt die Entwicklung kontrollierter: Zunächst analysiert der Agent vorhandene Endpunkte und Tests. Anschließend erstellt er zusätzliche Tests für die gewünschte Funktion. Danach implementiert er die Änderung und überprüft sowohl die neuen Tests als auch die bestehende Testsuite. Auf diese Weise lassen sich unbeabsichtigte Verhaltensänderungen früher erkennen.

Ein sinnvoller Codex-Auftrag für eine Fehlerkorrektur mit Regressionstest wäre beispielsweise: „Analysiere den gemeldeten Fehler. Erstelle zunächst einen Regressionstest, der den Fehler reproduziert. Führe den Test aus und bestätige, dass er aufgrund des beschriebenen Fehlers fehlschlägt. Behebe anschließend die Ursache, ohne den Test zu verändern. Führe zum Abschluss alle relevanten Tests aus."

Dieser Ansatz hat einen langfristigen Vorteil: Der Fehler wird nicht nur behoben, sondern bleibt durch den Regressionstest überprüfbar. Bei späteren Änderungen kann der Test verhindern, dass derselbe Fehler unbemerkt zurückkehrt.

Die fünf häufigsten Fehler beim TDD-Einsatz mit Codex

1. Codex schreibt Tests und Implementierung gleichzeitig. Wenn Tests und Code in einem einzigen unkontrollierten Schritt entstehen, geht ein wesentlicher Vorteil des Test-First-Ansatzes verloren. Besser: RED, GREEN und REFACTOR als getrennte Arbeitsschritte durchführen.

2. Tests werden an den fehlerhaften Code angepasst. Ein KI-Agent könnte versuchen, fehlgeschlagene Tests so zu verändern, dass sie zur bestehenden Implementierung passen. Damit verlieren die Tests ihre Funktion als unabhängige Anforderung. Besser: Akzeptanzkriterien vorab festlegen und Änderungen an bestehenden Tests gesondert prüfen.

3. Nur der Happy Path wird getestet. Eine Funktion funktioniert bei normalen Eingaben, scheitert aber bei Nullwerten, ungültigen Daten oder Grenzfällen. Besser: Codex ausdrücklich zu Negativtests, Grenzwertanalysen und Fehlerfällen auffordern.

4. Ein erfolgreicher Testlauf wird mit vollständiger Qualität verwechselt. Vier oder fünf erfolgreiche Unit Tests sagen wenig über Authentifizierung, Sicherheit, Nebenläufigkeit oder reale Produktionslast aus. Besser: Unit Tests durch Integrationstests, Sicherheitsprüfungen und Code Reviews ergänzen.

5. Zu große Änderungen werden auf einmal durchgeführt. Wenn Codex gleichzeitig viele Funktionen verändert, wird es schwieriger, Fehler einer konkreten Änderung zuzuordnen. Besser: Kleine, klar abgegrenzte Aufgaben mit jeweils eigenen Tests verwenden.

Allgemeinere Stolperfallen beim KI-gestützten Programmieren, die unabhängig von TDD auftreten, beschreibt Vibe Coding richtig starten: 10 Fehler, die du bei KI-Projekten vermeiden solltest (Zum Artikel).

Wie verhindert man, dass Codex Tests einfach umschreibt?

Eine der wichtigsten Fragen beim KI-gestützten TDD lautet: Was passiert, wenn der Agent einen Test nicht besteht und ihn stattdessen verändert?

Genau deshalb sollten wichtige Tests nicht ausschließlich durch Prompt-Anweisungen geschützt werden. In professionellen Projekten sind zusätzliche technische Kontrollen sinnvoll. Beispielsweise:

• Tests und Implementierung in getrennten Commits überprüfen.
• Änderungen an zentralen Testdateien über Pull Requests freigeben lassen.
• CI-Tests unabhängig vom lokalen Codex-Arbeitsverzeichnis ausführen.
• Geschützte Branches und verpflichtende Reviews verwenden.
• Sicherheitsrelevante Akzeptanztests unabhängig vom implementierenden Agenten definieren.

Besonders wertvoll ist die Trennung zwischen dem Agenten, der Code entwickelt, und der Instanz, die dessen Ergebnis bewertet. Das kann ein menschlicher Entwickler sein, ein separater Review-Agent oder eine Kombination aus automatisierter CI-Prüfung und manuellem Review. Wichtig ist dabei: Ein zweiter KI-Agent ist nicht automatisch unabhängig oder zuverlässiger. Auch dessen Ergebnisse müssen überprüfbar bleiben.

Wie du Codex grundsätzlich sicher und kontrolliert einsetzt – von Git und Sandbox-Umgebungen bis zu Backups und Freigaben – beschreibt Codex sicher verwenden: Git, Sandbox, Backups und Freigaben richtig einrichten (Zum Artikel).

TDD mit Codex und GitHub Actions automatisieren

Damit Tests nicht nur lokal ausgeführt werden, empfiehlt sich eine CI-Pipeline. Für das Python-Beispiel lässt sich eine einfache GitHub-Actions-Konfiguration erstellen.

Datei: .github/workflows/tests.yml

name: Python Tests

on:
  push:
  pull_request:

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout repository
        uses: actions/checkout@v4

      - name: Setup Python
        uses: actions/setup-python@v5
        with:
          python-version: "3.12"

      - name: Install dependencies
        run: |
          python -m pip install --upgrade pip
          python -m pip install pytest

      - name: Run tests
        run: |
          python -m pytest -v

Die Pipeline startet bei Pushes und Pull Requests und führt die Tests in einer separaten Umgebung aus. Für produktive Projekte sollten Abhängigkeiten reproduzierbar festgelegt und verwendete GitHub Actions nach Möglichkeit auf geprüfte Commit-SHAs gepinnt werden.

In Kombination mit Branch-Schutzregeln können fehlgeschlagene Tests verhindern, dass Änderungen ohne weitere Prüfung in den Hauptbranch übernommen werden. Wie sich ein solcher kontrollierter GitHub-Workflow mit Codex im Detail aufbauen lässt, zeigt Codex mit GitHub richtig nutzen: Branches, Pull Requests und Code Reviews (Zum Artikel). So wird TDD von einer reinen Entwicklungsmethode zu einem festen Bestandteil des Software-Qualitätsprozesses.

Klassische Entwicklung vs. Codex ohne TDD vs. Codex mit TDD

TDD macht Codex nicht automatisch zu einem besseren Programmierer. Die Methode sorgt aber dafür, dass Entwicklungsaufgaben strukturierter bearbeitet und Ergebnisse systematischer überprüft werden können.

Für welche Projekte lohnt sich Test Driven Development mit Codex?

Besonders geeignet ist der Ansatz für Anwendungen, bei denen korrektes Verhalten eindeutig beschrieben werden kann. Dazu gehören beispielsweise Backend-Funktionen, REST-APIs, Datenvalidierung, Geschäftslogik, Berechnungen und Fehlerkorrekturen. Auch für bestehende Softwareprojekte kann TDD sinnvoll sein, wenn neue Funktionen hinzugefügt werden sollen, ohne vorhandenes Verhalten zu beschädigen.

Weniger eindeutig ist der Nutzen bei rein explorativen Aufgaben, frühen Designprototypen oder Anforderungen, die sich noch stark verändern. Auch dort sind Tests hilfreich. Der klassische strikte RED-GREEN-REFACTOR-Zyklus muss jedoch nicht für jede kleine Änderung die wirtschaftlichste Vorgehensweise sein. Entscheidend ist, dass der Testaufwand zum Risiko und zur Komplexität der Anwendung passt.

Best Practices: So nutzt du Codex für zuverlässigere Softwareentwicklung

Für den produktiven Einsatz empfiehlt sich ein klarer Ablauf. Eine TDD-Checkliste für dein nächstes Codex-Projekt:

• Anforderungen und Akzeptanzkriterien definiert
• Tests vor der Implementierung erstellt
• RED-Phase nachvollziehbar überprüft
• Implementierung ohne Teständerungen durchgeführt
• GREEN-Phase erfolgreich abgeschlossen
• Refactoring mit erneuter Testausführung durchgeführt
• Bestehende Testsuite und CI geprüft
• Änderungen und verbleibende Risiken dokumentiert

Ein zusätzlicher Tipp: Dokumentiere in deinem Projekt nicht nur, welche Tests existieren, sondern auch, warum sie geschrieben wurden. So bleibt die fachliche Absicht selbst dann nachvollziehbar, wenn Codex später größere Teile der Implementierung überarbeitet.

Häufig gestellte Fragen zu Test Driven Development mit Codex

Kann Codex automatisch Unit Tests schreiben?

Ja. Codex kann aus Anforderungen und bestehendem Quellcode automatisierte Tests erstellen. Wie zuverlässig diese Tests sind, hängt jedoch von der Qualität der Anforderungen, dem Projektkontext und der anschließenden Überprüfung ab.

Muss ich programmieren können, um TDD mit Codex zu nutzen?

Grundlegende Programmierkenntnisse sind sehr hilfreich. Codex kann die Erstellung von Tests und Code erleichtern, ersetzt aber nicht das Verständnis für Anforderungen, Fehlerfälle und Softwarequalität.

Funktioniert TDD mit Codex auch für JavaScript und TypeScript?

Ja. Neben Python können beispielsweise JavaScript- und TypeScript-Projekte mit Jest oder Vitest nach dem Test-First-Prinzip entwickelt werden.

Kann Codex bestehende Tests automatisch reparieren?

Codex kann fehlerhafte Tests analysieren und Änderungsvorschläge erstellen. Allerdings sollte zunächst geklärt werden, ob der Fehler tatsächlich im Test oder in der Implementierung liegt. Tests sollten nicht lediglich angepasst werden, um einen erfolgreichen Testlauf zu erzwingen.

Ist TDD mit Codex langsamer als direktes KI-Coding?

Die ersten Entwicklungsschritte können mehr Zeit benötigen, weil Anforderungen und Tests vorab festgelegt werden. Dafür können Fehler früher auffallen und spätere Korrekturen einfacher werden. Ob sich insgesamt Zeit sparen lässt, hängt vom Projekt ab.

Kann ich Codex mit TDD vollständig autonom arbeiten lassen?

Technisch lassen sich viele Schritte automatisieren. Für produktive Anwendungen sind jedoch weiterhin menschliche Freigaben, unabhängige Prüfungen und geeignete Berechtigungsgrenzen empfehlenswert.

Fazit: Erst Tests, dann Code – auch bei KI

Test Driven Development ist keine neue Erfindung. Doch durch KI-Coding-Agenten wie Codex gewinnt die Methode eine neue Bedeutung. Wenn KI immer schneller Software erzeugen kann, wird die Frage wichtiger, wie wir deren Qualität kontrollieren.

Der Test-First-Ansatz bietet dafür einen strukturierten Rahmen. Anstatt Code blind zu übernehmen, legen wir zunächst fest, welches Verhalten erwartet wird. Danach implementiert Codex die passende Lösung und überprüft sie anhand automatisierter Tests.

Die wichtigste Erkenntnis: Nicht die Geschwindigkeit, mit der KI Code schreibt, entscheidet über die Qualität einer Anwendung – sondern wie gut Anforderungen, Implementierung und Überprüfung zusammenarbeiten.

Wer Codex mit klaren Akzeptanzkriterien, Test Driven Development und automatisierten CI-Prüfungen kombiniert, schafft eine deutlich bessere Grundlage für nachvollziehbare und wartbare Softwareentwicklung.

Wie sich Codex zusätzlich gezielt für Sicherheits- und Qualitäts-Reviews einsetzen lässt, zeigt Code Reviews mit Codex: Fehler finden, bevor sie produktiv gehen (Zum Artikel).

Weitere verständliche Anleitungen rund um Codex, KI-Agenten und Softwareentwicklung findest du im KI-Buster Blog.

Redaktioneller Stand: 30. Oktober 2026. Die Code-Beispiele, Prompts und das Praxisbeispiel sind eigene, vereinfachte Beispiele zu Demonstrationszwecken; es werden keine selbst gemessenen Produktivitätsgewinne oder durchgeführten Projekttests behauptet.