Hallo zusammen,

ich möchte hier ein aktuelles Pilotprojekt von mir teilen und zur Diskussion stellen. Es geht um die Frage, wie weit man die Code-Generierung durch KI treiben kann, wenn man als Mensch konsequent nur noch die Rolle des Software-Architekten einnimmt.

Das Projekt: Axiom Trader (aktuell v0.4.0-alpha) – ein hochperformantes Handelssystem für macOS.

Das Experiment: Ich schreibe keine einzige Zeile Code selbst. Jede Implementierung, jeder Bugfix, das Speichermanagement und die Render-Pipelines werden komplett von der KI umgesetzt.

Der Tech-Stack:

* Sprachen: C++20 und Objective-C++ (Gewichtung ca. 52% zu 45% im Repo).

* UI/Rendering: Ein "Blender-Modell". Dear ImGui eingebettet in ein natives CAMetalLayer-Hosting-View für minimale Latenzen unter macOS 15/16.

* Plattform: Optimiert für Apple Silicon (M-Chips), Zero-Overhead-Schleifen, explizite Metal-Pipeline-Zustände.

Wie funktioniert das in der Praxis?

Der Schlüssel zum Erfolg ist eine extrem strikte ARCHITECT.md im Repository. Diese fungiert als unumstößliches Regelwerk (Guardrails) für die KI.

Die wichtigsten Regeln, die das System stabil halten:

1. Strikte Schichtentrennung: Der Core src/core/) enthält die deterministische Logik und darf absolut keine UI- oder Grafik-Header (ImGui, Metal) importieren.

2. RAII-Zwang: Ressourcenmanagement erfolgt ausnahmslos über RAII, um Speicherlecks im C++-Code von vornherein auszuschließen.

3. UI-Scoping: Dynamische ImGui-Tabellen müssen zwingend über ID-Scoping ImGui::PushID / PopID) abgesichert werden, um State-Konflikte im UI-Thread zu verhindern.

Bisherige Erkenntnis:

Wenn die architektonischen Leitplanken eng und mathematisch präzise genug gesteckt sind, neigt die KI nicht zu Halluzinationen. Stattdessen liefert sie hochoptimierten, sauberen C++20-Code, der sich in Xcode tadellos kompilieren lässt. Das Build-System von Xcode 16 verarbeitet diesen hybriden C++/Obj-C++ Mix extrem performant.

Das Projekt steuert gerade auf die Version v0.5.x zu (Anbindung von SQLite für die Persistenz und Textur-Streaming via stb_image.h in die Metal-Buffer).

Mich würde euer Feedback interessieren:

Hat jemand von euch schon ähnliche Projekte umgesetzt, bei denen die KI vollständige* Code-Autonomie hatte?

* Wie steuert ihr die Code-Qualität bei generiertem C++20-Code (Stichwort: statische Codeanalyse vs. Prompt-Guardrails)?

* Seht ihr bei so einem "Architekt (Mensch) vs. Developer (KI)"-Modell langfristig die Zukunft in der Anwendungsentwicklung?

Wer sich das Regelwerk oder den Code genauer ansehen möchte: Das Projekt ist Open Source auf GitHub (Link packe ich in die Kommentare/Signatur).

Freue mich auf eine sachliche Diskussion!

GitHub

GitHub - tkreutz0-cmyk/axiom-trader: The Vision: A high-p...

The Vision: A high-performance, deterministic trading journal built on the "Blender Model"—prioritizing full GUI control, local data sovereignty, and zero App Store friction. - tkreutz0-c...

Screenshot

Hey, vielen Dank dass du das online stellst.

Ich habe es mir selber oberflaechlich angeschaut und einmal durch Claude Opus 4.7 gejagt und es gibt da einige Punkte anzumerken.
Ein smell ist fuer mich natuerlich das Darstellen von Geldwerten als Fliesskommazahl.
Dokumentation is an verschiedenen Orten uneinhetlich abgelegt.

Claudes Anmerkungen sind:
- High Performance C++ ist in der Code Base selber nicht zu erkennen (Allokation im Hotpath und dergleichen)
- Die verschiedenen konkurrierenden Implementierung (src.main.mm vs Sqlite.hpp vs StorageManager.hpp)

Meine Erfahrungen mit komplett AI generiertem Code sind ehrlicherweise bisher ernuechternd.
Ich wollte mal schauen wie es sich verhaelt wenn es mehr Richtung persistent Specs / BDD geht.

vor 7 Minuten, Wodar Hospur hat gesagt:

Meine Erfahrungen mit komplett AI generiertem Code sind ehrlicherweise bisher ernuechternd.
Ich wollte mal schauen wie es sich verhaelt wenn es mehr Richtung persistent Specs / BDD geht.

Vielen Dank für das ehrliche und detaillierte Feedback!

Genau das ist der springende Punkt: Es gibt hier definitiv noch einiges zu tun. Einige Funktionen und optimierte Codepfade sind aktuell auch bewusst temporär ausgeschaltet oder als Prototyp hinterlegt, während an ganz anderen Baustellen parallel weitergearbeitet wird.

Man muss bei diesem Projekt massiv berücksichtigen, dass hier absolut iterativ vorgegangen wird. Der Code, den du jetzt siehst, ist der Zustand eines fließenden Übergangs. Insgesamt ist das ein völlig neuer, experimenteller Workflow, den es so in klassischen, (echten) Produktiv-Projekten eins zu eins wahrscheinlich nie geben wird – da dort von Anfang an ganz andere Code-Reviews und statische Analysen greifen.

Es ist und bleibt ein Experiment, um die Grenzen der rein KI-gesteuerten Generierung auszuloten. Aber dafür ist es immerhin schon ein ganzes Stück weit gekommen und liefert eine stabile, native Metal-Oberfläche auf macOS, auf der wir jetzt die feineren architektonischen Klingen (wie Fixed-Point für Geldwerte und Allokations-Stopps im Hotpath) iterativ schleifen können.

Ich halte euch hier über die nächsten Refactoring-Schritte auf dem Laufenden!