Pensiero critico assistito: usare l’AI come contraddittorio, non come oracolo 🧪

Ti è mai capitato di leggere una risposta AI impeccabile, ordinata, quasi elegante, e pensare: “Perfetto, facciamo così”? Poi passano due giorni, arriva il primo incidente in produzione e scopri che quella soluzione era splendida come una facciata appena verniciata: bella da lontano, fragile da vicino.

Il punto non è che l’AI “sbaglia”. Sbagliamo noi quando la trattiamo come oracolo invece che come contraddittorio interno. La differenza è tutta qui: nel primo caso deleghiamo il giudizio, nel secondo lo alleniamo.

L’AI più utile non è quella che risponde al posto tuo, ma quella che migliora la qualità dei dubbi prima che diventino bug.

Risposte plausibili, decisioni rischiose 🎭

Nel lavoro quotidiano c’è una tentazione fortissima: confondere la plausibilità linguistica con l’affidabilità tecnica. Un output scritto bene ci rassicura. E la rassicurazione, in software, è spesso il modo più elegante di chiamare una scorciatoia.

Quando accettiamo una proposta AI senza contraddittorio, non stiamo accelerando la conoscenza: stiamo automatizzando la conferma dei nostri bias. Se il team è già convinto di una direzione, il modello tenderà a rinforzarla con argomenti coerenti. Coerenti, sì. Necessariamente veri, no.

È la stessa dinamica che emerge in Question-Driven Specification: il problema non è produrre risposte in fretta, ma decidere bene quando i requisiti sono ancora opachi.

Da oracolo a contraddittorio interno 🪞

Il modello “oracolo” è semplice da descrivere: chiedi, ricevi, incolli, merge. È anche il modello più pericoloso, perché riduce l’attrito proprio dove l’attrito servirebbe.

Il modello “contraddittorio”, invece, segue una logica diversa: chiedi, stress-testi, confronti, decidi. L’AI non è il giudice finale, è la controparte che ti obbliga a esplicitare assunzioni, limiti e trade-off.

In pratica cambia la postura mentale. Non domandi “qual è la soluzione giusta?” ma “dove può rompersi questa soluzione?”. E questa singola inversione evita molte sorprese costose.

Accettare output AI senza contraddittorio non è efficienza: è fretta con una buona grammatica.

Il protocollo C-C-C-D per non auto-ingannarsi 📐

Quando una decisione ha impatto reale, uso un protocollo minimale in quattro passaggi:

• Claim: cosa sta affermando davvero il modello?
• Constraints: quali vincoli reali devono valere nel tuo contesto? Sicurezza, performance, compliance, costi operativi, compatibilità legacy.
• Counterexample: qual è il caso concreto in cui questa proposta fallisce?
• Decision: cosa accetti, cosa scarti, cosa validi con test prima del merge?

Sembra banale. Funziona perché costringe il team a smettere di discutere per impressioni e a discutere per falsificabilità. In altre parole: meno opinioni in libertà, più ipotesi verificabili.

Se vuoi una base metodologica complementare, il mindset di Unknowns-Driven Development è perfetto: partire da ciò che non sai, invece di fingere chiarezza prematura.

Prompt per criticare meglio, non solo per produrre meglio ✍️

Molti prompt chiedono output. Quelli più utili chiedono attrito cognitivo. Alcuni esempi che uso spesso:

• “Indicami 3 failure mode realistici di questa soluzione.”
• “Qual è l’assunzione più fragile e come posso verificarla in meno di un giorno?”
• “Quali trade-off operativi sto sottovalutando?”
• “Quali test potrebbero falsificare questa proposta?”

Non sono formule magiche. Sono domande che spostano la conversazione da “dimmi cosa fare” a “aiutami a decidere con più onestà”.

Questo approccio è coerente anche con Context engineering: non vince il prompt più brillante, vince il contesto più rigoroso.

Tre situazioni reali dove cambia tutto 🔄

Primo scenario: endpoint retry-safe. La proposta AI sembra pulita finché non chiedi controesempi su retry simultanei. E lì emerge il dettaglio che mancava: chiave di idempotenza persistente, non solo memoria volatile.

Secondo scenario: refactor di modulo legacy. Il modello suggerisce una separazione elegante in più file. Al contraddittorio, però, saltano fuori dipendenze cicliche nascoste. Decisione pragmatica: refactor in due step, prima contract test, poi separazione definitiva.

Terzo scenario: requisito ambiguo, il classico “deve essere veloce”. Usata come critico, l’AI inizia a chiedere p95, carico atteso, budget errore, soglie di saturazione. Il requisito finalmente smette di essere poetico e diventa testabile.

In tutti e tre i casi il guadagno non è “scrivere prima”. È sbagliare meno tardi, che nel mondo reale vale molto di più.

Anti-pattern da evitare quando tutto sembra andare bene 🚫

Ci sono abitudini che sembrano innocue e poi presentano il conto:

• usare l’AI per confermare una decisione già presa;
• delegarle la stima finale del rischio;
• saltare test perché l’output “sembra robusto”;
• scambiare velocità iniziale con affidabilità nel tempo.

La trappola è sempre la stessa: il team vede un miglioramento di throughput e lo interpreta come miglioramento di qualità. A volte è vero. Spesso no.

Conclusione: il vantaggio competitivo è il dubbio strutturato 🧠

L’AI non elimina il bisogno di pensiero critico. Lo rende più urgente. Perché se puoi generare dieci soluzioni in dieci minuti, la capacità scarsa non è più produrre opzioni: è scegliere senza auto-ingannarti.

Per uno sprint, prova un esperimento semplice: applica il protocollo C-C-C-D solo alle decisioni ad alto impatto. Poi misura tre cose concrete: bug intercettati prima del merge, requisiti chiariti prima dello sviluppo, rollback evitati.

Se i numeri migliorano, non hai trovato un nuovo “trucco AI”. Hai solo rimesso al centro una vecchia disciplina: pensare meglio prima di costruire.

E oggi, paradossalmente, è l’atto più moderno che possiamo fare.