Il problema del vibe coding non è nel codiceThe problem with vibe coding isn't the code

Una riflessione partita come entusiasmo, (quasi) finita come rifiuto.A reflection that started as enthusiasm and (almost) ended as rejection.

Metto le mani avanti perché chi mi conosce so già cosa sta per dire,
ma calma.

Sono stato uno dei primi che all’inizio ha urlato

Il vibecoding è una figata

Mi piaceva davvero tanto, è stato un momento di riconoscimento puro dei miei limiti.
Ho probabilmente perso centinaia di euro in subscription
perché volevo testarli tutti, con l’idea che prima o poi qualche interfaccia
farà davvero davvero bene quello che ho in testa.

Da designer mi sembrava di aver sbloccato il sacro graal, anni a cercare di studiare programmazione e poi finalmente qualcuno che lo fa al posto mio…

Mi sbagliavo.

Mi ha aperto la testa, sì.
Mi ha fatto pensare: ok, ora posso finalmente risolvere da solo problemi che prima richiedevano sempre uno sviluppatore, tempo, incastri, attese.


Insomma quelle che comunemente chiamiamo competenze.

E mi ha un po’ illuso di poter far partire la nuova unicorn italiana da 10 billion.
Perché qualche mia idea è pure caruccia (me l’ha detto la mamma).
E sono sicuro che nessuno di voi vorrà mettersi contro…vero???

Per chi lavora su prodotto, design e sistemi… è stato quasi liberatorio.

E infatti quella fase era sana. Era pura esplorazione.

Il punto è cosa succede dopo?

Il problema non è quando funziona,
ma quando diventa un pretesto.

Quando il vibe coding smette di essere uno strumento
e diventa un pretesto per legittimare decisioni già prese altrove.
Un nuovo modo di lavorare che nessuno ha davvero deciso o testato,
ma che a un certo punto sembra essere l’unica strada sensata.

Perché funziona, è veloce 🏁
Ti fa fare cose che prima richiedevano tempo, competenze,
delle persone. Dei team complessi che dovevano lanciare deploy, risolvere bug
e cercare di integrare una nuova funziona perché il CEO la mattina si è svegliato
e voleva rivoluzionare il mondo.


Quando “fare di più con meno” diventa una strategia

Ed è qui che la cosa smette di essere solo tecnica.

In molti contesti ho visto il vibe coding diventare un argomento comodo.
Siamo più veloci. Riusciamo a fare le stesse cose con molto meno.
Meno tempo, meno persone…

Che spesso è solo un altro modo per parlare di costi,
ne abbiamo parlato nello scorso post.

Nei sistemi un po’ più grandi, i costi sono sempre la prima variabile che si guarda.
E quando trovi una narrativa che ti permette di dire
che puoi tagliare senza perdere valore,
quella narrativa diventa immediatamente una strategia.

Il problema è che i costi non spariscono mai davvero.
Si spostano. Si posticipano.
e quasi mai li pagherà chi ha preso la decisione.

Si spostano sulle persone che restano
e devono capire tutto.
Su ruoli che diventano vaghi.
Su sistemi che funzionano finché nessuno li stressa veramente.
Su storici di righe di codice scritte da persone che il contesto non riteneva più necessarie.


Il contesto?

Intendo le decisioni, i vincoli, l’ownership…
Anche lui resta fuori dalla porta dopo esser stato licenziato.

A quel punto non stai più usando l’AI per pensare meglio.
La stai usando per evitare di pensare al contesto.

Il codice funziona per carità…
Ma spesso non sai il perché.
E non sai cosa succederà quando qualcun altro ci metterà mano
e poi dovrai rimettercela tu perché avrai bisogno di cambiare qualcosa…
e lì inizieranno a vedersi i primi problemi.

Non è una critica al vibe coding per carità.

È una critica a ciò che succede quando nessuno si prende carico del contesto.
Di quando si prendono decisioni perché sono mainstream,
perché “che ci vuole per creare un nuovo CRM da zero in 5min” per farti risparmiare tempo e soldi, quando magari stai lavorando con un macigno che ha 20 anni di dati, persone e decisioni stratificate.

Ed è sempre lì che i problemi iniziano (mannaggia eh).

Vi lascio un ascolto che magari non sarà di vostro gusto (ho gusti strani).
Però racchiude bene come mi sentivo in quel periodo di vibe coding.
Entusiasmo incluso.

Alla prossima 👋🏻

Let me get ahead of this, because I already know what the people who know me are about to say,
but hold on.

I was one of the first people who, early on, shouted

Vibe coding is awesome

I really loved it. It was a moment of pure recognition of my own limits.
I probably burned hundreds of euros on subscriptions
because I wanted to try them all, convinced that sooner or later some interface
would do really, really well what I had in my head.

As a designer, it felt like I'd unlocked the holy grail. Years of trying to learn to code, and finally someone doing it for me…

I was wrong.

It opened my mind, sure.
It made me think: okay, now I can finally solve on my own the problems that used to always need a developer, time, juggling schedules, waiting.


Basically, what we usually call skills.

And it kind of fooled me into thinking I could launch Italy's next 10-billion unicorn.
Because some of my ideas are actually pretty cute (my mom said so).
And I'm sure none of you would want to argue with that…right???

For anyone working on product, design and systems… it was almost liberating.

And honestly, that phase was healthy. It was pure exploration.

The question is, what happens next?

The problem isn't when it works,
it's when it becomes an excuse.

When vibe coding stops being a tool
and becomes an excuse to legitimize decisions already made somewhere else.
A new way of working that nobody actually decided on or tested,
but that at some point seems like the only sensible path.

Because it works, it's fast 🏁
It lets you do things that used to take time, skills,
people. Complex teams that had to ship deploys, fix bugs
and try to integrate a new feature because the CEO woke up that morning
and wanted to change the world.


When “doing more with less” becomes a strategy

And this is where it stops being just a technical thing.

In a lot of contexts I've seen vibe coding turn into a convenient argument.
We're faster. We can do the same things with a lot less.
Less time, fewer people…

Which is often just another way of talking about costs,
we talked about that in the last post.

In bigger systems, cost is always the first variable people look at.
And when you find a narrative that lets you say
you can cut without losing value,
that narrative instantly becomes a strategy.

The problem is that costs never really disappear.
They shift. They get pushed down the road.
and they're almost never paid by whoever made the decision.

They shift onto the people who stay
and have to figure everything out.
Onto roles that turn vague.
Onto systems that work until someone actually puts them under stress.
Onto a history of lines of code written by people the context no longer considered necessary.


The context?

I mean the decisions, the constraints, the ownership…
It gets left outside the door too, after being laid off.

At that point you're no longer using AI to think better.
You're using it to avoid thinking about the context.

The code works, sure…
But often you don't know why.
And you don't know what will happen when someone else gets their hands on it
and then you have to go back in yourself because you need to change something…
and that's when the first problems start to show.

Look, this isn't a criticism of vibe coding.

It's a criticism of what happens when nobody takes ownership of the context.
Of decisions made because they're mainstream,
because “how hard can it be to build a new CRM from scratch in 5 minutes” to save you time and money, when maybe you're dealing with a monster that has 20 years of layered data, people and decisions.

And that's always where the problems start (go figure).

I'll leave you with a listen that might not be your cup of tea (I have weird taste).
But it captures pretty well how I felt during that vibe coding period.
Enthusiasm included.

Until next time 👋🏻

Next article Il costo del contestoThe cost of context