Una volta ho chiesto a un'IA di costruire il sito web di un brand. Quello che è uscito sembrava convincente a prima vista, ma era rotto proprio nei punti che contano. L'header mostrava esattamente due link. Non c'era una pagina "Chi siamo" da nessuna parte. Un pannello di amministrazione esisteva nel backend, eppure nessun pulsante o rotta nel frontend permetteva di raggiungerlo. Il lato server funzionava. Il lato utente no.
La maggior parte delle persone che si imbattono in questo assume che l'IA sia diventata pigra o abbia raggiunto un limite di token. Non è quello che sta accadendo. Il problema è strutturale. Gli strumenti di coding basati su IA sono progettati per monitorare la coerenza interna. Si chiedono: "Tutto ciò che ho dichiarato è coerente con se stesso?". Non si chiedono: "Questo tipo di deliverable contiene tutto ciò che dovrebbe contenere?". Se menzioni due pagine per il sito del tuo brand, il modello controlla diligentemente se quelle due pagine si linkano a vicenda. Una volta che i link funzionano, considera il compito completato. Non ha la nozione intrinseca che un sito di un brand abbia bisogno di una pagina "Chi siamo", di segnali di fiducia o di un percorso di contatto. Non ha uno standard nella sua testa.
Chiamo la soluzione una Baseline di Completezza.
Una baseline di completezza è semplicemente una checklist standard di ciò che un determinato deliverable deve contenere. Generi l'artefatto, quindi confronti l'output reale con questo standard esterno invece di fidarti del senso di "fatto" interno dello strumento.
Verifica su tre livelli
Non tutti i pezzi mancanti sono ugualmente ovvi. Una baseline utile controlla tre livelli distinti.
Esistenza. La parte esiste davvero? Sembra banale, ma un'IA costruirà volentieri un wrapper di navigazione che fa riferimento a una pagina dashboard senza mai generare la pagina dashboard stessa. Il riferimento esiste. Il bersaglio no.
Raggiungibilità. Un utente reale può effettivamente raggiungerla? I pannelli admin nascosti sono il sintomo classico. La rotta e il componente potrebbero anche esistere nel codebase, eppure nessun elemento del menu, pulsante o reindirizzamento li espone all'interfaccia. Se un utente non può imbattersi in esso durante l'uso normale, allora non è realmente lì.
Sostanzialità. C'è una struttura o dei dati reali dietro la superficie? Una pagina che si carica ma contiene solo testo segnaposto e nessun campo per il caricamento di immagini è uno scheletro travestito. Una pagina "Chi siamo" senza un campo per le immagini o un campo di testo modificabile non è completa, anche se l'HTML viene renderizzato correttamente.
Questi tre livelli intercettano diverse classi di lacune. L'esistenza trova la scarpa mancante. La raggiungibilità trova la scarpa chiusa in un armadio. La sostanzialità trova la scarpa senza suola.
Baseline per tipologia
Una singola baseline non coprirà ogni progetto. Devi classificare ciò che stai costruendo e definire i requisiti non negoziabili per quella categoria.
Siti web di brand hanno bisogno di sezioni specifiche e pagine raggiungibili. Pensa a "Chi siamo", "Contatti", link alla privacy e una navigazione che esponga effettivamente ogni vista principale.
API hanno bisogno di documentazione, codici di errore esaustivi e rate limit. Un endpoint funzionante che restituisce 200 OK in caso di successo e un generico 500 per tutto il resto non è un'API finita. È un pericolo.
Automazioni hanno bisogno di log e avvisi di errore. Se un workflow si interrompe alle 2 del mattino e nessuno lo sa finché un essere umano non controlla la cronologia di esecuzione, l'automazione è incompleta. L'osservabilità non è una funzionalità extra. Fa parte del deliverable.
Una volta definita la categoria, la baseline si scrive da sola. La parte difficile è applicarla dopo che il codice è stato generato.
Regole di design che reggono
Ho ricostruito il mio flusso di lavoro attorno a questa idea e sono arrivato a tre regole pratiche che impediscono ai progetti di sfaldarsi lentamente.
Design vincolato alle capacità. Prima di impegnarti con uno strumento o un modulo generato, rileva cosa può effettivamente fare. Se una libreria di componenti manca del supporto nativo per il mobile drawer, non lasciare che l'IA generi uno schema di navigazione completo che presupponga la sua esistenza. Il sistema dovrebbe degradare con eleganza invece di rompersi quando manca una funzionalità. Conosci i confini per primi. Progetta al loro interno.
Motore pubblico, valori privati. Usa un motore pubblico per il lavoro pesante, ma inietta i tuoi dati, le tue configurazioni e le tue convenzioni private a runtime. Questo mantiene i tuoi metodi personali o aziendali al sicuro e separati dallo scaffold generato. L'IA costruisce l'intelaiatura. Tu incastri il vetro. Questo evita che il modello codifichi rigidamente assunzioni che violano i tuoi standard reali o che faccia trapelare pattern sensibili in contesti di addestramento pubblici.
Propose, do not auto-advance. Let the AI suggest the next step, but force a human to make the choice. Automate the flow of execution, never the judgment. When a model auto-generates a database migration, an auth scheme, and a payment hook in one breath, you get convenience at the cost of oversight. Make the tool present the plan. Let the developer press the button.
Picking the Right Model for the Job
I tested this across different models and found a clear split in value. Cheaper models handle mechanical bulk shockingly well. They churn out boilerplate, repetitive components, and structural stubs faster than you can type. The expensive models earn their price only when they demonstrate restraint. You want the premium option when it refuses to invent fake fixes and instead flags a genuine gap. A model that hallucinates a workaround for a missing API endpoint is dangerous. A model that stops and says, "This workflow requires a webhook target that is not defined," is worth the cost. Pay for discernment, not volume.
Build Systems, Don't Chase Magic
Do not try to fix AI gaps by throwing bigger models or more prompting tricks at the problem. Fix them with a baseline. The gap is not a capacity problem. It is an expectations problem.
To stop the missing blocks, do three things.
Give the system a completeness baseline before any code is written. Make it a physical checklist that lives next to the task.
Bake your conventions into reusable parts. If you enforce your baseline through templates, lint rules, or pre-built scaffolds, the AI starts from a position of correctness rather than hoping it guesses your standards.
Automate the flow while keeping a human in control of judgment. Let the machines handle repetition. Reserve the decisions for people who understand the context.
Here is one last habit that changed how I work. If you make the same design decision seven times, stop treating it as a one-off choice. That is not repetition. That is a law. Name it. Turn it into a rule. Document it. When you codify the pattern, you remove the chance that an AI will drift away from it the eighth time.
The source for this framework and the original exploration can be found here.
If you want to trade notes with others working through the same problems, you can join the GyaanSetu learning community.