Ich denke zunehmend, dass die Fähigkeiten, die für die Ingenieurarbeit mit LLM-Unterstützung erforderlich sind, wahrscheinlich genauso hoch sind wie für das Ingenieurwesen im Allgemeinen. (Es ist sicherlich tiefer als z.B. Excel, und es gibt große Unterschiede in der Excel-Kompetenz.)

Der Skill-Cap ist ein Gamer-Begriff. Er erfasst die Intuition, dass es einige Spiele gibt, bei denen der Unterschied zwischen dem besten und dem schlechtesten Spieler marginal ist, wie bei Tic Tac Toe, und andere, bei denen dies ganz und gar nicht zutrifft und man das Spiel ein Leben lang studieren kann, während man sich kontinuierlich verbessert (Poker, Go).

Das ist nicht nur auf der Ebene der Mikromechanik oder der Prompt-Engineering oder des Kontext-Engineering. Es gibt ganze Arbeitsweisen, die sich darauf stützen, was das LLM am besten kann, und die Zeit, die Sie dafür aufwenden können, ist nicht in allen Sitzungen oder Projekten festgelegt.

Und da Sie die Kontrolle oder den Einfluss über die Gesamtheit des Systems haben, müssen Sie Metabeschlüsse fassen über: "Sollte ich wollen, dass dieses System mehr Unterkomponenten der Art hat, die LLMs einfach *durchlaufen*? Oder sollte ich andere Architekturen oder ähnliche Entscheidungen treffen?"

Und ja, wir sind Jahre davon entfernt zu lernen, wie der Wartungszyklus für von LLM gelieferten Teilsysteme aussieht, aber das kluge Geld setzt wahrscheinlich darauf, dass "Ein Mensch sich im Allgemeinen bewusst sein kann, dass es passiert."

Wie auch immer, das Zeug macht sehr, sehr viel Spaß und ich befinde mich an einem seltsamen Ort, an dem ich mir wünsche, der Urlaub wäre vorbei, damit ich kostenlos Code schreiben könnte.

(Als eine der vielen Anpassungen an diesen Stil profitiert es von mehrstündigen Blöcken ununterbrochener Zeit, da die Agenten auf Kontext angewiesen sind und die ersten Minuten einer Sitzung schwierig sind. Das ist schwer vom Küchentisch bei den Schwiegereltern zu liefern.)