Developer Tools

Chiedi a un modello di rispondere in JSON e nella maggior parte dei casi json.loads() funziona senza problemi. I casi che ti costano una sessione di debug sono altri: un commento su una riga dentro l’oggetto, un code fence markdown che lo avvolge, una chiave scritta userEmail quando il tuo codice si aspetta user_email. Un prompt più rigido (“rispondi SOLO con l’oggetto JSON, nessun altro testo”) rende questi casi più rari. Non li rende impossibili, perché il modello può comunque ignorare la richiesta. Con l’output strutturato la richiesta diventa superflua: passi all’API un JSON Schema, che vincola il campionamento dei token del modello così che la risposta debba rispettarlo. ...

Salvi un file, Prettier lo riformatta, ed ESLint segnala subito un errore sulla riga che Prettier ha appena toccato. Entrambi gli strumenti sono configurati, entrambi sono attivi, e invece di aiutarti si combattono a vicenda. I due strumenti fanno lavori diversi. Il problema è che hanno entrambi un’opinione su una cosa sola: come deve apparire il codice sulla pagina. Cosa controlla davvero ESLint ESLint analizza il codice in un albero di sintassi astratto e applica regole sulla sua struttura. Il suo contributo più utile sono le regole che individuano bug reali: una variabile mai definita, un return irraggiungibile dopo un altro return, un import rimasto inutilizzato dopo un refactoring, una chiave duplicata in un oggetto che sovrascrive la prima in silenzio. Sono controlli semantici: ESLint legge cosa fa il codice. ...

Perché “sembra giusto” non è un test per un prompt Stringi il testo di un prompt che instrada i ticket, lo provi sui tre esempi che hai aperti nel tuo notebook e lo metti in produzione. Una settimana dopo, i reclami di fatturazione che prima finivano nella coda giusta cominciano a finire in “domanda”. Non i tre casi che hai controllato: gli altri quattrocento che non hai controllato. Niente va in crash. Non c’è nessuno stack trace. Il prompt, letto ad alta voce, suona ancora bene. ...

Cosa fa davvero il function calling negli LLM Chiedi a un modello “che tempo fa ad Austin in questo momento” senza nessuna connessione con il mondo esterno, e hai due opzioni: dire che non lo sa, o inventare qualcosa. Il function calling offre una terza opzione. Il modello descrive cosa gli serve, passa quella descrizione al tuo codice e aspetta una risposta vera prima di rispondere. Il nome è un po’ fuorviante. Il modello non chiama niente. Emette un blocco di dati strutturati che dice quale tool vuole e con quali argomenti, e la tua applicazione decide se eseguirlo e cosa fare con il risultato. “Tool use” è il termine più accurato, ed è quello usato nella documentazione di Anthropic; OpenAI e Google parlano quasi sempre di function calling. Il meccanismo è lo stesso sotto entrambi i nomi. Il modello produce solo una richiesta, mai l’effetto collaterale. ...

Lancia npm install su un progetto, poi pnpm install sullo stesso package.json: ottieni due alberi node_modules diversi e due lockfile diversi. Aggiungi un collega che usa Yarn e il repository finisce con tre lockfile nella sua storia, ognuno con un albero delle dipendenze leggermente diverso. Tutti e tre leggono lo stesso package.json e scaricano dal medesimo registro npm. Il punto su cui i tre non sono d’accordo è cosa scrivere su disco. ...

Cosa fa davvero un decoratore alla tua funzione Vuoi misurare il tempo di ogni funzione che chiama un’API esterna lenta. Puoi incollare chiamate a time.perf_counter() in ognuna, oppure scrivere la misurazione una sola volta e applicarla ovunque. Un decoratore è la seconda opzione: è una funzione che prende un’altra funzione, la avvolge in un comportamento aggiuntivo e restituisce la versione avvolta con lo stesso nome originale. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 import time def timed(func): def wrapper(*args, **kwargs): start = time.perf_counter() result = func(*args, **kwargs) elapsed = time.perf_counter() - start print(f"{func.__name__} took {elapsed:.3f}s") return result return wrapper @timed def fetch_price(ticker): time.sleep(0.2) # al posto di una chiamata di rete return 142.50 fetch_price("AAPL") # fetch_price took 0.201s @timed sopra def fetch_price è l’abbreviazione di fetch_price = timed(fetch_price). Python chiama timed una sola volta, subito dopo la definizione di fetch_price, e ricollega il nome fetch_price a quello che timed restituisce. Tutto quello che fa la @ è questo. ...

Installa due progetti Python sulla stessa macchina e il secondo può rompere il primo. Uno richiede requests==2.28, l’altro requests==2.32, e pip ha un’unica cartella site-packages di sistema in cui scrivere. L’ultima installazione vince, in silenzio. Te ne accorgi quando l’altro progetto comincia a lanciare errori che non hanno nulla a che fare con il codice che hai appena modificato. Un ambiente virtuale dà a ogni progetto il proprio site-packages. Il venv non tocca nulla a livello globale, e due progetti possono dipendere da versioni incompatibili della stessa libreria senza che nessuno dei due se ne accorga. ...

Cosa distingue un agente CLI di coding da un altro Chiedi a un agente CLI di coding di sistemare un test che fallisce e non ti risponderà con un suggerimento. Legge l’output del test, apre il file, modifica una riga, rilancia il test e ti riporta il risultato una volta che passa. Quel ciclo è il prodotto, non la finestra di chat. Il modello dentro il ciclo si prende la maggior parte dell’attenzione, ed è anche la parte che cambia più in fretta: i vendor ne inseriscono di nuovi ogni pochi mesi, e diversi agenti ti lasciano scegliere quale usare. Quello che resta fermo è l’harness costruito attorno al modello — quali tool può raggiungere, come gestisce il contesto, cosa può eseguire senza chiedere, e dove girano quei comandi. Due agenti con lo stesso modello possono comportarsi in modo molto diverso per questo motivo. L’harness è ciò che stai davvero scegliendo. ...