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!

vor 6 Stunden, Wodar Hospur hat gesagt:

Claudes Anmerkungen sind:

vor 5 Stunden, tkreutz2 hat gesagt:

Grenzen der rein KI-gesteuerten Generierung auszuloten

Was erwartest du genau zu erfahren?
Die Grenzen hängen davon ab, wo du die Grenzen ziehst.

Ein aussagekräftiger Vergleich zwischen KI-generierter und menschlicher Softwareentwicklung erfordert:

Quantitative Metriken (z. B. Entwicklungszeit, Fehlerrate, Testabdeckung) für objektive Daten.
Qualitative Metriken (z. B. Code-Design, Entwicklerzufriedenheit) für subjektive Bewertungen.
Langfristige Studien zur Bewertung von Wartbarkeit und Skalierbarkeit und kontextspezifische Analysen (z. B. Projektgröße, Teamdynamik, Domänenkomplexität).

Mir scheinen bestimmte Beobachtungen sehr nützlich zu sein, um zu einer Bewertung zu kommen.

Am 13.5.2026 um 17:08, tkreutz2 hat gesagt:

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?

Die Qualität der KI-Ausgabe hängt stark von den Prompt-Guardrails ab.

Testet du, welche Formulierungen mehr oder weniger gut arbeiten?
Wenn sowas wie Best-Practice-to-generate herauskommt, würde ich das unterstützen.

Hallo @hellerKopf ,

du triffst hier einen extrem wichtigen Punkt. Ein Experiment ohne klare Metriken und Definition von „Grenzen“ läuft Gefahr, rein anekdotisch zu bleiben. Vielen Dank für diesen methodischen Anstoß!

Zu deiner Frage, was ich genau erfahren will und wo ich die Grenzen ziehe:
Meine primäre Hypothese ist: Kann eine KI komplexe, plattformspezifische Systemarchitekturen (wie hardwarenahes Metal-Rendering gepaart mit deterministischer Trading-Logik) fehlerfrei verwalten, wenn der Mensch ausschließlich abstrakte Regeln vorgibt?

Die Grenze ziehe ich da, wo die KI architektonische Brüche erzeugt (wie die von dir/Claude entdeckte Dreifach-Implementierung der Persistenz), weil der Kontext-Fenster-Horizont oder das logische Verständnis für das Gesamtgefüge reißt.

Zu den Metriken (Quantitativ & Qualitativ):
Da ich das Projekt alleine in meiner Freizeit hochziehe, sind vollumfängliche Langzeitstudien schwer machbar. Aber ich tracke für mich bereits einige Daten, die ich gerne im Verlauf des Projekts teilen kann:

• Entwicklungszeit (Time-to-Market): Wie viele Minuten vergehen vom Architektur-Konzept in der ARCHITECT.md bis zum kompilierbaren Feature in Xcode? (Spoiler: Bei UI-Prototypen extrem schnell, bei Refactorings im Core bricht die Geschwindigkeit ein).

• Fehlerrate / Regressionen: Wie oft führt ein neuer Prompt dazu, dass eigentlich funktionierende Features an anderer Stelle unbemerkt wegbrechen?

Zu deiner Frage bezüglich der Formulierungen (Best-Practice-to-generate):
Ja, absolut! Das ist im Grunde der Kern der ARCHITECT.md. Ich teste intensiv, welche Detailtiefe die KI benötigt.

Meine bisherige Erkenntnis: Allgemeine Phrasen wie "Schreibe performanten Code" bewirken gar nichts. Die KI benötigt restriktive, imperative Verbote und mathematische Konzepte. Ein Beispiel: Erst als ich die Regel "Nutze RAII" durch die konkrete Anweisung "Nutze ausnahmslos std::unique_ptr oder Stack-Allokation für Ressourcen in src/core/" ersetzt habe, sank die Memory-Leak-Rate im generierten Code gegen Null.

Ich dokumentiere diese Erkenntnisse parallel. Wenn daraus am Ende eine Art strukturiertes „Best-Practice-Template“ für C++20-Generierung entsteht, teile ich das sehr gerne hier im Forum!

Die "feine Klinge" (Fixed-Point-Math für die Währungen) schlage ich übrigens gerade ein – ich poste das Update, sobald die Pipeline fehlerfrei steht.

vor 3 Stunden, tkreutz2 hat gesagt:

Ein Beispiel: Erst als ich die Regel "Nutze RAII" durch die konkrete Anweisung "Nutze ausnahmslos std::unique_ptr oder Stack-Allokation für Ressourcen in src/core/" ersetzt habe, sank die Memory-Leak-Rate im generierten Code gegen Null.

Das ist ein Punkt, wo ich gerne tiefer gehen will.

Verglichen werden kann:
Ich fordere die Regeln von einem frisch Ausgebildeten, einem Junior (2 Jahre BE) und einem Senior.
Ich nenne die Anforderung genauso in den Anweisungen an die KI.

Das Ergebnis sollte sein zu erkennen, auf welchem Level beginnt die KI besser zu sein, als der humane Mitarbeiter.
Dann erfolgt das Tuning. Wie muss ich die Anforderung formulieren, damit KI den Junior ersetzt und ab wann ist die KI dem Senior gleich.

Ich habe das für zwei Systeme gemacht, die sich untereinander schon geringfügig unterscheiden.
Was mir die drei Arten von Mitarbeiter geantwortet hätten und welche Memory-Leak-Rate diese verursachen, versuche ich gerade vor Ort zu ermitteln.

Die LLM haben auf "Nutze RAII" wie folgt reagiert:

LLM1	LLM2	Übereinstimmung/Ergänzung
1. Ressourcen an Objektlebensdauer binden	Ressourcen werden im Konstruktor erworben und im Destruktor freigegeben.	✅ Übereinstimmung
2. Kein manuelles new/delete im Anwendungscode	Vermeide new/delete; nutze Smart Pointer oder Container.	✅ Übereinstimmung
3. Kein manuelles malloc/free in modernem C++	Kein manuelles Speichermanagement; nutze Standardbibliothek.	✅ Übereinstimmung
4. Destruktor gibt die Ressource zuverlässig frei	Destruktor gibt Ressourcen frei, auch bei Ausnahmen.	✅ Übereinstimmung
5. Destruktoren dürfen keine Exceptions werfen	Nicht explizit erwähnt, aber implizit durch Ausnahmesicherheit abgedeckt.	⚠️ Ergänzung:
6. Ressourcenbesitz eindeutig modellieren	Konsistente Ownership-Semantik (z. B. unique_ptr, shared_ptr).	✅ Übereinstimmung
7. Rule of Zero bevorzugen	Nutzung von Standardtypen, die Ressourcen selbst verwalten.	✅ Übereinstimmung
8. Falls eigene Ressourcenklasse nötig: Rule of Five beachten	Eigenen RAII-Wrapper erstellen, inkl. Move-Semantik.	✅ Übereinstimmung (implizit durch Move-Semantik)
9. Kopierbarkeit bewusst entscheiden	Move-Semantik für Ownership-Übertragung; Kopieren oft gelöscht.	✅ Übereinstimmung
10. Locks per RAII verwalten	Nutzung von std::lock_guard, std::scoped_lock.	✅ Übereinstimmung
11. Dateien per RAII verwalten	Nutzung von std::fstream oder eigenen Wrappern.	✅ Übereinstimmung
12. Transaktionen und Rollbacks absichern	Nicht explizit erwähnt.	❌ Fehlend
13. Frühe Returns müssen sicher sein	RAII stellt sicher, dass Ressourcen auch bei return/throw freigegeben werden.	✅ Übereinstimmung (implizit)
14. Keine „Cleanup“-Blöcke am Funktionsende	Aufräumlogik gehört in Destruktoren.	✅ Übereinstimmung
15. Rohpointer nur als beobachtende Pointer verwenden	Rohe Zeiger nur für Nicht-Ownership; Ownership durch RAII-Typen.	✅ Übereinstimmung
16. Scope bewusst klein halten	Nicht explizit erwähnt.	⚠️ Ergänzung: Wichtiger Punkt,
17. Initialisierung vollständig und gültig machen	Konstruktoren sollten Objekte in gültigen Zustand versetzen.	✅ Übereinstimmung (implizit)
18. Keine halbgültigen Objekte bevorzugen	Keine init()-Methoden; Objekte sollten nach Konstruktion gültig sein.	✅ Übereinstimmung (implizit)
19. Qt-spezifisch: Ownership beachten	Qt’s Eltern-Kind-Mechanismus und QScopedPointer/QSharedPointer.	✅ Übereinstimmung
20. Qt-spezifisch: Smart Pointer passend wählen	Nutzung von std::unique_ptr, QSharedPointer etc.	✅ Übereinstimmung

Bearbeitet Freitag um 07:105 Tage von hellerKopf

Hallo @hellerKopf ,

deine strukturierte Gegenüberstellung der LLM-Antworten deckt das Kernproblem perfekt auf. Sie zeigt genau das, was ich die „KI-Varianz-Krise“ (oder das Overconfidence-Pattern) nenne: Die KI optimiert auf Eloquenz, nicht auf Wahrheit (p. 6). Sie listet im Chat brav alle 20 RAII-Regeln auf, bricht diese aber im echten Code-Generierungsprozess, sobald der Kontext komplexer wird (p. 6). Sie verhält sich exakt wie ein Junior-Entwickler in der Theorieprüfung vs. Praxis.

Um die KI auf das Level eines Seniors zu hieven, reicht rein esoterisches Prompt-Tuning oder das Erweitern von Text-Guidelines ab einem gewissen Punkt nicht mehr aus. Man muss die Software-Architektur selbst als Kontrollmechanismus aufbauen.

Ich habe für diesen Zweck ein übergeordnetes Framework entwickelt, das ich als „Living Architecture Library“ (basierend auf einem SYNAPSE-CPP Kern) in meinen Projekten einsetze (pp. 1, 19). Das Ziel ist eine KI-Governance, die auf einem Drei-Instanzen-Modell basiert (pp. 1, 9):

1. Instanz 1: Der Generator (Probabilistisch): Das ist die Entwickler-KI (wie Copilot oder Claude) (p. 9). Ihr Output ist grundsätzlich „untrusted“ (p. 9). Sie liefert lediglich Lösungs-Hypothesen im Akkord (Junior-Level) (p. 9).

2. Instanz 2: Der Falsifikator (Antagonist): Ein separates KI-Agenten-System mit dem expliziten, destruktiven Auftrag: „Suche systematisch nach Fehlern, Memory Leaks und Logikbrüchen im Code von Instanz 1“ (p. 9).

3. Instanz 3: Der Evaluator (Deterministisch): Ein harter, in C++20 geschriebener Kern, der nicht mehr auf Wahrscheinlichkeiten basiert (p. 9). Er prüft den generierten Code und die Systemzustände gegen unverrückbare mathematische und architektonische Invarianten (p. 9).

Angewandt auf dein RAII-Beispiel:
Wenn Instanz 1 Code generiert, jagt Instanz 3 (der Evaluator) diesen durch eine automatisierte Kette (z. B. zyklomatische Komplexitätsprüfung \(\le 10\), Clang-Tidy Matcher auf new/delete und automatisierte Test-Suites) (p. 9). Verletzt die KI eine dieser Invarianten, wird der Code rigoros verworfen, und das System triggert mit dem Fehlerprotokoll eine neue Iteration (p. 17).

Erst durch diese deterministische Kontrollschicht (Instanz 3) wird die unzuverlässige „Junior-KI“ gezwungen, Code auf absolutem „Senior-Niveau“ abzuliefern (p. 9). Das System sichert sich selbst ab (p. 19).

Dieses Prinzip der Markt- und Code-Governance nutzen wir auch im Axiom Trader (p. 16), um die KI-Autonomie mathematisch zu bändigen. Wenn dich (oder die anderen) die genauen mathematischen Invarianten-Prüfungen dieses Setups interessieren, kann ich das gerne mal näher aufdröseln!

vor 8 Minuten, tkreutz2 hat gesagt:

Sie verhält sich exakt wie ein Junior-Entwickler in der Theorieprüfung vs. Praxis.

Genau hier sehe ich auch die Herausforderung.
Die hitzige Diskussion, ob KI .... ersetzen kann, vernachlässigt vollkommen den 'Maßstab' nach dem man dies beurteilen kann.
Der Junior könnte mir auch alle 20 Punkte zu RAII (nur als Beispiel) aufzählen.
Aber auch beim Senior bin ich nicht sicher, ob er alle Punkte berücksichtigt.

Und ob KI/LLM alle seine Punkte auch berücksichtigt, muss ich aufwendig nachprüfen.

Hallo zusammen,

ich möchte die methodische Diskussion hier direkt aufgreifen und euch den nächsten Evolutionsschritt meines Experiments vorstellen. Die Frage, wie man die unzuverlässige „Junior-KI“ bändigt und reproduzierbare „Senior-Ergebnisse“ erzielt, hat mich zu einem radikalen Umdenken im Workflow gezwungen.

Reines Prompt-Tuning in der IDE reicht ab einer gewissen Projektgröße nicht mehr aus. Wenn die KI direkt im Quellcode arbeitet, entstehen die von euch völlig zu Recht kritisierten Brüche (wie die Float-Leichen oder redundante Implementierungen).

Ich habe daher ein automatisiertes KI-QS- und Pre-Check-System direkt in das Repository integriert. Die KI arbeitet ab sofort nicht mehr direkt auf den Quellcodedateien, sondern durchläuft eine strikte Vier-Phasen-Governance-Pipeline:

1. Die Invarianten (decisions/prompt-guardrails.md): Hier sind die harten Architektur-Gesetze (wie das plattformunabhängige Blender-Prinzip, das absolute Float-Verbot und das Allokations-Verbot im Hotpath) maschinenlesbar für die KI hinterlegt.

2. Die Sandbox (Pre-Check-Phase): Die KI darf bestehenden C++ Code nicht mehr direkt verändern. Sie muss jeden Code-Vorschlag zuerst in einer isolierten Review-Datei im neuen Verzeichnis docs/pre-checks/ablegen.

3. Der Konformitäts-Beweis: In dieser Review-Datei muss die KI vorab schriftlich und logisch beweisen, dass ihr generierter Code-Vorschlag keine einzige Regel der Guardrails verletzt.

4. Die Dialog-Historisierung: Parallel dazu wird der vollständige Konversations- und Prompt-Verlauf als Markdown-Dokument im Git-Repository versioniert. Wer das Repo klont, sieht somit in Zukunft nicht nur das fertige Produkt, sondern die lückenlose Evolution der "Mensch-Maschine-Diskussion".

Die Praxisprobe läuft gerade:
Ich habe die von euch angestoßene Architekturentscheidung ADR-0004 (Einführung von plattformunabhängiger FixedPoint-Arithmetik via int64_t zur Eliminierung aller Floats) ins Repo gepusht. Die Windows-Dev-Umgebung auf meinem Handheld steht.

Die Entwickler-KI hat nun den Auftrag erhalten, das großflächige Core-Refactoring exakt nach diesem neuen Pre-Check-Muster in docs/pre-checks/0004-fixed-point-review.md vorzubereiten. Sobald die KI den Code und ihren Konformitätsbeweis dort abgelegt hat, werde ich als menschlicher Chef-Architekt das finale Review durchführen, bevor der Code live in den Xcode-Core fließt.

Ich halte euch über die Ergebnisse dieses kontrollierten KI-Einsatzes auf dem Laufenden!

Hallo @hellerKopf ,

exakt an diesem Punkt schließt sich der Kreis zu meinem neuen Pre-Check-System. Du hast vollkommen recht: Wenn ich den Code genauso mühsam Zeile für Zeile prüfen muss, habe ich zeitlich nichts gewonnen.

Genau deshalb zwinge ich die KI, die Beweislast umzukehren und das Konformitäts-Audit vorab selbst zu schreiben. Als menschlicher Architekt lese ich nicht mehr kopflos C++ Code, sondern prüfe primär die Plausibilität der von der KI gelieferten Beweiskette gegen meine Invarianten.

Und hier ist der direkte Praxis-Beweis, wie dieses System ein rein menschliches Review schlägt:

Ich habe die KI über meine Pipeline das Refactoring der Festkomma-Arithmetik (ADR-0004) in die Sandbox docs/pre-checks/0004-fixed-point-review.md generieren lassen. Beim Überfliegen des von der KI geschriebenen Audits fiel der Blick sofort auf Kapitel 4: „Grenzen und Risiken – Compiler-Unterstützung“.

Die KI stellte dort in ihrem eigenen Audit fest: „Implementierung nutzt int128. Wenn der Compiler keine int128-Unterstützung bietet (z. B. MSVC ohne Emulation), schlägt die Compilation fehl.“

Einem menschlichen Junior-Entwickler (und Hand aufs Herz: auch vielen Senioren!) wäre dieser plattformspezifische Fehler beim schnellen Tippen unter macOS niemals aufgefallen. Sie hätten den Code eingecheckt, und das Windows-Build-System wäre Stunden später auf die Nase geflogen.

Weil meine Pipeline die KI aber dazu zwingt, ein eigenes Risiko-Audit abzuliefern, wurde diese architektonische Sollbruchstelle sichtbar, bevor auch nur eine einzige Zeile Code live in den Core geflossen ist.

Ich habe die KI aufgrund ihres eigenen Audits nun angewiesen, ein plattformunabhängiges Fallback via Compiler-Guards und x64-Hardware-Intrinsics (_umul128 / _udiv128) für den MSVC-Compiler auf Windows einzubauen, um das Blender-Prinzip (vollkommene OS-Unabhängigkeit) zu wahren.

Der Code sieht im Pre-Check für Windows nun so aus:

 Vollständiger Source ist im Repository

Ich habe kurz den ADR gelesen, die aber eine 64 bit Ganzzahl als Entscheidung listet, warum wird dann also von 128 Bit Arithmetik gesprochen, klingt für mich nach einem Fehler?

Deine angewandte Methodik hat mich an einen Artikel/ einen Beiträg zum Thema „Programmieren Lernen“ erinnert. Dabei ging es um die Beobachtung dass Studenten dazu neigen immer mehr Fallunterscheidungen jnd Komplexität in ihren Lösungen einzubauen wenn sie aufgrund von Feedback auf Fehler hingewiesen werden. So sehe ich dass mehr Prozessschritte eingeführt werden und ich frage mich ob „weniger“ auch oder besser zum Ziel führen kann. So kenne ich aus der Java Welt archunit.org oder auch Konsist und würde hoffen es gibt eine ähnliche Art und Weise solche Regeln zu beschreiben.

Hallo @Wodar Hospur,

guter Punkt – das wirkt auf den ersten Blick tatsächlich wie ein Widerspruch, ist aber im Kern eine bewusste Designentscheidung, die ich gerade aufgrund eines KI‑Prechecks angepasst habe.

Zur 64‑bit vs. 128‑bit Frage:

Im ADR ist bewusst festgelegt:

• Persistenz / Datenmodell → int64_t (Fixed Point, skalierte Ganzzahlen)

• 128‑bit → nur als intermediäre Rechenhilfe (Multiply/Divide), nicht als Data-Type

Das Problem ist durch den Pre‑Check jetzt sichtbar geworden:

__int128 ist kein standardisierter Bestandteil von C++, sondern eine Compiler-Erweiterung (Clang/GCC), die z. B. unter MSVC nicht existiert.

Damit verletze ich mein eigenes Blender-/DNA-Prinzip:

Es dürfen nur Sprach- und Compiler-Features verwendet werden, die plattformübergreifend gleichzeitig existieren.

Das ist kein Optimierungsproblem, sondern ein architektonischer Regelbruch.

Deshalb die Anpassung:

• 64‑bit bleibt der definierte Datenraum

• 128‑bit wird nicht mehr als „implizit vorhanden“ angenommen

• sondern über:

  • Compiler-Guards

  • oder platform-spezifische Intrinsics (_umul128 etc.)
    explizit behandelt

Das ADR ist an der Stelle aktuell noch nicht nachgeführt – das ist genau der Punkt, den dieser Pre‑Check sichtbar gemacht hat.

Kurzes Update dazu:

Ich habe die daraus entstandene Architektur-Anpassung inzwischen sauber in das ADR-0004 überführt und versioniert.

Konkret wurde dort jetzt explizit festgehalten, dass:

• __int128 keine valide Grundlage für Cross-Platform-Code ist

• und alle entsprechenden Operationen über Compiler-Guards bzw. Intrinsics abgesichert werden müssen

Das war im ursprünglichen ADR so nicht sauber formuliert und ist erst durch den Pre-Check sichtbar geworden.

Für mich bestätigt das aktuell den Ansatz ganz gut: → reale Probleme führen zu architektonischen Präzisierungen, nicht nur zu Code-Fixes.

Kurzes Update zum Projekt – inzwischen ist einiges passiert.

Ich bin mittlerweile aus der reinen Experimentphase raus und habe das System einmal komplett refaktorisiert und stabilisiert.

## 🔧 Stand aktuell

Die komplette Pipeline ist jetzt durchgängig:

SQLite → Core → UI → Rendering

Das hatte ich am Anfang tatsächlich nicht sauber geschlossen – das System hatte einen klassischen "Silent Failure":

→ Daten waren korrekt vorhanden  

→ wurden aber nicht dargestellt  

Am Ende war das kein Bug, sondern ein Architekturproblem.

## 🧠 Wichtigste Änderung: Determinismus

Ich habe im Rahmen des Refactorings eine harte Entscheidung getroffen:

→ vollständiges Verbot von float/double im Core

Stattdessen läuft alles über ein eigenes Fixed-Point System auf int64-Basis.

Grund:

- reproduzierbare Ergebnisse

- keine Rundungsfehler

- plattformunabhängig

## 🧱 Architektur

Ich habe die Struktur jetzt komplett klar gezogen:

- Core (C++20, deterministisch, ohne UI)

- Mapping Layer (DB → Core)

- SQLite (DAO Pattern)

- UI (Dear ImGui)

- Rendering (Metal)

Wichtig: Kein Layer kennt Funktionen eines anderen, die er nicht kennen darf.

## 🔧 Refactoring-Erkenntnis

Der spannendste Punkt war ehrlich gesagt:

Der größte Fehler im System war kein Code-Fehler,

sondern ein fehlender Datenfluss.

Das hat man erst gesehen, als alles „eigentlich korrekt“ war.

## 🌍 Ergebnis

- Trades werden jetzt korrekt aus SQLite geladen

- im Core deterministisch berechnet

- im UI dargestellt

- und auf der Weltkarte visualisiert

## 🚀 Nächster Schritt

- Async DB Worker (kein I/O im UI Thread)

- Interaktion auf der Map (Zoom / Selection)

- Weiter Richtung Simulation / Constraints statt Logging

## 🧠 Fazit bisher

Die eigentliche Schwierigkeit ist nicht:

„Kann KI Code schreiben?“

sondern:

„Kann man die Architektur so präzise definieren, dass KI gar nicht falsch arbeiten kann?“

Falls Interesse besteht, kann ich gerne nochmal detaillierter auf das Refactoring eingehen – das war tatsächlich der lehrreichste Teil.

Bearbeitet vor 11 Stunden11 h von tkreutz2

vor 11 Minuten, tkreutz2 hat gesagt:

Die eigentliche Schwierigkeit ist nicht:

„Kann KI Code schreiben?“

sondern:

„Kann man die Architektur so präzise definieren, dass KI gar nicht falsch arbeiten kann?“

Das ist ja die eigentliche Frage, vollkommen unabhängig vom Projektthema.
Die Frage ist aber die gleiche, die ich mit natürlichen Intelligenzen zu beantworten habe:

„Kann man die Architektur so präzise definieren, dass die Entwickler gar nicht falsch arbeiten können?“
oder
"Wie präzise muss ich die Vorgaben definieren, damit die Entwickler ausreichend gut arbeiten?"

Und genau da ist dann der Unterschied.
Entwickler bringen Kreativität und Erfahrung mit. Mangelnde Vorgaben werden oft durch den Entwickler ergänzt.
Je nach Qualität der menschlichen Entwickler werden Fehler in Architekturvorgaben und Rules ausgeglichen.
Eine KI wird das nicht machen, wenn man keine entsprechende Aufforderung formuliert.

Genau das ist für mich auch der entscheidende Punkt.

Ich sehe das weniger als Frage „KI vs. Mensch“, sondern als Frage der notwendigen Präzision in der Architektur.

Bei menschlichen Entwicklern können unklare oder unvollständige Vorgaben oft durch Erfahrung und Kreativität ausgeglichen werden. Das System bleibt trotzdem funktionsfähig.

Bei KI funktioniert das nicht. Sie setzt exakt das um, was spezifiziert ist – inklusive aller Lücken.

Für mich führt das zu der Konsequenz, dass Architektur und Spezifikation deutlich präziser und strukturierter gedacht werden müssen, wenn man KI ernsthaft einsetzen will.

Mein Ansatz mit dem AXIOM-Projekt geht genau in diese Richtung: Systeme so zu entwerfen, dass Zustände, Datenflüsse und Abhängigkeiten möglichst deterministisch und nachvollziehbar bleiben, anstatt sich auf implizite Annahmen zu verlassen.

In dem Sinne passt der Vergleich eigentlich sehr gut – nur dass die fehlende „Kompensation“ der KI die Schwächen der Architektur deutlich sichtbarer macht.

vor 2 Stunden, tkreutz2 hat gesagt:

Für mich führt das zu der Konsequenz, dass Architektur und Spezifikation deutlich präziser und strukturierter gedacht werden müssen, wenn man KI ernsthaft einsetzen will.

Das deckt sich auch mit den Studien, die es dazu auch inzwischen gibt. Die Planungsphase rückt viel mehr in den Vordergrund und da sehe ich auch die größte Problematik, denn die Spezifikation war schon immer das größte Problem in der Softwareentwicklung. Man konnte so viel spezifizieren, wie man wollte, sobald es in die Entwicklung geht, geht die Spezifikation und Programmcode auseinander. Es ist manchmal auch schwierig, die Dinge unmissverständlich in Worte zu packen, damit kein Interpretationsspielraum übrig bleibt. Dafür ist die Sprache zu vielfältig. Deswegen beschränken sich Programmiersprachen auch nur auf wenige Worte, damit es eindeutig ist. Außerdem wurden die Anforderungen auch zu gerne "über den Zaun geworfen". Es heißt dann oft: "Der Kunde will ... Mach das mal fertig!". Das ist dann quasi vorbei. Jetzt muss man sich hinsetzen und genau planen, was der Kunde eigentlich wirklich will. Das viel erhoffte Vibe Coding funktioniert meiner Meinung auch nicht. Ab einem gewissen Punkt kommt da überwiegend Müll raus.

Guter Punkt – und ich glaube, genau da liegt der eigentliche Kern der ganzen Diskussion.

Du beschreibst im Grunde das klassische Problem der Softwareentwicklung:

Spezifikation und Implementierung driften auseinander – selbst wenn man sich noch so viel Mühe gibt.

Der Unterschied, den ich im Projekt gerade konkret sehe (AXIOM Trader):

Bei menschlichen Entwicklern wird ein Teil dieser Lücke meist durch Erfahrung und Intuition kompensiert.

Bei der KI fällt diese Kompensation komplett weg – sie setzt exakt das um, was spezifiziert ist, inklusive aller Lücken.

Das führt zu einem interessanten Effekt:

→ Architekturfehler werden nicht mehr „verdeckt“, sondern sofort sichtbar und reproduzierbar.

Ich habe das im Projekt relativ deutlich gesehen:

Der größte Fehler war am Ende kein Bug im Code, sondern ein fehlender Datenfluss bei eigentlich korrekten Komponenten.

Das wäre in einem klassischen Team vermutlich länger „mitgeschleppt“ worden.

Deshalb sehe ich KI weniger als Ersatz für Entwickler,

sondern eher als Verstärker für Architekturqualität:

- saubere Spezifikation → sehr gute Ergebnisse

- unscharfe Spezifikation → zuverlässig schlechte Ergebnisse

Dein Punkt zur Planungsphase passt da perfekt rein.

Das Bottleneck verschiebt sich meiner Meinung nach von der Implementierung hin zur Definition von:

- Zuständen

- Datenflüssen

- Invarianten

Ich versuche das aktuell über relativ harte Guardrails + Pre-Check-Systeme zu erzwingen.

Der Code ist da fast nur noch „Konsequenz der Architektur“.

Was mich interessieren würde:

Hast du in deinen Projekten Ansätze gesehen, wie man diese Spec-Drift systematisch in den Griff bekommt?

Also eher methodisch (z. B. ArchUnit, Contracts, formale Constraints etc.) – unabhängig von KI?