Ich experimentiere in letzter Zeit mit allen möglichen Modellen - von "Frontier", oder sollte ich sagen verboten (hallo, fable-5!), bis "billig". Eine Beobachtung: Wenn AI-Coding-Tools sich danebenbenehmen, ist die Ursache fast nie das Modell selbst. Es ist der Wrapper um das Modell herum. Das Harness vermurkst Edit-Operationen. Prompts werden mitten in der Session mutiert. Die Kontextmenge ist zu gering und beeinflusst das LLM auf Arten, die nie beabsichtigt waren (je "billiger" das Modell, desto spezifischer muss der Kontext sein). Das Modell ist in Ordnung. Die Rohrleitung ist kaputt.
Du warst vermutlich schon in dem entsprechenden Organisationsmeeting. Ein Team performt unter Erwartung, eine Initiative kommt nicht voran, ein Experiment scheitert. Die Diagnose landet bei den Menschen. Es fehlte an Antrieb. Es fehlte an Skill. Sie waren der falsche Fit.
Die Diagnose ist fast nie die Rohrleitung. Die Berichtsstruktur, die das Signal verzögert hat. Das Fehlen erreichbarer Ziele. Die gehetzten Beta-Features, die Kunden enttäuscht haben. Die Roadmap, die sich dreimal geändert hat. Der Decision-Rights-Graph, der es zu niemandes Aufgabe gemacht hat zurückzudrücken. Die Senior-Führungskraft, die dreimal mit "Vorschlägen" reingegrätscht ist, die sich verpflichtend anfühlten und nie auf Skrutiny trafen. Die Übergaben, bei denen an jedem Schritt die Hälfte des Kontexts verloren ging.
Das "Modell" ist in Ordnung. Das "Harness" ist kaputt.
Engineers lernen das schneller als Organisationsmenschen, teils weil Engineers ein Harness austauschen, das Kontextlevel anpassen und in Echtzeit zusehen können, wie sich der AI-Coding-Output verbessert. Organisationen bekommen diese Feedback-Schleife selten. Deshalb landet die Diagnose immer wieder bei den Menschen, und die kaputte Rohrleitung überlebt jeden Postmortem.
Gedanken dazu? Findet mich auf Bluesky.