Il costo della verifica è il vero costo della programmazione con l'IA

Un tempo ponevo una sola domanda quando sceglievo un modello di IA per la programmazione.

Quale modello è abbastanza potente per questo compito?

Questa domanda va bene. Ma non è più la mia prima domanda.

La domanda migliore è: quanto velocemente posso verificare l'output?

Questo approccio cambia il modo in cui utilizzi i modelli a basso costo. Non considerarli come versioni deboli dei modelli più grandi. Considerali come lavoratori per compiti con percorsi di verifica brevi.

Alcuni compiti sono economici da revisionare perché puoi vedere i risultati immediatamente.

• Pulizia dei README • Esempi d'uso • Commenti al codice • Note del changelog • Piccoli script di formattazione • Template per le issue

Se un modello scrive un cattivo paragrafo nel README, te ne accorgi. Elimini la parte errata. L'errore è fastidioso, ma non ti costa quasi nulla. Questo è l'uso migliore per i modelli economici.

La categoria successiva è il lavoro testabile.

Se puoi definire il comportamento previsto ed eseguire una suite di test, usa un modello più economico per la prima bozza. Devi fornire al modello confini chiari.

Non dire: Aggiungi dei test per questo helper.

Dì: Aggiungi test per input vuoti, input null, valori duplicati, configurazione non valida, configurazione predefinita e input normali. Non modificare il codice di runtime.

Questo costringe il modello a lavorare all'interno di un perimetro di verifica.

Alcuni compiti mancano di test automatizzati ma permettono controlli manuali chiari.

• Formattazione dell'output CLI • Esempi di configurazione • Note per la simulazione (dry run) di migrazione • Piccoli script di conversione dati

Per questi, chiedi al modello di includere:

  • Come eseguire il codice
  • Quale input utilizzare
  • Quale output aspettarsi
  • Quali casi limite (edge cases) controllare

Se un modello non è in grado di spiegare come verificare il proprio lavoro, non fidarti del codice.

I piccoli refactoring sono pericolosi. Una diff potrebbe sembrare breve e pulita. Ma il comportamento potrebbe cambiare in un percorso nascosto, in un valore predefinito o in un controllo dei permessi.

Aumenta il tuo livello di rischio quando un compito tocca:

  • Fallback
  • Valori predefiniti
  • Routing
  • Permessi
  • Fatturazione
  • Limiti di frequenza (rate limits)
  • Migrazioni
  • Compatibilità con le versioni precedenti

Questi errori sono difficili da individuare in una revisione del codice standard. Richiedono un contesto profondo.

Suddividi il tuo lavoro in base al costo di verifica:

  • Basso costo di verifica: Usa un modello a basso costo per la bozza.
  • Medio costo di verifica: Usa un modello a basso costo, poi correzioni umane.
  • Alto costo di verifica: Usa un modello potente con test e revisione umana.

La dimensione non conta. Un compito piccolo è costoso se è difficile da verificare.

La parte costosa della programmazione con l'IA non è la generazione. È la fiducia.

Source: https://dev.to/zephyrelabs369/verification-cost-is-the-real-ai-coding-cost-1354

Optional learning community: https://t.me/GyaanSetuAi