Introduzione

TCAF è un framework operativo model-agnostic per lo sviluppo software assistito dall’AI. Collega analisi del progetto, architettura, pianificazione, implementazione, verifica e riconciliazione attraverso attività esplicite e revisionabili.

TCAF limita l’esecuzione dell’AI, non l’autorità del developer né la sua possibilità di lavorare direttamente sul software.

Il developer continua a fare il developer

TCAF non trasforma il developer o il team di sviluppo in un supervisore passivo del codice generato. I developer restano liberi di analizzare il sistema, assumere decisioni architetturali, scrivere codice, modificare qualsiasi area del repository, sostituire un approccio, eseguire un refactoring motivato, investigare problemi e risolverli direttamente.

Gli strumenti AI servono ad accelerare e facilitare lo sviluppo software reale. Non ricevono un mandato indipendente per riprogettare l’applicazione, ampliare il task, sostituire codice funzionante o scegliere una strategia di implementazione differente senza autorizzazione.

Le modifiche eseguite dal developer fanno parte dello stato corrente del progetto. Un agente AI deve rileggerle e integrarle, non ripristinare una versione precedente, sovrascriverle o comportarsi come se fossero rilevanti soltanto le modifiche prodotte dall’agente stesso.

Perché esiste TCAF

I modelli AI possono produrre codice rapidamente, ma possono colmare le informazioni mancanti con assunzioni, ampliare il perimetro richiesto, riscrivere aree funzionanti, ignorare le convenzioni locali o dichiarare controlli non realmente completati. Una risposta plausibile può comunque descrivere un risultato errato o incompleto.

TCAF sostituisce questa libertà implicita con un confine operativo esplicito. Prima dell’implementazione viene ispezionato lo stato pertinente del progetto e la modifica richiesta viene trasformata in un Task Contract che definisce obiettivo autorizzato, superficie di modifica, aree da preservare, comportamento atteso, controlli e condizioni di arresto.

Questa struttura serve a rendere l’assistenza AI più utile, non semplicemente più restrittiva. Un modello può lavorare con decisione all’interno di un task chiaro perché non deve inventare autorità o contesto di progetto.

Il ciclo operativo

1. Ispezionare lo stato pertinente del progetto senza presumerlo.
2. Identificare la fonte del task ed eseguire soltanto l’analisi necessaria per quel task.
3. Produrre un Task Contract con obiettivi, confini e condizioni di arresto espliciti.
4. Ottenere review e approvazione del developer prima di un’implementazione sostanziale.
5. Implementare secondo il principio preservation-first e rendere il nuovo codice coerente con i pattern locali già presenti.
6. Eseguire o riportare i controlli minimi pertinenti, distinguendo le evidenze realmente ottenute dalle verifiche ancora necessarie.
7. Restituire risultato, limitazioni, eventuali deviazioni e prossima azione del developer.
8. Riconciliare documentazione, backlog e stato del progetto soltanto quando autorizzato esplicitamente.

Oltre la generazione controllata di codice

TCAF non si limita a chiedere a un’AI di scrivere una funzione. Può supportare il processo operativo dalla comprensione iniziale del progetto e dalle baseline architetturali fino alla pianificazione dei task, all’implementazione, alla review e alla riconciliazione dello stato.

Il framework è intenzionalmente indipendente dal modello e dallo strumento. Gli stessi principi possono essere trasportati tramite Codex, Cline, una CLI generica o un’altra interfaccia, anche se ogni adapter può avere capacità e limitazioni differenti.

Cosa non è TCAF

TCAF non è un project manager autonomo, un coding agent, un sostituto del giudizio ingegneristico o una forma di vibe coding parzialmente supervisionato. Non assegna all’AI la proprietà del repository per poi chiedere al developer di approvare il risultato a posteriori.

È la disciplina operativa che permette ai developer di usare l’AI come acceleratore mantenendo piena autorialità, libertà tecnica e responsabilità sul software.

Stato attuale della validazione

Il framework è stato esercitato attraverso scenari di installazione, adozione di progetto, task di sviluppo e riconciliazione documentale, compreso l’utilizzo verificato con Codex e l’utilizzo con Cline accompagnato da limitazioni documentate. Non ogni principio è stato ancora testato con ogni modello, adapter, tipo di progetto e condizione che può verificarsi durante un task attivo. La documentazione distingue quindi comportamento verificato, verificato con limitazioni, procedura allineata al framework, capacità pianificata e operazione non supportata.