Als Experiment startete ich die Implementierung eines BMI-Rechners mit Google Canvas [1]. Im Mittelpunkt stand damals vor allem die Frage, wie schnell sich mit KI überhaupt ein funktionierendes kleines Web-Tool bauen lässt. Innerhalb kürzester Zeit stand ein lauffähiger Prototyp, der genau das tat, was er sollte – Größe und Gewicht erfassen, BMI berechnen, Ergebnis anzeigen.
Was dieser ersten Version fehlte, war alles, was ein Projekt über einen reinen Prototyp hinaus ausmacht: kein Versionsmanagement, strukturierter Entwicklungsprozess, Pull Requests, Releases. Es war ein funktionierendes Experiment – aber noch kein „richtiges“ Softwareprojekt im klassischen Sinn.
Mit der neuen Möglichkeit, Codex direkt mit GitHub zu verbinden [2], bot sich nun der nächste logische Schritt an: Ein bestehendes KI-Projekt nicht nur weiterzubauen, sondern es in einen nachvollziehbaren Entwicklungs- und Release-Workflow zu überführen.
Codex analysiert den bestehenden Code
Nach der Anbindung des Repositories an Codex habe ich den vorhandenen BMI-Rechner mit einem einfachen Prompt von der KI analysieren lassen. Dabei beschränkte sich Codex nicht auf eine formale Codeprüfung, sondern stellte strukturiert Verbesserungsvorschläge zu Logik und Benutzerführung vor.
Im Kern betrafen die Hinweise drei Dimensionen:
- fachliche Korrektheit (BMI-Grenzwerte),
- Nutzerkomfort (Umgang mit Eingaben),
- Bedienbarkeit (Reset, Wiederverwendung)
Aus den Verbesserungsvorschlägen wählte ich zwei aus, die kontrolliert nacheinander umgesetzt werden sollten.
Konkrete Verbesserungen direkt mit Codex umgesetzt
Die beiden wichtigsten Änderungen wurden jeweils als Pull Request (PR) von Codex direkt nach GitHub übertragen – inklusive automatischer Merge-Meldung ohne Konflikte.
Erste Änderung: Überarbeitung der BMI-Klassifikation. Der BMI selbst ist nur eine Zahl. Erst mit klar definierten Kategorien wie Untergewicht, Normalgewicht, Übergewicht oder Adipositas erhält der Wert eine sinnvolle Einordnung. [3]
Zweite Änderung: UX-Verbesserung mit Input Persistence und Reset-Controls. Eingegebene Werte werden beim Neuladen der Seite erhalten, und ein Reset-Button macht den Rechner alltagstauglicher.
Nach dem Merge funktionierten beide Änderungen direkt im Live-Betrieb – ein klares Zeichen dafür, wie eng Codex bereits an einen echten Entwicklungsworkflow herankommt.
Testen bleibt menschliche Verantwortung
Ein wichtiger Punkt bleibt: Codex kann den Code (noch) nicht selbst testen. Es gibt keine echte UI-Ausführung, keine simulierten Nutzereingaben und keine visuelle Kontrolle. Das bedeutet, dass manuelle Tests durch Entwickler*innen notwendig bleiben, um sicherzustellen, dass das Tool in allen Fällen zuverlässig funktioniert.
In einer professionellen Praxis würden diese manuellen Tests später durch automatisierte Tests, Quality Gates oder Abnahmeregeln ergänzt werden – doch im ersten Praxisdurchlauf stand der manuelle Qualitätscheck im Vordergrund
Codex prüft README und CHANGELOG
Nach den Code-Änderungen bat ich Codex zusätzlich, die bestehende README.md zu prüfen. Ziel war es zu klären, ob die neuen Funktionen dort bereits korrekt dokumentiert sind oder ob Ergänzungen notwendig werden. Auch hier zeigte sich, dass Codex nicht nur auf Code fokussiert arbeitet. Die Dokumentation wurde geprüft, inhaltliche Lücken identifiziert und die README anschließend sinnvoll um die neuen Funktionen ergänzt.
Als nächster Schritt stellte sich die Frage, ob die Sourcen nun reif für ein echtes Release sind. Die Antwort von Codex fiel bemerkenswert professionell aus: Vor dem Release sollte noch ein CHANGELOG ergänzt werden. Natürlich erstellt Codex Vorschläge für dieses CHANGELOG gleich mit.
Damit waren plötzlich alle klassischen Release-Bausteine vorhanden:
- sauberer Code
- aktualisierte README
- CHANGELOG
- vollständige PR-Historie
Der Schritt zum Release war damit nicht mehr inhaltlich, sondern nur noch formal.
Kontext-Management mit Codex
Im weiteren Verlauf der Arbeit zeigte sich ein interessanter Aspekt im Zusammenspiel von Codex und GitHub. Nach einem erfolgreich gemergten Pull Request wurde im Code ein Fehler entdeckt, der im nächsten Schritt wieder mit Unterstützung von Codex analysiert werden sollte. Dabei fiel auf, dass Codex weiterhin von einem älteren Stand des Repositories ausging und die bereits gemergten Änderungen nicht automatisch berücksichtigte.
Dieses Verhalten ist weniger als Fehler zu verstehen, sondern vielmehr als Eigenschaft der Arbeitsweise von Codex. Statt kontinuierlich den aktuellen Zustand eines Repositories zu verfolgen, arbeitet Codex jeweils auf Basis eines kontextuellen Snapshots. Änderungen, die nach diesem Zeitpunkt vorgenommen werden – etwa durch einen Merge in den Hauptbranch –, sind für Codex nicht automatisch Teil seines Arbeitskontexts.
Für die praktische Arbeit bedeutet das, dass nach einem Merge ein bewusster Neustart des Arbeitskontexts notwendig sein kann, um wieder konsistente Ergebnisse zu erhalten. Gerade in iterativen Entwicklungsphasen wird deutlich, dass der Übergang von einem erfolgreichen Pull Request zur nächsten Korrektur nicht nur technisch, sondern auch kontextuell sauber gestaltet werden sollte.
Vom Prototyp zum echten Release
Heute steht der BMI-Rechner nicht mehr nur als einfacher KI-Prototyp da, sondern als kleines, versioniertes Softwareprodukt mit sauberer Dokumentation und nachvollziehbarer Entwicklungsbasis [4].
Fazit: Codex als Entwicklungs-Partner
Die Erfahrungen zeigen, dass der Einsatz von KI-gestützten Entwicklungswerkzeugen wie Codex zwar einen erheblichen Geschwindigkeitsgewinn ermöglicht, gleichzeitig aber neue Anforderungen an Struktur, Kontext und Kontrolle mit sich bringt. Besonders im Zusammenspiel mit klassischen Werkzeugen wie GitHub wird deutlich, dass erfolgreiche Pull Requests und Releases nicht automatisch einen konsistenten Arbeitskontext für die KI bedeuten. Der Schritt vom funktionierenden Prototypen zum stabilen Release bleibt damit weiterhin eine bewusste, menschlich gesteuerte Aufgabe
Das übergeordnete Fazit aus diesen ersten echten Pull Requests mit Codex fällt positiv aus:
- Codex ist weit mehr als ein reiner Code-Generator – es kann Analyse, Umsetzung und Dokumentation unterstützen
- Der PR-Workflow funktioniert (für dieses kleine Projekt) erstaunlich gut
- Testen und Bewertung bleiben menschliche Aufgaben
- Architekturentscheidungen müssen nach wie vor bewusst getroffen werden.
Damit zeigt sich: KI-gestützte Entwicklung verlässt die Spielwiese und wird zu einer ernsthaften Arbeitsmethode – solange Mensch und Maschine bewusst zusammenarbeiten.
Ausblick: Vom funktionierenden Workflow zur professionellen Praxis
Der beschriebene Workflow zeigt, wie weit sich KI-gestützte Entwicklung mit Codex und GitHub heute bereits tragen lässt – von der Analyse über Pull Requests bis hin zur Dokumentation und Release-Vorbereitung. Gleichzeitig wird deutlich, dass dieser Einstieg bewusst noch auf den operativen Kern fokussiert ist. In der praktischen Anwendung zeigt sich zudem, dass ein erfolgreicher Merge nicht automatisch einen konsistenten Arbeitskontext für Codex bedeutet. Auch nach einem abgeschlossenen Pull Request kann es notwendig sein, den Arbeitskontext der KI gezielt neu aufzusetzen, um Folgeänderungen zuverlässig auf Basis des aktuellen Repository-Stands vornehmen zu können.
Für eine weitergehende Professionalisierung stellen sich unter anderem folgende Fragen, die in zukünftigen Betrachtungen eine Rolle spielen können:
- Wie sollte ein sauberer Initial-Startprompt für Codex aussehen, um eine fundierte Repo-Analyse sicherzustellen, bevor Änderungen erfolgen?
- Wie lässt sich eine systematische Kopplung von Codex-Prompts und GitHub-Issues etablieren, sodass jede KI-Änderung auf einer formalen Anforderung basiert?
- Welche Governance- und Freigaberegeln braucht es, wenn KI dauerhaft in produktiven Repositories arbeitet?
- Wie können automatisierte Tests, Security-Checks und Quality Gates sinnvoll in diesen Workflow integriert werden?
- Wo verläuft die saubere Trennung zwischen Experiment und produktivem Betrieb?
Diese Punkte markieren die nächste Entwicklungsstufe auf dem Weg von einem funktionierenden KI-Workflow hin zu einer dauerhaft tragfähigen, professionellen KI-gestützten Softwarepraxis.
Referenzen
[1] Apps bauen mit Google Gemini Canvas
[2] hrmnns/bmi-rechner: Eine einfache Web-App zur Berechnung des Body-Mass-Index (BMI)
[3] BMI – Adipositas Gesellschaft
[4] BMI Rechner zum Ausführen auf GitHub-Pages