Ecco come mi sento riguardo al vibe coding. Qualsiasi progetto che provo e che presenta qualche tipo di complicazione ha questo immediato slancio di progresso. Le cose sono fantastiche e sembra di avere un superpotere. Poi... man mano che aggiungo più complessità, tutto si ferma bruscamente. Gli unici progetti che penso di poter creare sono quelli che rientrano in questa "zona vibe". Prototipi, interfacce utente, prodotti—qualsiasi cosa sia semplice e abbia bassa complessità si inserisce perfettamente in quella zona. Prove di concetti, interazioni, cose del genere. Gli strumenti sono in grado di creare cose che si adattano a quel contesto. Ma. Tutto va in pezzi man mano che quella curva di complessità aumenta. E il problema è che qualsiasi buon processo di design del prodotto ha una complessità crescente. Un prototipo di base diventa un buon prototipo non appena ha interazioni stratificate, transizioni, buone affordances, stati di hover, 1000 piccoli dettagli che fanno sentire qualcosa di corretto e reale. Il vantaggio del vibe coding dovrebbe essere che ci si muove velocemente e si possono creare cose al volo—lasciando che l'IA faccia tutto il lavoro per te. Il problema è che perde slancio non appena viene aggiunta la complessità necessaria. Continua a rifare se stesso, riscrivere codice, influenzare cose che non sono correlate e poi causare altri problemi. Ma se aggiungi quella complessità, ogni sessione di vibe coding si trasforma rapidamente in una sessione di bug-bashing alla whack-a-mole. Non sono sicuro della soluzione a questo. Con il prototipaggio tradizionale la soluzione è duplicare, aggiungere più complessità, creare più frame/scenari, modificare, forkare, ecc. Tuttavia, con il vibe coding, un piccolo prompt può distruggere letteralmente tutto. C'è una fase in cui finisco per camminare su gusci d'uovo di prompt—cercando di non dargli troppa o troppo poca contesto affinché non diventi ribelle e rompa tutto. Ci sono solo poche eccezioni a questo. @cursor e @framer. Posso fare grandi progressi con Cursor, dargli un contesto ristretto, e devo approvare le modifiche che fa. Questo sembra un flusso di lavoro corretto. Il problema è che non posso vedere la cosa che sta creando perché è un IDE, non un ambiente visivo. Sì, posso creare build locali e aggiornare il mio browser e tutto quel genere di cose. Ma l'aspetto visivo è totalmente perso dall'esperienza di coding. È uno strumento per sviluppatori. Framer fa questo nel modo giusto perché consente solo aggiornamenti ristretti all'interno di un singolo componente sulla pagina. Sì, è limitante perché può fare solo una cosa alla volta, ma almeno non sta cercando di creare l'intera pagina da zero e gestirla tutto attraverso un'interfaccia di prompt. Questi sembrano l'approccio giusto. @Cursor: Permetti all'IA di modificare qualsiasi cosa ma consenti all'utente di approvare quelle modifiche e vederle nel contesto. @Framer: Permetti all'IA di modificare solo in modo ristretto un singolo file o componente per mantenere la complessità al minimo e ridurre le modifiche catastrofiche. Sono ottimista che strumenti come @Figma, @Lovable, @Bolt e @V0 possano creare prototipi interessanti, ma continuo a sbattere contro muri quando si tratta di fare qualcosa di più di un semplice prototipo di interazione di base. Devono fare meno secondo me. Spero che quegli strumenti aggiungano più controlli che siano sulla stessa linea di Cursor e Framer. Aggiungo anche che questo è simile a come lo facciamo con la generazione di grafici di @Basedash. Ma non siamo uno strumento vibe nel senso normale, quindi i paralleli sono un po' più difficili da tracciare.