La tua agenzia scrive il codice con l'AI. Ecco cosa richiedere prima di firmare

Sì, la sua agenzia sta quasi certamente usando l'AI per scrivere parte del suo codice, e va bene così. Quello che non va bene è codice redatto dall'AI che nessun umano ha letto con attenzione e che nessun test esercita, mergiato di venerdì perché la demo era in scadenza. La soluzione non è vietare lo strumento. È una breve lista di controlli da inserire nel contratto e nel repository prima del primo sprint.

Perché questo conta più di due anni fa

Un developer con un assistente di coding può produrre in un pomeriggio una feature che sembra funzionare e che prima richiedeva tre giorni. Questo è reale. Il problema è che revisione, testing e comprensione non sono diventati più rapidi allo stesso ritmo. Se un'agenzia mantiene le stesse abitudini di revisione che aveva prima e triplica il proprio output, ottiene lo stesso tasso di bug per riga applicato a tre volte le righe.

Il debito tecnico un tempo si accumulava a velocità umana. Ora si accumula a velocità di macchina, e in superficie sembra pulito. La prima versione del nostro stesso motore di outreach, descritta nella sezione 4, era una catena di cinque passaggi che si leggeva splendidamente: ogni step ben nominato, ogni funzione commentata con sicurezza, nulla su cui un revisore si sarebbe fermato. Aveva anche cinque punti in cui poteva fallire silenziosamente, e la superficie pulita era esattamente il motivo per cui nessuno metteva in discussione i quattro step extra. Il codice scritto dall'AI è ben formattato e ben nominato, il che è esattamente ciò che spinge un revisore debole a scorrerlo velocemente. Abbiamo scritto della disciplina generale in gestione del debito tecnico. Questo articolo riguarda la versione specifica che emerge quando è un fornitore a scrivere il codice.

Le cinque cose da richiedere

1. Un gate di test che blocca i merge, non una promessa di testing

"Scriviamo test" è una frase. Un gate è una configurazione. Chieda entrambe queste cose prima che il lavoro inizi:

• Branch protection su main così nulla viene mergiato mentre la pipeline è in rosso. GitHub lo documenta sotto protected branches, e ogni host principale ha un equivalente.
• Una soglia di coverage imposta nella CI, non riportata in una slide. Su uno stack TypeScript sono poche righe in una config di Vitest o Jest. Il numero conta meno del fatto che faccia fallire la build quando scende.

Poi faccia una domanda che separa le agenzie: "Può mostrarmi una pull request del mese scorso bloccata da un test fallito?" Se la risposta è "i nostri test non falliscono mai", i test non stanno testando nulla.

2. Un umano nominato che legge ogni diff redatto dall'AI

Gli assistenti producono codice. Non si prendono la responsabilità per esso. Il suo contratto dovrebbe nominare chi lo fa, e il repository dovrebbe dimostrarlo: ogni pull request ha un revisore che non è l'autore, e la revisione ha commenti, non solo una spunta verde.

Stia attento a due anti-pattern:

• Pull request auto-mergiate. Una persona scrive il prompt, una persona approva, stessa persona. Quella è revisione zero.
• Revisione solo da parte dell'AI. I bot di revisione AI colgono lo stile e i bug evidenti. Non sanno che la sua regola di pricing ha un'eccezione IVA per i clienti saudi. L'umano che conosce il dominio deve leggere il diff.

3. Una policy su dipendenze e segreti

Gli assistenti AI amano aggiungere package. Ricorreranno a una libreria per imbottire una stringa. Ognuna è una superficie di supply-chain e una questione di licenza. Richieda:

• Un lockfile committato e una regola secondo cui le nuove dipendenze vengono segnalate nella descrizione della pull request.
• Nessun segreto, dato cliente o codice proprietario incollato in strumenti che si addestrano sugli input. La maggior parte dei livelli enterprise dei principali assistenti offre un'impostazione no-training; il contratto dovrebbe specificare che l'agenzia ne usa una.
• Assegnazione chiara di tutti i deliverable a lei, comunque siano stati prodotti. Le buone agenzie lo fanno già. La clausola sull'AI chiude semplicemente la scappatoia del "ma lo ha scritto uno strumento".

4. Meno righe, non più

Il codice più economico da testare è quello che non è mai stato scritto. L'AI rende indolore generare una pipeline a sei step dove uno solo basterebbe, e ogni step extra è un punto dove si può verificare un fallimento silenzioso.

Lo abbiamo riscontrato nel nostro stesso motore di outreach. Esegue lo scraping del sito di un prospect con un crawler self-hosted e usa un modello locale per redigere un'email su misura per ogni azienda. La prima versione era una catena: estrarre i fatti, riassumere, scegliere un angolo, redigere, perfezionare. Era più lenta, più costosa e, soprattutto, aveva cinque punti in cui poteva andare storta e cinque cose da testare. Collassarla in un'unica chiamata che estrae i fatti e redige in un solo passaggio ha battuto la catena sia in costo che in qualità dell'output, e ha dimezzato la superficie che dovevamo coprire con i test. Abbiamo scritto il caso generale in single call vs agent chains.

Chieda alla sua agenzia come decide quando il codice generato è troppo codice. Se non hanno una risposta, pagherà le righe extra due volte: una per scriverle e una per mantenerle.

5. Una codebase che potrebbe passare a qualcun altro

Il vero test del codice scritto dall'AI è se un nuovo engineer, con o senza assistente, può leggerlo in una settimana. Richieda:

• Decisioni architetturali scritte nel repository, in una breve cartella docs o in un file ADR, non nella cronologia di una chat. Scriva il perché, non solo il cosa. Se la sua agenzia collassa una catena a cinque step in un'unica chiamata, come abbiamo fatto noi, la motivazione va messa vicino al codice, altrimenti il prossimo engineer con un assistente ricostruirà la catena, perché una catena è ciò a cui gli assistenti tendono naturalmente.
• Pattern coerenti tra le feature. Gli assistenti AI divergono. La feature A usa uno stile di accesso ai dati, la feature B un altro, perché sono stati prompted in giorni diversi. Il linting e un piccolo set di template risolvono la maggior parte di questo problema.
• Test di integrazione per i flussi che generano fatturato: signup, checkout, il webhook dal suo payment provider. I unit test sugli helper sono riempitivo a basso costo. L'eccezione IVA saudita della sezione 2 è il tipo di regola che solo un test end-to-end su un checkout reale può individuare, e coprire i tre percorsi in questo modo con uno strumento come Playwright è ciò che protegge il fatturato.

Cosa comporta questo per il preventivo

Si aspetti preventivi corretti più bassi sul boilerplate: schermate CRUD, form, tabelle admin, integrazioni standard. Si aspetti che restino più o meno stabili sulle parti che non erano mai state limitate dalla digitazione: il data model, i casi limite nelle sue regole di business, le performance, e la revisione stessa.

Un'agenzia il cui preventivo è sceso del 60 percento su tutta la linea da quando ha adottato strumenti AI ha tagliato la revisione oppure sta per farlo. Una il cui preventivo non si è mosso affatto probabilmente non sta trasferendo il risparmio. La via onesta nel mezzo è un numero più basso sul lavoro predicibile e una voce per testing e revisione che non si è ridotta. Se sta valutando i modelli di engagement, prezzo fisso vs time and materials spiega come strutturare tutto questo.

Domande da fare alla prima chiamata

• Quali strumenti di coding AI usate, e con quale livello di abbonamento?
• Mostratemi la vostra branch protection e la configurazione CI su un progetto recente.
• Chi revisiona il codice redatto dall'AI, e posso vedere una pull request con commenti di revisione reali?
• Come decidete quando il codice generato è troppo codice?
• Cosa succede al mio codice e ai miei dati dentro gli strumenti che usate?

Risposte chiare e specifiche significano che l'agenzia ci ha pensato. Rassicurazioni vaghe significano che lei è il primo cliente a chiederlo. Abbini queste domande ai più ampi segnali d'allarme nei progetti software e filtrerà la maggior parte del rischio in una singola conversazione.

Il punto centrale

Gli strumenti di coding AI sono un moltiplicatore di velocità. Moltiplichi un team disciplinato e ottiene un team disciplinato che consegna più in fretta. Moltiplichi uno sciatto e ottiene sciatteria su larga scala, con una codebase che sembra eccellente finché non arriva il primo vero incidente. Il suo compito come acquirente non è scegliere lo strumento. È richiedere il gate, il revisore, la policy e il repository leggibile, e poi verificare che esistano.

Se desidera una build dove i test sono nella pipeline e il revisore è nominato prima del primo commit, parliamone.