Ik denk steeds meer dat de vaardigheidsgrens voor LLM-ondersteunde engineering waarschijnlijk net zo hoog is als voor engineering in het algemeen. (Het is zeker dieper dan bijvoorbeeld Excel, en er zijn OOMs in Excel-vaardigheid.)

Skill cap is een gamerisme. Het vangt de intuïtie dat er sommige spellen zijn waar het verschil tussen de beste speler en de slechtste speler marginaal is, zoals tic tac toe, en andere waar dit helemaal niet waar is en men het spel een leven lang kan bestuderen terwijl men voortdurend verbetert (poker, go).

Dit is niet alleen op het niveau van de micro-mechanica of prompt-engineering of context-engineering. Er zijn hele werkmodi die leunen op wat de LLM het beste doet, en de hoeveelheid tijd die je eraan kunt besteden is niet vastgelegd voor alle sessies of projecten.

En dus, gezien het feit dat je controle of invloed hebt over de totaliteit van het systeem, heb je metadecisions te maken over "Moet ik willen dat dit systeem meer subcomponenten heeft van het soort dat LLM's gewoon *doorwerken*? Of moet ik andere architectuur of vergelijkbare keuzes maken?"

En ja, we zijn jaren verwijderd van het leren hoe de onderhoudscyclus eruitziet voor LLM-geleverde subsystemen, maar het slimme geld is waarschijnlijk "Een mens kan zich in algemene zin bewust zijn dat het gebeurt."

Hoe dan ook, dit spul is heel, heel leuk en ik bevind me in een vreemde situatie waarin ik wens dat de vakantie voorbij was, zodat ik gratis code kon schrijven.

(Als een van de vele aanpassingen aan deze stijl profiteert het van meerdaagse blokken van ononderbroken tijd omdat de agenten gedijen op context en de eerste paar minuten van een sessie slecht zijn. Dit is moeilijk te leveren vanaf de keukentafel bij de schoonfamilie.)