Aider: un agente di sviluppo in CLI

#Che cos'è Aider e cosa fa nel tuo repository

Aider è un assistente di programmazione da riga di comando, open source, che si presenta come uno strumento per programmare in coppia con un'IA nel terminale. Lanci il comando aider in un repository Git, descrivi una modifica in linguaggio naturale e Aider propone modifiche ai file, le applica e poi le registra in un commit. Funziona sia con modelli ospitati (Claude, GPT, DeepSeek) sia con modelli locali serviti da Ollama o LM Studio, il che lo rende uno dei pochi agenti di programmazione utilizzabili senza che una sola riga del tuo progetto lasci la macchina. Il repository ufficiale supera le 49.000 stelle su GitHub.

Tre cose lo distinguono da una semplice chat. Innanzitutto, mantiene una mappa del repository: a ogni richiesta, invia al modello un elenco dei file con le loro classi, funzioni e firme principali, in modo che il modello sappia dove cercare senza che tu gli mostri tutto. Inoltre, è integrato con Git: ogni modifica diventa un commit annullabile. Infine, esegue ripetutamente i comandi che gli fornisci, come linter e test, e cerca di correggere ciò che fallisce. Non è un agente autonomo che esplora il web o avvia server: è un editor di codice guidato dalla conversazione.

#Installa Aider

Il metodo ufficiale più breve passa per il pacchetto aider-install, che installa Aider nel proprio ambiente Python isolato e, se necessario, scarica una versione compatibile di Python. Per questa procedura è richiesta una versione di Python compresa tra 3.8 e 3.13. Sono disponibili installatori basati su uv, eseguibili con una sola riga di comando, per macOS, Linux e Windows. La vecchia procedura con pipx funziona ancora, ma la documentazione attuale raccomanda aider-install.

python -m pip install aider-install
aider-install

# Vérifier
aider --version

Spostati quindi nella directory radice del tuo progetto. Se la cartella non è un repository Git, Aider propone di crearne uno, ma è meglio inizializzarlo tu stesso: tutta la rete di sicurezza descritta più avanti si basa su Git.

#Collegarlo a Ollama senza cadere nelle trappole del contesto

La documentazione ufficiale di Aider per Ollama si riassume in quattro passaggi: definire la variabile OLLAMA_API_BASE (l'indirizzo abituale è http://127.0.0.1:11434), scaricare il modello con ollama pull, avviare il server, poi lanciare aider con il prefisso ollama_chat/ davanti al nome del modello. Il prefisso ollama_chat/ è esplicitamente consigliato al posto di ollama/.

export OLLAMA_API_BASE=http://127.0.0.1:11434
ollama pull devstral:24b
OLLAMA_CONTEXT_LENGTH=8192 ollama serve

# Dans un autre terminal, à la racine du projet
aider --model ollama_chat/devstral:24b

L'insidia più costosa è la finestra di contesto. Ollama utilizza per impostazione predefinita 2.000 token di contesto, una quantità minuscola per un agente di programmazione, e, aspetto decisivo, scarta silenziosamente ciò che supera questo limite. Senza saperlo, puoi quindi parlare a un modello che ha ricevuto solo l'inizio dei tuoi file. Aider limita il problema: per impostazione predefinita, regola autonomamente la finestra di Ollama in base alla dimensione di ogni richiesta, più 8.000 token per la risposta. Se preferisci una dimensione fissa, devi usare un file di impostazioni del modello, non il file di configurazione principale.

- name: ollama_chat/devstral:24b
  extra_params:
    num_ctx: 32768

Il contesto ha un costo in termini di memoria: la cache KV cresce con la finestra e un modello da 24 miliardi di parametri che occupa già circa 14 GB in Q4 lascia poco margine su una scheda da 16 GB. La guida sulla finestra di contesto e quella sulla quantizzazione della cache KV forniscono gli ordini di grandezza.

#Quale modello locale per Aider

La qualità di Aider dipende da quella del modello che lo pilota, e la difficoltà è duplice: il modello deve ragionare sul codice e rispettare un formato di modifica rigoroso. Un modello che non segue questo formato produce modifiche che lo strumento non sa applicare. La classifica pubblica di Aider, basata su 225 esercizi Exercism in sei linguaggi, misura proprio questa duplice capacità; è dominata da modelli ospitati di dimensioni molto grandi, e i modelli che trovano spazio su un computer personale vi occupano posizioni sensibilmente inferiori. Consultala prima di aspettarti un risultato di livello cloud.

Per una postazione locale, Devstral 24B, pubblicato da Mistral AI e All Hands AI, è un punto di partenza sensato: è progettato per gli agenti di programmazione, occupa 14 GB nella libreria Ollama e dichiara una finestra di contesto di 128.000 token. Su una GPU da 12 GB o meno, bisogna passare a un modello più piccolo e accettare più errori di formato. La guida «Migliore LLM locale per programmare» confronta i candidati attuali; questa guida non fissa alcuna classifica, perché cambia troppo rapidamente.

#Un primo cambiamento, dal prompt al commit

1. 01
   Aggiungere i file giusti

   Avvia aider passandogli i file da modificare, ad esempio aider src/api.py src/models.py. I file aggiunti sono quelli che può modificare; il resto del repository gli è noto attraverso la mappa.
2. 02
   Descrivere il cambiamento in modo preciso

   Scrivi una richiesta completa: «Aggiungi un endpoint GET /users/:id che restituisca l'utente, o un errore 404 se non esiste». Una richiesta vaga produce un diff vago.
3. 03
   Rileggere il diff

   Aider mostra le modifiche e le applica. Guardale con /diff prima di procedere: è il momento di rifiutare, non dopo tre richieste aggiuntive.
4. 04
   Verificare il commit

   Ogni modifica viene registrata con un messaggio descrittivo. Se il risultato non è soddisfacente, /undo annulla l'ultimo commit effettuato da Aider.
5. 05
   Procedere per piccoli passi

   Chiedi poi i test, la gestione del caso limite e il logging, un passo alla volta. I piccoli passi mantengono il contesto breve e il diff leggibile.

#I comandi di chat che contano

Aider offre decine di comandi che iniziano con una barra obliqua; ne bastano pochi per lavorare. La regola generale: ciò che non hai aggiunto alla chat non può essere modificato, ma la mappa del repository permette al modello di sapere che esistono altri file.

/add et /drop

Aggiungono o rimuovono file dalla chat. Rimuovere i file diventati inutili libera spazio nel contesto, cosa molto importante con un modello locale.

/read-only

Aggiunge un file solo come riferimento: il modello lo legge senza poterlo modificare. Utile per un file di convenzioni o un contratto di interfaccia.

/ask, /code, /architect

Cambiano la modalità di chat, per un singolo messaggio o in modo duraturo con /chat-mode.

/run et /test

/run lance une commande shell et peut en verser la sortie dans le chat ; /test lance la commande de test et ajoute la sortie au chat si elle échoue, ce qui déclenche une correction.

/diff et /undo

/diff montre les changements depuis votre dernier message ; /undo annule le dernier commit s'il a été fait par Aider.

/tokens

Mostra il numero di token utilizzati dal contesto attuale: un controllo da fare abitualmente per capire perché un modello locale «dimentica».

/map

Mostra la mappa del repository inviata al modello.

#Le modalità di chat: code, ask, architect

Aider distingue quattro modalità di chat. La modalità code, quella predefinita, modifica i tuoi file. La modalità ask permette di discutere del codice senza mai modificarlo. La modalità architect fa lavorare due modelli: un modello architetto propone la soluzione, poi un modello editor la traduce in modifiche precise ai file. La modalità help risponde alle domande su Aider stesso. Non esiste una modalità intermedia chiamata "paired"; l'abbinamento di un modello potente e di un modello veloce si configura con le opzioni --model e --editor-model.

Il flusso consigliato dalla documentazione consiste nell'alternare /ask e /code: si discute dell'approccio in modalità ask, poi si passa in modalità code, dove un semplice «go ahead» basta per eseguire il piano concordato. È una versione più fluida della modalità architect con un solo modello. Per un modello locale di dimensioni medie, spesso è il miglior compromesso: eviti di caricare due modelli in memoria e mantieni il controllo sul piano.

La modalità architect è giustificata per i modelli che ragionano bene ma modificano male il codice. Richiede due richieste invece di una: attivala solo se la modalità code genera regolarmente diff non validi.

#Git, la tua rete di sicurezza

Aider si basa su Git per rendere ogni errore reversibile. A ogni modifica, crea un commit dei cambiamenti con un messaggio descrittivo, generato dal modello debole a partire dal diff e dalla conversazione, nello stile dei commit convenzionali. Prima di intervenire su un file con modifiche non ancora incluse in un commit, crea un commit delle modifiche già presenti: il tuo lavoro e quello dell'IA rimangono separati nella cronologia. I commit che crea riportano la dicitura «(aider)» nel nome dell'autore, il che permette di ritrovarli.

Ne derivano molti piccoli commit. La buona pratica consiste nel far lavorare Aider su un branch dedicato, rivedere le modifiche e poi accorpare i commit prima del merge. Due opzioni meritano di essere conosciute: --no-auto-commits disattiva la creazione automatica dei commit e --git-commit-verify riattiva gli hook pre-commit, che lo strumento aggira per impostazione predefinita con --no-verify. Se il tuo team si affida a questi hook, questa opzione cambia tutto.

git switch -c ai/endpoint-users
aider src/api.py
# ... relire, tester, puis :
git rebase -i main

#Eseguire i tuoi test nel ciclo di lavoro

È l'impostazione che trasforma Aider da un generatore di codice in uno strumento che si corregge. Con --test-cmd e --auto-test, esegue la tua suite di test dopo ogni modifica; se il comando restituisce un codice di uscita non nullo, legge l'output e tenta di correggere il problema. Il principio è lo stesso per il linter, con --lint-cmd, e Aider esegue per impostazione predefinita il linting dei file che modifica.

aider --test-cmd "pytest -x -q" --auto-test --lint-cmd "ruff check"

Due precauzioni. Il comando di test deve essere rapido: con un modello locale, ogni ciclo richiede già diverse decine di secondi di generazione. Inoltre, deve mostrare gli errori e restituire un codice di uscita diverso da zero, altrimenti Aider crede che tutto vada bene.

#Cosa non funziona con un modello locale e come aggirare il problema

Errori nel formato delle modifiche

Il modello restituisce una modifica che lo strumento non può applicare. Passa a un modello più grande o prova la modalità architect. La documentazione di Aider dedica una pagina di risoluzione dei problemi a questi errori.

Perdita del contesto

Sintomo: il modello ignora un file che hai appena aggiunto. Causa probabile: finestra troppo piccola o contesto saturo. Risposta: /tokens, /drop dei file inutili, poi contesto più grande.

File troppo lunghi

Un file di diverse migliaia di righe satura un contesto locale. Suddividilo, oppure chiedi una modifica a una funzione specifica.

Richieste vaghe

« Migliora questo codice » genera diff imprevedibili. Indica il file, la funzione, il comportamento atteso.

Errore per superamento del limite di token

Aider segnala quando un modello supera i suoi limiti e suggerisce azioni: chiedere modifiche più piccole, dividere i file, cambiare modello.

#Aider o un agente nell'editor

Aider si rivolge a chi lavora al terminale e vuole una cronologia Git pulita. Se preferisci restare in VS Code, Cline offre un'esperienza equivalente con validazione passo dopo passo; se vuoi un agente da terminale più autonomo, OpenCode è un'opzione. La scelta non dipende dalla qualità del modello, che è la stessa, ma da dove vuoi rileggere i diff.

• Aider + Ollama: il workflow completo nel terminale
• Migliore LLM locale per programmare
• Comprendere la finestra di contesto
• Cline + Ollama in VS Code
• OpenCode + Ollama nel terminale
• Rivedere il codice con un LLM locale prima del commit

• Fonte: documentazione di Aider per Ollama
• Fonte: le modalità di chat di Aider
• Fonte: integrazione Git di Aider
• Fonte: lint e test in Aider
• Fonte: Devstral nella libreria Ollama