Ti sei mai domandato come funziona un coding agent? Cioè, come fa a fare quello che fa? Come fa un language model a scrivere codice?

In questa serie di messaggi esploriamo un po’ alla volta l’archietettura generale di un coding agent per capire come funziona e come fa a fare quello che fa.

In linea generale un coding agent è un’architettura (e tutti i maggiori produttori + la community indipendente stanno lottando per trovare la migliore) che si compone di moduli che ormai stanno prendendo forma e si stanno standardizzando il cui scopo è quello di integrare un language model (LLM) con strumenti che gli permettono di interagire con il mondo esterno, in questo caso con un ambiente di sviluppo.

Il capostipite è stato Claude Code, ma oggi abbiamo decine e decine di implemetazioni.

Cos’hanno in comune?

A grandi linee questi componenti:

  • Un language model (LLM) che è il cervello del coding agent che genera il codice e prende le decisioni.
  • Un tool registry: un catalogo di strumenti che il coding agent può utilizzare per interagire con l’ambiente (lettura/scrittura di file, cercare nel web, eseguire comandi…)
  • Un context manager: un modulo che gestisce il contesto che il language model ha a disposizione e può “vedere”
  • Guardrail: una serie di funzionalità che servono a limitare o interromperei comportamenti indesiderati (quando il modello svalvola)
  • Un agent loop: un ciclo “while true” che chiama il modello finché ci sono chiamate di tool da fare o finché non si raggiunge un obiettivo.
  • Permessi: un modulo che registra i permessi che l’utente ha concesso al sistema di poter utilizzare certi strumenti o accedere a certe risorse (es.: scrittura ai file negata, accesso in sola lettura)

Perché capire come funziona un coding agent?

Perché in questo modo siamo più consapevoli di cosa stiamo usando, dei limiti e delle potenzialità.