Docs-as-Code · AI · SW-Tools
SW-Tools, hilfreich as hell – und eine Crew aus Monstern.
Ich bin Daniel. Ich baue SW-Tools, mit denen große Teams ihr Wissen, ihre Qualität und ihre Entscheidungen im Griff behalten.
Tools
Woran ich gerade arbeite – manche Tools schon im Code, manche noch eine Idee.
Alpha
deciwa
Feedback und Freigaben direkt auf deinen Docs, Websites und deinem Code – damit klar ist, was bestätigt ist und was die KI noch tun soll.
Mehr erfahren →Prototyp
monsterbrain
Ein Gehirn für Menschen und KI-Agenten: Wissen, Konzepte und Ergebnisse in einer klaren Ordnerstruktur.
Mehr erfahren →Idee
quawa
Prüft, ob die Tests von KI-geschriebenem Code wirklich testen.
Mehr erfahren →Idee
faktwerk
Wissen einmal pflegen und für jede Rolle passend darstellen – immer konsistent.
Mehr erfahren →
Views
Gute Darstellungen machen komplexe Zusammenhänge in Sekunden klar, schlechte verstecken sie. Mich beschäftigt, wie man Informationen, Datenstrukturen und Workflows aus großen Projekten so zeigt, dass Menschen Probleme spüren, statt sie lesen zu müssen.
Zu den Views →
Toolchain-Vergleich
Eine kostenlose Tabelle für den Toolchain-Vergleich mit über 160 Anforderungen aus Docs-as-Code-Projekten im Automotive-Umfeld – damit Tool-Entscheidungen auf Fakten beruhen statt auf Bauchgefühl.
Weiterlesen →
Documentation as Code in der Automotive-System- und Softwareentwicklung
Der beste Überblick, den ich zu Docs-as-Code in einem professionellen Automotive-Projekt kenne: das Paper von Dr. Momcilo Krunic über ein ASPICE-konformes Setup mit 150 Engineers – mit seiner Erlaubnis veröffentlicht.
Weiterlesen →
Aus Sicht des Managements: Was bringt Docs-as-Code?
Ein erdachtes Gespräch mit dem Projektleiter eines Automotive-Softwareprojekts mit 500 Leuten: warum die Qualität der Dokumentation in Expertentools leidet und wie Docs-as-Code hilft.
Weiterlesen →
Ideen
Dinge, die ich gern bauen würde – noch nicht begonnen, aber schon durchdacht. Es geht um Probleme, die mir immer wieder begegnen: Doku, die nicht zum Code passt, Kennzahlen, die niemand sieht, Architektur und Anforderungen, die nichts voneinander wissen. Wenn dich etwas davon reizt, lass uns reden.
Zur Ideensammlung →
Über mich
Ich bin Softwareentwickler und baue am liebsten Tools, die anderen die Arbeit leichter machen. Dafür habe ich useblocks gegründet und als Teamlead Sphinx-Needs und viele weitere Docs-as-Code-Tools mitgebaut – sie laufen heute in großen Entwicklungsprojekten. Inzwischen begleite ich useblocks als Advisor.
Mich treibt um, wie große, verteilte Teams den Überblick behalten – über Anforderungen, Tests, Entscheidungen und das Wissen dazwischen. Meine Tools sind klein und fokussiert: Jedes löst genau ein Problem.
Mehr über mich →