AI-lveareRichiedi un pilota

Per software house e team di prodotto

Una software factory di agenti AI.

Software costruito da agenti, accettato solo con prove. Ogni lavoro passa da un test sul commit esatto, dalla revisione di un modello di un'altra famiglia e dall'approvazione di una persona del vostro team. App mobile, web, firmware, servizi, sulla vostra infrastruttura.

Pilota di 4 settimane su un vostro repository.

INTENTOPRINPUTOUTPUTOBBLIGO 12GATE VERDECCCCGCCRCODICECELLEGATECORPOREGISTROGUARDIANAUMANO
Schema. L'intento entra, le celle (C) costruiscono, il gate (G) prova, la guardiana (R) rivede, l'umano chiude col codice, la PR esce. Il corpo scrive tutto nel registro.
Uno sciame al lavoro
1Cella
obbligo in corso

Filtro per data nell'elenco degli ordini

checkpoint 2 di 3

costruisce
2Gate
obbligo verde

Accesso con passkey

suite completa verde

prova sul commit esatto
3Guardiana
obbligo respinto

Notifiche per i nuovi messaggi

nessun test copre il caso senza rete

rivede, altra famiglia
4Umano
obbligo serve l'umano

Aggiornamento dell'SDK dei pagamenti

evidenza pronta, serve il codice

approva la chiusura
Esempio illustrativo: quattro obblighi di uno sciame, uno per ruolo.
1

Dove si usa

Qualsiasi genere di software

Dai ticket al rilascio, su qualsiasi genere di software.

AI-lveare non è legato a una piattaforma, a un framework o a un test runner. Conosce tre cose: l'evidenza che un lavoro deve produrre, il gate che la prova e il bersaglio su cui provarla. Tutto il resto, dai comandi di test al dispositivo su cui installare, lo dichiara il vostro progetto. I primi tre sono i lavori tipici di una software house.

1Il backlog di ticket

I ticket che nessuno prende in mano: ognuno diventa un obbligo con un esito verificabile, una cella lo costruisce, e la PR arriva pronta per la revisione del team.

Ticket in ingresso, PR in uscita.
2Una funzionalità nuova, in più PR

Una funzionalità grande si scrive come una missione a più obblighi, in sequenza o in parallelo. Ogni PR chiude con il suo gate verde, e le correzioni trovate dopo rientrano nello stesso sciame.

Il lavoro grande, spezzato in prove piccole.
3Test end-to-end su un dispositivo vero

Un telefono, un tablet o un dispositivo in lease allo sciame: il gate installa la build, lancia i flussi e conserva lo screenshot come evidenza. Se il dispositivo non risponde, il gate è rosso.

La prova sul dispositivo, non sull'emulatore.
E poiComeCosa ottenete
4 I bug del QA prima del rilascioLe segnalazioni di un giro di QA diventano obblighi con un test che riproduce il difetto. Nessuna correzione chiude senza quel test verde e una revisione indipendente.Ogni bug ha il suo test.
5 Aggiornamenti di piattaforma e rilasciIl salto di versione di un SDK, di un framework o di un target di compilazione, con la build di rilascio collaudata prima di toccare la versione in produzione.Il lavoro che si rimanda sempre.
6 Firmware e dispositiviLo stesso metodo vale per un microcontrollore: il progetto dichiara come si compila, come si carica e come si prova. AI-lveare non è legato a una piattaforma.Non solo app e web.
7 Più progetti che si coordinanoBackend, frontend web e app mobile che devono cambiare insieme: uno sciame padre delega una parte a ciascuno sciame figlio, collauda l'insieme e chiude solo quando tutti hanno chiuso.Il lavoro coordinato fra repository.
8 Manutenzione continuaDipendenze, avvisi di sicurezza, piccoli debiti tecnici: lavori che valgono un obbligo ciascuno e che uno sciame porta avanti mentre il team fa altro.Il debito tecnico che cala.

Per le aziende che non scrivono software: One Small Step Apps consegna il progetto, e la factory resta dietro le quinte.

2

Come funziona

Un obbligo, quattro ruoli, più sciami

Un obbligo è un lavoro con un esito verificabile.

Una cella prepara la modifica in una copia del repository. Il gate esegue i controlli definiti dal progetto sul commit esatto. Una guardiana di un'altra famiglia di modelli rivede il risultato. Una persona legge l'evidenza e approva la chiusura con un codice, anche dal telefono.

2.1Il ciclo di un obbligo, e dove serve una persona
  1. 1Intento
    umano

    Cosa serve, cosa è fuori scope, quale evidenza chiude.

  2. 2Cella
    agente

    Costruisce a checkpoint, in una copia del repository.

  3. 3Gate
    automatico

    I test del progetto sul commit esatto. Rosso: si torna indietro.

  4. 4Guardiana
    altro modello

    Rivede il lavoro. Respinge con un motivo o accetta.

  5. 5Integrazione
    automatico

    Il lavoro si integra e il gate gira di nuovo.

  6. 6Chiusura
    umano

    Legge l'evidenza e chiude col codice, anche dal telefono.

  7. 7Merge
    umano

    La PR la fonde il team, quando vuole.

In arancio i passi che chiedono una persona del vostro team. Gli altri non la aspettano.
2.2I quattro ruoli
1Cella

Un agente costruisce un obbligo alla volta, a checkpoint, in una copia del repository tutta sua.

2Gate

La prova oggettiva. I comandi del vostro progetto girano sul commit esatto: se il gate è rosso, il lavoro non va avanti.

3Guardiana

Un modello di un'altra famiglia rivede il lavoro. Il sistema rifiuta una guardiana della stessa famiglia della cella.

4Umano

Legge l'evidenza e chiude col codice, anche dal telefono. Ogni passo resta scritto nel registro.

La cella in duetto In arrivo

Due modelli, un solo codice.

Per alcuni tipi di obbligo la cella diventa una coppia: due modelli di famiglie diverse, per esempio Claude Code e Codex, si dividono il lavoro e si rivedono a vicenda mentre costruiscono, prima ancora del gate e della guardiana. Distribuisce anche il consumo fra i due abbonamenti.

È una delle due cose su cui stiamo lavorando ora, insieme all'isolamento per cella.

2.3Più progetti che si coordinano

Uno sciame per repository. Un padre per il lavoro che li attraversa.

Un prodotto vero è fatto di più repository: il backend, il frontend web, l'app mobile. Un lavoro che li tocca tutti nasce in uno sciame padre, che lo divide e delega una parte a ciascuno sciame figlio. Ogni figlio lavora con i suoi gate e la sua guardiana; il padre collauda l'insieme e chiude solo quando tutti hanno chiuso. La delega ha un solo livello e nessun ciclo: il corpo lo controlla.

PSciame padre: prodottopossiede l'obbligo
obbligoIl cliente vede la data di consegna in tutte le app
Scrive l'obbligo comune, lo divide in tre parti e le delega. Fa il collaudo end-to-end con tutte e tre le parti insieme, e chiude solo quando i tre figli hanno chiuso.
1Backend
apiobbligo delegato
Il nuovo campo nell'API e la migrazione.
cella, gate, guardiana: i suoi
2Frontend web
webobbligo delegato
Il campo nel modulo e nella lista.
cella, gate, guardiana: i suoi
3App mobile
mobileobbligo delegato
Il campo nella schermata e nel sync.
cella, gate, guardiana: i suoi
Esempio illustrativo. Ogni figlio ha il suo repository, i suoi gate e la sua PR. Il padre non integra niente finché il collaudo d'insieme non è verde.
Quando il sistema chiede una decisione in più
Azione irreversibile

Chiusura, merge, rilascio, annullamento: col codice, anche dal telefono.

Scelta vera

Una decisione che l'intento non prende: da 2 a 4 opzioni, con conseguenze e raccomandazione.

Gate che non diventa verde

Tre respingimenti sullo stesso punto: si riprova, si rivede o si annulla.

Le domande di fatto non arrivano all'umano: le verifica una cella. Il team può intervenire quando vuole, dalla TUI, dalla pagina o da Telegram.

3

Cosa cambia per il team

Sette differenze
1Un flusso, non un assistente

Gli strumenti di oggi aiutano uno sviluppatore alla volta. Qui il lavoro entra come intento ed esce come PR, con più agenti in parallelo e il team che approva.

2Revisione incrociata fra fornitori

Il sistema rifiuta una guardiana della stessa famiglia della cella. Il codice scritto da un modello lo rivede un modello di un altro fornitore: è la difesa contro gli errori correlati.

3Il gate decide, non l'agente

Un lavoro chiude su un test verde eseguito sul commit esatto, non su "l'agente dice che ha finito". I comandi del gate li dichiara il vostro progetto.

4L'evidenza prima del codice

Il responsabile approva cosa deve succedere e legge il risultato, senza leggere ogni riga. Le decisioni vere arrivano con opzioni, conseguenze e una raccomandazione.

5Il registro di ogni passo

Chi ha fatto cosa, con quale modello, su quale commit, con quale verdetto. L'audit si fa leggendo, non ricostruendo.

6Uno sciame che impara

Un lavoro respinto diventa una lezione nel prompt delle celle successive dello stesso sciame. Gli errori non si ripetono allo stesso modo.

7Le quote sotto controlloSoglie impostabili in arrivo

Il consumo lo governa il corpo, non l'agente. Per ogni servizio legge la quota rimasta e le ore al reset e calcola un ritmo: quanto gli sciami possono spendere per ora, con una riserva per il lavoro delle persone. Sopra c'è un tetto fisso, e una cella che supera la soglia si ferma con un allarme.

Il conto è in token, non in percentuali: con due fornitori il 25% di uno può valere più di tutta la quota dell'altro. Un compito che può girare su un modello meno costoso senza perdere qualità ci va. Le percentuali per servizio e i limiti di costo per sciame, impostabili dall'interfaccia, sono fra i lavori in corso.

Tutto in italiano: intenti, obblighi, riga di comando, interfaccia, documenti.

4

Open source e commerciale

Una CLI, due modi

Entrambi i modi sono in costruzione nelle prossime settimane. Il pilota parte sull'installazione commerciale, presso di voi.

Open source In preparazione
ailveareuna macchina, in locale

La stessa CLI, sulla vostra macchina, senza server centrale.

Non è ancora pubblicata, e non ha ancora una licenza.

Commerciale Pilota
ailveareserver centrale, presso di voi

Un server sulla vostra infrastruttura. Più persone, più progetti, anche dal telefono.

È l'installazione del pilota. Installazione, supporto e affiancamento di One Small Step Apps; i modelli li pagate direttamente ai fornitori.

5

Sicurezza

Cosa è vero oggi
  • Installato sulla vostra infrastruttura. Il server, il repository, il registro e le evidenze stanno da voi e non passano dai sistemi di One Small Step Apps.

  • I modelli con le vostre chiavi. Il codice che gli agenti leggono e scrivono arriva ai fornitori dei modelli (Anthropic, OpenAI e gli altri che scegliete) con le vostre chiavi e i vostri contratti, non con i nostri.

  • Una persona su ogni chiusura. Nessun obbligo si chiude senza l'approvazione, con codice, di una persona del vostro team. Il merge lo fate voi.

  • Tutto nel registro. Chi ha fatto cosa, con quale modello, su quale commit, con quale verdetto.

  • Isolamento per singolo agente: in sviluppo. Oggi ogni cella lavora nella propria copia del repository con i permessi dell'utente che la esegue. L'isolamento di file, rete e segreti per cella non è ancora disponibile.

6

Domande

Quelle dei tech lead
1Gli agenti scrivono test ridondanti, costosi, a volte inutili. Come lo evitate?

In tre modi. Il gate conta i test eseguiti: una voce che ne richiede e ne trova zero è rossa. Per i lavori che lo meritano l'evidenza si scrive prima del codice: i test vengono proposti, controfirmati da un modello di un'altra famiglia e approvati da una persona, poi la cella lavora fino al verde. E la guardiana rivede anche i test, non solo il codice: un test che non prova la funzionalità è un motivo di respingimento.

2Gli agenti tendono a uscire dallo scope. Come lo contenete?

L'intento dice cosa è fuori scope, e ogni obbligo ha una taglia (S, M, L) con un numero di checkpoint proporzionato: un lavoro che non ci sta si divide, non si allarga. La guardiana confronta il checkpoint con l'intento, non solo con il codice. Un'idea buona ma fuori scope diventa una proposta di obbligo nuovo, che una persona accetta o scarta.

3Chi scrive gli acceptance criteria?

Una persona del team, nell'intento. Ogni obbligo porta la propria evidenza, scritta in modo che il gate la sappia eseguire: se non si può eseguire, l'intento non è pronto. Nel pilota gli intenti si scrivono insieme. Far proporre i criteri a un modello, da approvare poi, è un'idea annotata e non ancora nel prodotto.

4Coordina anche le persone del team, oltre agli agenti?

No, oggi coordina agenti. Le persone entrano all'intento, alle decisioni vere e alla chiusura. Il registro dice quale cella lavora su quale obbligo e su quale branch, e questo aiuta a non pestarsi i piedi, ma il coordinamento del lavoro umano non è una funzione del prodotto.

5Quali modelli usa, e chi li paga?

Modelli di frontiera come Claude Code e Codex, modelli cloud come Kimi o GLM, modelli locali via Ollama. Una regola è nel codice: la guardiana deve essere di una famiglia diversa dalla cella che ha scritto il codice. L'azienda assegna i modelli ai compiti: chi costruisce, chi rivede, chi giudica. Oggi l'assegnazione è scritta nella configurazione dello sciame; un'impostazione per compito, con il rilevamento dei modelli installati, è fra i lavori in corso. Le chiavi e gli abbonamenti sono vostri, il contratto è fra voi e il fornitore, e il costo per obbligo si misura durante il pilota sul vostro repository.

6Quanto consuma? Si possono mettere dei limiti?

Il consumo è governato dal corpo, non lasciato agli agenti. Per ogni servizio il corpo legge la quota rimasta e le ore al reset e calcola un ritmo: quanto gli sciami possono spendere per ora, tenendo una riserva per il lavoro delle persone. Sopra c'è un tetto fisso sulla parte di quota che gli sciami possono usare, e una cella che supera la soglia si ferma con un allarme invece di continuare. Il conto si fa in token, perché le percentuali di servizi diversi non si confrontano. Oggi il tetto e le soglie sono valori nella configurazione; le percentuali per servizio e i limiti di costo per sciame impostabili dall'interfaccia sono fra i lavori in corso.

7Funziona con il nostro stack e la nostra CI?

AI-lveare non conosce linguaggi, framework o test runner. Il progetto dichiara in un file i comandi del gate (test, lint, build, collaudo su dispositivo) e il formato dei risultati. La vostra CI resta com'è: la PR arriva nel vostro flusso, e il merge lo fate voi.

8Serve Jira?

No. Il lavoro entra come intento scritto. I ticket di Jira o di un'altra board sono una fonte: oggi li legge chi scrive l'intento, un connettore automatico è fra i lavori previsti e non ancora fatto.

9E se il gate non diventa mai verde?

Dopo tre respingimenti sullo stesso punto il sistema si ferma e chiede a una persona: riprovare, rivedere l'intento o annullare. Nessuna cella aspetta all'infinito, e nessuna cella decide da sola di cambiare i test per farli passare: li vede la guardiana.

10Chi è responsabile del codice che va in produzione?

Il vostro team. Nessun obbligo si chiude senza l'approvazione, con codice, di una persona del team, e il merge lo fate voi. Il registro conserva chi ha fatto cosa, con quale modello, su quale commit, con quale verdetto.

11È sicuro? Prompt injection, segreti, accessi?

La risposta onesta: l'isolamento per singolo agente è in sviluppo. Oggi una cella lavora nella propria copia del repository con i permessi dell'utente che la esegue. Le difese che ci sono già: il gate deterministico, la revisione di un modello di un'altra famiglia, la chiusura solo umana, il registro di ogni passo. Nel pilota questo limite è scritto nel contratto.

12Quanto tempo chiede al team?

L'intento all'inizio, le decisioni vere quando capitano, l'approvazione delle chiusure. L'approvazione si fa dal telefono con un codice, leggendo l'evidenza e non il diff. Il tempo si misura nel pilota, sul vostro lavoro.

13Si installa e funziona?

Non ancora. Il pilota è assistito: One Small Step Apps installa e scrive gli intenti con voi. La versione open source per una macchina sola e l'installazione commerciale autonoma sono in costruzione nelle prossime settimane.

14Che differenza c'è con Copilot, Cursor o Devin?

Copilot e Cursor aiutano uno sviluppatore alla volta, nel suo editor. Qui il lavoro entra come intento ed esce come PR, con più agenti in parallelo. Rispetto agli agenti autonomi come Devin: la revisione è di un fornitore diverso da chi scrive, il gate decide e non l'agente, tutto gira sulla vostra infrastruttura, e intenti, interfaccia e documenti sono in italiano.

Il primo passo

Un pilota di 4 settimane sul vostro repository.

01
Installazione sulla vostra infrastruttura.

02
Un intento e i gate del progetto, scritti insieme.

03
Un obiettivo concordato di 5-10 obblighi.

04
Il registro e un report con lavori chiusi, respingimenti, tempi e interventi umani.

Chi fa cosa
One Small Step Apps installa, scrive gli intenti con voi e segue gli sciami. Il vostro team dichiara i gate, approva le chiusure e fa i merge.
Costi
Il pilota è quotato a giornate. I modelli li pagate direttamente ai fornitori, con le vostre chiavi.
Limite dichiarato
L'isolamento per singolo agente è in sviluppo: oggi una cella lavora con i permessi dell'utente che la esegue.
Richiedi un pilota