![\"\"](\"https:\/\/brinkhaus-gmbh.de\/wp-content\/uploads\/2026\/02\/ChatGPT-Image-Feb-9-2026-05_11_49-PM.png\")
<\/figure>Zwei Dokumentationsebenen: Eine f\u00fcr Menschen, eine f\u00fcr Maschinen<\/h2>\n\n\n\n
In meinen Kundenprojekten habe ich begonnen, konsequent zwei Markdown-Dateien zu pflegen.<\/p>\n\n\n\n
Die README.md<\/strong> ist das, was man kennt: eine Kurzeinf\u00fchrung f\u00fcr Menschen. Was ist das Projekt? Wozu dient es? Wie startet man es? Das \u00dcbliche \u2013 aber konsequent aktuell gehalten.<\/p>\n\n\n\n Daneben steht die CLAUDE.md<\/strong>. Diese Datei ist speziell f\u00fcr den KI-Assistenten geschrieben. Sie enth\u00e4lt die Grundstruktur des Projekts, erkl\u00e4rt wie Dinge aufgebaut sind, wie sie zusammenh\u00e4ngen, wo die Fallstricke liegen. Claude Code liest diese Datei automatisch beim Start einer Session.<\/p>\n\n\n\n Der Clou: Claude schreibt diese Datei im Wesentlichen selbst. Ich lasse die KI nach einer Arbeitssession ihre Erkenntnisse dokumentieren. Was hat sie gelernt? Wo gab es Probleme? Was muss die n\u00e4chste Instanz wissen? Ich korrigiere dann Kleinigkeiten, aber der Gro\u00dfteil kommt von der KI selbst.<\/p>\n\n\n\n Das klingt nach einer Spielerei. Ist es nicht. Es ist eine Wissensdatenbank, die mit jedem Arbeitszyklus besser wird.<\/p>\n<\/div><\/div>\n\n\n\n Hier kommt mein QM-Hintergrund ins Spiel. Im ISO 9001-Kontext gibt es ein Grundprinzip: Wenn ein Prozess regelm\u00e4\u00dfig Probleme verursacht, beschreibt man ihn besser. Man wartet nicht, bis jemand den gleichen Fehler zum dritten Mal macht \u2013 man schreibt auf, wie es richtig geht 👌.<\/p>\n\n\n\n Genau das mache ich mit Claude. Wenn ich beobachte, dass die KI sich regelm\u00e4\u00dfig an bestimmten Problemen aufh\u00e4lt \u2013 etwa an einer ungew\u00f6hnlichen Build-Konfiguration oder einer Projektkonvention, die nicht offensichtlich ist \u2013, fordere ich sie auf, das in der CLAUDE.md festzuschreiben. Damit die n\u00e4chste Instanz diesen Fehler nicht wiederholt.<\/p>\n\n\n\n Wenn die Beschreibungen dabei zu kompliziert oder verworren werden, lasse ich Claude sie vereinfachen. Die Anweisung lautet dann sinngem\u00e4\u00df: \u201eSchreib das so um, dass deine n\u00e4chste Instanz es auf Anhieb versteht.” Das ist nichts anderes als der PDCA-Kreislauf: Planen, Durchf\u00fchren, \u00dcberpr\u00fcfen, Verbessern. Nur eben f\u00fcr eine KI statt f\u00fcr ein Team.<\/p>\n\n\n\n Das Ergebnis sind Prozessbeschreibungen, die immer besser werden. Nicht weil ich sie m\u00fchsam pflege, sondern weil die kontinuierliche Verbesserung in den Arbeitsablauf eingebaut ist.<\/p>\n\n\n\n Wenn eine KI programmiert, braucht man Tests. Das ist unstrittig. Was weniger offensichtlich ist: Die klassische gr\u00fcn\/rot-Anzeige reicht nicht.<\/p>\n\n\n\n Mir war von Anfang an wichtig, dass meine Tests einen textuellen Report erzeugen. Nicht nur \u201ebestanden” oder \u201efehlgeschlagen”, sondern: \u201eTeste jetzt die Filterberechnung mit Parametersatz A. Habe validiert, dass der Ausgabewert innerhalb der Toleranz von 0,1% liegt. Pr\u00fcfe nun die Grenzwerte f\u00fcr B, C und D.”<\/p>\n\n\n\n Warum? Weil ich wie ein Chef handele, der Validierungen hinterfragt 🙈. Wenn ich in einem Testergebnis sehe, dass Claude etwas gepr\u00fcft hat, stelle ich Fragen: \u201eHast du wirklich den Originalwert verglichen oder nur gegen deinen eigenen Output getestet?” Manchmal macht sich die KI Dinge einfacher als gewollt 😮. Das f\u00e4llt nur auf, wenn man versteht, was gepr\u00fcft wurde.<\/p>\n\n\n\n Zus\u00e4tzlich zum lesbaren Report erzeuge ich einen JSON-Output. Der ist f\u00fcr die maschinelle Auswertung gedacht \u2013 Continuous Integration, automatische Dashboards, Trendanalysen. Aber er ist auch f\u00fcr die KI selbst n\u00fctzlich: In der n\u00e4chsten Session kann Claude die JSON-Reports lesen und wei\u00df sofort, was beim letzten Mal funktioniert hat und was nicht.<\/p>\n\n\n\n Diese Doppelstruktur \u2013 menschenlesbar und maschinenlesbar \u2013 ist mehr Aufwand beim Einrichten. Aber sie zahlt sich aus, weil sie Qualit\u00e4t absicherbar macht. Nicht nur \u201egr\u00fcn” 😉.<\/p>\n<\/div><\/div>\n\n\n\n Es gibt ein Prinzip, das ich mittlerweile auf alles anwende: Jede Struktur, die ich aufbaue, lasse ich von Claude beschreiben.<\/p>\n\n\n\n Wenn ich eine neue Teststruktur einrichte \u2013 sei es als CTest in CMake-Projekten oder als zentral aufgerufenes Python-Skript \u2013, dann dokumentiert Claude, wie diese Struktur funktioniert, wo sie liegt, wie man sie aufruft. Das wird Teil der CLAUDE.md.<\/p>\n\n\n\n Der doppelte Nutzen: Erstens kann die n\u00e4chste KI-Instanz sich sofort einarbeiten und die eigene Arbeit verifizieren. Zweitens kann ich selbst nach drei bis sechs Monaten Pause in ein Projekt zur\u00fcckkehren und wei\u00df sofort, was Sache ist.<\/p>\n\n\n\n Diesen zweiten Punkt untersch\u00e4tzen viele. Wer als Einzelentwickler oder in einem kleinen Team arbeitet, kennt das Gef\u00fchl: Man \u00f6ffnet ein Projekt nach einem halben Jahr und braucht einen Tag, um sich wieder reinzudenken. Mit einer guten CLAUDE.md brauche ich eine halbe Stunde \u2013 weil dort steht, was ich damals wusste. Und die KI es sowieso eher “nach 5sec” alles wieder kennt 🤣.<\/p>\n\n\n\n \u00dcber die letzten Monate hat sich bei mir ein Standard etabliert, den ich inzwischen auf alle Kundenprojekte anwende:<\/p>\n\n\n\n Erstens ist jedes Projekt \u201eKI-wartbar”. Das bedeutet: Eine neue KI-Instanz kann sich in das Projekt einarbeiten und produktiv werden, ohne dass ich eine Stunde Kontext liefern muss.<\/p>\n\n\n\n Zweitens existiert eine CLAUDE.md, die nicht einmalig geschrieben, sondern aus Session-Learnings gewachsen ist. Sie ist ein lebendiges Dokument.<\/p>\n\n\n\n Drittens gibt es eine Teststruktur mit textuellem und JSON-Output. Der Mensch kann die Ergebnisse \u00fcberfliegen und versteht, was gepr\u00fcft wurde. Die Maschine kann sie auswerten.<\/p>\n\n\n\n Viertens gibt es einen einfachen Einstiegspunkt. Tests aufrufen, Ergebnisse lesen, weiterarbeiten. Kein Setup-Marathon.<\/p>\n\n\n\n Das klingt nach viel? Ist es anfangs auch. Man muss diese Strukturen aufbauen \u2013 und ja, man muss sie betreuen. Aber wenn sie einmal stehen, wird etwas Bemerkenswertes m\u00f6glich: Man wird hemmungslos.<\/p>\n\n\n\n Wenn Tests da sind und eine KI die Arbeit macht, traut man sich an Dinge heran, die man als einzelner Entwickler nie angefasst h\u00e4tte. Umstrukturierungen, die eigentlich funktionierenden Code betreffen. Aufr\u00e4umarbeiten, die man seit Jahren vor sich herschiebt. Die Qualit\u00e4t wurde dabei in meinen Projekten teilweise erheblich besser \u2013 nicht trotz der KI, sondern weil die Strukturen ihr den Rahmen geben, in dem sie ihre St\u00e4rken ausspielen kann.<\/p>\n\n\n\n Man merkt an allem, was ich beschreibe: Das ist nicht so, dass man eine KI loslaufen l\u00e4sst und am Ende fertigen Code einsammelt. Man muss Strukturen betreuen, Ergebnisse pr\u00fcfen, Prozesse verbessern.<\/p>\n\n\n\n Negativ formuliert k\u00f6nnte man das \u201eBabysitten” nennen. Ich formuliere es lieber so: Man arbeitet einen sehr guten, aber manchmal zerstreuten Mitarbeiter ein. Und man baut dabei Strukturen auf, die nicht nur der KI helfen, sondern dem gesamten Projekt 😁.<\/p>\n\n\n\n Das Ergebnis war f\u00fcr mich: hochqualitative Strukturen, die vorher nicht existierten. Projekte, die nicht nur funktionieren, sondern wartbar, testbar und nachvollziehbar sind. F\u00fcr die KI \u2013 und f\u00fcr jeden Menschen, der nach mir kommt.<\/p>\n<\/div><\/div>\n\n\n\n Dies ist Teil 2 einer dreiteiligen Serie \u00fcber KI-gest\u00fctzte Softwareentwicklung in der Praxis. In Teil 3 geht es um die praktische Implementierung: Wie REST-Schnittstellen, Selbstdiagnose-Patterns und MCP-Integration die Br\u00fccke zwischen KI und laufender Software schlagen.<\/em><\/p>\n","protected":false},"excerpt":{"rendered":" Als ich vor Jahren mein Startup leitete, war ich nebenbei Qualit\u00e4tsmanagementbeauftragter. Ich habe ISO 9001-Audits durchgef\u00fchrt, Prozessbeschreibungen geschrieben, PDCA-Kreisl\u00e4ufe durchlaufen. Damals fand ich das teilweise l\u00e4stig. Teilweise cool, weil es in der Firma Prozesse erzwang – und jeder wusste, dass selbst wenn man Jan \u00fcberredete, es die ISO9001 trotzdem geben w\u00fcrde 🤣. Heute bin ich … <\/p>\nISO 9001-Denkweise auf KI-Arbeit \u00fcbertragen<\/h2>\n\n\n\n
![\"\"](\"https:\/\/brinkhaus-gmbh.de\/wp-content\/uploads\/2026\/02\/ChatGPT-Image-Feb-9-2026-05_13_01-PM-1024x683.png\")
<\/figure>Warum \u201eTests sind gr\u00fcn” nicht reicht<\/h2>\n\n\n\n
Strukturen beschreiben lassen<\/h2>\n\n\n\n
Der Standard \u00fcber alle Projekte<\/h2>\n\n\n\n
![\"\"](\"https:\/\/brinkhaus-gmbh.de\/wp-content\/uploads\/2026\/02\/ChatGPT-Image-Feb-9-2026-05_14_38-PM-1024x683.png\")
<\/figure>Kein Babysitten, sondern Einarbeitung<\/h2>\n\n\n\n
\n\n\n\n