Risolvere Problemi Complessi in Codebase Legacy

Una guida avanzata al Context Engineering per coding agents, basata sul talk di Dex su come affrontare codebase complesse ed evitare lo “slop” attraverso il workflow Research-Plan-Implement.

Introduzione

“Gli LLM sono funzioni stateless. L’unico modo per ottenere output migliori è fornire input migliori.”

Dex, esperto di agent engineering e speaker di riferimento ai conferenza AI Engineer, ha dedicato mesi a studiare come far funzionare i coding agent in contesti reali: codebase legacy, progetti Java di 10 anni, monorepo complessi.

Il punto di partenza è una ricerca di Eigor che ha analizzato 100.000 sviluppatori di ogni dimensione aziendale. I risultati erano chiari: l’AI per software engineering funziona benissimo su progetti greenfield (una dashboard Next.js nuova), ma produce “slop” e rework continuo su codebase brownfield complesse.

La promessa era: “Quando i modelli miglioreranno, funzionerà anche sulle nostre codebase legacy.” Ma Dex e il suo team hanno scoperto che non è necessario aspettare modelli migliori. Con il Context Engineering appropriato, anche i modelli attuali possono risolvere problemi complessi senza slop.

Il Problema della Context Window

Per capire il Context Engineering, bisogna prima comprendere come funzionano i Large Language Models nel contesto dei coding agents.

LLM come Funzioni Stateless

Gli LLM non hanno memoria persistente. Sono stateless: ogni volta che devono scegliere il prossimo tool da chiamare o la prossima azione da intraprendere, l’unica cosa che influenza la decisione è ciò che è presente nella conversazione fino a quel momento.

# Ogni turn dell'agent segue questo pattern:
Context Window → Model → Next Tool Call → Update Context → Model → ...

Per ogni task, possono esistere centinaia di prossimi passi corretti e centinaia di passi sbagliati. L’unico fattore che determina quale strada prenderà l’agent è la qualità del contesto.

Ottimizzare il Contesto

Il contesto deve essere ottimizzato per quattro dimensioni:

1. Correttezza - Informazioni accurate e precise
2. Completezza - Tutti i dettagli rilevanti presenti
3. Dimensione - Compatto, senza noise inutile
4. Traiettoria - Storia della conversazione che guida verso il successo

Il Problema della Traiettoria Negativa

Molti sviluppatori cadono in questo pattern:

Utente: "Implementa feature X"
Agent: [fa qualcosa di sbagliato]
Utente: "No! Questo è sbagliato, rifallo"
Agent: [fa qualcos'altro di sbagliato]
Utente: "Di nuovo sbagliato! Ascoltami!"
Agent: [continua a sbagliare]

Dal punto di vista dell’LLM, questa conversazione ha stabilito un pattern: “Faccio qualcosa, l’umano mi dice che ho sbagliato, poi faccio qualcos’altro, l’umano mi dice che ho sbagliato…”

Il token più probabile successivo in questa conversazione è: fare qualcosa di sbagliato così l’umano può dire di nuovo che ho sbagliato.

Cosa Danneggia il Contesto?

In ordine di gravità:

1. Informazioni incorrette - Il peggiore: guida l’agent nella direzione completamente sbagliata
2. Informazioni mancanti - L’agent deve fare assunzioni o riempire i gap con ipotesi
3. Troppo noise - Output verbosi, JSON densi, UUID inutili che riempiono il contesto

La Dumb Zone

Uno dei concetti più importanti del Context Engineering è quello che Dex chiama “The Dumb Zone” - un termine volutamente provocatorio per un fenomeno reale.

Come Funziona la Context Window

I modelli Claude hanno una context window di circa 200.000 token (circa 168.000 token utilizzabili per input, il resto riservato per output e processing).

Sembra molto spazio, ma si riempie sorprendentemente in fretta quando si lavora su codebase reali:

• Ricerca di file con glob e grep
• Lettura di interi file per capire come funzionano
• Output di build e test
• JSON verbosi da MCP servers
• Storia della conversazione

Il 40% è il Punto Critico

Basandosi su ricerche di Jeff Huntley e altri esperti di coding agents, emerge un pattern chiaro:

Più utilizzi la context window, peggiori diventano i risultati.

La degradazione inizia intorno al 40% della context window (circa 67k token per Claude). Oltre questa soglia, l’agent inizia a:

• Fare scelte subottimali
• Dimenticare informazioni viste prima
• Ripetere ricerche già fatte
• Chiamare tool in modo meno efficiente

┌─────────────────────────────────────────┐
│ SMART ZONE (0-40%)                      │ ← Ottime performance
│ • Tool calling preciso                  │
│ • Memoria contestuale forte             │
│ • Decisioni accurate                    │
├─────────────────────────────────────────┤
│ DUMB ZONE (40-100%)                     │ ← Performance degradate
│ • Tool calling inefficiente             │
│ • Informazioni perse                    │
│ • Decisioni subottimali                 │
└─────────────────────────────────────────┘

Il Problema degli MCP

Se si configurano troppi MCP servers che producono output verbosi (JSON densi, UUID, strutture dati complesse), si rischia di lavorare sempre nella Dumb Zone.

Ogni chiamata MCP aggiunge migliaia di token al contesto, riempendo rapidamente la finestra prima ancora di iniziare il lavoro vero e proprio.

Compaction: Evitare la Dumb Zone

La soluzione al problema della Dumb Zone è il Compaction - o come dice Dex: “Cleverly Avoiding the Dumb Zone.”

Cosa Significa Compaction?

Intentional Compaction significa prendere una conversazione esistente con l’agent e comprimerla in un file markdown conciso che cattura:

• Esattamente quali file e line numbers sono rilevanti
• La comprensione del problema
• Il contesto necessario per continuare il lavoro

# Esempio di conversazione normale (riempie il contesto):
Utente: "Come funziona l'autenticazione?"
Agent: [cerca file... legge auth.ts... legge middleware.ts... legge config.ts...]
Agent: "Ho trovato il sistema di autenticazione. Ecco cosa fa..."

# Con compaction:
Utente: [fornisce un markdown compatto]
"""
## Autenticazione
- Implementata in: src/auth/auth.ts:45-89
- Middleware: src/middleware/auth.ts:12-34
- Config: config/auth.yaml:5-15
- Pattern: JWT con refresh tokens
"""
Agent: [legge solo i file necessari, inizia subito a lavorare]

Cosa Occupa Spazio?

Durante una sessione di lavoro con un coding agent, il contesto si riempie con:

1. Ricerca di file - Output di glob, grep, find
2. Comprensione del codice - Lettura di interi file, anche quando serve solo una funzione
3. Editing - Storia delle modifiche ai file
4. Test e Build output - Spesso molto verboso
5. Tool output verboso - JSON, strutture dati, UUID

Cosa Compattare?

Un buon compaction include:

## Contesto: Feature Login Social

### File Rilevanti
- src/auth/social-login.ts:23-67 - Implementazione OAuth
- src/components/LoginButton.tsx:12-45 - UI del bottone
- tests/auth/social.test.ts - Test suite esistente

### Comprensione del Sistema
L'applicazione usa Passport.js per OAuth. La configurazione è in
`config/passport.ts`. I callback redirect a `/auth/callback/:provider`.

### Task Corrente
Aggiungere supporto per GitHub OAuth oltre a Google e Facebook esistenti.
Pattern da seguire è lo stesso di GoogleStrategy (lines 23-45).

### Testing
Eseguire: npm test -- auth/social
Build: npm run build && npm run type-check

Questo markdown sostituisce una conversazione che potrebbe aver consumato 30-40k token di ricerche, letture e discussioni.

Sub-Agents per il Context Control

Uno degli errori più comuni nell’utilizzo dei sub-agent è antropomorfizzarli con ruoli umani.

Come NON Usare i Sub-Agents

# ❌ SBAGLIATO: Sub-agents come ruoli
- Frontend Agent
- Backend Agent
- QA Agent
- Data Scientist Agent

Questo approccio non risolve il problema del contesto - crea solo confusione su chi fa cosa.

Come Usare i Sub-Agents

I sub-agent esistono per una sola ragione: controllare il contesto.

Il pattern corretto:

┌─────────────────────────────────────────┐
│ Parent Agent (Main Context)            │
│ • Ha un task da completare              │
│ • Deve capire come funziona qualcosa    │
└────────────────┬────────────────────────┘
                 │
                 │ Fork sub-agent
                 ├─────────────────────────┐
                 │                         │
        ┌────────▼──────────┐    ┌────────▼──────────┐
        │ Sub-Agent 1       │    │ Sub-Agent 2       │
        │ "Cerca come       │    │ "Trova i test     │
        │  funziona OAuth"  │    │  per auth"        │
        │                   │    │                   │
        │ [fa 50 ricerche]  │    │ [legge 20 file]   │
        │ [legge 30 file]   │    │ [analizza setup]  │
        └────────┬──────────┘    └────────┬──────────┘
                 │                         │
                 │ Return succinct         │
                 │ message                 │
                 │                         │
        ┌────────▼─────────────────────────▼──────┐
        │ "OAuth è in src/auth/oauth.ts:45-89"   │
        │ "Test suite usa Jest in tests/auth/"   │
        └────────────────────────────────────────┘

Esempio Pratico

# Senza sub-agent (riempie il context):
Utente: "Aggiungi supporto per Stripe webhooks"
Agent: [cerca 'stripe'... 50 risultati]
Agent: [legge payment.ts, checkout.ts, config.ts, utils.ts...]
Agent: [legge documentazione Stripe da MCP...]
Agent: [analizza webhook handling esistente...]
# Contesto: 45k token usati

# Con sub-agent:
Utente: "Aggiungi supporto per Stripe webhooks"
Parent: [lancia sub-agent: "Find how we handle webhooks"]
Sub-Agent: [cerca, legge, analizza - tutto in contesto separato]
Sub-Agent: → "Webhooks handled in src/webhooks/handler.ts:12-89.
              Pattern: Express middleware + signature verification.
              Similar: GitHub webhook implementation at lines 120-156."
Parent: [legge solo handler.ts]
Parent: [inizia a lavorare]
# Contesto parent: 8k token usati

Quando Usare Sub-Agents

Lanciare un sub-agent quando:

• Serve esplorare una parte sconosciuta della codebase
• Bisogna capire come funziona un sistema complesso
• Si deve fare una ricerca approfondita
• Il parent agent sta avvicinandosi al 40% del contesto

Non lanciare sub-agent per:

• Task che si possono fare con 1-2 tool call
• Quando sai già dove si trova il codice
• Per dividere “responsabilità” (ruoli) invece di gestire il contesto

Research Plan Implement (RPI)

Il workflow Research-Plan-Implement è l’applicazione pratica di tutti i concetti di Context Engineering in un sistema ripetibile.

I Tre Pilastri

┌──────────────┐      ┌──────────────┐      ┌──────────────┐
│   RESEARCH   │  →   │     PLAN     │  →   │  IMPLEMENT   │
└──────────────┘      └──────────────┘      └──────────────┘
  Understand            Design               Execute
  Stay objective        Be specific          Stay focused

1. Research Phase

Obiettivo: Capire come funziona il sistema, trovare i file giusti, rimanere oggettivi.

# Esempio di prompt per research:
"Esplora la codebase e documenta come funziona il sistema di autenticazione.
Sii obiettivo - non proporre soluzioni, solo documentare lo stato attuale.

Include:
- File chiave e line numbers
- Pattern architetturali utilizzati
- Dipendenze e configurazioni rilevanti
- Come i test sono organizzati"

Output della research phase:

## Research: Sistema di Autenticazione

### Architettura
L'app usa Passport.js (src/auth/passport.ts:10-89) con strategia JWT.
Token generati in auth.service.ts:45-67, validati in middleware/auth.ts:12-34.

### File Principali
- src/auth/auth.service.ts:45-120 - Login, registration, token generation
- src/auth/passport.ts:10-89 - Passport configuration
- src/middleware/auth.ts:12-78 - Auth middleware per routes
- config/auth.yaml:1-25 - JWT secrets, expiration, refresh tokens

### Database
User model: src/models/User.ts:23-89
Fields: email, hashedPassword, salt, role, createdAt

### Testing
Integration tests in tests/auth/integration.test.ts
Unit tests per ogni componente in tests/auth/unit/

Questa research può aver consumato 35k token (lettura di molti file, ricerche multiple), ma è compattata in 300 token di markdown.

2. Plan Phase

Obiettivo: Definire i passi esatti, includere file names e line snippets, essere molto espliciti su come testare.

# Esempio di prompt per planning:
"Basandoti sulla research, crea un piano dettagliato per aggiungere
autenticazione OAuth con Google.

Il piano deve includere:
- Step esatti da seguire in ordine
- File da modificare con line numbers
- Code snippets di esempio dove utile
- Come testare ogni cambiamento
- Possibili edge cases"

Output della plan phase:

## Plan: Aggiungere Google OAuth

### Step 1: Installare dipendenze
```bash
npm install passport-google-oauth20 @types/passport-google-oauth20

Step 2: Configurare Google Strategy

File: src/auth/passport.ts Posizione: Dopo JWT strategy (line 89)

// Add after line 89
import { Strategy as GoogleStrategy } from 'passport-google-oauth20';

passport.use(new GoogleStrategy({
  clientID: process.env.GOOGLE_CLIENT_ID,
  clientSecret: process.env.GOOGLE_CLIENT_SECRET,
  callbackURL: '/auth/google/callback'
}, async (accessToken, refreshToken, profile, done) => {
  // Find or create user logic
}));

Step 3: Aggiungere routes

File: src/routes/auth.routes.ts Posizione: Line 45 (dopo le route JWT esistenti)

router.get('/auth/google',
  passport.authenticate('google', { scope: ['profile', 'email'] })
);

router.get('/auth/google/callback',
  passport.authenticate('google', { session: false }),
  authController.oauthCallback
);

Step 4: Implementare callback controller

File: src/controllers/auth.controller.ts Nuova funzione: oauthCallback

Step 5: Testing

# Test manuale
1. Visitare http://localhost:3000/auth/google
2. Completare OAuth flow
3. Verificare JWT token ritornato

# Test automatici
npm test -- auth/oauth.test.ts

Edge Cases

• Utente esiste già con stessa email
• Google profile senza email
• Token scaduto durante OAuth flow

> [!NOTE]
> Un piano ben fatto dovrebbe essere così dettagliato che anche un modello "stupido" potrebbe eseguirlo senza errori. Include file paths esatti, line numbers, e code snippets.

### 3. Implement Phase

**Obiettivo**: Eseguire il piano mantenendo il contesto minimo.

```bash
# Prompt per implement:
"Esegui il piano in plan.md passo dopo passo.

Regole:
- Segui il piano esattamente
- Esegui i test dopo ogni step quando indicato
- Se un test fallisce, fermati e chiedi prima di procedere
- Committa dopo ogni step completato"

L’implement phase è la meno complessa perché tutto il lavoro difficile (capire il sistema, progettare la soluzione) è già stato fatto nelle fasi precedenti.

Il contesto dell’implement agent contiene:

• Il piano (2-5k token)
• I file da modificare (letti on-demand)
• Output dei test

Totale: 10-15k token invece di 80-100k senza RPI.

Perché RPI Funziona

Senza RPI:
┌─────────────────────────────────────────┐
│ Context: 85k token                      │
│ • 40k ricerche e letture                │
│ • 20k discussioni e tentativi           │
│ • 15k code changes e test output        │
│ • 10k rework e correzioni               │
└─────────────────────────────────────────┘
   ↓
Performance nella Dumb Zone
Risultati mediocri, slop

Con RPI:
┌──────────────────┐  ┌──────────────────┐  ┌──────────────────┐
│ Research: 35k    │→ │ Plan: 12k        │→ │ Implement: 15k   │
│ (contesto a sé)  │  │ (contesto a sé)  │  │ (contesto a sé)  │
└──────────────────┘  └──────────────────┘  └──────────────────┘
   ↓                     ↓                     ↓
Sempre nella Smart Zone
Risultati ottimi, no slop

Mental Alignment

Un beneficio nascosto ma fondamentale di RPI è il Mental Alignment - mantenere tutto il team allineato su come la codebase sta evolvendo.

Cos’è il Mental Alignment?

Domanda: A cosa serve il code review?

Risposta comune: “Trovare bug, verificare qualità, validare l’approccio.”

Risposta vera: Il code review serve principalmente a mantenere tutti nel team allineati su come il sistema sta cambiando e perché.

Il Problema dello Scale

Quando si inizia a usare AI per scrivere codice, la produttività può crescere di 2-3x. Ma questo crea un problema:

Team di 3 persone
Senza AI: 500 righe/settimana/persona = 1,500 righe totali
Con AI:   1,500 righe/settimana/persona = 4,500 righe totali

Riuscite a fare code review di 4,500 righe a settimana mantenendo mental alignment?

Per molti team, la risposta è no. Si crea un gap:

• I junior/mid usano AI intensivamente → producono molto codice, incluso slop
• I senior fanno meno AI → devono fare review di 3x più codice
• I senior iniziano a odiare l’AI perché passano il tempo a pulire slop

I Piani come Documentazione

Con RPI, il piano diventa la documentazione del cambiamento.

# Traditional PR
- 47 file changed
- 1,247 lines added
- 389 lines deleted

Review: "Scroll attraverso centinaia di righe di verde in GitHub"

# PR con RPI
- Research document: Come funziona il sistema
- Plan document: Cosa cambieremo e perché
- 47 file changed (implementazione del piano)

Review: "Leggi research + plan (5 minuti), valida approccio,
         poi sample check del codice invece di leggere tutto"

AMP Threads nei PR

Mitchell Hashimoto (fondatore di HashiCorp) ha iniziato a includere gli AMP threads (conversazioni con l’AI) nelle sue pull request.

Questo permette ai reviewer di:

1. Vedere il journey: Capire il processo di pensiero
2. Verificare i prompt: Validare che le domande fatte all’AI erano quelle giuste
3. Controllare i test: Vedere che i test sono stati eseguiti progressivamente
4. Trust but verify: Sample check invece di full review

# PR Description
## Research
[Link al research doc o thread]

## Plan
[Link al plan doc]

## Implementation
Seguito il piano step-by-step:
- ✅ Step 1: Dependencies installed
- ✅ Step 2: Google Strategy configured (tests passing)
- ✅ Step 3: Routes added (tests passing)
- ✅ Step 4: Controller implemented
- ✅ Step 5: Integration tests passing

## Manual Testing
[Screenshot o video del flusso OAuth funzionante]

Quando Usare RPI

Non tutti i task richiedono il workflow completo Research-Plan-Implement. Dex propone una matrice decisionale.

Matrice Complessità vs Sforzo

Complessità del Task
      ↑
      │
 Alta │  [Full RPI]        [Full RPI + Multiple]
      │  • Research         • Ricerche multiple
      │  • Plan             • Piani modulari
      │  • Implement        • Coordinazione sub-agents
      │
Media │  [Research + Plan] [Research + Plan]
      │  • Quick research   • Research dettagliata
      │  • Outline plan     • Plan completo
      │  • Implement        • Implement incrementale
      │
Bassa │  [Talk Directly]   [Light Plan]
      │  • Niente formale   • Outline veloce
      │  • Direct prompts   • Quick implement
      │
      └────────────────────────────────────────→
         Singolo file       Multi-repo/Sistema
                        Scope del Task

Esempi Pratici

Talk Directly (basso a sinistra):

"Cambia il colore del bottone login da blu a verde"
"Aggiungi console.log in questa funzione per debug"
"Fixa questo typo nel README"

Light Plan (basso a destra):

"Aggiungi validazione email al form di registrazione"
→ Quick outline: form component → validation logic → error display → tests

Research + Plan (medio):

"Implementa rate limiting sulle API"
→ Research: capire infrastruttura API attuale
→ Plan: dove aggiungere middleware, configurazione, testing
→ Implement: seguire il piano

Full RPI (alto):

"Migra il sistema di autenticazione da sessioni a JWT"
→ Research approfondita: tutti i punti di autenticazione, database, middleware
→ Plan dettagliato: migration strategy, backward compatibility, rollout plan
→ Implement incrementale: step by step con testing continuo

Full RPI + Multiple (alto a destra):

"Implementa sistema di microservizi con event sourcing"
→ Multiple research su: architettura esistente, event bus, persistence, deployment
→ Piani modulari per ogni servizio
→ Sub-agents coordinati per implementazione parallela

Quando È Troppo?

Segnali che state esagerando con RPI:

• State facendo research per cambiare un commento
• Il piano è più lungo del codice che produrrà
• State usando sub-agents per leggere un singolo file
• Il team si lamenta che il processo rallenta invece di accelerare

Quando È Troppo Poco?

Segnali che dovreste usare più RPI:

• L’agent continua a produrre soluzioni sbagliate
• Finisce il contesto prima di completare il task
• Dovete rifare lo stesso lavoro 2-3 volte
• Il codice funziona ma nessuno capisce perché
• Code review richiede spiegazioni lunghe

Best Practices Avanzate

1. On-Demand Compressed Context

Molti team iniziano documentando tutto in file CLAUDE.md o simili:

my-repo/
  CLAUDE.md           ← "Ecco come funziona tutto"
  src/
    frontend/
      CLAUDE.md       ← "Ecco come funziona il frontend"
    backend/
      CLAUDE.md       ← "Ecco come funziona il backend"

Problema: Questa documentazione diventa stale rapidamente.

┌─────────────────────────────────────┐
│ Quantità di "bugie" nella codebase │
│            ↑                        │
│            │  ┌─ Documentazione     │
│            │  │                     │
│            │  │                     │
│            │  ├─ Commenti          │
│            │  ├─ Function names    │
│            └──┴─ Codice            │
└─────────────────────────────────────┘

Soluzione: On-demand compressed context

Invece di mantenere documentazione statica, generi context quando serve:

# Invece di leggere CLAUDE.md potenzialmente obsoleto:

"Esplora il sistema di SCM providers, Jira integration, e Linear integration.
Crea un research doc che documenta lo stato ATTUALE del codice."

# Il research agent:
- Legge il codice reale (source of truth)
- Comprime in markdown
- Fornisce snapshot accurato al 100%

Questo approccio:

• ✅ È sempre aggiornato (generato dal codice)
• ✅ È specifico per il task corrente
• ✅ Non richiede manutenzione
• ✅ Comprime solo ciò che serve

2. Progressive Disclosure

Se volete comunque mantenere dei file di contesto, usate progressive disclosure:

monorepo/
  .claude/
    context.md        ← Root context (sempre caricato)
  services/
    api/
      .claude/
        context.md    ← Caricato solo se lavori qui
      auth/
        .claude/
          context.md  ← Caricato solo se lavori su auth

Pattern:

• Root context: Architettura generale, convenzioni globali, comandi base
• Service context: Pattern specifici di quel servizio
• Module context: Dettagli implementativi del modulo

L’agent carica solo ciò che serve, rimanendo nella Smart Zone.

3. Non Outsourcing del Thinking

Regola d’oro: L’AI può amplificare il tuo thinking, non sostituirlo.

# ❌ Outsourcing del thinking:
"Implementa un sistema di caching performante per l'app"
[agent produce qualcosa]
[tu lo accetti senza capire]

# ✅ Amplificazione del thinking:
"Ho pensato a tre approcci per il caching:
1. Redis in-memory cache
2. CDN edge caching
3. Application-level caching con LRU

Fai research su come è strutturata la nostra infrastruttura
e dimmi quale approccio si integra meglio. Poi creiamo un piano insieme."

Il caso di studio di Parquet Java che Dex menziona è perfetto esempio:

Tentativo di rimuovere dipendenze Hadoop da Parquet Java fallì inizialmente. Dopo molte iterazioni sbagliate, Dex e Blake tornarono alla lavagna fisica per ragionare sull’architettura, identificare i footguns, e solo DOPO crearono un piano che l’AI potesse eseguire.

4. Pick One Tool and Get Reps

Dex raccomanda fortemente:

“Pick one tool and get some reps. Non consiglio di fare min-maxing tra Claude, Codex, e tutti questi diversi strumenti.”

Perché?

• Ogni tool ha quirks diversi
• Le tecniche di Context Engineering variano leggermente
• Serve muscle memory per sapere quando intervenire
• La competenza si costruisce con ripetizione

Iniziate con un tool, padroneggiatelo, poi (se necessario) esplorate altri.

5. Frequent Intentional Compaction

Il pattern più potente è costruire l’intero workflow intorno al context management:

Session 1: Research
[contesto cresce a 35k]
↓
/compact → research.md
[contesto reset]

Session 2: Planning
[carica research.md + task]
[contesto cresce a 12k]
↓
/compact → plan.md
[contesto reset]

Session 3: Implement
[carica plan.md]
[contesto cresce a 15k man mano che implementi]
↓
[task completo]

Ogni fase rimane nella Smart Zone perché compatti frequentemente.

Casi Studio Reali

Caso 1: Boundary ML / BAML (Successo)

Context: Dex fa un podcast con Vibv, CEO di Boundary ML. Decide di tentare un oneshot fix su una codebase Rust di 300.000 righe per un linguaggio di programmazione custom (BAML).

Approccio:

1. Multiple research phase (alcuni scartati perché inadeguati)
2. Plan senza research vs plan con research (comparati)
3. Implementazione finale

Risultato:

• PR creato lunedì sera durante podcast
• Martedì mattina, CTO aveva già visto il PR
• Non realizzò che era “un bit per il podcast”
• Commento: “Yeah this looks good, we’ll ship it next release”

Confirmation: Funziona in brownfield codebase, no slop.

Caso 2: 35k Righe in Un Sabato (Successo)

Vibv era ancora scettico dopo il primo successo. Dex e team si siedono per 7 ore di sabato lavorando su BAML.

Risultato:

• 35.000 righe di codice shipped
• Alcuni PR merged una settimana dopo
• Parte è codegen (golden files update), ma molto è codice reale
• Stima: 1-2 settimane di lavoro in 7 ore

Confirmation: RPI può risolvere problemi complessi, non solo fix semplici.

Caso 3: Parquet Java Hadoop (Fallimento Istruttivo)

Context: Dex e Blake tentano di rimuovere dipendenze Hadoop da Parquet Java.

Cosa successe:

• Crearono research
• Crearono piani
• Implementarono
• Non funzionò

Il punto di svolta:

“A un certo punto, buttammo via tutto e tornammo alla lavagna. Dovemmo capire dove erano tutti i footguns, come le cose si integravano realmente, PRIMA di poter creare un piano che funzionasse.”

Lesson learned:

• RPI non è magia
• Per problemi estremamente complessi, serve human thinking approfondito
• L’AI amplifica il thinking, non lo sostituisce
• Una bad line of research → tutto il piano sbagliato → 100 bad lines of code

Spec-Driven Development È Morto?

Un topic importante del talk: il concetto di “Spec-Driven Development” è stato semantically diffused.

Semantic Diffusion

Martin Fowler scrisse nel 2006 sul problema della Semantic Diffusion:

“Creiamo un buon termine con una buona definizione. Poi tutti si emozionano e iniziano a usarlo per significare 100 cose diverse a 100 persone. Diventa inutile.”

È successo con “Agent”:

• Agent = persona
• Agent = microservice
• Agent = chatbot
• Agent = workflow
• Agent = tools in a loop (definizione originale)

Spec-Driven Dev: Troppi Significati

Dex elenca cosa la gente intende con “Spec-Driven Dev”:

1. Scrivere un prompt migliore
2. Product requirements document
3. Verifiable feedback loops e backpressure
4. Trattare il codice come assembly (idea originale di Sean)
5. Usare un mucchio di file markdown mentre codi
6. Documentazione per libreria open source (!!!)

Spec-Driven Development è overhyped.
È semantically diffused.
È inutile come termine.

Cosa Funziona Davvero

Invece di inseguire buzzword, Dex propone di concentrarsi su tecniche concrete:

1. Research - Capire il sistema
2. Planning - Comprimere intent
3. Compaction - Gestire context window
4. Sub-agents - Controllare il contesto
5. Mental alignment - Tenere il team allineato

Il Futuro: 99% AI-Generated Code

Il vero problema non è tecnico - è organizzativo.

Il Rift

Si sta creando una spaccatura nei team:

Senior/Staff Engineers:
• Non adottano AI perché "non li rende COSÌ tanto più veloci"
• Devono fare review di 3x più codice
• Passano tempo a pulire slop
• Odiano sempre più l'AI ogni settimana

Junior/Mid Engineers:
• Usano AI intensivamente
• Colma gap di skill
• Produce anche slop
• Aumenta produttività ma crea debito

Non È Colpa dell’AI

“Questo non è colpa dell’AI. Non è colpa degli engineer mid-level. Il cambiamento culturale è difficile e deve venire dall’alto se deve funzionare.”

La Soluzione

Se siete technical leader:

1. Pick one tool and get reps - Diventare competenti voi stessi
2. Stabilire processi - RPI o simili per gestire l’output aumentato
3. Insegnare context engineering - Non solo “usa l’AI”, ma “usa l’AI bene”
4. Aggiornare code review - Leggere piani, validare approcci, sample check codice
5. Mental alignment nuovo - Trovare modi per tenere il team allineato con 3x output

SDLC per 99% AI Code

Il team di Dex sta costruendo un Agentic IDE per aiutare team di ogni dimensione a:

• Gestire workflow con 99% AI-generated code
• Mantenere qualità senza slop
• Conservare mental alignment
• Scalare produttività senza caos

Conclusione

Il Context Engineering non è una moda passeggera - è la competenza fondamentale per usare coding agents efficacemente.

Key Takeaways

1. LLM = Stateless Functions - Solo il contesto determina l’output
2. Smart Zone vs Dumb Zone - Stare sotto il 40% della context window
3. Compaction - Comprimere conversazioni in markdown essenziale
4. Sub-Agents = Context Control - Non ruoli, ma fork per ricerca
5. RPI Workflow - Research → Plan → Implement per problemi complessi
6. Mental Alignment - Piani e research tengono il team allineato
7. Non Outsourcing Thinking - L’AI amplifica, non sostituisce
8. Get Reps - La competenza viene con pratica ripetuta

L’Equazione Finale

Bad line of code = Bad line of code (1x damage)
Bad line in plan = 100 bad lines of code (100x damage)
Bad line in research = Entire approach wrong (1000x damage)

Investite il vostro tempo umano ai livelli più alti di leverage: research e planning. Lasciate l’implement all’AI.

Il futuro dello sviluppo software non è “AI vs Human” - è Human thinking amplificato da AI. Chi padroneggia il Context Engineering padroneggerà questo futuro.

Buon coding! 🚀