NambaAI - Ein CLI-Tool, das Codex-Arbeit in einen SPEC-, Validierungs- und PR-Handoff-Workflow überführt

Wenn ich Codex nutze, finde ich den Ablauf unpraktisch, bei dem vage Anfragen direkt zu Codeänderungen führen. Deshalb entwickle ich ein CLI-Tool, das diesen Prozess in ein strukturierteres Entwicklungsverfahren überführt.

NambaAI ist kein Tool, das Codex ersetzt, sondern eher eine Workflow-Schicht, die um Codex herum arbeitet.

Die Grundidee ist wie folgt.

request → SPEC → execution → validation → PR handoff

Statt die Anfrage eines Nutzers also direkt an die Implementierung weiterzugeben, hilft es dabei, zuerst Ziele, Umfang, Einschränkungen und Akzeptanzkriterien zu ordnen, diese in einer SPEC-Datei festzuhalten und dann die Arbeit auszuführen.

Aktuell ist es vor allem um den folgenden Ablauf herum aufgebaut.

namba project
namba plan "Arbeitsanfrage"
namba run SPEC-XXX
namba sync
namba pr
namba land

Ich experimentiere außerdem mit einem Queue-Workflow, um mehrere SPECs nacheinander zu verarbeiten.

Der Grund für dieses Tool ist, dass mit zunehmender Bequemlichkeit von AI Coding Änderungen oft nicht mehr nachvollziehbar sind oder sich später nur schwer erkennen lässt, nach welchen Kriterien etwas implementiert wurde. Gerade wenn man Codex wiederholt nutzt, kann leicht unklar werden, „was eigentlich vereinbart war“, „wo genau der Umfang endete“, „wie validiert wurde“ und „worauf man im PR achten sollte“.

NambaAI ist ein Versuch, dieses Problem auf folgende Weise zu verringern.

• Ziele und Umfang vor der Arbeit zuerst festhalten
• SPEC-Datei vor der Implementierung erzeugen
• Ausführungsergebnisse und Validierungs-Evidence dokumentieren
• PR-Handoff-Dokument erzeugen
• Von Codex erzeugte Änderungen so aufbereiten, dass Menschen sie leichter reviewen können
• Nicht als einmaligen Prompt, sondern als wiederholbaren Entwicklungsprozess verwalten

Es geht nicht in die Richtung, einen universellen autonomen Agenten wie in bestehenden AI-Agent-Frameworks zu bauen. Der Fokus liegt derzeit darauf, Codex ins Zentrum zu stellen und Arbeit in Einheiten zu zerlegen und zu dokumentieren, die von Entwicklerinnen und Entwicklern überprüft werden können.

Es ist noch in einem frühen Stadium, daher gibt es viele Punkte, die noch fehlen.

• Zu wenige praktische Anwendungsbeispiele
• Onboarding-Dokumentation muss verbessert werden
• Zu wenig eval pack
• Sicherheitsprüfung für Installer/Hooks erforderlich
• Plattformübergreifende Tests auf macOS, Linux und Windows erforderlich
• Zu wenig Vergleich mit bestehenden AI-Coding-Harnesses
• Zu wenig Validierung in realen Projekten

Dies ist mein erstes selbst entwickeltes Open-Source-Projekt in einer frühen Phase; eher als ein ausgereiftes Produkt ist es derzeit ein Schritt zur Validierung der Richtung.

Von Menschen, die Codex im Berufsalltag oder in privaten Projekten nutzen, hätte ich besonders gern Feedback zu den folgenden Punkten.

1. Ob ein solcher SPEC-basierter Codex-Workflow im realen Entwicklungsprozess nützlich erscheint
2. Welche Teile überdesignt wirken
3. Welche zusätzlichen Vertrauens- oder Sicherheitsmechanismen nötig wären, um es in realen Projekten einzusetzen
4. Ob es bestehende Tools oder Muster gibt, mit denen man es sinnvoll vergleichen könnte
5. Ob es im Installations- oder Nutzungsablauf Stellen gibt, die unpraktisch oder riskant wirken

Auch kritische Meinungen sind willkommen. Da es noch in einem frühen Stadium ist, hilft es mir im Moment mehr zu wissen, wo die Schwächen liegen, als nur positive Rückmeldungen zu bekommen.

[namcher9428]

Ich hatte es eigentlich mit Blick auf die CLI gebaut, aber in letzter Zeit nutze ich es in codex desktop! Ich hatte Sorge, dass es mit dem in Codex Desktop integrierten Harness kollidieren könnte, aber zum Glück ist die Kompatibilität sehr reibungslos haha.

Außerdem muss ich noch die Inhalte dieses codex-Updates auf 0.131.0 berücksichtigen, und weil ich nur dieses Harness verwende, fallen mir ständig noch Stellen auf, an denen etwas fehlt – aber am meisten fehlt es wohl meinem Körper an Energie...