---
title: "Vibe coding: un caso studio - Ribbon Family App"
description: Fin dove si può spingere lo sviluppo in vibe coding puro? Quali sono le difficoltà che bisogna affrontare e i tempi di lavoro a cui si va incontro?
featured_image: https://www.sernicola-labs.com/wp-content/uploads/2026/05/14-1-2-1024x614.webp
date: 2026-05-18
modified: 2026-05-19
author: Team Sernicola Labs
url: https://www.sernicola-labs.com/focus/vibe-coding-caso-studio-ribbon-family-app/
categories: [Focus]
---

# Ribbon Family App – Fin dove si può spingere il vibe coding puro?

## Ribbon Family App
Fin dove si può spingere il vibe coding puro?

***L’informatica** è una scienza prevalentemente sperimentale. **Studio**, **progettazione** e **dimensionamento** sono naturalmente degli aspetti essenziali in ogni progetto che supera una certa complessità. Tuttavia niente può sostituire la **validazione pratica**: sono i **test**, svolti su **casi reali**, in **ambienti reali** e soprattutto con **utenti reali**, a fare la differenza tra un progetto che ha **successo** ed uno che **fallisce**.*

*Il nostro team utilizza già il [vibe coding](https://www.sernicola-labs.com/sviluppo-web-tramite-vibe-coding/) come strumento per la realizzazione di **prototipi**, **MVP**, **software di appoggio** e **connettori per piattaforme web**. Lo utilizziamo per lo più tramite **linea di comando**, con un **approccio ingegneristico** e una mente da sviluppatori ([ne parliamo qui](https://www.sernicola-labs.com/sviluppo-web-tramite-vibe-coding/)). Riteniamo infatti che un approccio misto di **sviluppo manuale**, **vibe coding** e **orchestrazione di agenti AI**, diventerà (in poco tempo) lo standard dello **sviluppo web professionale**.*

*C'è anche un altro approccio del **vibe coding** che vale la pena monitorare: quello che strumenti AI avanzati come Claude Code e Codex mettono a disposizione di **startup** e **liberi professionisti non tecnici**, i quali hanno comunque la necessità di **testare soluzioni software** (come **siti**, **app** o **web app**) per la propria attività.*
*Tramite questi **strumenti AI** è possibile sviluppare, senza **competenze informatiche approfondite**, sistemi già funzionanti: utili ad esempio per la **validazione di nuove idee**, per valutare la **risposta del mercato** o per testare internamente **flussi di lavoro automatici**, rimandando il coinvolgimento di aziende specializzate come la nostra a un momento successivo.*

*Questo approccio permette di procedere con lo **sviluppo professionale** soltanto quando i **requisiti** sono certi e l’**idea** è consolidata e validata dagli **utilizzatori finali**, così da ridurre il **rischio imprenditoriale** iniziale e soprattutto limitare gli **aggiustamenti successivi** che molto spesso risultano onerosi per le nuove attività in termini di **tempo** e **costi**.*

*La domanda che ci siamo posti è: allo stato attuale, quanto in là ci si può spingere con il **vibe coding puro**? Quali sono le **difficoltà** che bisogna affrontare e i **tempi di lavoro** a cui si va incontro?*

*Abbiamo deciso quindi di presentarvi un interessante **caso studio**: un progetto portato avanti dal nostro fotografo di fiducia [Emanuele Cardinali](https://cardinali.studio/)(sono suoi i ritratti artistici del nostro [team](https://www.sernicola-labs.com/sviluppatori-web-design-milano/)), che ha realizzato un’**app nativa Apple** completamente progettata e sviluppata tramite **sistemi AI**, sia a livello **grafico** che **software**.*

### Non ho scritto una riga di codice. Ho pubblicato un'app sull'App Store.

#### Un caso studio onesto su cosa significa fare vibe coding nel 2026, senza esperienza di sviluppo ma con un'idea chiara in testa.

#### L'inizio

A **febbraio 2026** avevo un account Claude. Lo usavo per lavorare alla **SEO** del mio **sito da fotografo**: roba pratica, niente di particolarmente ambizioso. Poi ho visto online alcuni video in cui delle persone usavano Claude Code per costruire **software**, e ho deciso di provarlo. Non per fare un **prodotto**. Solo per capire di cosa si trattasse.
L'idea di partire da un'**app per la gestione condivisa di un neonato** è venuta quasi da sola. Mio figlio aveva da poco compiuto un anno, e avevo ancora molto fresca la frustrazione di non riuscire a trovare un'**app** che mi piacesse per tenere traccia delle sue cose insieme a mia moglie: **biberon**, **ore di sonno**, **febbre**, **medicine**. Le app che esistevano erano o brutte, o scomode, o tutte e due. Altre mi lasciavano comunque una domanda senza risposta: dove finiscono i **dati** di mio figlio? **Abitudini di sonno**, **frequenza dei pasti**, **temperatura della febbre**, **medicine somministrate**. Non ero disposto a fidarmi ciecamente di un'app di cui non sapevo nulla. Così ho pensato: proviamo con questa.
Non era un **piano**. Era un **esperimento**.
Tre mesi dopo, **Ribbon Family** è sull'App Store.

#### I primi giorni

Nei primi due o tre giorni lavoravo così: scrivevo a Claude Code qualcosa tipo "**mi piacerebbe questa funzione**", "**fammi le domande che ti servono per realizzarla**", e aspettavo. L'**AI** produceva qualcosa. Io guardavo il **risultato**, dicevo se mi piaceva o no, e andavo avanti.
Funzionava in maniera sorprendente, in un certo senso. Ma era come **guidare con gli occhi chiusi** sperando di arrivare comunque a destinazione.

Il problema non era che l'**AI** sbagliasse. Il problema era che io non sapevo abbastanza per **guidarla con precisione**, e lei non sapeva abbastanza del mio **progetto** per muoversi in autonomia senza rischiare di **rompere qualcosa**. I **prompt generici** producono **risultati generici**, e in un'**app con più funzioni interconnesse** un intervento impreciso in un punto può rompere qualcosa di completamente diverso dall'altra parte.

Ho capito abbastanza presto che per ottenere **risultati migliori** dovevo diventare qualcos'altro rispetto a un **utente passivo**. Non uno **sviluppatore**, ma qualcosa di più simile a un **direttore dei lavori** molto preciso.

[" data-category="1" data-lg-size="1177-2560"

>](https://www.sernicola-labs.com/wp-content/uploads/2026/05/screen_ttc_dashboard-scaled.webp)

[" data-category="1" data-lg-size="1200-896"

>](https://www.sernicola-labs.com/wp-content/uploads/2026/05/recipe_pastina_trota_carota.webp)

[" data-category="1" data-lg-size="1177-2560"

>](https://www.sernicola-labs.com/wp-content/uploads/2026/05/screen_mother_discharge-scaled.webp)

[" data-category="1" data-lg-size="1200-896"

>](https://www.sernicola-labs.com/wp-content/uploads/2026/05/recipe_semolino_manzo_verdure.webp)

#### La curva di apprendimento

**Non ho imparato a programmare**. Non so leggere Swift, non saprei dire dove finisce un blocco di codice e dove ne inizia un altro. Ma ho dovuto imparare tutto il resto.

- Xcode, prima di tutto: come è strutturato, dove si trovano le cose, cosa significa un errore di build rispetto a un warning, come funziona il simulatore.

- App Store Connect: come si configura un'app, cosa sono i capability, come funziona il processo di review, cosa va nell'age rating e cosa nella privacy nutrition label.

- CloudKit: come si struttura la condivisione dei dati tra dispositivi, cosa sono le zone, come funziona la sincronizzazione.

- StoreKit 2: come si configurano le subscription, cosa sono i product identifier, come si testa un acquisto in sandbox.

Niente di tutto questo l'ho imparato scrivendo codice. L'ho imparato leggendo la documentazione Apple, guardando video su YouTube, cercando nei forum, e usando l'AI come interlocutore tecnico ogni volta che mi bloccavo su qualcosa di specifico. "**Cosa significa questo errore?** Perché CloudKit non sincronizza tra i due dispositivi? Qual è la differenza tra un Private Cloud store e uno Shared Cloud store?"

Il vibe coding non elimina la curva di apprendimento. La riduce e la sposta. Invece di imparare a scrivere codice, impari a capire abbastanza dell'argomento per fare le **domande giuste** e riconoscere quando qualcosa non va.

#### Il metodo

Il **metodo** che uso oggi è molto diverso da quello dei primi giorni, ed è venuto fuori per **tentativi** e **aggiustamenti**.
La regola più importante che ho imparato è questa: **un problema per volta**. Ogni intervento sul **codice** ha un **perimetro preciso**. Prima di toccare qualcosa di grosso (che non sia cambiare il colore di un testo), produco un **audit in sola lettura**: Claude Code esamina il **codice esistente** e mi dice cosa c'è, come è strutturato, e quali sono i **rischi** di un intervento. Solo dopo, se il **piano** mi convince, procedo con un’**esecuzione mirata**: ogni **prompt di implementazione** include una lista esplicita di cose da non toccare: **file**, **funzioni**, **servizi** che non devono essere modificati, neanche se sembrano rilevanti.
Per le **funzioni nuove e complesse** il flusso è più lungo. Parto dall'**idea**, faccio **ricerche**, chiedo all'**AI** di abbozzare un **piano di sviluppo strutturato**, lo discuto, lo correggo, e poi procedo **passo per passo**. Per i **lavori ricorrenti** ho configurato alcune **skill** e qualche **sub-agent** che conosce già il **contesto del progetto** e non ha bisogno di essere re-introdotto ogni volta.
Con questo metodo non ho mai perso **lavoro** in modo definitivo. In un paio di occasioni ho avuto delle **regressioni**, ma l'abitudine di salvare ogni **step** prima di un intervento significativo mi ha sempre permesso di **tornare indietro**.

#### Le notifiche CloudKit: una storia di umiltà

C'è una funzione di Ribbon Family che mi ha fatto passare più giorni difficili di qualunque altra: le **notifiche di collaborazione**. L'idea è semplice: **quando un genitore registra qualcosa nel diario del bambino, l'altro riceve una notifica in tempo reale**. Un biberon alle tre di notte, un cambio di pannolino, la temperatura della febbre.

Pensavo fosse relativamente semplice da implementare, appoggiandomi a CloudKit che già gestisce la sincronizzazione dei dati tra i dispositivi dei genitori. Beh, non lo era.

Il problema è che **CloudKit** e le **notifiche push** hanno una loro logica specifica, e i casi limite sono molti. Le **subscription** CloudKit non si comportano come ci si aspetta, iOS silenzia le notifiche, decifrare i log in Console non è poi così semplice, la **sincronizzazione** tra store può arrivare in **ordine diverso su dispositivi diversi.**

Ho impiegato giorni a capire ognuna di queste cose. Non perché fossero impossibili da risolvere, ma perché da profano non sapevo nemmeno che esistessero come problemi. Dovevo prima scoprire che il problema aveva un nome, poi cercare nella documentazione e nei forum degli sviluppatori, poi capire come si traduceva nel mio caso specifico.

Alla fine sono arrivato a un **risultato funzionante**. Ma non mi soddisfa ancora, e ci sto lavorando per un aggiornamento futuro.

#### Ribbon oggi

**Ribbon Family** è un'**app per iOS** che accompagna la **famiglia** dalla **gravidanza** al primo anno di vita del **bambino** e oltre.

- C'è il tracciamento settimana per settimana della gravidanza, con contenuti editoriali prodotti appositamente.

- C'è il diario del bambino: sonno, pasti, pannolini, crescita, febbre, medicine.

- C'è una funzione di calcolo della finestra fertile, che ruota intorno a un algoritmo basato sul metodo sintotermico, per chi sta cercando una gravidanza.

- C'è una sezione svezzamento con una guida alla sicurezza del bambino e sessanta ricette illustrate.

- C'è la condivisione in tempo reale tra partner via CloudKit, in modo che entrambi i genitori vedano sempre i dati aggiornati. 

E ci sono funzioni semplici ma molto utili come i **calendari delle visite della gravidanza**, delle **visite pediatriche** e delle **vaccinazioni**, che i genitori alla prima esperienza affrontano sempre con un certo senso del mistero.

L'ho costruita in **tre mesi**, da solo, senza saper scrivere una riga di **codice**. E senza nessun **server proprietario**: tutti i **dati** restano sul dispositivo dell'utente e nel suo **iCloud personale**.

La preoccupazione che avevo come padre è diventata una **scelta di architettura**.

#### Mi sento l'autore, non lo sviluppatore

Quando guardo **Ribbon Family** oggi non riesco a dire con piena convinzione di sentirmi lo **sviluppatore**. Non ho scritto il **codice**. Non so spiegare nel dettaglio tecnico come funziona la **sincronizzazione** tra i tre **Core Data store** che reggono l'app.
Ma mi sento l'**autore**, senza nessun dubbio.
Ho passato mesi a ragionare sull'**esperienza utente**: quali **schermate**, in quale ordine, con quale **gerarchia di informazioni**. Ho costruito i **mockup** in Figma. Ho pensato all'**architettura delle funzioni**, a come dovevano comportarsi, a quali **casi limite** gestire. Ho scelto ogni **colore**, ogni **testo**, ogni **icona**. Ho lavorato sui **contenuti editoriali**, sulle **ricette**, sul **linguaggio dell'app**. Ho preso centinaia di **decisioni di prodotto**, di **design** e di **direzione**.
Quel lavoro l'ho fatto io. Il **codice** che lo implementa l'ha scritto l'**AI** seguendo le mie **istruzioni**.
È una distinzione che vale la pena fare con chiarezza, perché cambia il modo di guardare al **vibe coding**. Non è un modo per fare il **programmatore** senza esserlo. È un modo per essere il **direttore creativo** e di **prodotto** di qualcosa che senza l'AI non avresti mai potuto costruire.

#### Il limite onesto

C'è una domanda che, ingenuamente, mi sono posto di recente: c’è qualcosa che non posso fare con il **vibe coding**?
Per qualche minuto mi sono risposto di no, ma la verità è che non posso fare una marea di cose, solo che per lo più sono cose che non so di non poter fare.
Posso realizzare quasi tutto quello che mi viene in mente. Alcune cose in modo rapido, altre passandoci settimane, ma con la giusta dose di **impegno** e **metodo** anche le più complesse sono state alla mia portata. Il vero tetto non è tecnico, è **cognitivo**: un **esperto** conosce soluzioni che a me non vengono nemmeno in mente, perché non ho i **riferimenti** per immaginarle. Sa che certi problemi esistono prima ancora di incontrarli. Conosce **pattern architetturali** che io non ho mai sentito nominare. Sa quando una scelta che sembra ragionevole oggi creerà problemi seri tra sei mesi.
Io so fare solo le cose che mi vengono in mente, con i riferimenti che ho. E i miei riferimenti sono molti meno di quelli di uno **sviluppatore esperto**.
Questo è il vero confine del **vibe coding** nel 2026: non quello che non riesci a fare, ma quello che non ti viene nemmeno in mente di fare. E quel confine, per ora, non si sposta studiando **prompt engineering**. Si sposta solo accumulando **esperienza** e **conoscenza del campo**, come in qualunque altro mestiere.

#### A che punto siamo

Il **vibe coding** nel 2026 non è per tutti. Richiede **curiosità**, **pazienza**, e la disponibilità a imparare cose che devi capire abbastanza per non muoverti alla cieca. Richiede **metodo**: senza una **procedura precisa**, un'**AI** che lavora su un **codebase reale** fa danni.
Al momento non sostituisce un **team di sviluppo**, non sostituisce uno **sviluppatore esperto**. Chiunque ti dica il contrario sta semplificando.
Ma per qualcuno con un’**idea chiara**, la voglia di **imparare** e la pazienza di costruire un **metodo funzionante**, è una cosa reale. Non una promessa futura, non un esperimento di laboratorio.
**Ribbon Family** esiste. È sull’App Store. L'ho costruita io, da zero, in tre mesi, partendo da un account Claude che usavo per la SEO del mio sito da fotografo.
Questo mi sembra già abbastanza **straordinario** da raccontare.