Presentiamo il Citizen Developer SDLC di Tenex, un ciclo di vita in sei fasi che trasforma ciò che i dipendenti non tecnici costruiscono con l'IA da prototipo personale a produzione governata su cui l'intera azienda può fare affidamento.
Di Alex Lieberman (@businessbarista), Arman Hezarkhani (@ArmanHezarkhani, Suchi Patel e Ashwin Kadaru (@AshwinKadaru
Un framework di Tenex.co.
Il riepilogo
Il Citizen SDLC è un ciclo di vita in sei fasi (idea, portale d'ingresso, triage, provisioning, build, esecuzione e modifica) che trasforma il software costruito da dipendenti non tecnici con l'IA da prototipo personale a produzione governata. Un principio attraversa ogni fase: l'IA fa il lavoro, il codice deterministico imposta i guardrail e gli umani gestiscono le eccezioni. Esiste perché l'IA ha ridotto il costo di scrivere codice a quasi zero e ha spostato il collo di bottiglia a valle, assicurandosi che ciò che viene costruito sia solido e mantenendo governata una flotta crescente di applicazioni una volta in produzione.
Uno dei nostri clienti è una società di investimento. Un membro del loro team di operazioni di portafoglio, una persona che non ha mai scritto una riga di codice, ha costruito la dashboard che tutto il suo team usa ora ogni giorno. Tiene traccia del lavoro di creazione di valore in diverse dozzine di società in portafoglio. L'ha costruita chiedendo a Claude, iterando per circa due mesi. Ogni singola riga è stata scritta dall'IA.
Ed è valida. Le visualizzazioni sono corrette, il flusso di lavoro si adatta al modo in cui il team opera realmente e l'adozione è stata immediata. Ha abbozzato il prodotto corretto prima che qualsiasi ingegnere fosse coinvolto.
Non è fortuna. Per decenni, la persona che capiva un problema aziendale non era quasi mai la persona che poteva costruire il software per risolverlo. Colmare quel divario era uno sforzo titanico: un product manager per trasformare il suo problema in un capitolato, ingegneri per tradurre il capitolato in codice e un posto in coda dietro tutto il resto nella roadmap. Passavano mesi tra l'idea e lo strumento, e ciò che finalmente veniva rilasciato era l'interpretazione di qualcun altro di ciò che lei intendeva.
Quel divario è appena crollato. Il potere di costruire è passato alle persone che capiscono realmente il processo, sanno cosa significano i dati e vivono il flusso di lavoro ogni giorno. Ha costruito la cosa giusta al primo tentativo perché era la fonte. Nessuno si è messo in mezzo per tradurla, o per fraintenderla leggermente. Questa è la promessa del citizen development, e lei l'ha mantenuta.
Poi abbiamo guardato sotto il cofano.
L'intera applicazione era un singolo file HTML. 540 KB. Circa 5.300 righe. Il dataset principale viveva al suo interno come un blob di dati da 80 KB su una singola riga. Quando il file necessitava di aggiornamenti, l'IA aveva aggiunto funzioni di patch che riscrivevano i valori ogni volta che l'app veniva caricata. Salvare il lavoro significava che l'app riscriveva il proprio HTML, si scaricava sul laptop e tu lo ricaricavi su un drive condiviso come nuova versione. Se due persone modificavano contemporaneamente, vinceva l'ultimo salvataggio e le modifiche dell'altra persona sparivano.
Un giorno, una funzione di salvataggio ha cercato un marcatore nel file, non lo ha trovato e ha riscritto comunque ciò che aveva. L'intera applicazione da 540 KB è stata troncata a 7 byte. In una singola scrittura silenziosa, la dashboard su cui il suo team faceva affidamento ogni giorno ha cessato di esistere, e nulla nel modo in cui era stata costruita era progettato per intercettarlo, fermarlo o ripristinarlo.
La maggior parte dei leader, sentendo questa storia, conclude che il citizen development è una responsabilità da eliminare. Noi pensiamo che sia la lezione sbagliata e che le aziende che agiscono di conseguenza perderanno. La lezione giusta: lei ha fatto il suo lavoro brillantemente. Nessuno aveva costruito la strada su cui il software potesse viaggiare.
Il collo di bottiglia si è spostato
Per decenni, costruire software è stata la parte costosa. Era lento, scarso e costoso, e l'intero ciclo di vita dello sviluppo software è cresciuto per proteggerlo. Specifiche, ticket, sprint, code review: ogni cerimonia nel SDLC tradizionale esiste perché scrivere il codice era il collo di bottiglia.
L'IA ha ridotto quella fase a quasi zero e il collo di bottiglia si è spostato. Quando chiunque può costruire un'app funzionante in un pomeriggio, il lavoro costoso non è più la costruzione. È ciò che viene dopo: assicurarsi che ciò che è stato costruito sia solido e sicuro, e mantenere governata una flotta crescente di queste app una volta in produzione.
GIF
E la costruzione non sta rallentando, creando due problemi da risolvere:
Primo, qualità sotto il cofano. Un agente guidato da una pagina vuota da un non-ingegnere converge su software raffazzonato che funziona oggi ed è impossibile da mantenere per sempre. Il file da 540 KB non è un'eccezione; è l'output predefinito della costruzione senza binari.
Secondo, proliferazione. Ogni team vuole la propria app e nessun gruppo IT centrale può costruire e gestire manualmente dozzine di esse. Senza guardrail, ognuna viene costruita sullo stack che il costruttore o il modello ha scelto: un database diverso, uno schema di autenticazione diverso, segreti nascosti dove capitano. Blocca le richieste e loro non si fermano, si spostano solo fuori dai radar. In entrambi i casi, erediti non solo una flotta di app, ma anche il groviglio di infrastrutture sottostanti, e nulla di tutto ciò è qualcosa che l'IT possa ragionevolmente proteggere, supportare o spiegare.
Quindi la vera domanda che ogni azienda sta per affrontare è: come si fa a permettere al personale non tecnico di rilasciare software interno reale senza ereditare quella flotta?
Le tre risposte predefinite falliscono tutte:
1) Bloccare tutto. Le richieste si accumulano, la pazienza finisce e le app ombra vengono comunque costruite. Ora non puoi vedere nulla. Non puoi governare ciò che non puoi vedere.
2) Lasciare fare. Puntare i non-ingegneri verso strumenti IA senza struttura e celebrare le demo. È così che si ottiene il file da 540 KB. E non puoi risolvere il problema con le revisioni a posteriori. Quando un monolite appare in code review, è già un monolite. Deve essere prevenuto al punto di partenza.
3) Revisionare tutto. Mettere un'approvazione umana su ogni modifica. Il tuo team IT è snello, il volume di build esplode e ora ogni deploy aspetta l'agenda del revisore. Le revisioni uccidono l'adozione o vengono timbrate senza pensarci. Entrambi gli esiti vanificano lo scopo.
Quindi la risposta non è un altro documento di policy, ma un ciclo di vita: un vero SDLC, progettato per persone che non si definiranno mai sviluppatori, con guardrail integrati nella piattaforma invece di essere scritti in un memo. Una strada che porta una build dalla prima idea in linguaggio semplice fino alla produzione governata, senza mai chiedere al costruttore di diventare un ingegnere. La persona fornisce l'intento; la piattaforma fornisce la disciplina.
Un principio attraversa ogni fase: l'IA fa il lavoro, il codice deterministico imposta i guardrail e gli umani gestiscono le eccezioni. L'IA abbozza, classifica e scrive. Il codice decide cosa è permesso. Le persone vengono impiegate solo dove è richiesto giudizio. Tieni a mente questa divisione; è ciò che rende scalabile l'intera cosa.
Lo chiamiamo Citizen SDLC. Sei fasi, ognuna governata.
Fase 1
L'idea
Una persona descrive l'app in linguaggio semplice, con l'aiuto dell'IA: cosa fa, chi la usa, quali dati tocca, chi la possiede. Richiede minuti e si legge come un memo. Funge anche da brief su cui si basa tutto ciò che viene dopo. Questa è la prima mossa del modello operativo: l'IA fa il lavoro di trasformare un'elucubrazione in un artefatto strutturato.
Ecco come appare in pratica. Qualcuno nella finanza del fondo scrive: "Voglio un tracker per gli avvisi di richiesta di capitale. Al momento è un foglio di calcolo che aggiorno a mano e invio via email ogni venerdì." L'IA chiede ciò che chiederebbe un analista di accoglienza. Chi altro deve vederlo? Dodici persone tra finanza del fondo e relazioni con gli investitori. Dove vivono i dati oggi? Un foglio di calcolo su Box, e la sola lettura va bene. Chi lo possiede quando tu non ci sei? Il suo manager. L'elucubrazione è diventata un brief: scopo, utenti, fonte dati, livello di accesso, proprietario, persino una prima ipotesi sulla forma dell'app. Una PRD, di fatto, scritta da qualcuno che non ha mai sentito il termine PRD.
GIF
Non esiste ancora nulla. Nessun codice, nessun accesso, nessuna infrastruttura. È voluto: l'azienda si forma un'opinione sull'app prima che l'app esista, invece di sei mesi dopo che è diventata critica.
Fase 2
Il portale d'ingresso
Ogni richiesta passa attraverso un unico portale d'ingresso strutturato, e la stessa azione che la presenta la inserisce direttamente in triage. Il brief è la richiesta, il ticket che l'IT vede, la registrazione permanente e una voce in un catalogo che tutti possono cercare, tutto in una volta. Niente richieste in corridoio, niente favori, niente pipeline ombra. Non puoi governare ciò che non puoi vedere, e non puoi condividere ciò che non puoi trovare. Il portale d'ingresso rende entrambe le cose vere dal primo giorno.
Questa è la fase che uccide la pipeline ombra. Una build che salta il portale d'ingresso può ancora esistere come prototipo su un laptop, ma è lì che rimane. Tutto ciò che trasforma un prototipo in software su cui un team può fare affidamento vive a valle di questa fase: archiviazione reale, login aziendale, una pipeline di deploy, un posto dove effettivamente eseguirlo. Niente di tutto ciò raggiunge una build che non è mai passata. Puoi aggirare il portale d'ingresso; semplicemente non puoi superare lo stadio di prototipo se lo fai.
Fase 3
Il triage
L'IA classifica la richiesta lungo due assi. Forma: che tipo di app è? Una revisione inversa di ciò che i dipendenti costruiscono effettivamente si riduce quasi sempre a un breve elenco: generatori di artefatti, automazioni di flussi di lavoro, app CRUD e dashboard interattive. Nominare la forma ti dice l'architettura di cui ha bisogno e consegna alla fase successiva la strada lastricata da timbrare. Raggio d'impatto: quanto danno potrebbe fare questa build se andasse male? Lo valutiamo su quattro dimensioni:
- Portata e capacità: cosa può toccare e può scrivere o solo leggere?
- Reversibilità e autonomia: c'è un umano nel ciclo e l'azione può essere annullata?
- Esposizione: chi vede l'output e quanto viaggia al di fuori dell'azienda?
- Sensibilità dei dati: quanto sono riservati i dati con cui interagisce?
Ma ecco la regola che rende tutto ciò affidabile: l'IA consiglia. Il codice decide. Il modello legge il brief e lo classifica; poi il codice delle policy scritto dall'IT controlla ogni classificazione rispetto alle regole. Guardalo funzionare sul tracker degli avvisi di richiesta di capitale. Forma: dashboard interattiva. Raggio d'impatto: dati interni del fondo, dodici utenti interni, sola lettura, umano nel ciclo, nessuna sovrapposizione con app esistenti. Ogni dimensione rientra nelle soglie approvate, quindi è approvato, e nessun umano ha discusso al riguardo.
Ora cambia un fatto. Supponi che il tracker abbia bisogno anche dei dati sugli impegni dei limited partner. Il brief può essere persuasivo quanto vuole; quel singolo cambiamento porta la dimensione della sensibilità dei dati oltre la soglia impostata dall'IT e la richiesta va a una persona. Nessuna decisione è stata presa nel mezzo. Una regola corrisponde o non corrisponde.
Tre vie d'uscita:
- Approvato. Raggio d'impatto entro ogni soglia, brief completo, alta fiducia. Dal nostro cliente, circa 9 richieste su 10 si risolvono in questo modo, automaticamente.
- Riutilizzo. Si sovrappone a un'app che esiste già, quindi il richiedente viene indirizzato al proprietario di quell'app invece di costruire un duplicato. I duplicati vengono fusi, non moltiplicati.
- Segnalato. Una dimensione supera la sua soglia, o la fiducia è bassa. Un umano nell'IT e nella Sicurezza riceve l'intera richiesta come contesto.
GIF
La decima richiesta, quella fuori dalla norma, arriva comunque sulla scrivania di un umano con il brief completo allegato. Le altre nove non ne hanno mai avuto bisogno.
Fase 4
Il provisioning
Ecco la mossa che permette all'IT di dire sì in volume: il provisioning non è l'IT che perde il controllo su ciò che viene rilasciato, ma il controllo dell'IT che si sposta a monte. Invece di revisionare ogni app a posteriori, l'IT crea la strada lastricata una volta e ogni app nasce su di essa. Una persona approva e la piattaforma timbra l'app dalla strada per la sua forma: un repository, login aziendale, un'identità di deploy, un ambiente privato e il proprio database, tutto definito come infrastruttura-come-codice che l'IT possiede e versiona. Provisioning in pochi minuti.
Questo è l'unico momento in cui vengono eseguiti poteri elevati e un umano è di fronte ad esso. Ogni app nasce isolata, governata e revisionata: il proprio ambiente isolato, nessun indirizzo pubblico, nessun segreto cloud memorizzato, una traccia di audit immutabile dal giorno zero. Il lavoro di sicurezza è avvenuto una volta, nella strada. Nessuna app deve ripeterlo.
Poiché la strada è creata per forma, l'approvazione umana è una postura predefinita, non una tassa permanente. Forme nuove e build ad alto raggio d'impatto mantengono il gate umano per sempre. Ma una volta che la strada di una forma si è dimostrata valida per un numero sufficiente di build, le richieste a basso raggio d'impatto su quella strada possono essere provisionate automaticamente. È la stessa logica di "risparmiare il giudizio umano per la coda" applicata una fase prima: all'inizio instradi più cose a una persona e, man mano che gli schemi si consolidano, la linea si sposta verso l'automazione.
E la strada porta con sé un'altra cosa importante quanto l'infrastruttura: il regolamento dell'IA. Il repository ereditato consegna all'agente di codifica una serie di istruzioni a ogni sessione, codificando gli anti-pattern appresi da fallimenti reali. Non incorporare blob di dati in linea superiori a 1 KB. Non aggiungere funzioni che riscrivono i dati quando l'app viene caricata. È così che la qualità sotto il cofano viene risolta senza chiedere al costruttore di conoscere una singola best practice: la strada fa sì che l'agente le segua. Ognuna di queste regole è una cicatrice con una storia alle spalle (ne hai letta una).
Fase 5
La build
Il costruttore sollecita il suo agente di codifica (Claude Code, Codex, ecc.) all'interno di un workspace cloud controllato, mai sul proprio laptop. Un agente terminale su un laptop eredita tutto ciò che si trova lì: email, drive sincronizzati, cookie del browser, credenziali memorizzate nella cache. Nel workspace, l'agente vede il progetto. Nient'altro.
Tutto ciò che un ingegnere normalmente si porterebbe dietro è invece portato dai binari: dal nostro cliente, 35 guardrail in quattro livelli che il costruttore non può disattivare.
Il livello di merge include controlli di deriva progettati appositamente per il codice generato dall'IA: budget di dimensione dei file, nessun dato in linea di grandi dimensioni, conformità del registro di audit. Verde o non viene integrato. Quando un controllo fallisce, il costruttore chiede all'agente di sistemarlo e ricarica.
Gli umani non revisionano le modifiche di routine. I controlli sono la revisione. Le modifiche di routine si muovono alla velocità della CI, non alla velocità dell'agenda di un revisore. Ciò che arriva a un umano è la coda consequenziale, rilevata meccanicamente: modifiche distruttive allo schema, nuove dipendenze, modifiche ai vincoli stessi dell'agente, qualsiasi cosa tocchi l'infrastruttura. Quelle aspettano una persona. Nient'altro lo fa. E quando qualcosa di nuovo sfugge comunque, la soluzione è un nuovo controllo automatizzato, non più revisione umana. Il sistema diventa più rigoroso codificando le lezioni, non aggiungendo riunioni.
Ricorda la dashboard dell'inizio. Due di quei controlli di deriva avrebbero reagito su di essa nella prima settimana. Il blob da 80 KB su una singola riga avrebbe fallito la CI al suo primo commit, mesi prima che qualsiasi modalità di guasto si consolidasse.
Fase 6
Esecuzione e modifica
Sei mesi dopo, il tracker degli avvisi di richiesta di capitale è ancora in esecuzione, ed è qui che il ciclo di vita dimostra il suo valore. Qualcuno nelle relazioni con gli investitori mette in dubbio la scadenza del bonifico sull'avviso di marzo. La traccia di audit risponde in trenta secondi: chi ha modificato il campo, quando e cosa diceva prima, registrato nella stessa transazione della modifica stessa. Nessuno ricostruisce la verità da una catena di email. Quando il costruttore cambia team, la proprietà viene trasferita a un successore designato invece di dissolversi in un'alzata di spalle. E se lascia completamente l'azienda, il suo login muore e ogni porta che apriva si chiude all'istante. Il tracker incluso. La richiesta di funzionalità per il trimestre successivo percorre gli stessi binari del primo commit.
La governance si basa sui segnali, non su audit annuali. Le metriche di utilizzo del tracker mostrano che altri due team ci stanno facendo affidamento, quindi viene promosso e riceve investimenti. La dashboard delle valute che nessuno ha aperto da aprile viene archiviata, non lasciata a marcire in un menu. Nessuno la piange. La proprietà viene assegnata il primo giorno, quindi nulla sopravvive al suo costruttore senza proprietario. La documentazione si rigenera man mano che l'app si evolve, quindi non diventa mai obsoleta. Un'app inutilizzata è un fallimento, non un trofeo. L'obiettivo non è mai stato il numero di app: è un catalogo vivente di cui le tue persone si fidano realmente, invece di un cimitero di software dimenticato.
Man mano che il catalogo cresce da dieci app a duecento, un team centrale non può più tenere d'occhio tutto, e la supervisione deve spostarsi verso i team che possiedono le app. Quando e quanto lontano federare è una questione di giudizio, e si sposta man mano che il portafoglio cresce. La governance qui è una postura che continui a ottimizzare, non un controllo che imposti una volta.
La regola che tiene insieme il tutto
C'è un innesco che insegniamo a ogni cliente, perché risponde al 90% delle domande del tipo "questa cosa ha bisogno dell'intero processo?": la regola del secondo consumatore. Funziona perché è il momento in cui il profilo di rischio cambia.
Qualcuno che costruisce un'analisi per sé, sul proprio laptop, con accesso ai dati limitato? Basso raggio d'impatto, governance leggera. Grafici, memo e script che esegue per sé non hanno bisogno di una pipeline di deploy. Ma nel momento in cui una seconda persona vuole usare l'output direttamente, invece di chiedere all'autore aggiornamenti? Il raggio d'impatto aumenta: più portata, dati che viaggiano più lontano, qualcun altro che si fida che siano corretti. Ora è software, e passa all'intero ciclo di vita, deliberatamente, come un evento esplicito. Stesse fonti dati, stessa identità, nuova strada.
Quell'unica regola è il motivo per cui il processo non sommerge le persone. La maggior parte delle build non supera mai la linea. Quelle che lo fanno sono esattamente quelle che meritano la cerimonia.
Ciò di cui siamo onesti
Nessuna piattaforma fa sì che i costruttori alle prime armi scrivano codice perfetto. Non pretendiamo di farlo. I livelli esistono affinché un errore sia un inconveniente all'interno di un piccolo confine, non un incidente in tutta l'azienda. Ogni livello copre esattamente ciò che quello superiore non può coprire:
E l'audit non previene nulla, ma rende ogni incidente breve, spiegabile e attribuibile. Questa è la differenza tra un brutto pomeriggio e un brutto trimestre.
Il citizen development non è destinato a sostituire l'ingegneria professionale. I sistemi di registrazione nei processi regolamentati, qualsiasi cosa rivolta ai clienti o agli investitori, le app costruite per utenti esterni, qualsiasi cosa in cui i tempi di inattività comportano una penalità finanziaria: tutto questo appartiene ancora all'ingegneria, e il portale d'ingresso le instrada lì dal primo giorno. Ciò che sostituisce è il collo di bottiglia. Democratizza la lunga coda di strumenti interni che non sono mai valsi un progetto di ingegneria formale e li rilascia a una velocità che la coda della roadmap non potrebbe mai offrire. Un framework senza confini è uno slogan; questo sa cosa non è.
Cosa cambia realmente
Alla società di investimento, la prima app attraverso la piattaforma è quella che l'ha motivata: la dashboard della storia di apertura, ricostruita sui binari. Stessi schermi. Stessa costruttrice. Ora con archiviazione reale, login aziendale e una cronologia di ogni modifica. Non può più troncarsi a 7 byte, perché la classe di codice che lo ha causato non può essere integrata.
Circa 9 richieste su 10 si risolvono già automaticamente, e questa quota è solo in crescita. La maggior parte di ciò che i costruttori non tecnici realizzano è per natura a basso raggio d'impatto. Strumenti interni, prevalentemente in lettura, per un pubblico ristretto. Man mano che la strada di ogni forma si dimostra valida, un numero maggiore di queste build diventa sicuro da provisionare e distribuire senza alcun umano nel ciclo. L'attenzione umana continua a concentrarsi sulla coda consequenziale e a diradarsi ovunque altrove.
Oggi "sì" richiede minuti, e tende all'istantaneo, perché "no" è integrato.
Ogni azienda sta per avere centinaia di costruttori. La maggior parte delle aziende sta ancora decidendo se averne paura o esserne entusiasta. Quelle che vinceranno non saranno quelle con il maggior numero di costruttori. Saranno quelle con le strade migliori.
