# klaassen-teach-ai-think-senior-engineer-every-2025-11-07

## Veille

8 strategie di planning con l'IA - Agenti di ricerca paralleli - Grounding sul codebase - Cronologia Git - Vibe prototyping - Agenti di stile - Compounding engineering - Every Source Code - Kieran Klaassen

## Titre Article

Teach Your AI to Think Like a Senior Engineer

## Date

2025-11-07

## URL

https://every.to/source-code/teach-your-ai-think-like-a-senior-engineer

## Keywords

strategie di planning, agenti di ricerca, operazioni parallele, email bankruptcy di Cora, riprodurre e documentare, grounding sulle best practice, grounding sul codebase, grounding sulle librerie, cronologia git, vibe prototyping, sintesi con opzioni, agenti di revisione dello stile, compounding engineering, memoria istituzionale, CLAUDE.md, base di conoscenza docs, log AppSignal, gem RubyLLM, EmailClassifier, event tracking, revisori specializzati, SDLC, ciclo di vita del software, SDLC agentico

## Authors

Kieran Klaassen (General Manager, Cora)

## Ton

**Profilo:** Tutorial per praticanti avanzati | In prima persona da praticante | Prescrittivo-sistematico | Esperto

Klaassen adotta la voce di un praticante esperto che condivide un playbook tattico concreto, facendo seguito al suo precedente articolo, più filosofico. La struttura in 8 strategie (riprodurre → best practice → codebase → librerie → git → vibe → sintesi → revisione) dimostra il pensiero sistematico tipico di un ingegnere senior. Il linguaggio tecnico da ingegnere sul campo (log di AppSignal, la gem RubyLLM, helper method, denormalizzazione, pull request), fondato su esempi di produzione tratti da Cora, costruisce credibilità. Il tono sicuro e prescrittivo ("Puoi evitare di costruire la cosa sbagliata, anche tu") riflette la padronanza dell'argomento. I link diretti a GitHub e il sistema di planning reso open-source mostrano un impegno nella condivisione aperta della conoscenza. L'enfasi su "come renderlo compounding" dopo ogni strategia rafforza la tesi centrale dell'accumulo di conoscenza. Tipico dei tutorial avanzati di Source Code di Every (Klaassen, i pezzi tecnici di Dan Shipper), rivolti a praticanti pronti a implementare immediatamente più che alla comprensione concettuale.

## Pense-betes

- **Seguito dell'articolo precedente**: Stop Coding and Start Planning (2025-11-06)
- **Tesi centrale**: le operazioni di ricerca parallele insegnano all'IA il tuo modo di pensare più rapidamente del planning umano sequenziale
- **8 strategie di planning** per livello di fidelity (One: correzioni rapide, Two: scope chiaro, Three: requisiti incerti) **Strategia 1: Riprodurre e documentare**
- Fidelity: One & Two, correzioni di bug
- Ruolo dell'agente: guida di riproduzione passo dopo passo
- Esempio Cora: 19 utenti bloccati per email bankruptcy, i log di AppSignal hanno rivelato errori di rate limit soppressi, fallimenti silenziosi
- Compounding: checklist @kieran-rails-reviewer aggiornata — "job in background che chiamano API esterne: i rate limit sono gestiti?" **Strategia 2: Fondarsi sulle best practice**
- Fidelity: tutte, specialmente per pattern non familiari
- Agente: @agent-best-practices-researcher
- Casi d'uso: architettura tecnica, copywriting, ricerca sui prezzi, percorsi di upgrade
- Esempio: una gem indietro di 2 versioni; l'agente ha trovato la guida ufficiale + 3 post di blog con casi limite; 3 minuti di ricerca hanno evitato ore di debugging
- Compounding: i risultati vengono salvati in docs/*.md (pay-gem-upgrades.md, pricing-research.md); l'agente controlla la documentazione locale prima del web **Strategia 3: Fondarsi sul tuo codebase**
- Fidelity: qualsiasi cosa a rischio di duplicare una funzionalità esistente
- Ruolo dell'agente: cercare nel codice esistente implementazioni correlate
- Esempio: funzionalità di event tracking; l'agente ha trovato un sistema di tracking esistente dimenticato, con helper method
- Compounding: creazione di un agente @event-tracking-expert che distilla tutti i pattern di tracking, eseguito automaticamente sulle funzionalità pertinenti **Strategia 4: Fondarsi sulle tue librerie**
- Fidelity: librerie in rapida evoluzione o poco documentate
- Ruolo dell'agente: analizzare il codice sorgente per comprenderne le capacità
- Esempio: la gem RubyLLM evolve costantemente, la documentazione è in ritardo; l'agente ha letto il sorgente e trovato il supporto streaming non documentato della v1.9
- Compounding: la conoscenza si aggiorna automaticamente a ogni aggiornamento di dipendenza, mai informazioni obsolete **Strategia 5: Studiare la cronologia git**
- Fidelity: refactor, prosecuzione di lavoro passato, comprensione del "perché"
- Ruolo dell'agente: ricercare le decisioni passate e il loro contesto
- Esempio: EmailClassifier v1 vs. v2; l'agente ha trovato una PR vecchia di 3 mesi che mostrava come il passaggio alla v2 fosse stato tentato, avesse rotto dei casi limite, e fosse stato deliberatamente ripristinato
- Compounding: memoria istituzionale preservata e ricercabile, i nuovi membri del team ereditano il ragionamento **Strategia 6: Vibe prototype per chiarire**
- Fidelity: Three, incertezza UX, esplorativo
- Ruolo dell'agente: costruire rapidamente versioni usa e getta con cui interagire
- Esempio: ridisegno dell'interfaccia Brief, 5 prototipi da 5 minuti ciascuno, feedback utente "pulsante archivia in alto a sinistra — riflesso ereditato da Gmail"
- Compounding: il vibe coding trasforma l'incertezza in specifiche concrete, le reazioni degli utenti vengono documentate **Strategia 7: Sintetizzare con opzioni**
- Fidelity: fine della fase di ricerca prima dell'implementazione
- Ruolo dell'agente: presentare 2-3 percorsi di soluzione con pro/contro onesti
- Esempio: sincronizzazione della inbox Gmail, 3 opzioni (innesto sull'esistente / tempo reale / cache mirror), tradeoff (veloce ma disordinato / pulito ma lento / sforzo iniziale ma migliore nel lungo termine)
- Compounding: la scelta rivela preferenze ("preferisco ciò che è ampiamente supportato rispetto a ciò che è all'avanguardia"), codificate per decisioni future simili **Strategia 8: Revisione con agenti di stile**
- Fidelity: ultimo passaggio di planning prima dell'implementazione
- Ruolo dell'agente: rilevare disallineamenti con lo stile del codice e l'architettura
- Tre agenti di revisione:
- Semplificazione: segnala l'over-engineering
- Sicurezza: verifica le vulnerabilità
- Style-Kieran: preferenze personali (query semplici vs. join complessi, denormalizzazione)
- Compounding: gli agenti accumulano gusto nel tempo, ogni "non mi piace questo" rende il sistema più intelligente **Guida pratica per iniziare**:
- Scegliere una funzionalità Fidelity Two (multi-file, scope chiaro)
- 15-20 minuti di ricerca: best practice (web), pattern (codebase), capacità delle librerie (docs/sorgente)
- Lasciare che l'IA sintetizzi: problema (1 frase), 2-3 approcci (pro/contro), confronto con pattern esistenti, casi limite/sicurezza
- Catturare le proprie reazioni di revisione: annotare "troppo complesso" o "modo migliore" — scrivere il PERCHÉ
- Rilasciare la funzionalità, confrontare l'implementazione con il piano, annotare le divergenze
- Codificare 1 apprendimento: aggiungerlo a CLAUDE.md ("Quando X, verificare Y" o "Preferire A a B perché C")
- Creare agenti specializzati: Event Tracking Expert, Security Checker
- Ripetere: la settimana successiva, fare riferimento agli appunti; il secondo piano è migliore del primo **Open source**: marketplace GitHub di Every, comando /plan + agenti di ricerca pronti all'uso

## RésuméDe400mots

Kieran Klaassen presenta 8 strategie concrete che trasformano una filosofia di planning in sistemi operativi per insegnare all'IA a ragionare come un ingegnere senior. In seguito al suo precedente articolo su planning vs. vibe coding, questa guida tattica descrive in dettaglio come condurre operazioni di ricerca parallele più rapide del planning umano sequenziale.

**Framework in 8 strategie**

**1. Riprodurre e documentare**: prima di correggere un bug, riprodurlo e documentarlo. Esempio della email bankruptcy di Cora: 19 utenti bloccati; l'agente ha esaminato i log di AppSignal → errori di rate limit venivano soppressi silenziosamente. Niente più congetture. Compounding: aggiornamento permanente della checklist @kieran-rails-reviewer.

**2. Fondarsi sulle best practice**: @agent-best-practices-researcher cerca sul web come altri hanno risolto il problema. Casi d'uso: architettura, copywriting, pricing, upgrade. Una gem indietro di 2 versioni: 3 minuti di ricerca hanno trovato la guida ufficiale + 3 post di blog sui casi limite, evitando ore di debugging. Compounding: i risultati vengono salvati in docs/*.md, l'agente controlla prima la documentazione locale.

**3. Fondarsi sul codebase**: cercare pattern esistenti prima di ricrearli. Funzionalità di event tracking: l'agente ha trovato un sistema esistente dimenticato con i relativi helper method, evitando la costruzione di un secondo sistema incompatibile. Compounding: l'agente @event-tracking-expert distilla tutti i pattern e viene eseguito automaticamente.

**4. Fondarsi sulle librerie**: per librerie in rapida evoluzione e poco documentate, leggere il codice sorgente. Gem RubyLLM: l'agente ha scoperto il supporto streaming della v1.9, non documentato ma presente nella test suite. Compounding: aggiornamento automatico a ogni bump di versione della dipendenza.

**5. Studiare la cronologia git**: comprendere il "perché" dietro le decisioni passate. Upgrade di EmailClassifier: l'agente ha trovato una PR vecchia di 3 mesi che mostrava come la v2 fosse già stata tentata, avesse rotto dei casi limite (archivio→posta in arrivo e posta in arrivo→archivio invertiti) e fosse stata deliberatamente ripristinata con un ragionamento dettagliato. 5 minuti di ricerca hanno evitato di reintrodurre un bug già risolto. Compounding: memoria istituzionale preservata e ricercabile.

**6. Vibe prototype per chiarire**: Fidelity Three, UX incerta. Interfaccia Brief: 5 prototipi da 5 minuti ciascuno, feedback concreto degli utenti ("pulsante archivia in alto a sinistra — riflesso da Gmail"). I prototipi vengono scartati, la conoscenza confluisce nel piano. Compounding: l'incertezza diventa specifiche concrete e documentate.

**7. Sintetizzare con opzioni**: combinare tutta la ricerca in 2-3 approcci con tradeoff onesti. Sincronizzazione della inbox Gmail: opzione A (innestare sul sistema esistente — veloce ma disordinato), B (tempo reale — pulito ma lento), C (cache mirror — sforzo iniziale ma migliore nel lungo termine). L'agente fa la ricerca, l'essere umano giudica. Compounding: le scelte rivelano preferenze codificate per decisioni future simili ("preferire ciò che è ampiamente supportato rispetto a ciò che è all'avanguardia").

**8. Revisione con agenti di stile**: 3 revisori specializzati nel passaggio finale. Agente di semplificazione (segnala l'over-engineering), agente di sicurezza (verifica le vulnerabilità), agente style-Kieran (preferenze personali: query semplici vs. join complessi, denormalizzazione). Compounding: gli agenti accumulano gusto nel tempo.

**Un caso rivelatore di email bankruptcy**: inizialmente giudicato semplice ("archiviare in blocco 53.000 email, quanto può essere difficile?"). 20 minuti di lavoro dell'agente di ricerca hanno riportato alla realtà: i rate limit di Gmail vengono raggiunti a 2.000, timeout di sistema, lunga attesa per l'utente. La funzionalità semplice è diventata una sfida architetturale di 3 giorni. Il planning ha evitato di costruire completamente la cosa sbagliata.

**Implementazione pratica**: scegliere una funzionalità Fidelity Two → 15-20 minuti di ricerca (best practice web + pattern del codebase + capacità delle librerie) → l'IA sintetizza il piano (problema/approcci/pattern/casi limite) → catturare il PERCHÉ dietro le reazioni di revisione → rilasciare → confrontare l'implementazione con il piano → codificare 1 apprendimento in CLAUDE.md → creare agenti specializzati → ripetere la settimana successiva.

**Contributo open-source**: Klaassen ha reso open-source il proprio sistema di planning sul marketplace GitHub di Every, con il comando /plan e agenti di ricerca pronti all'uso. Filosofia: non partire da zero, adattare sistemi comprovati già esistenti.

Ogni strategia include una nota "come renderlo compounding", a dimostrazione della tesi centrale: le operazioni di ricerca parallele insegnano all'IA una conoscenza istituzionale che si accumula più rapidamente del planning umano sequenziale.

## GrapheDeConnaissance

- Kieran Klaassen —a_créé→ Compound Engineering (METHODOLOGIE, 0.95)
- Kieran Klaassen —dirige→ Cora (ORGANISATION, 0.98)
- Kieran Klaassen —travaille_chez→ Every (ORGANISATION, 0.98)
- Compound Engineering —est_basé_sur→ opérations de recherche parallèles (CONCEPT, 0.95)
- opérations de recherche parallèles —remplace→ planification séquentielle humaine (CONCEPT, 0.9)
- Kieran Klaassen —utilise→ Claude Code (TECHNOLOGIE, 0.97)
- Cora —utilise→ Gmail API (TECHNOLOGIE, 0.92)
- Gmail API —mesure→ limite de débit à 2000 emails (MESURE, 0.95)
- AppSignal —permet→ diagnostic logs production (CONCEPT, 0.9)
- Cora —utilise→ RubyLLM (TECHNOLOGIE, 0.88)
- CLAUDE.md —référence→ préférences architecturales (CONCEPT, 0.92)
- git history —permet→ mémoire institutionnelle (CONCEPT, 0.9)
- vibe coding —permet→ transformation des incertitudes UX en spécifications (CONCEPT, 0.88)
- Every —publie→ planning system open-source (TECHNOLOGIE, 0.93)

---
Canonical: https://www.thekb.eu/it/fiches/klaassen-teach-ai-think-senior-engineer-every-2025-11-07/