Handwerk
Reale Dinge müssen funktionieren. Fehler werden nicht theoretisch, sondern praktisch sichtbar.
VERTIEFUNG · PERSÖNLICHE ENTWICKLUNG
Kein gerader Lebenslauf. Eine durchgehende Frage.
Mehr als 35 Jahre Lebenserfahrung erklären die Art, wie ich Fragen stelle. Sie beschreiben keinen 35-jährigen Plan für ATLAS. ATLAS selbst war nicht das Ziel. Es entstand viel später aus konkreten Problemen beim Programmieren und daraus, jede nächste logische Frage weiterzuverfolgen, als ursprünglich beabsichtigt.
FREIGEIST ALS ARBEITSWEISE
Nicht gegen Regeln. Aber auch nicht für Regeln nur deshalb, weil sie schon da sind.
Mein Berufsweg verlief nicht entlang einer einzelnen Disziplin. Er begann im Handwerk, führte über Meisterverantwortung, Bereichs- und Geschäftsführung, Projektleitung und komplexe Baustellen bis zu BIM-, Dokumenten- und Datenmanagement und schließlich zu eigener Software und Automatisierung.
Diese Wechsel waren kein Bruch. Sie haben denselben Blick geschärft: erst verstehen, was in der Realität passiert, dann fragen, was davon wirklich notwendig ist. Wenn eine Grenze nur aus Gewohnheit existiert, darf man sie hinterfragen.
Führung & Projekte
Menschen, Termine, Gewerke und Entscheidungen funktionieren nur, wenn Zusammenhänge verstanden werden.
Daten & Automatisierung
Je digitaler die Arbeit wurde, desto offensichtlicher wurden Wiederholung, Medienbrüche und verlorener Kontext.
VIER JAHRE ALS LONG-DISTANCE-MUSHER
16 Huskys, ein Mensch – und nur als Team kommt man durch.
Ein prägender Teil dieser Lebenserfahrung waren vier Jahre mit dem Valkoira Alaskan Husky Kennel. Mit 16 Schlittenhunden ging es im Long-Distance-Bereich 300 oder 600 Kilometer durch Eis, Schnee und die Wildnis Skandinaviens und Alaskas.
Dort entsteht Zusammenarbeit nicht aus Organigrammen. Jeder Hund hat Persönlichkeit, Stärken, Grenzen und eine Rolle im Rudel. Als Musher kann man Richtung und Verantwortung übernehmen, aber nicht jeden Meter erzwingen. Man beobachtet, reagiert auf Wetter, Gelände und Team, vertraut Erfahrung und muss Entscheidungen treffen, obwohl der Weg nicht fertig vor einem liegt.
Valkoira ist deshalb kein später erfundener Markenname. Der Name kommt aus diesem realen Team – und die Erfahrung gehört zu der langen Entwicklung, aus der später auch die Fragen hinter ATLAS gewachsen sind.
DER DIGITALE DRUCK WÄCHST
In den letzten rund acht Jahren wurde aus der Frage zunehmend ein technischer Zwang.
Mit immer mehr digitalen Werkzeugen wuchs paradoxerweise auch die Zahl der Brüche: Daten lagen in unterschiedlichen Systemen, Dokumente verloren ihren Bezug, Menschen übertrugen Kontext von Hand und Software bildete jeweils nur einen Ausschnitt der Realität ab.
Damit wurde aus einer lange vorhandenen Denkweise eine konkrete technische Aufgabe: Wie kann eine Maschine Information nicht nur speichern, sondern ihren Kontext, ihre Beziehungen und ihre Folgen so weit verstehen, dass Menschen nicht ständig die Lücken zwischen Systemen schließen müssen?
KEIN ATLAS-PLAN
ATLAS war nicht das Ziel. Jeder Schritt löste das Problem, das gerade sichtbar geworden war.
Es begann beim Programmieren. Mich störte, dieselben Funktionen immer wieder zu schreiben. Also entstanden universelle Module, und die Datenbank steuerte, wer oder was welche Funktion verwendet.
Dann wurden gewöhnliche Exception-Codes zum nächsten Problem: Sie sagten, dass etwas fehlgeschlagen war, aber zu wenig über die Situation. Ein Wrapper entstand um vier Fragen: wer, wie, wo und warum? Daraus wurde Question. All das lebte noch vollständig im Code.
Dahinter gab es keinen ATLAS-Fahrplan. Es gab nur die Gewohnheit, Wiederholung zu entfernen, Kontext explizit zu machen und das nächste Problem so weit zu verfolgen, bis es verständlich wurde.
EIN WISSENSCHAFTLICH-TECHNISCHES BAUPROJEKT ALS BESCHLEUNIGER
2019 änderte sich nicht die Frage. Es änderte sich die Dringlichkeit – und die Möglichkeit, sie praktisch zu beantworten.
In einem komplexen wissenschaftlich-technischen Bauprojekt trafen Wissenschaft, Bau, technische Anlagen, 3D-Modelle, Dokumente, Daten und viele beteiligte Disziplinen aufeinander. Die vorhandenen Werkzeuge konnten jeweils Teile davon abbilden. Die eigentliche Arbeit verlangte jedoch den Zusammenhang dazwischen.
Über fast zwei Jahre entstand aus konkreter Notwendigkeit ein weitgehend automatisiertes 3D-Modell. Später kamen große Dokumentmengen, OCR, Datenbanken, Konverter und Schnittstellen hinzu. Mit jeder technischen Lösung wurde deutlicher, dass nicht das einzelne Werkzeug die eigentliche Frage beantwortet.
Die Größen beschreiben dokumentierte berufliche Projekterfahrung. Sie sind keine ATLAS-ROI-, Geschwindigkeits- oder Kundenergebnis-Claims.
DEZEMBER 2025 · DER SPRUNG ZU SPEZIFIKATIONEN
Wie bekommen wir die Missverständnisse zwischen Mensch und Maschine aus der Welt?
Diese Frage stellte ich einem LLM. Die Antwort lautete: Regeln, Spezifikationen und eine gemeinsame Sprache. Regeln kannte ich. Mit Spezifikationen konnte ich zunächst wenig anfangen. Meine Reaktion war schlicht: Dann machen wir das so. Ich wusste nicht, wohin diese Entscheidung führen würde.
Code wurde zunehmend zu Spezifikationen. Dann kam die nächste Frage: Was kann man mit Spezifikationen alles machen? Die Antwort war: fast alles. Also ging es Schritt für Schritt ins Unbekannte, immer mit der nächsten logischen Frage statt mit einer fertigen Zielarchitektur.
Erst im Rückblick wird die Folge sichtbar: Wie bekommt man immer mehr Logik aus dem Code heraus? Was braucht eine Maschine, damit sie diese Logik finden, verbinden und anwenden kann? Registry entstand. Dann Matrix und Graph. Pattern wurden explizit. Ontologie und Telemetrie folgten. Jede Ebene beantwortete eine Lücke, die durch die vorherige sichtbar geworden war.
Performance war nicht das Ziel. Die wiederkehrende Frage war: Wie viel davon kann eine Maschine selbst machen und dabei trotzdem wissen, was sie tut, warum sie es tut und wo sie stoppen muss?
DIE KOMPLEXITÄT WECHSELT DIE SEITE
Tausende Spezifikationen waren nicht mehr mein Thema. Genau dafür war die Maschine da.
Mit jeder neuen Spezifikation wuchs eine Ebene, die ich als Mensch weder vollständig im Kopf halten noch zuverlässig von Hand verdrahten konnte. Field-Wiring, Abhängigkeiten, Versionen und die Frage, welche Spezifikation mit welcher anderen zusammenwirkt, wurden selbst zum Problem.
Die Konsequenz war nicht, diese Komplexität wieder zu vereinfachen, damit ich sie manuell verwalten konnte. Die Konsequenz war: Die Maschine übernimmt die Verwaltung der Spezifikationen und ihres Ablaufs. Meine Rolle blieb die Vision, die Richtung, die Fragen und der Blick auf das große Ganze.
Auch die Spezifikationen selbst entstanden zunehmend nicht durch mich als einzelnen Autor. LLM-Rollen arbeiteten als Author, Reviewer und Reviewer2: formulieren, prüfen, widersprechen, nachschärfen. Ich gab nicht jede einzelne Verbindung vor. Ich arbeitete mit einem System, das immer mehr seiner eigenen beschriebenen Realität maschinenlesbar halten konnte.
Mit wachsender Reife verschob sich damit auch der Rahmen. Neue Schritte wurden nicht mehr nur aus einer menschlichen Idee heraus vorgeschlagen, sondern mussten zu dem passen, was ATLAS bereits über sich selbst beschrieben, begrenzt und verlangt hatte. Architekturentscheidungen wie AMEX/ATEX wurden so nicht als vorheriges persönliches Zielbild festgelegt, sondern aus dem bestehenden ATLAS-Rahmen als notwendige nächste Lösung abgeleitet und anschließend wieder geprüft.
Das bedeutet nicht, dass ATLAS außerhalb menschlicher Verantwortung entscheidet. Es beschreibt den Punkt, an dem die maschinenlesbare Realität stark genug wurde, um den Lösungsraum selbst einzugrenzen: Was widerspricht bestehenden Regeln? Was fehlt? Welche nächste Struktur ist notwendig? Wo muss gestoppt und eine Frage erzeugt werden?
WAS ATLAS HEUTE BEDEUTET
Was heute existiert, ist das Ergebnis eines offenen Weges.
Heute verbindet ATLAS Pattern, Kontext, Spezifikationen, Authority, Ausführung und Evidence. Keine dieser Ebenen war ursprünglich das Ziel. Sie kamen hinzu, weil jede ein neu sichtbar gewordenes Problem löste: Maschinen mehr Zusammenhang zu geben und weniger menschliche Übersetzungsarbeit zu benötigen.
Für Kunden ist diese Tiefe optional. Entscheidend bleibt das Ergebnis: Software soll sich an die reale Arbeit anpassen – nicht umgekehrt.
Was davon ist für Ihre Situation relevant?
Sie müssen ATLAS nicht verstehen, um mit Valkoira zu arbeiten. Ausgangspunkt ist immer Ihre reale Situation.