Un builder di app AI può gestire React e Flutter?

Creare un client web React e un client mobile Flutter con due strumenti AI distinti sembra sensato finché non cambia la prima regola condivisa. A quel punto uno strumento aggiorna il flusso nel browser, l'altro conserva l'ipotesi di ieri e il database accetta entrambe le versioni. Quella che sembrava una divisione del lavoro è diventata un'attività di integrazione.

Per la maggior parte dei piccoli team, un solo builder di app AI è la scelta migliore, a condizione che possa produrre basi di codice separate per React, Flutter e backend, esporre il sorgente e consentire a ogni client di essere rilasciato in modo indipendente. «Un solo builder» dovrebbe significare un unico contesto di pianificazione e un unico contratto di sistema. Non dovrebbe significare un'unica applicazione gigantesca, un solo ciclo di rilascio o il tentativo di condividere il codice dell'interfaccia tra TypeScript e Dart.

L'alternativa può funzionare. Due strumenti specialistici hanno senso quando team web e mobile separati gestiscono già i propri client, il contratto API è governato al di fuori di entrambi gli strumenti e l'organizzazione accetta il costo del coordinamento. Senza queste condizioni, il secondo strumento aggiunge un confine che qualcuno dovrà sorvegliare per tutta la vita del prodotto.

Ti serve un builder di app AI o due?

Scegli un solo builder quando lo stesso prodotto, backend, modello dati e sistema di identità servono entrambi i client. Scegline due solo quando la specializzazione per piattaforma vale più del contesto condiviso e hai persone incaricate di mantenere il confine.

I punteggi seguenti presuppongono un fondatore o un piccolo team di prodotto, una API Go, un database PostgreSQL, un client web React e un client mobile Flutter. Un punteggio di 5 significa che l'approccio gestisce l'aspetto con poco coordinamento manuale. Un punteggio di 1 significa che il team deve costruire e sorvegliare da sé il collegamento mancante.

Questi numeri aiutano a decidere, non sono un benchmark di prodotto. Se un candidato non può esportare il sorgente, non può modellare un backend reale o costringe web e mobile in un unico deployment, riduci nettamente il suo punteggio. Allo stesso modo, una configurazione con due strumenti può guadagnare punti quando un team di piattaforma maturo gestisce il contratto API, il servizio di identità, la policy di rilascio e i test di compatibilità.

Non contare schermate o prompt. Conta le autorità. Ti serve un'unica autorità per ogni fatto di business, un contratto API, una policy di identità e una sequenza di migrazione. React e Flutter sono consumer di queste decisioni.

La logica di business condivisa sta dietro entrambi i client

Metti nel backend permessi, regole di prezzo, transizioni dei flussi, quote e convalide che proteggono i dati archiviati. React e Flutter possono ripetere controlli leggeri per offrire un riscontro rapido, ma l'API deve prendere la decisione finale.

Spesso i team chiamano «logica condivisa» due cose diverse. Il codice sorgente condiviso significa che entrambi i client importano la stessa implementazione. Il comportamento di business condiviso significa che entrambi i client ricevono lo stesso risultato da un'unica autorità. React e Flutter usano linguaggi e modelli di interfaccia diversi, quindi forzare la condivisione dell'implementazione tra loro crea di solito una terza astrazione più difficile da capire di entrambi i client. Condividi invece il comportamento tramite l'API.

Supponi che un ordine possa passare da draft a submitted solo se contiene almeno una riga e l'account è attivo. Se ogni client gestisce quella regola, presto ne esistono quattro versioni: il controllo del modulo React, lo stato del pulsante Flutter, il gestore di invio web e il gestore di invio mobile. Una modifica alla policy deve arrivare ovunque prima che qualunque client pubblichi una release. Una build mobile meno recente può restare installata per mesi.

Il backend dovrebbe esporre l'azione consentita e applicarla di nuovo quando l'azione arriva:

{
  "order_id": "ord_4821",
  "status": "draft",
  "allowed_actions": ["submit"],
  "version": 7
}

I client decidono come rendere l'azione. Il server decide se submit è consentito alla versione 7. Se un'altra richiesta modifica prima l'ordine, il server restituisce un conflitto invece di lasciare che l'ultimo autore vinca in silenzio.

La documentazione di React raccomanda un'unica fonte della verità per ogni parte dello stato. Questa indicazione si applica all'interno dell'albero del browser, non a un intero prodotto con più client. Il genitore comune di un'app web e di un'app mobile è il contratto del backend. Spostare lì lo stato di business durevole segue la stessa idea sul confine del sistema.

La guida all'architettura di Flutter separa viste e view model da repository e servizi. Dice anche che i servizi incapsulano endpoint API esterni e che i repository trasformano i loro risultati in modelli di dominio. È un buon confine lato client. Non interpretare il repository come il permesso di ricostruire in Dart la policy del server. Un repository mobile può memorizzare nella cache, ritentare e mappare dati, ma non deve diventare una seconda autorità per decidere se un ordine può essere inviato.

Alcune logiche restano giustamente specifiche del client: formattazione dell'input, presentazione offline, navigazione, animazioni e gestione dei permessi del dispositivo. Un'app mobile può accodare una bozza offline, mentre l'app web salva subito. Una volta connessi, entrambi devono inviare lo stesso comando alla stessa regola sul server.

PostgreSQL deve stare dietro un'API

Né un bundle React né un'applicazione Flutter dovrebbero connettersi direttamente a PostgreSQL. Sono entrambi client distribuiti, il cui codice e dettagli di connessione possono essere ispezionati, copiati e modificati dagli utenti.

Il manuale di PostgreSQL descrive l'autenticazione del client come la decisione del server del database se consentire a un client di connettersi con l'utente database richiesto. Questo meccanismo protegge una connessione al database. Non sa che Alice può modificare l'ordine 42 ma non il 43, oppure che una vecchia build mobile non deve usare una nuova transizione del flusso. L'autorizzazione applicativa appartiene all'API.

Una connessione diretta da React è particolarmente insostenibile perché il browser avrebbe bisogno di accesso di rete al database e di credenziali disponibili al codice scaricato. Inserire una password in Flutter la nasconde solo finché qualcuno non estrae l'applicazione. La sicurezza a livello di riga può aggiungere protezione dentro PostgreSQL, ma non trasforma un client non affidabile in un peer sicuro del database. Servono comunque endpoint stabili, controlli di frequenza, limiti sugli input, contesto di audit e un punto in cui far evolvere gli schemi senza interrompere le build installate.

Usa una topologia con un unico confine applicativo pubblico:

React client  \
               -> HTTPS API -> domain rules -> PostgreSQL
Flutter client /

Assegna all'API un ruolo database con privilegi limitati. Tieni le credenziali di migrazione fuori dall'applicazione in esecuzione. Esegui le migrazioni come attività di deployment separata, con una propria revisione e un proprio piano di recupero. Questa divisione limita ciò che può fare un processo API compromesso e impedisce a entrambi i client di conoscere le credenziali del database.

Talvolta due strumenti AI producono due backend perché ognuno vuole un progetto completo. Rifiuta questo risultato, a meno che due servizi non siano una separazione intenzionale del dominio. Un backend web e uno mobile che scrivono sulle stesse tabelle creano autorizzazioni duplicate, transazioni incoerenti e due punti da riparare a ogni modifica dello schema. Un sottile backend-for-frontend può essere ragionevole quando ogni client richiede forme di risposta diverse, ma questi adattatori dovrebbero chiamare lo stesso servizio di dominio invece di aggirarlo per scrivere direttamente.

Verifica il confine con un controllo semplice ma efficace. Cerca nei repository React e Flutter generati stringhe di connessione PostgreSQL, variabili host del database, driver SQL e credenziali di servizi con privilegi. Trovarne anche una nel codice client fa fallire la revisione architetturale. La configurazione client prevista contiene solo un URL base dell'API, configurazione pubblica dell'identità e impostazioni non segrete delle funzionalità.

Anche le migrazioni del database richiedono compatibilità con le versioni precedenti. Aggiungi prima una colonna nullable o una nuova tabella, distribuisci codice che gestisca entrambe le forme, esegui il backfill se necessario, cambia le letture e rimuovi il vecchio campo solo quando i client supportati non ne dipendono più. La distribuzione mobile allunga quest'ultimo intervallo più di quanto si aspettino molti team che lavorano solo sul web.

L'autenticazione ha un'unica autorità e due adattatori client

Usa un solo emittente di identità, un solo record utente e una sola policy di autorizzazione lato server, poi implementa adattatori di sessione distinti per browser e mobile. L'autenticazione dimostra chi è il chiamante. L'autorizzazione decide cosa può fare. Confonderle produce endpoint che accettano un token valido e poi si fidano del client per nascondere azioni vietate.

Il client React in genere lavora con reindirizzamenti del browser, cookie o token, protezioni dalle richieste cross-site e schede che possono entrare in competizione durante il rinnovo. Flutter deve gestire deep link, sospensione dell'applicazione, archiviazione sul dispositivo e callback del sistema operativo. Queste differenze giustificano codice client separato. Non giustificano directory utenti separate o significati diversi per i ruoli.

La Mobile Application Security Cheat Sheet di OWASP sconsiglia di inserire le credenziali nel codice e raccomanda token di accesso sicuri e revocabili, archiviati tramite meccanismi sicuri specifici della piattaforma. Segui il principio, ma ricorda cosa può e non può fare l'archiviazione sicura. Riduce il furto occasionale dei token dai file. Non può rendere affidabile un dispositivo compromesso, quindi l'API controlla comunque scadenza, audience, emittente, stato dell'account e autorizzazione in ogni operazione protetta.

Scrivi il contratto di autenticazione prima di chiedere a uno dei client di implementare le schermate:

Access token: short lived, sent to the API
Refresh mechanism: rotated or invalidated by the identity system
Logout: ends the local session and revokes server-side refresh authority
Account disabled: API rejects new operations even if a client still shows cached data
Role changed: next authorized request uses current server policy

Il test più rivelatore non è un accesso riuscito. Disabilita un account mentre entrambi i client sono aperti. La richiesta protetta successiva di ciascun client dovrebbe fallire nello stesso modo, i dati privati locali dovrebbero essere cancellati secondo la policy e nessuno dei due client dovrebbe tentare il rinnovo all'infinito. Poi modifica un ruolo e verifica che una schermata non aggiornata non possa eseguire la vecchia azione.

Evita di conservare la verità sui ruoli nelle claim del token più a lungo di quanto tu possa tollerare un'autorizzazione non aggiornata. Le claim possono aiutare l'interfaccia a renderizzare rapidamente, ma il server dovrebbe consultare la policy corrente per le operazioni sensibili. Se una modifica del ruolo deve avere effetto immediato, un token autosufficiente a lunga durata con i vecchi ruoli va contro questo requisito.

Un builder ottiene 4 invece di 5 in questo punto perché un contesto condiviso non elimina il lavoro di sicurezza specifico per piattaforma. Un builder può generare entrambi gli adattatori, ma una persona deve comunque testare reindirizzamenti del browser, deep link mobile, conflitti nel rinnovo, sfasamento dell'orologio, revoca e comportamento al ripristino del dispositivo.

Un contratto mantiene onesti React e Flutter

Tratta la descrizione dell'API come un input di build per entrambi i client e una promessa di compatibilità per le versioni rilasciate. Un prompt in prosa non è un contratto perché due esecuzioni di generazione possono interpretare la stessa frase in modo diverso.

OpenAPI è una scelta pratica per API HTTP. Definisci campi di richiesta, campi di risposta, corpi degli errori, requisiti di autenticazione e identificatori stabili delle operazioni. Genera o mantieni manualmente client TypeScript e Dart sottili a partire dal documento, poi conserva il comportamento dell'applicazione in normali hook React e repository Flutter. Il codice client generato dovrebbe essere sostituibile. Non nascondervi decisioni di prodotto.

Questo frammento rende esplicito un conflitto di versione:

/orders/{orderId}/submit:
  post:
    operationId: submitOrder
    requestBody:
      required: true
      content:
        application/json:
          schema:
            type: object
            required: [expected_version]
            properties:
              expected_version:
                type: integer
    responses:
      "200":
        description: Order submitted
      "409":
        description: Order changed since the client loaded it

La fonte della verità è il comportamento del server insieme al contratto verificato. I tipi TypeScript e Dart generati sono proiezioni. Se uno strumento modifica un tipo client senza cambiare il contratto, la build dovrebbe sovrascrivere o rifiutare quella modifica.

I test di contratto dovrebbero esercitare comportamenti che gli schemi statici non possono esprimere. Invia un ordine vuoto e aspettati lo stesso codice di errore dalle richieste create da entrambi i client. Ripeti una richiesta con un expected_version vecchio e aspettati 409. Invia un valore enum sconosciuto a un fixture di client meno recente e verifica che adotti un fallback sicuro invece di bloccarsi.

Favorisci modifiche additive all'API. Nuovi campi di risposta opzionali sono in genere sicuri quando i client ignorano i campi sconosciuti. Rimuovere un campo, rendere obbligatorio un campo facoltativo o riutilizzare un valore enum con un nuovo significato può interrompere una build mobile installata. Versiona un endpoint solo quando non puoi preservarne il significato. Gli incrementi di versione di routine spostano soltanto il peso della compatibilità in più directory.

C'è una raccomandazione diffusa di condividere modelli di dominio in un pacchetto multipiattaforma. Sembra efficiente perché ordine, account e fattura compaiono in entrambi i client. In pratica, i pacchetti TypeScript e Dart richiedono comunque comportamenti separati per serializzazione, valori null, date e strumenti di rilascio. Genera le forme di trasporto da un unico contratto, poi lascia che ogni client le trasformi in modelli di interfaccia locali. Le definizioni condivise sono utili. Un modello runtime condiviso forzatamente non lo è.

Un contratto rende più praticabili anche due strumenti. Offre a ciascuno un confine che non può reinterpretare con leggerezza. Tuttavia qualcuno al di fuori di entrambe le sessioni di generazione deve gestire le modifiche al contratto, i controlli di compatibilità e le note di rilascio. Se nessuno ha questo compito, il contratto resterà indietro rispetto alle implementazioni.

I cicli di rilascio dovrebbero restare indipendenti

Rilascia il client web, il client mobile e l'API secondo calendari separati anche quando un solo builder crea tutti e tre. La generazione coordinata non richiede un deployment coordinato.

React può spesso raggiungere gli utenti pochi minuti dopo il deployment. Le release mobile passano dalla revisione dello store e gli utenti possono rimandare gli aggiornamenti. L'API deve quindi supportare la build web corrente e ogni versione mobile ancora nella finestra di supporto del team. Un piano di rilascio che presuppone l'aggiornamento simultaneo di tutti i client fallirà alla prima revisione in ritardo o al primo rollout graduale.

Usa una matrice di compatibilità per ogni modifica:

Le parole nelle celle contano più dei numeri di versione. Costringono il team a dichiarare cosa fa davvero un client meno recente. Mantieni la matrice nel piano di modifica e trasforma le sue affermazioni in test quando possibile.

Un rollout sicuro di una funzionalità segue spesso questo ordine:

1. Aggiungi strutture di database e comportamento API compatibili con le versioni precedenti.
2. Rilascia client che comprendono la nuova risposta ma mantengono nascosta la funzionalità.
3. Osserva errori e segnali di compatibilità prima di abilitare le scritture.
4. Abilita la funzionalità tramite una capacità controllata dal server o un'impostazione dell'account.
5. Rimuovi i vecchi percorsi solo dopo la chiusura della finestra di supporto.

I feature flag sono utili per l'esposizione, non per riparare schemi incompatibili. Se un vecchio client si blocca analizzando un nuovo campo obbligatorio o un enum, disattivare un pulsante dopo l'avvio non lo salverà. La compatibilità appartiene al progetto del payload.

Due strumenti possono essere forti nel packaging specifico per piattaforma. Un builder orientato al mobile può capire meglio metadati dello store e autorizzazioni del dispositivo, mentre un builder orientato al web può gestire bene il deployment nel browser. Assegna all'approccio con due strumenti un punteggio di release più alto solo se questi punti di forza superano il lavoro aggiuntivo di coordinare preparazione dell'API, esposizione della funzionalità e finestre di supporto.

Mantieni visibili gli identificatori di release nei log e nei rapporti di errore. Ogni richiesta API dovrebbe portare un nome client non segreto e un identificatore di build, così gli operatori possono distinguere una regressione del browser da un comportamento di una vecchia versione mobile. Non fidarti di quell'identificatore per l'autorizzazione, perché un client può falsificarlo.

Il rollback ha tre significati diversi

Rollback del client, rollback del server e rollback dei dati risolvono errori diversi e richiedono procedure separate. Trattarli come un solo pulsante «annulla» trasforma una release recuperabile in dati persi.

Un deployment React può di solito reindirizzare il traffico a un artefatto precedente. Un rollback mobile significa spesso fermare un rollout graduale e inviare una build corretta. I dispositivi già aggiornati possono conservare la versione difettosa. L'API deve tollerare entrambe le versioni durante quell'intervallo.

Il codice server può essere ripristinato solo se il database resta compatibile con il binario precedente. Una migrazione additiva spesso lo consente. Una migrazione che rinomina una colonna sul posto, ne riscrive il significato o elimina dati potrebbe non consentirlo. Usa migrazioni expand-and-contract: aggiungi la nuova rappresentazione, lascia operare entrambe le versioni del codice, sposta i dati, cambia le letture e rimuovi la vecchia rappresentazione in seguito.

Il rollback dei dati è quello pericoloso. Ripristinare uno snapshot del database cancella scritture valide eseguite dopo lo snapshot. Per molti incidenti in produzione, una riparazione in avanti è più sicura: distribuisci codice corretto, identifica le righe coinvolte con una query di audit e applica una modifica compensativa mirata. Gli snapshot proteggono dalle catastrofi, ma non sostituiscono con leggerezza una migrazione reversibile.

Esaminiamo un errore tipico. Il deployment dell'API aggiunge delivery_window come campo obbligatorio. Il nuovo client web lo invia. La build mobile in revisione non lo fa. Il team modifica la colonna del database in NOT NULL e i vecchi invii mobile iniziano a restituire errori del server. Ripristinare soltanto il client web non cambia nulla. Ripristinare solo l'API può fallire se il vecchio binario non riesce a leggere il nuovo schema. Ripristinare l'intero database eliminerebbe ordini non correlati.

Il recupero corretto consiste nel fare accettare all'API un campo mancante, assegnare un valore predefinito documentato o rinviare la transizione, e restituire il campo come facoltativo finché il supporto mobile non è abbastanza diffuso. Il team può quindi riparare i record interessati senza riavvolgere scritture non correlate. L'errore originale non era l'assenza di un pulsante di rollback. Era una sequenza incompatibile.

Per ogni modifica, scrivi queste quattro righe prima del deployment:

Web rollback: artifact and routing action
Mobile containment: rollout stop, affected builds, fixed build path
API rollback: compatible binary and schema range
Data repair: query, owner, backup point, and forward correction

Un builder aiuta quando i suoi snapshot e la sua cronologia di pianificazione coprono la modifica correlata, ma verifica l'ambito. Uno snapshot del sorgente, un artefatto distribuito e un backup PostgreSQL sono risorse diverse. Un test di rollback convincente ripristina ogni risorsa in un ambiente usa e getta e dimostra che il vecchio client può ancora completare il suo principale flusso di scrittura.

Due builder aumentano la responsabilità di integrazione

Due strumenti non dimezzano la manutenzione. Creano due storie di generazione, due serie di ipotesi e una superficie di integrazione che vive al di fuori di entrambi.

Il primo mese può sembrare più rapido perché ogni strumento produce codice familiare per la piattaforma. Il costo emerge quando una modifica attraversa il confine: rinominare un campo, cambiare un permesso, aggiungere uno stato dell'account, modificare il comportamento di logout o deprecare un endpoint. Ogni prompt deve includere il contratto corrente e le conseguenze dello stato di rilascio dell'altro client. Omettere un dettaglio produce codice plausibile che compila e viola comunque il comportamento del prodotto.

Lo schema di errore è prevedibile. Lo strumento web aggiunge archived a un enum e lo visualizza correttamente. Lo strumento mobile considera ancora i valori sconosciuti un errore di analisi. L'API viene distribuita per prima, un record archiviato appare nell'elenco di un utente e la schermata mobile smette di caricare tutti i record. Ogni modifica locale sembrava ragionevole. Nessuno ha testato la combinazione tra versioni.

La manutenzione richiede un responsabile e un pacchetto di modifica ripetibile:

• La modifica di comportamento e la regola del server che la gestisce
• La differenza nell'API e nella migrazione
• I casi di accettazione React
• I casi di accettazione Flutter
• L'ordine di rilascio e i limiti del rollback

Questo pacchetto è utile anche con un solo builder, ma un unico contesto di pianificazione può tenerlo collegato all'intera modifica. Con due strumenti, il team deve copiarlo tra i due, registrare entrambi gli output e riconciliare le modifiche in conflitto. L'automazione può rilevare la deriva dello schema, ma non può decidere quale interpretazione rispecchi il prodotto.

Non presumere che l'esportazione del sorgente elimini la dipendenza dallo strumento. Il codice esportato ti dà la custodia, e questo conta, ma la manutenibilità dipende da una struttura leggibile, test, scelte sulle dipendenze, istruzioni di build e un percorso pulito per rigenerare solo ciò che è cambiato. Esamina un progetto generato come se il builder sparisse domani. Uno sviluppatore React competente può rilasciare il client web, uno sviluppatore Flutter può compilare l'app mobile e uno sviluppatore backend può migrare PostgreSQL senza la cronologia originale della chat?

Monitora la manutenzione con elementi concreti: fallimenti dei test di contratto, tempo dedicato a riconciliare modifiche generate, numero di modifiche manuali perse alla rigenerazione, versioni client non supportate e risultati delle prove di recupero. Evita una metrica di vanità come le righe di codice condiviso. Una piccola quantità di mapping di presentazione duplicato può costare meno di un livello di condivisione sofisticato.

Due builder diventano ragionevoli quando due team operano già in questo modo. Ogni team gestisce il proprio client, un gruppo di piattaforma gestisce API e identità e i test automatici di compatibilità vengono eseguiti prima della release. In questo contesto, gli strumenti si adattano all'organizzazione. Un fondatore da solo non dovrebbe imitare un organigramma che non possiede.

Come dovresti decidere?

Scegli l'approccio dimostrando una modifica tra client, non confrontando la velocità con cui ogni strumento disegna la prima schermata. La prova dovrebbe includere una modifica allo schema, una regola di autorizzazione, una build mobile meno recente, release indipendenti e una prova di rollback.

Chiedi ai candidati con un solo builder di creare una piccola fetta verticale: client React e Flutter inviano lo stesso comando d'ordine a un'API Go supportata da PostgreSQL. Modifica la regola dopo che entrambi i client funzionano. Aggiungi un campo facoltativo, nega un ruolo, rilascia solo la modifica web e ripristina il precedente artefatto del server senza perdere nuove righe. Esporta il sorgente ed esegui i test fuori dall'interfaccia del builder.

Chiedi ai candidati con due strumenti di svolgere la stessa sequenza usando un documento OpenAPI verificato fornito a entrambi. Misura quanti fatti devi copiare tra le sessioni e quanto spesso uno strumento modifica elementi fuori dal proprio confine. Includi il tempo necessario per diagnosticare la deriva, non solo il tempo di generazione.

Usa un solo builder se supera queste soglie:

• Crea progetti React, Flutter e backend separati attorno a un unico contratto.
• Mantiene PostgreSQL dietro il backend e i segreti fuori dai client.
• Supporta release indipendenti di client e server.
• Espone sorgente, stato del deployment e punti di recupero distinti.
• Il suo codice generato può essere compilato e testato senza dipendere dalla cronologia della chat.

Scegli due strumenti quando una capacità specialistica cambia in modo sostanziale il risultato mobile o web e una persona nominata gestisce il governo del contratto. «L'output mobile era più bello» non basta. Integrazione con il dispositivo, comportamento di accessibilità, packaging per lo store, funzionamento offline o una competenza già presente nel team possono bastare se il beneficio resiste al calcolo della manutenzione.

Koder.ai può generare applicazioni React, Go con PostgreSQL e Flutter da un unico contesto di chat, con modalità di pianificazione, esportazione del sorgente, deployment e hosting, snapshot e rollback. Questa combinazione si adatta all'architettura con un solo builder descritta qui, ma dovresti comunque eseguire il test della fetta verticale perché un elenco di funzionalità non può dimostrare il tuo percorso di rilascio e recupero.

La decisione può cambiare in seguito. Un sistema con confini chiari consente a un team di sostituire il generatore React, quello Flutter o entrambi senza spostare le regole di business fuori dall'API. Fai in modo che la prima architettura preservi questa possibilità.

Il test scomodo è semplice: se lo strumento mobile sparisse il giorno della release, potresti spiegare il contratto API attuale, compilare il client esportato e continuare a pubblicare? Se la risposta dipende dai prompt ricordati, correggi il modello di responsabilità prima di aggiungere un altro strumento.