Il problema delle stime nell'era dell'AI: il tuo istinto potrebbe avere ragione
Il dramma delle stime ai tempi dello sviluppo con AI
Ti ricordi quando dicevi al project manager "ci metto due settimane" e ci azzeccavi più o meno? Quei tempi sembrano preistoria. L'arrivo degli AI agent che non solo completano codice ma lo progettano e lo scrivono da soli ha mandato in tilt ogni previsione.
La formula di una volta (che funzionava, più o meno)
Prima, con lo sviluppo tutto umano, stimare era prevedibile:
- Conoscenza del codebase + Complessità del design + Velocità di scrittura + Tempo per test e debug = Timeline approssimativa
Conoscevi il codice a memoria, sapevi che l'autenticazione filava liscia ma lo schema del database era un casino. Calcolavi ore di refactoring, casi limite e produttività giornaliera. Non era esatto – slittava del 20-40% – ma dava un'idea giusta.
L'AI agent: reset totale delle stime
Ora dai lo stesso compito a un AI coding assistant. Tutto cambia:
Capirà l'architettura del tuo codebase al primo colpo? Dipende da documentazione, limiti del context window e quanto il modello si adatta al tuo stack.
Tirerà fuori la soluzione perfetta subito? Se azzecca al primo inference, ore. Se serve prompting iterativo, giorni.
Quanto riscriverai tu? Il codice AI va customizzato, rinforzato per security e adattato all'integrazione.
Verità nuda: troppi fattori fuori dal tuo controllo da developer.
La confessione del "coding a sensazione"
Molti developer non lo ammettono: facciamo più "coding a sensazione" del previsto. Cioè:
- Stime basate sulla velocità di inference AI, non sulla complessità reale
- Speranza che l'AI capisca al volo, senza cicli di iterazione
- Sottostima dell'integrazione con il codice esistente
- Sovrastima della capacità di fixare allucinazioni o buchi di security
Non è pigrizia. È che gli strumenti vecchi non reggono la nuova realtà.
Cosa funziona davvero (strategie pratiche)
Problemi con le timeline AI-assisted? Ecco cosa usano i developer:
1. Misura il baseline dell'AI prima
Prova feature piccole nel tuo workflow AI. Cronometra inference, iterazioni e revisioni. Dati reali, non supposizioni.
2. Separa tempo umano e machine
Non stimare tutto insieme. Dividi:
- Generazione AI: Prompt, inference, output iniziale
- Review umana: Audit codice, check security, refactoring
- Integrazione: Collegamenti, test, debug
Così prevedi meglio ciò che controlli tu.
3. Crea pacchetti di contesto
L'AI inciampa senza background. Investi 2-3 ore in doc architettura, convention codice e esempi. Output migliori, meno iterazioni, tempi totali ridotti.
4. Accetta l'incertezza con buffer
Niente stime precise. Di' "3-8 giorni a seconda del modello" invece di "5 giorni". Più onesto e utile.
5. Traccia e ottimizza il processo
Ogni team ha il suo workflow AI ideale. Monitora prompt profondi o refinement iterativo. Adatta stime ai risultati veri.
Il quadro generale
Quel disagio sulle stime non è colpa tua. È il software estimation che si ribalta. Passiamo da "quanto ci mettono gli umani a codare?" a "quanto impiega l'AI a capire, proporre e noi a validare/integrare?".
Più duro da prevedere, perché varia per:
- Qualità modello e velocità inference
- Specificità problema e match con training data
- Doc e struttura del tuo codebase
- Skill del team nel guidare gli agent
Il lato positivo
Quando l'AI centra al primo colpo – e capita spesso – spedisci feature in giorni, non settimane. Variabilità alta, ma throughput medio superiore.
Misurala, adattati e via.
Verso il futuro
I developer che vincono ora non si aggrappano ai vecchi metodi. Sono quelli che:
- Accettano il caos delle stime
- Misurano ossessivamente il workflow AI
- Costruiscono contesto e prompt solidi
- Danno range ampi ma timelines reali
- Spediscono veloce e imparano iterando
Il tuo "coding a sensazione" non è un difetto. È la norma del development intelligente, dove stimi con la machine intelligence.