tkreutz2

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.

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.

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:
Damit verletze ich mein eigenes Blender-/DNA-Prinzip:
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.

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

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:
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.
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.
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.
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 ,
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):
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).
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).
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!

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.

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!

Screenshot

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...

Dieses Problem kenne ich nur zu gut und einer meiner ehemaligen Chefs hat es am besten klassifiziert. Man nennt es das "Haben-Wollen-Syndrom". Es wird kein Tag im Leben des Admins geben, der friedlich verläuft, sobald der ERSTE Mitarbeiter etwas hat, was ein anderer Mitarbeiter nicht hat. Dabei ist es Sch...Egal, ob es der größere Monitor, der Drucker, die Workstation oder sonst was ist.
Aus dem Grund funktioniert IT auch nur dann in diesem Bereich erfolgreich, wenn es of der gleichen organisatorischen Ebene agiert, wie alle anderen. Wenn andere Abteilungen beispielsweise einen GF im Vorstand haben zu einem Thema, muss es die IT auch haben. Ist das nicht der Fall, wird eine solche IT sich niemals gegen andere innerhalb der Organisation durchsetzen können, weil nie Kommunikation auf Augenhöhe stattfinden wird.
Und das ist ein grundsätzliches Problem der betrieblichen Organisation, seit der Erfindung der Betriebswirtschaft im akademischen Bereich.
Im Grunde genommen sind sehr viele Probleme in der IT Kommunikationsprobleme und die eigentliche Herausforderungen neben dem fachlichen Wissen im Laufe einer IT-Karriere wird es immer sein, Kommunikationsprobleme zu lösen.

Dieses Problem kenne ich nur zu gut und einer meiner ehemaligen Chefs hat es am besten klassifiziert. Man nennt es das "Haben-Wollen-Syndrom". Es wird kein Tag im Leben des Admins geben, der friedlich verläuft, sobald der ERSTE Mitarbeiter etwas hat, was ein anderer Mitarbeiter nicht hat. Dabei ist es Sch...Egal, ob es der größere Monitor, der Drucker, die Workstation oder sonst was ist.
Aus dem Grund funktioniert IT auch nur dann in diesem Bereich erfolgreich, wenn es of der gleichen organisatorischen Ebene agiert, wie alle anderen. Wenn andere Abteilungen beispielsweise einen GF im Vorstand haben zu einem Thema, muss es die IT auch haben. Ist das nicht der Fall, wird eine solche IT sich niemals gegen andere innerhalb der Organisation durchsetzen können, weil nie Kommunikation auf Augenhöhe stattfinden wird.
Und das ist ein grundsätzliches Problem der betrieblichen Organisation, seit der Erfindung der Betriebswirtschaft im akademischen Bereich.
Im Grunde genommen sind sehr viele Probleme in der IT Kommunikationsprobleme und die eigentliche Herausforderungen neben dem fachlichen Wissen im Laufe einer IT-Karriere wird es immer sein, Kommunikationsprobleme zu lösen.

Dieses Problem kenne ich nur zu gut und einer meiner ehemaligen Chefs hat es am besten klassifiziert. Man nennt es das "Haben-Wollen-Syndrom". Es wird kein Tag im Leben des Admins geben, der friedlich verläuft, sobald der ERSTE Mitarbeiter etwas hat, was ein anderer Mitarbeiter nicht hat. Dabei ist es Sch...Egal, ob es der größere Monitor, der Drucker, die Workstation oder sonst was ist.
Aus dem Grund funktioniert IT auch nur dann in diesem Bereich erfolgreich, wenn es of der gleichen organisatorischen Ebene agiert, wie alle anderen. Wenn andere Abteilungen beispielsweise einen GF im Vorstand haben zu einem Thema, muss es die IT auch haben. Ist das nicht der Fall, wird eine solche IT sich niemals gegen andere innerhalb der Organisation durchsetzen können, weil nie Kommunikation auf Augenhöhe stattfinden wird.
Und das ist ein grundsätzliches Problem der betrieblichen Organisation, seit der Erfindung der Betriebswirtschaft im akademischen Bereich.
Im Grunde genommen sind sehr viele Probleme in der IT Kommunikationsprobleme und die eigentliche Herausforderungen neben dem fachlichen Wissen im Laufe einer IT-Karriere wird es immer sein, Kommunikationsprobleme zu lösen.

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.

Was verstehst Du denn unter "Branchenwechsel" ? - Du schreibst was von komplett neuem Ausbildungsberuf (was man natürlich machen kann), aber das hat primär ja erst mal nichts mit der Branche zu tun.
Branchenwechsel wäre in meinen Augen z.B. der Wechsel von einem Industriebetrieb zu einer Bank (Dienstleistung), oder von Handel zu Energie & Umwelt.
Ohne regionalen Bezug, wird hier kaum jemand einen Tipp geben können. Aber die Frage nach Flexibilität (also Bereitschaft, dorthin umzuziehen, wo ggf. ein anderes Angebot vorhanden ist), spielt schon eine Rolle.
Warum hat Dir denn der Betrieb, der Dich ausgebildet hat, kein Jobangebot gemacht ?
Das wären alles so die Fragen, die mir bei einem Bewerbungsgespräch einfallen würden.
Du kannst ja mal anonymisiert Deine Bewerbungsunterlagen hochladen und hier prüfen lassen. Vielleicht gibt es ein paar Punkte, die optimiert werden können.
Ansonsten wurde ja der Tipp gegeben, Kontakte auszubauen. Gibt es denn irgendwelche Projekte, die Du in Deinem persönlichen Showcase hast (z.B. Git Repo) und anhand interessierte Leute einen Einblick in Deine Skills bekommen können ?

Ich lese hier viel über ob KI‑Beiträge zulässig oder sinnvoll sind. Mir scheint aber, das eigentliche Problem liegt eine Ebene tiefer:

Wir haben kein gemeinsames Modell dafür, wo KI denken darf – und wo Verantwortung liegen muss.
Ich habe dazu ein Architekturmodell formuliert, das genau diese Trennung explizit macht: KI als Generator, niemals als Autorisierungs‑ oder Entscheidungsinstanz.

Wenn das hier interessiert, gern Feedback/Widerspruch.

Ki-Foren.pdf

Ich habe zwei Punkte, die ich gerne einwerfen würde: Einerseits wurde meiner Meinung nach bei Postgres, Go, ... zu kurz gedacht. Das sind ja auch nur Tools, die erstmal irgendwo laufen müssen. Dazu braucht es Compiler und Betriebssystem. Andererseits ist die reine Spezifikation ja auch keine Lösung. Das muss erst noch implementiert werden, ist soweit also nur reine Theorie und in der Praxis unbrauchbar.
Ich stelle mir die Frage: Wozu? Die meisten Programme (sofern nicht zu viele externe Bibliotheken eingebunden werden) werden wohl auch noch in 20 Jahren laufen. Was einmal läuft bricht ja nicht automatisch über Nacht. Docker, VMs & Co erlauben hier auch lange veraltete Software zumindest noch virtuell zu unterstützen. Der Go oder Rustcompiler oder die JVM werden nicht auf einmal magisch verschwinden. Insofern denke ich was Technologien anbelangt tut es vermutlich jede, die man initial im Kopf haben würde. Software die einfach nur in 20 Jahren unverändert laufen soll ist eingefroren in der Zeit und die externen Abhängigkeiten sehr überschaubar. Solange man diese kontrollieren kann, wird auch die Software funktionieren. Natürlich kann man die Abhängigkeiten noch weiter reduzieren, indem man die Schnittstellen, an denen man am ehesten Veränderungen vermutet austauschbar macht.
Wenn ich darüber hinaus noch mehr Sicherheiten will, dann muss man sich vermutlich stark an Open Software orientieren. Wenn du einmal den Sourcecode besitzt, wird es schwer sein, dir den wieder wegzunehmen. Insofern halte ich es schon für sinnvoll auf z.B. Linux, LLVM & Co zu setzen. Ob ich z.B. Postgres einsetze hängt in erster Linie aber auch eher davon ab, welche Daten ich verarbeite und was meine Anforderungen an die Verarbeitung sind, als dass ich maximale Unabhängigkeit will. Sind die Anforderungen nicht allzu hoch und ist Unabhängigkeit wirklich ein Ziel, dann ist so eine (einfache) Datenbank auch schnell selber geschrieben. [Mir ist durchaus bewusst, dass man analoge Argumente auch für OS und Compiler bringen kann, nur das sind noch seltenere Anwendungsfälle].
Schlussendlich bin ich aber auch hier von Hardware und OS abhängig. Was wenn mein OS nicht mehr unterstützt wird? Was, wenn es keinen Support für die Hardware gibt? Alte Hardware läuft nicht für immer und auch hier muss vorgesorgt werden. Klar wird es vermutlich Linuxtreiber für die Hardware geben - und wenn nicht, dann sind diese auch schnell selbst geschrieben. Aber diese Diskussion ist ein Fass ohne Boden. Wo hört man auf?
Das Positionspaper finde ich im Übrigen richtig gut. Es stößt mir schon länger auf, dass Informatik mit "Tools lernen" gleichgesetzt wird. Module wie "Betriebssysteme" oder "Computerarchitektur", aber auch theoretische Informatik sind auch unter Studenten eher unbeliebt. Ich denke oft, dass sich Leute "früher" vielleicht besser mit der Materie ausgekannt haben, weil weniger Abstraktion dazwischen war, weniger Resourcen verfügbar waren und die Leute so kreativer sein mussten. Und das gilt nicht nur für Informatik. Ob BASIC oder der Nano-Pi genau die richtige Abstraktionsebene für den Einstieg sind, darüber lässt sich sicherlich streiten. Dennoch bin ich ein großer Fan!

Hallo zusammen,
ich möchte in der Plauderecke eine Architekturdiskussion anstoßen – bewusst ohne konkretes Produkt‑ oder Framework‑Bashing.
Ausgangspunkt ist ein privates Projekt / Showcase, bei dem ich mich gefragt habe:
Wie müsste man Software heute entwerfen, wenn sie 20 Jahre unverändert betreibbar sein soll?
Statt „State of the Art 2026“ habe ich daher ein paar bewusste Gegenentscheidungen getroffen:
• stabiler Kern (PostgreSQL, klar definierte Domänenlogik)
• Service‑Schicht in Go (kompiliert, wenig Abhängigkeiten)
• Zugriff über mehrere sehr unterschiedliche Clients:
– Web (Browser)
– native Clients (C#, C++20)
– Terminal‑Zugriff (TN3270), testbar sogar auf sehr alter Hardware
• Druck/PDF‑Erzeugung nicht über Office‑Reports, sondern über eine textbasierte Build‑Pipeline (groff) in Docker
Der Retro‑Teil ist dabei weniger Nostalgie als Härtetest:
Wenn eine Anwendung über blockorientierte Terminals funktioniert, erzwingt das automatisch klare Datenmodelle und saubere Schnittstellen.
Mich interessiert nicht „retro vs. modern“, sondern die Frage:
Welche Teile heutiger Softwarearchitektur sind wirklich langlebig – und welche sind es nur, weil wir sie alle benutzen?
Wie seht ihr das aus eurer Praxis?
Gibt es aus eurer Sicht Architekturprinzipien, die den letzten 15–20 Jahren tatsächlich standgehalten haben?
Technologiepapier_Manifest_MovieSystem_v1.pdf

Um zu verstehen, warum ich mich für diesen Stack (Go, Retro-Anbindung, kein modernes Web-UI-Bling-Bling) entschieden habe, möchte ich mein Positionspapier zur Informatikbildung teilen. Mir geht es darum, dass gerade Auszubildende wieder lernen, Systeme zu bauen und zu durchdringen, statt nur Oberflächen zu bedienen. Mein Projekt ist der technische Prototyp für genau diesen didaktischen Ansatz.
Positionspapier_Informatikbildung_Gestaltbare_Systeme.pdf

übersetzbar, bestenfalls. lesbar scheitert schon an diakritischen zeichen die in unserem alphabet nicht vorkommen.

Das Voynich-Manuskript, Rongorongo und Co. lassen grüßen

Indem man ihn ins Meer gibt. - aber das ist vielleicht doch etwas zu poetisch für eine Architekturdiskussion. ;)
Der ursprüngliche Ansatz ist in meinen Augen sehr gut durchdacht und setzt trotzdem, Meiner Meinung nach, auf einer Ebene an, die langfristig nicht die stabilste ist.
Denn im Grunde listet auch das Manifest am Ende nur Tools auf: PostgreSQL, Go, groff, TN3270, Docker. Alles gute, bewährte Werkzeugen, Ja. Aber auch Tools, die in 20 Jahren möglicherweise anders aussehen, anders heißen oder durch etwas Besseres ersetzt werden. Damit dann doch wieder eine "kuratierte" Toolsammlung.

Denn was wirklich langlebig ist, ist nicht das Tool, es ist die Logik.
Denn was bedeutet "ein Film"? Was ist "eine Sammlung"? Was bedeutet es, ein Medium eindeutig zu identifizieren? Diese Fragen, die Sprache des Problems selbst, haben sich in den letzten 50 Jahren kaum verändert. Und sie werden das in den nächsten 20 Jahren auch nicht tun.
Das kennt man auch unter dem Begriff "Domain-Driven-Design". Denn die fachliche Beschreibung was ein System tun soll, ist das eigentlich langlebige Artefakt. Denn alles andere, Frameworks, Sprachen, Protokollem, Druckengines sind austauschbar. Solange die Fachlichkeit klar definiert ist.

Deshalb, vielleicht etwas radikal, aber eigentlich konsequent: Die Spezifikation als einziges Artefakt.
Deshalb mit den heutigen Mitteln weiter gedacht, was spricht dagegen, das System auf einem gut formulierten, natürlichsprachigen Prompt aufzubauen? Einer Beschreibung der Logik und nicht der Implementierung.
Die KI darf sich ändern, das Modell dahinter ebenfalls. Aber der Prompt, also die Anforderungsbeschreibung, bleibt konstant.
Ja ja, der Einwand: "Aber die KI ist doch auch ein Tool!" Jup, stimmt. Aber der Prompt in natürlicher Sprache ist eben kein Tool, und der ist die Spezifikation. Und diese bleibt über Generationen wirklich interpretierbar. Denn ein gut geschriebener Satz ist in 20 Jahren noch genauso gültig und lesbar (natürliche Sprache ändert sich nciht so schnell, selbst knapp 1.000 Jahre alte Gedichte und Minnegesänge von Walther von der Vogelweide sind heute noch lesbar), und von jeder zukünftigen Technologie interpretierbar.

Und HTML als Warnung
Was vor 20 Jahren in HTML gebaut wurde, würde heute niemand mehr so bauen. Nicht weil die Anforderungen falsch waren, sondern weil das "Tool" HTML sich verändert hat, und weil die Implementierung die eigentliche Logik eingeschlossen hat wie ein Bernstein. Die Logik ist mit dem Tool zusammengewachsen und damit genauso veraltet.
Das ist das eigentliche Problem bei „20-Jahre-Architekturen": Nicht dass die Tools sich ändern, das ist unvermeidlich. Sondern dass die Logik so tief in die Tools eingebettet wird, dass sie nicht mehr separat überleben kann.

Ws ich sagen will ist nicht, das keine Tools mehr zu verwenden ist, natürlich muss irgendwas gebaut werden. Aber die Investition in Langlebigkeit sollte nicht primär in die Wahl des "richtigen" Tools fließen, sondern in die saubere und werkzeugagnostische Beschreibung dessen, was das System tun soll.
Der Kern ist dann nicht PostgreSQL.
Der Kern ist dann die Antwort auf die Frage: "Was ist eigentlich ein Film in diesem System und welche Regeln gelten für Ihn?"

Sorry, bischen länger geworden die Antwort. ;)

Hallo zusammen,
ich möchte in der Plauderecke eine Architekturdiskussion anstoßen – bewusst ohne konkretes Produkt‑ oder Framework‑Bashing.
Ausgangspunkt ist ein privates Projekt / Showcase, bei dem ich mich gefragt habe:
Wie müsste man Software heute entwerfen, wenn sie 20 Jahre unverändert betreibbar sein soll?
Statt „State of the Art 2026“ habe ich daher ein paar bewusste Gegenentscheidungen getroffen:
• stabiler Kern (PostgreSQL, klar definierte Domänenlogik)
• Service‑Schicht in Go (kompiliert, wenig Abhängigkeiten)
• Zugriff über mehrere sehr unterschiedliche Clients:
– Web (Browser)
– native Clients (C#, C++20)
– Terminal‑Zugriff (TN3270), testbar sogar auf sehr alter Hardware
• Druck/PDF‑Erzeugung nicht über Office‑Reports, sondern über eine textbasierte Build‑Pipeline (groff) in Docker
Der Retro‑Teil ist dabei weniger Nostalgie als Härtetest:
Wenn eine Anwendung über blockorientierte Terminals funktioniert, erzwingt das automatisch klare Datenmodelle und saubere Schnittstellen.
Mich interessiert nicht „retro vs. modern“, sondern die Frage:
Welche Teile heutiger Softwarearchitektur sind wirklich langlebig – und welche sind es nur, weil wir sie alle benutzen?
Wie seht ihr das aus eurer Praxis?
Gibt es aus eurer Sicht Architekturprinzipien, die den letzten 15–20 Jahren tatsächlich standgehalten haben?
Technologiepapier_Manifest_MovieSystem_v1.pdf

Ein sehr spannendes Thema!
Im Paper selbst schreibst du <Ziel ist nicht „anti‑Microsoft/anti‑Apple“ [...]> ich denke dazu, daß es bei dem Ruf nach Langlebigkeit so ist, daß Microsoft-/Appleprodukte dann nur als Clients zum Einsatz kommen können, weil die ja Funktionen/Kompatibilitäten in manchmal in kürzester Zeit abschalten. Dann müsste das ganze Backend als OpenSource gestaltet sein. Hast du dir Project Nomad schon mal angesehen? Das könnte ja ggf. um die von dir gewünschten Funktionalitäten aufgebohrt werden? Ich hatte da letztes Wochenende bisschen mit rumgebastelt, die Idee an sich ist in jedem Fall super.

Hallo zusammen,
ich möchte in der Plauderecke eine Architekturdiskussion anstoßen – bewusst ohne konkretes Produkt‑ oder Framework‑Bashing.
Ausgangspunkt ist ein privates Projekt / Showcase, bei dem ich mich gefragt habe:
Wie müsste man Software heute entwerfen, wenn sie 20 Jahre unverändert betreibbar sein soll?
Statt „State of the Art 2026“ habe ich daher ein paar bewusste Gegenentscheidungen getroffen:
• stabiler Kern (PostgreSQL, klar definierte Domänenlogik)
• Service‑Schicht in Go (kompiliert, wenig Abhängigkeiten)
• Zugriff über mehrere sehr unterschiedliche Clients:
– Web (Browser)
– native Clients (C#, C++20)
– Terminal‑Zugriff (TN3270), testbar sogar auf sehr alter Hardware
• Druck/PDF‑Erzeugung nicht über Office‑Reports, sondern über eine textbasierte Build‑Pipeline (groff) in Docker
Der Retro‑Teil ist dabei weniger Nostalgie als Härtetest:
Wenn eine Anwendung über blockorientierte Terminals funktioniert, erzwingt das automatisch klare Datenmodelle und saubere Schnittstellen.
Mich interessiert nicht „retro vs. modern“, sondern die Frage:
Welche Teile heutiger Softwarearchitektur sind wirklich langlebig – und welche sind es nur, weil wir sie alle benutzen?
Wie seht ihr das aus eurer Praxis?
Gibt es aus eurer Sicht Architekturprinzipien, die den letzten 15–20 Jahren tatsächlich standgehalten haben?
Technologiepapier_Manifest_MovieSystem_v1.pdf

Stimme Skylake zu, zunächst dachte ich auch 1 bis 2. Aber auch die KI meint, eine 2. Kann nichts negatives finden.