Manfred.Wolff IT-/KI Transformation, Agiler Coach

Ich gestehe. Anfang der 2000er habe ich bei einem Kunden abwechselnd zwei Sorten Release ausgeliefert. Das eine erfüllte alle geforderten Features und war fehlerhaft. Das nächste war in guter Qualität, dafür fehlte ein Teil des Funktionsumfangs. Und dann wieder von vorn. Das war kein Plan, den ich s

Leseprobe aus meinem Buch „Software mit KI entwickeln“. Das ist Kapitel 3, bis auf einen Querverweis unverändert. Es steht früh im Buch, weil alles Weitere daran hängt. Ich spiele Schach. Wenn ich am Brett sitze und am Zug bin, ist die wichtigste Frage nie, wie gut mein Gegner spielt. Die wichtigste

Auf LinkedIn lese ich seit Monaten dieselbe Warnung. KI-Code sei gefährlich, das Modell mache zu viele Fehler, am Ende müsse der Mensch alles kontrollieren. Im Gespräch mit erfahrenen Entwicklerinnen und Entwicklern höre ich die härtere Variante. Mit KI bekommt man nur schlechte Qualität. Beide Sätz

Gerade lese ich Posts, die erklären, dass jetzt jeder programmieren kann. Wir brauchen keine externen Entwickler mehr. Wir viben uns eine Software zusammen. Prompt rein, Code raus, fertig. Ich verstehe den Reiz. Ich nutze KI selbst täglich. Aber was da gerade passiert, kenne ich. No-Code hat dasselb

Mein claude-workflow-kit hat einen Review-Skill. Er liest den Code, bevor ich pushe. Eine Frage höre ich dazu immer wieder: Warum prüft dieser Skill nicht gleich die Sicherheit mit? Das Modell liest den Code ohnehin. Es könnte nebenbei nach Secrets und Injection-Lücken suchen. Genau das tut es nicht

Ich wollte mein Kanban-Board nachts abarbeiten lassen. 20 Issues ins Ready-Feld, ein Kommando, schlafen gehen. Der erste Versuch scheiterte nicht an der KI, sondern am Kontextfenster. 20 Issues in einer Session heißt: Issue 17 wird mit dem komprimierten Sediment von 16 Vorgängern gebaut. Irgendwann

Es gibt gerade eine Bewegung, die verspricht, den Menschen aus der Schleife zu nehmen. Das Muster ist immer gleich. Man schiebt einen Plan durch mehrere KIs, lässt sie ihn gegenseitig zerlegen, schiebt das Ergebnis wieder zurück, und am Ende soll ein Konzept stehen, das so abgesichert ist, dass niem

Meine Faustregel aus der Praxis: 80 bis 90 Prozent der typischen Entwicklungsaufgaben erledigt ein Sprachmodell heute zuverlässig, wenn die Leitplanken stimmen. Die restlichen 10 bis 20 Prozent scheitern nicht zufällig. Sie scheitern dort, wo die Trainingsdaten dünn sind. Das ist keine Vermutung, da

Ich spiele Schach. Wenn ich am Brett sitze und am Zug bin, passiert vorher eine von zwei Sachen. Von außen sehen beide gleich aus. Innen sind sie verschieden. Der Unterschied bestimmt, wann ich dem Modell die Arbeit überlassen kann. Wenn das Muster die Stellung kennt Meistens hatte ich die Stellung

Heute habe ich eine Stunde an einer Spezifikation gearbeitet. Nicht am Code. An der Spezifikation. Eine Stunde für einen Text, den am Ende niemand sieht außer mir und dem Modell. Kein Feature, keine Zeile, die läuft. Und trotzdem war es die wichtigste Stunde des Tages. Das Modell rät, und sagt es ni

Mein Workflow stand in einer Datei. Claude hat ihn trotzdem vergessen. Die Claude-Workflow.md beschreibt meinen 9-Schritte-Prozess für KI-gestützte Softwareentwicklung, sauber und vollständig. Am Anfang einer Session lief alles nach Plan. Zwei Stunden später fehlten plötzlich Schritte. Der Plan-Modu

Ich habe mein Werkzeug in wenigen Wochen fünfmal umgebaut. Fünfmal am selben Ding klingt nach fehlender Planung. Ich halte jeden dieser fünf Umbauten für richtig. Der Grund ist einfach. Jeder Umbau hatte einen konkreten Anlass. Keiner war auf Vorrat gebaut. In der klassischen Welt wäre das ein Warns