Lebensabschnitte
- Diplom und Promotion in Wirtschaftswissenschaften, Schwerpunkt: Operations Research
- Entwickler, Projektleiter und Bereichsleiter bei der sd&m GmbH, München
- Breichsleiter und CIO bei der Dresdner Bank, Frankfurt
- Vorstand bei der IVU Traffic Technologies AG, Berlin / Aaachen
- Buchautor (Projektmanagement und Public Transport)
- selbständiger Berater
Fachliches Spektrum
- Deutsche Bahn, Lufthansa, öffentlicher Verkehr
- Messgeräte für Hochfrequenztechnik, Bordrechner, Foto-Chemie
- Banken und Finanzinstitute
- Embedded Systems
- Sofware-Engineering, Produktivitäts-Tools, Modellierung, Enterprsie Architecture
- Knowledge Management, MediaWiki
Technisches Spektrum
- MVS, CICS, DB2, Adabas, Cobol
- Unix, Debian, RTOS, QNX, C, sh, php, node.js
- Web-Client: html, css, js
- ESP32, Arduino, Schrittmotore, C++
Hobby
- Solarenergie
- 3D-Druck
- Holz, Metall, Elektronik
- Musizieren, Chorgesang
Lebensmotto: "Aun aprendo" (Francisco de Goya)
"Noch immer lerne ich". So hat es der Wegbereiter der modernen Malerei gegen Ende seines Lebens mit schwarzer Kreide festgehalten – eine Zeit, in der er sich die damals noch recht junge Technologie der Lithograohie aneignete.
Herbst 2025
Am Anfang stand die Neugier: Wo ist die Grenze von Agentic Coding?
Erfahrung aus erster Hand ist durch nichts zu ersetzen.
Herausfinden, was funktioniert, wo die Tücken sind, wie man ihnen begegenet.
Und nebenbei etwas Nützliches schaffen
Frühjahr 2026
Erkenntnis: Wenn man sich ganz darauf einlässt, ist eine Produktivität erreicbar, die völlig außerhalb bisheriger Maßstäbe liegt.
Bei kleinen Systemen (5000 – 20.000) LoC kann man unter idealen Bedingungen einen Faktor größer als 10 erreichen.
Bei mittelgroßen Systemen (< 100kLoC) ist unter normalen Bedingungen ein Faktor 5 möglich.
Alles, was dahinter kommt, ist Neuland. Aber es gibt Gründe zur Hoffnung auf signifikante Prduktivitätsgewinne auch bei 1MLoC.
Der Beweis
Der Beweis ist die Anwendung RAP (Rapid Application Platform) – zu 100% mit Agentic Coding erstellt.
RAP ist ein generischer Application-Builder. Werkzeugmacher würden sagen: Es ist eine Maschine, mit der man Maschinen baut.
Der fachliche Inhalt einer Anwendung wird in Form syntaktisch annotierter Texte aufgeschrieben. RAP benutzt dazu – ebenso wie die AI Agents – die sogenannte Markdown Syntax. Dieser Ansatz ist zwar nicht so sexy wie NoCode-Click-Tools, aber er ist haushoch überlegen, wenn es um Produktivität geht.
Wenn man eine Anwendung auf der Basis von RAP erstellt, fühlt es sich so an, als ob man eine Spezifikation schreibt, die sofort ausgeführt wird.
In manchen Fällen kann man sogar den Nukleus einer RAP Anwendung in freuer Sprache durch Agentic Coding erstellen lassen, denn ich habe der AI beigebracht, die von mir entworfene Spezifikations-Notation zu benutzen und Sachverhalte in dieser Sprache zu notieren.
Schwer zu glauben. Wo ist der Haken?
Meine Erfahrung sagt: Die eingesetzte Technologie wird Anwendungen mit bis zu 100 Benutzern vertragen, die viel suchen und nachdenken, jedoch eher selten Daten massiv parallel verändern.
Vom Charakter her also typische "Dispositions"-Systeme.
RAP eignet sich nicht für massiv parallele Buchungssysteme. RAP eignet sich nicht für soziale Systeme. Es ist nicht auf Massentauglichkeit im Web ausgelegt. Auch nicht für Börsenhändler. Das Handy als Frontend spielt kaum eine Rolle.
Es geht um Fachleute, die vor mehreren Monitoren sitzen, sich in einer konmplexen Datenlandschaft unter wechselnden Perspektiven einen Überblick verschaffen müssen, um dann kluge Entscheidungen zu treffen.
RAP unterstützt Anwendungen, die "nah an der Datenbank" agieren. Man kann in RAP "Kochrezepte" für komplexe Recherchen hinterlegen und natürlich auch Daten verändern, soweit sie nicht bewusst readonly sind. Wenn es jedoch sehr verzweigte Geschäftsprozesse mit vielen Schnittstellen zu anderen Abteilungen gibt, will man in der Regel eine Business Process Management Platform als zusätzliches Frontend einbinden. RAP unterstützt dies durch alle erforderlichen APIs.
Das alles kann zu einem tollen System in unschlagbar kurzer Zeit führen.
Es sei jedoch nicht verschwiegen, dass RAP aktuell noch ein paar Defizite hat in Richtung Produktionsbetrieb (Container-Deployment, Lastverteilung, System-Monitoring, Auto-Restart ..). Nichts davon ist wirklich kritisch –
aber solche Dinge baut man nicht auf Vorrat…
Der nächste Schritt
Ich bin auf der Suche nach einem Partner, der den Wert der RAP Plattform erkennt und eine passende fachliche Problemstellung mitbringt. SO kann RAP weiter reifen.
Nach wenigen Wochen kann der Partner einen Prototyp benutzen, in dem er bereits viele seiner Daten vorfindet. Er kann sehen, wie die Anwendung sich verhalten wird, Reports entwerfen, APIs einbinden, Daten aus Nachbarsystemen importieren – denn auch dafür gibt es eine Spezifikationssprache, etwa zur Datenübernahme aus Excel oder SAP.
An einem bestimmten Punkt sagt der fachliche Auftraggeber, dass er die Anwendung in dieser Form nutzen will und "bestellt" sie. Spätestens dann werden die produktionsrelevanten technischen Aspekte nachgerüstet und man geht in einen Probebetrieb.
Ich biete an, mein Know How vollständig weiterzugeben, so dass spätestens nach 9 Monaten keine Abhängigkeit mehr zu mir als Person besteht.
Der Unternehmenspartner erwirbt alle Rechte an seiner Anwendung, jedoch nicht an der RAP-Plattform.
Aus RAP würde ich gern Open Source (MIT-Lizenz) machen, das sichert den Unternehmenspartner besser ab als exklusive Rechte an der RAP Source. "Source" meint hier übrigens nicht nur die klassischen technischen Artefakte, sondern vor allem Instruktionen und Konfigurationen für den AI Agenten, mit dem RAP weiterentwickelt werden sollte.
EIn wesentlicher Vorteil für das Unternehmen liegt darin, dass während der Arbeit an dem Projekt immer wieder kleinere Änderungen an RAP passieren werden. Man hat in dieser Periode ein Exklusivrecht darauf, dass solche Anpassungen rasch und zweckmäßig passieren. Wobei damit nicht gemeint ist, dass RAP irgendwelches fachliches Wissen über den Inhalt der konkreten Anwendung erhalten wird. RAP ist und bleibt eine generische "Engine".