22 settembre 2026

Agentic engineering in un contesto bancario: disciplina, repo come fonte di verità e “review del piano”

Come progettare un flusso di lavoro che sfrutti gli agenti senza perdere controllo, qualità e tracciabilità (soprattutto quando audit e compliance non sono opzionali).

Integrare agenti AI nel ciclo di sviluppo non è solo una questione di velocità. In un contesto regolato come quello bancario serve un modello operativo che protegga tracciabilità, sicurezza e responsabilità: specifiche verificabili, piani revisionabili, repository come single source of truth e una ripartizione netta tra ciò che resta umano (gusto, ownership, accountability) e ciò che può essere delegato (typing e boilerplate).

Costruire prodotti digitali in ambito fintech è un esercizio di equilibrio: da una parte la necessità di muoversi velocemente, dall’altra l’obbligo di spiegare e documentare perché una funzionalità esiste, come è stata progettata e chi se ne assume la responsabilità.

Quando aggiungi agenti AI al mix, la tentazione è trattarli come un acceleratore di codice. Ma se il tuo dominio è regolato (banking, assicurazioni, healthcare), l’acceleratore da solo non basta: serve un sistema operativo del prodotto che mantenga disciplina, auditabilità e qualità.

Di seguito raccolgo un modello pratico per rendere l’agentic engineering “adatto alla produzione” senza trasformarlo in caos: repo come fonte di verità, specifiche e piani in chiaro, e un’idea semplice ma potente—non rendere deterministico l’agente, rendi disciplinato il processo.

Determinismo vs disciplina: l’obiettivo non è “controllare l’AI”, è controllare il flusso

Nella vita reale neanche gli esseri umani sono davvero deterministici: due persone che implementano la stessa feature difficilmente produrranno lo stesso identico codice. Il punto, quindi, non è pretendere output identici, ma costruire un processo affidabile.

“Affidabile” in questo contesto significa:

  • specifiche chiare e verificabili
  • decisioni tracciate
  • cambiamenti piccoli e revisionabili
  • controlli automatici e manuali nei punti giusti

Se il processo è solido, l’agente diventa un moltiplicatore. Se il processo è fragile, l’agente amplifica solo l’entropia.

Il problema classico: BRD giganteschi e responsabilità diffuse

Molte organizzazioni partono da un flusso simile:

  1. esiste un problema di business
  2. viene prodotto un documento (spesso enorme)
  3. qualcuno lo “traduce” in requisiti di prodotto
  4. i team ingegneristici devono dedurre acceptance criteria, edge case e implementazione
  5. si rilascia, si corregge, si reitera

Questo ciclo funziona finché la complessità è gestibile. In un dominio regolato, però, si aggiunge un vincolo duro: devi poter ricostruire le decisioni. Non solo cosa hai fatto, ma perché lo hai fatto in quel modo.

Spostare il baricentro: il repository come “single source of truth”

Un passaggio chiave è decidere dove vive la verità operativa.

Documentazione e strumenti rimangono utili (wiki, tool di design, issue tracker), ma per rendere davvero produttivi team e agenti serve un punto centrale, versionato e vicino al codice.

Scelta pragmatica:

  • le specifiche e i piani di implementazione vivono nel repository
  • possono essere issue strutturate o file Markdown (ADR, RFC, spec)
  • ogni decisione rilevante rimane collegata a commit, PR e release

In un contesto di audit, questo cambia le regole del gioco: quando arriva una domanda scomoda (“perché questa logica calcola X così?”), hai una catena di evidenze più corta e più robusta.

Ruoli più fluidi, ma responsabilità più chiare

Un effetto collaterale interessante dell’adozione di agenti è che “i confini” tra funzioni tendono ad ammorbidirsi.

  • Product resta owner del problema: persona, obiettivo, vincoli, priorità.
  • Design resta owner della soluzione UX/UI, ma può aprire il processo: far sperimentare altri membri del team sui flussi, dentro un design system.
  • Engineering non è solo esecuzione: deve garantire confini, invarianti, architettura, qualità operativa.

Gli agenti aiutano a generare varianti, scenari, edge case, alternative. Ma la proprietà del risultato deve restare umana.

Qui vale una regola semplice:

Gusto, accountability e ownership restano sul lato umano.

Il resto—boilerplate, typing, refactoring ripetitivo—si può delegare con più serenità.

“Review del piano” invece di “review del mega-PR”

Uno dei punti più concreti è cambiare cosa si revisiona.

In ambienti dove la review è obbligatoria (e spesso lo è), il rischio è finire con PR ingestibili: decine di file, migliaia di righe, scarsa comprensione, alta probabilità di errori.

Un approccio più sostenibile è:

  1. Specifiche approvate (incluse le funzioni di controllo: compliance, risk, security quando serve)
  2. Piano di implementazione dettagliato, grande quanto basta per essere utile
  3. Task piccoli, abbastanza granulari da essere:
    • prodotti dall’agente
    • revisionati da umani e/o agenti
    • testati e rilasciati in modo incrementale

Il risultato è una review che valuta prima la traiettoria (piano), poi l’esecuzione (task). E questa è una differenza enorme quando vuoi velocità senza perdere governance.

Dove mettere gli umani: security, privacy e confini del rischio

Se vuoi usare agenti in produzione, la domanda “dove metto l’intervento umano?” deve avere una risposta esplicita.

Una divisione efficace è:

  • Agenti su parti a basso rischio e ad alto volume (es. wiring, UI ripetitiva, mapping, refactor meccanici)
  • Umani su:
    • GDPR e trattamento dati
    • security e compliance
    • remediation da penetration test
    • autorizzazioni, token, sessioni, confini di trust

Non perché l’agente “non sia capace”, ma perché in quei punti la responsabilità è indelegabile e la dimostrazione di controllo deve essere semplice.

Un modello a strati per ridurre il rischio (senza fermare la delivery)

Invece di discutere in modo astratto se “l’AI è sicura”, conviene strutturare una pipeline di verifiche. Un esempio realistico:

  1. Spec umana (con vincoli e acceptance criteria)
  2. Static checks e test (lint, typecheck, unit test)
  3. Dynamic checks (integrazione, end-to-end, security test/DAST)
  4. Review dell’agente (per coerenza e regressioni evidenti)
  5. Review umana mirata (punti critici)
  6. Release management con gate finale

Questo non è “burocrazia”: è una forma di risk budgeting. Automatizzi tutto ciò che può essere automatizzato, e conservi energie umane dove hanno impatto.

Seniority dopo gli agenti: non è (più) “sapere il framework a memoria”

L’arrivo degli agenti mette pressione su una definizione di seniority troppo legata al dettaglio sintattico.

Se il tuo valore è “conosco React Native a memoria”, il giorno in cui l’agente scrive quel codice meglio e più in fretta, ti senti spiazzato.

Ma la seniority vera inizia dove l’agente fatica:

  • ragionare per invarianti e confini
  • fare system design e threat modeling
  • capire perché una scelta è giusta per quel dominio
  • orchestrare il lavoro (umani + agenti)
  • alzare la qualità del team: mentoring, review, cultura operativa

In pratica: meno “abilità di digitazione”, più capacità di guidare sistemi.

Il rischio reale: la “cognitive surrender”

Il nemico non è l’AI. È la resa cognitiva: copiare/incollare output senza validazione, perché “sembra giusto”.

Questo atteggiamento esisteva già (ricette trovate online, snippet non compresi), ma gli agenti lo rendono più pericoloso perché l’output è più convincente.

L’antidoto è culturale e processuale:

  • chiedere sempre prove (test, metriche, reasoning, trade-off)
  • rendere obbligatorio il collegamento tra spec → piano → task → PR
  • misurare la qualità (defect rate, lead time, rollback) invece di misurare “righe prodotte”

Sintesi: agenti sì, ma dentro un sistema che regge

Un’adozione efficace dell’agentic engineering non parte dal prompt perfetto: parte dal modello operativo.

Se vuoi portare questo approccio nel tuo team già da domani, l’implicazione pratica è chiara:

  • sposta specifiche e piani nel repository
  • rendi piccole le unità di cambiamento
  • revisiona il piano prima del codice
  • automatizza i controlli, ma mantieni umani sui punti di rischio
  • ridefinisci la seniority come capacità di design, governance e responsabilità

Gli agenti possono aumentare la velocità. La disciplina aumenta l’affidabilità. In un prodotto reale—e soprattutto in un dominio regolato—servono entrambe.