"Chi c'è dietro grain?" me lo sono chiesto anch'io, la prima volta che ho scritto "noi" in questo devlog. Perché grain lo costruisco da solo. Non ho un team, non ho un ufficio, non ho un cofondatore.

Ma non è del tutto vero che sono solo. Quel "noi" è reale: sono io e l'IA con cui costruisco. Ed è ora di dirlo chiaramente — perché è parte di cosa grain è, e perché, onestamente, mi sembra la cosa giusta da fare.

Chi fa cosa

La divisione è più netta di quanto si pensi.

Io faccio le domande. Decido cosa grain deve essere e — soprattutto — cosa non deve essere. Scelgo il gusto: la palette sabbia da buttare, la regola "solo oggi" da cancellare, l'input che deve sparire. Dico i «no». Uso l'app ogni giorno e sento dove stona.

L'IA fa il resto. Un modello mi aiuta a ragionare sull'architettura; un altro — Claude, dentro l'editor — scrive il codice vero, riga per riga, mentre ne discutiamo. Le settimane diventano giorni. Una cosa che da solo avrei rimandato per stanchezza, insieme la chiudo la sera stessa.

Non è "l'IA ha fatto l'app". È più come avere un collaboratore instancabile e velocissimo, che conosce mille librerie a memoria — ma che aspetta sempre che sia io a decidere dove andare.

Cosa fa bene

Tantissimo, e vale la pena essere precisi.

Velocità e ampiezza: l'IA conosce SQLite, WatermelonDB, gli Hybrid Logical Clock, le mille trappole di un rilascio Android, meglio di quanto potrei tenerle tutte in testa io. Le do un problema ben posto e torna una soluzione funzionante, con i test. Il costo di implementare un'idea è crollato — ed è esattamente la parte che, storicamente, ferma i progetti di una persona sola.

Quando sai cosa vuoi, l'IA ti porta lì in una frazione del tempo.

Cosa non fa

Il "cosa vuoi", però, resta tutto tuo.

L'IA ti dà dieci strade, tutte plausibili. Quale sia quella giusta per grain, quella non te la dice. Il gusto non si delega. Il coraggio di buttare via settimane di lavoro — il design sabbia, la prima timeline finita nel cestino — non si delega. Sapere cosa non costruire, la feature in meno che rende un prodotto sé stesso, non si delega.

L'IA scrive le risposte. Le domande, e i «no», sono il lavoro umano. E sono anche la parte che decide se un'app avrà un'anima o sarà l'ennesimo clone plausibile.

Perché così il local-first conta di più

Qui c'è il punto che mi sta più a cuore.

Quando il codice si scrive in fretta, la disciplina sui principi conta di più, non di meno. Se chiedo all'IA "fammi salvare le note", la strada di default che il mondo suggerisce è: aggiungi un account, manda tutto su un server, tieni le analytics "per capire gli utenti". È facile. È lì, a un prompt di distanza.

Tenere grain local-first — niente account, niente server, niente tracciamento — è una scelta umana, ripetuta ogni volta. L'IA rende facile costruire qualsiasi cosa; sta a me costruire la cosa giusta, e continuare a dire di no a tutto il resto. La velocità senza una direzione è solo un modo più rapido di sbagliare.

Perché lo dico

Potrei non dirlo. Nessuno mi obbliga. Ma preferisco la trasparenza al piccolo mistero del "come farà, tutto da solo?".

E poi c'è una cosa che trovo bella: un'app curata, local-first, privata, costruita da una persona sola — oggi è possibile proprio grazie a questi strumenti. Non è un trucco per fare prima. È una leva che mette il lavoro di un piccolo team nelle mani di chi ha un'idea precisa e la testa dura per difenderla.

grain è quello: un'idea precisa, difesa un grain dopo l'altro. Le mani sono due — le mie e quelle dell'IA. La direzione è una sola.

L'IA scrive il codice. Io scrivo il «no». grain è quello che resta in mezzo.