01
Competenze tecniche
Qualità del codice, architettura, API, sistemi frontend, test, debugging e manutenibilità.
Metodo
Un modo pratico di usare l’AI nello sviluppo software è diventato TCAF.
TCAF nasce da problemi ricorrenti incontrati usando l’AI su progetti software reali: ampliamento non richiesto delle modifiche, riscritture inutili, perdita di contesto e codice che può richiedere più tempo per essere revisionato di quanto ne abbia fatto risparmiare. L’obiettivo è mantenere l’accelerazione utile senza rinunciare a comprensione, manutenibilità e responsabilità tecnica umana.
Prima l’esperienza
Costruito su oltre 10 anni di sviluppo software hands-on.
AngeliniLabs nasce dal lavoro software reale: sviluppo frontend e full-stack, architettura e integrazioni, manutenibilità, debito tecnico, implementazione di funzionalità, collaborazione nei team, progetti Agile e responsabilità progressivamente più ampie nella gestione dei progetti.
02
Gestione dei progetti
Perimetro, priorità, pianificazione, dipendenze, rischi, esigenze degli stakeholder, coordinamento del team e preparazione al rilascio.
03
Uso controllato dell’AI
AI come acceleratore per attività selezionate, non come sostituto del giudizio tecnico, della review o della responsabilità.
Dalla pratica al framework
È iniziato come un modo semplice per tenere sotto controllo i task assistiti dall’AI.
Il primo obiettivo era molto concreto: rendere il lavoro assistito dall’AI più circoscritto, chiaro, semplice da revisionare e più facile da recuperare quando uno strumento si comportava in modo imprevedibile.
Dopo aver usato ripetutamente l’AI per analisi, implementazione, debugging, refactoring, test e documentazione, continuava a emergere lo stesso schema: lo strumento poteva produrre rapidamente lavoro utile, ma poteva anche ampliare la modifica richiesta, sostituire logica già funzionante, perdere decisioni precedenti o generare codice che richiedeva più tempo per essere compreso di quanto ne avesse fatto risparmiare.
Prompt più brevi aiutavano, ma non bastavano. Un processo affidabile richiedeva anche contesto di progetto persistente, permessi espliciti, review obbligatoria del developer, un’indicazione chiara di cosa fosse stato verificato e cosa no e regole coerenti tra strumenti e modelli differenti.
È così che un metodo di lavoro leggero è diventato TCAF: un framework installabile e versionato con runtime, regole di progetto riutilizzabili, Task Contract, procedure di configurazione, integrazioni con gli strumenti, validazione e documentazione.
L’obiettivo non è automatizzare via l’ingegneria del software. È delegare lavoro selezionato senza cedere le decisioni, il contesto del progetto e la responsabilità sul codice che rendono il software manutenibile.
Cosa andava risolto
Il problema principale non era generare codice. Era controllare le modifiche.
I problemi più costosi non erano sempre errori evidenti. Erano modifiche ragionevoli prese singolarmente, ma capaci di indebolire il progetto nel suo insieme.
Il perimetro si amplia senza essere richiesto
Uno strumento AI può risolvere il problema richiesto e contemporaneamente modificare codice vicino, aggiungere astrazioni non necessarie o ampliare l’implementazione oltre ciò che serve.
Codice veloce, debugging lento
La generazione rapida smette di essere un vantaggio quando il codice risultante è difficile da spiegare, incoerente con il progetto o costoso da correggere e mantenere.
Il contesto del progetto si perde
Una chat può contenere decisioni importanti dietro un task, ma quel contesto può sparire quando cambiano sessione, strumento, modello o developer.
Il codice funzionante viene riscritto senza necessità
Gli strumenti AI tendono spesso a preferire l’approccio che progettarebbero da zero, anche quando l’implementazione esistente funziona e dovrebbe semplicemente essere estesa.
L’approccio TCAF
Mantenere le normali pratiche ingegneristiche. Rendere esplicita la delega all’AI.
TCAF mantiene developer e team responsabili del software. L’AI supporta attività selezionate; non diventa il soggetto che prende le decisioni di progetto.
01
Le decisioni restano al team
Requisiti, architettura, scomposizione dei task, strategia di implementazione, aspettative di qualità e accettazione finale restano responsabilità umane.
02
La delega è esplicita
L’AI riceve lavoro selezionato attraverso un Task Contract che indica risultato atteso, cosa può cambiare, cosa deve restare intatto, come verificare il risultato e quando lo strumento deve fermarsi.
03
Il codice esistente resta il riferimento
File correnti, metodi funzionanti, regole di progetto, modifiche del developer e convenzioni locali rappresentano lo stato da comprendere e preservare prima di proporre cambiamenti più ampi.
04
La verifica è esplicita
Test automatici, verifiche manuali, limitazioni note e decisioni ancora aperte restano visibili. Il fatto che uno strumento dichiari corretto il proprio lavoro non sostituisce mai la review del developer.
Come funziona
Una sequenza controllata, senza obbligare a usare l’AI per ogni task.
L’AI può ispezionare, preparare una bozza, implementare, verificare oppure non essere usata. Sono developer e team a decidere dove la delega fa davvero risparmiare tempo senza creare più rischi o lavoro di review.
01
Comprendere il progetto reale
Esaminare repository, regole di progetto, implementazione vicina, strumenti disponibili e origine del task prima di proporre modifiche.
02
Definire un task delimitato
Chiarire obiettivo, comportamento atteso, file o aree modificabili, esclusioni, criteri di accettazione, controlli e condizioni di arresto.
03
Scegliere cosa delegare
Il developer può scrivere direttamente il codice, chiedere all’AI di ispezionare o implementare una parte specifica oppure combinare i due approcci. TCAF non richiede uno sviluppo AI-first.
04
Preservare il codice funzionante prima di riscriverlo
Riutilizzare funzioni, validazioni, utility, naming e pattern architetturali esistenti quando risolvono già parte del problema, invece di sostituirli senza una ragione.
05
Verificare il risultato prima di accettarlo
Esaminare le modifiche, eseguire i controlli pertinenti, verificare il comportamento atteso e registrare eventuali limitazioni o punti ancora aperti prima di considerare il task concluso.
06
Aggiornare lo stato del progetto solo quando previsto
Commit, aggiornamenti del backlog, stato delle issue e documentazione di progetto restano azioni esplicite, non conseguenze automatiche di un’esecuzione AI.
Principi
Un’alternativa pratica allo sviluppo AI non controllato.
La differenza importante non è se l’AI viene usata. È se il lavoro resta comprensibile, revisionabile e sotto la responsabilità di persone che conoscono il software che stanno costruendo.
- L’ingegneria del software professionale resta la base.
- L’AI accelera attività selezionate; non possiede il progetto e non prende le decisioni tecniche al posto del team.
- I task piccoli rendono le modifiche più semplici da comprendere e revisionare, non servono soltanto ad accorciare i prompt.
- Il codice funzionante e le convenzioni locali vengono estesi prima di essere sostituiti senza necessità.
- Le modifiche umane e quelle accettate diventano lo stato corrente del progetto che il lavoro successivo deve rispettare.
- Il framework è progettato per restare utilizzabile con modelli e strumenti di sviluppo differenti.
Framework pubblico
TCAF è installabile, versionato e documentato.
Il framework include runtime CLI, Universal Run Protocol, Task Contract, regole di progetto riutilizzabili, integrazioni con gli strumenti, validazione e documentazione bilingue.
Progetto applicativo
Software Delivery Planner è la prima applicazione pubblica più estesa che utilizza TCAF.
L’applicazione in React, TypeScript e Fastify ancora in lavorazione collega implementazione, backlog, architettura, test, rischi, stime e documentazione di progetto. È anche il primo progetto più ampio portato avanti nel lavoro quotidiano utilizzando le regole TCAF.
Stato attuale
Una beta pubblica che migliora attraverso l’uso reale.
TCAF 0.3.3 è utilizzabile oggi, ma è ancora pre-1.0. Sono state testate l’integrazione con Codex e la procedura manuale documentata per Cline; ulteriori integrazioni e scenari di sviluppo verranno verificati progressivamente.