Penso sempre di più che il limite di abilità per l'ingegneria assistita da LLM sia probabilmente alto quanto quello per l'ingegneria in generale. (È certamente più profondo rispetto a, ad esempio, Excel, e ci sono OOM in competenza Excel.)

Il "skill cap" è un termine da videogioco. Cattura l'intuizione che ci sono alcuni giochi in cui la differenza tra il miglior giocatore e il peggior giocatore è marginale, come nel gioco del tris, e altri in cui questo è molto falso e si può studiare il gioco per una vita intera migliorando continuamente (poker, go).

Questo non è semplicemente a livello di micro meccanica o ingegneria dei prompt o ingegneria del contesto. Ci sono interi modi di lavorare che si basano su ciò che il LLM fa meglio, e la quantità di tempo che puoi dedicare a questi non è fissa in tutte le sessioni o progetti.

E quindi, dato che hai il controllo o l'influenza sull'interezza del sistema, hai delle metadecisoni da prendere su "Voglio che questo sistema abbia più sottocomponenti del tipo che i LLM semplicemente *elaborano*? O dovrei fare altre architetture o scelte simili?"

E sì, siamo a anni di distanza dal capire come appare il ciclo di manutenzione per i sottosistemi forniti da LLM, ma il buon senso suggerisce probabilmente che "un umano potrebbe essere consapevole in un senso generale che sta accadendo."

Comunque, queste cose sono molto, molto divertenti e mi trovo in un posto strano dove desidero che le vacanze finiscano così posso scrivere codice gratuitamente.

(Come una delle molteplici adattamenti a questo stile, beneficia di blocchi di tempo ininterrotti di diverse ore perché gli agenti prosperano nel contesto e i primi minuti di una sessione sono difficili. Questo è difficile da realizzare dal tavolo della cucina a casa dei suoceri.)