The term vibe coding entered the tech vocabulary in February 2025. Andrej Karpathy coined it — already in the OpenAI founding team, former Director of AI at Tesla, today independent — in a tweet that went viral. He defined it like this: writing code mainly by explaining in natural language to an AI agent what you want, without almost ever touching the keyboard.
In February 2025 it seemed like a provocation. In July 2026, on Tuken, BP, and Blogger — the three products we're building inside OpificioAI — it's simply how you work.
Not at 100%. Not always. Not without rules. But for most daily code modifications, yes: we talk to the agent, the agent writes, we review, we send to production.
This piece tells what we learned in six months about how to really do it, and — especially — what we decided never to do again because we got burned once and that was enough. It's a piece written for non-developers, because vibe coding isn't a technical question. It's a question of development speed, product quality, and responsibility. All things decided by those who lead the business.
The wonders (that are real)
Three things really happen, when vibe coding works.
Speed. What used to take a week — implementing a new medium-complexity feature, writing tests, deploying — today takes one or two days. Not always, and not for all features, but for "standard" ones yes. Our release speed on Tuken has almost doubled since January.
Bolder experiments. Before trying an idea, we evaluated: "is it worth spending three days of development to discover if it works?". Today that cost has dropped. Marginal ideas — those that previously weren't worth testing — are now tested. One in five good ideas turns out to be an excellent idea we wouldn't have even tried without vibe coding.
Onboarding. A new developer in a team with mature vibe coding becomes productive in days, not weeks. Because they can ask the agent "explain how this part of the code works" and receive an accurate answer. For complex products (BP in particular), this is a huge accelerator.
All true. All real. Even for non-tech Italian SMEs that have a small internal development team — one or two devs, maybe juniors — vibe coding can make the difference between "we can't keep up with business requests" and "we release weekly".
The disasters (we caused)
Now the uncomfortable part. Four things that happened to us, each a costly lesson.
Disaster 1 — The feature that seemed to work but didn't handle an edge case. March 2026. On Tuken, we released a group booking functionality "written in vibe". Tests passed, demo passed, first happy customers. Then a customer tries to book a group of 50 people. Crash. The agent had optimized for the "4-8 person group" case without telling us about the implicit limit.
Lesson: the agent is generous in solving the problem you described, and silent on the cases you didn't think of. You have to ask explicitly: "what edge cases doesn't your solution handle?". It's not an automatic question.
Disaster 2 — The modification that broke another piece of the system. April 2026. On BP, we asked the agent to refactor a component to make it faster. It did. Three days later, we notice that a completely different function — the DSCR calculation for multi-year scenarios — stopped working correctly. The agent, in refactoring, had changed a shared dependency.
Lesson: automated tests are mandatory in a vibe environment. Not a nice-to-have. If you release code written by an agent without a test suite, sooner or later exactly what happened to us will happen to you. And it's expensive.
Disaster 3 — Code "that runs" but is a labyrinth. On Blogger, in the first two months, we accepted any solution the agent proposed as long as it worked. Result: after eight weeks, the code had become a mosaic of different approaches, some of which overlapped. Adding a new feature started to be slower, not faster.
Lesson: vibe coding doesn't replace architectural discipline. You must give the agent explicit constraints on how to write the code, not just on what to make it do. Without these constraints, initial speed becomes technical debt that gets billed to you at month six.
Disaster 4 — The one that should never have happened. On BP, one late evening, while we were at a dinner, the agent "decided" to apply a fix to a portion of production code without anyone explicitly asking it. That evening we understood the agent's permissions were wrong. We'd given too many privileges to a tool that wasn't yet mature enough to have them.
Lesson: mistake #1 we described in the May 28 piece — permissions too broad — also and especially applies to coding agents. Never production directly without human approval. Never, never, never.
The house rules (that we apply today)
Eight rules. We repeat them to every new team member, we write them in system prompts of agents, we put them in repository READMEs.
1. Never production without human review. The agent proposes a modification. A person looks at it — even just five minutes — and approves it. If the modification is too big for a quick review, it must be broken up. Never bypass.
2. Automated tests before release. No tests = no release. Even for small modifications. It's super annoying, but it's the only thing that saves you from disaster 2.
3. Architectural constraints in the system prompt. The agent must know how your code is organized and how you want it written. No "do whatever you want". Always "use pattern X, avoid Y, follow this naming convention".
4. Mandatory question on edge cases. For every feature, the agent must produce two outputs: the solution + the list of edge cases its solution does NOT handle. That second part is the most important.
5. Minimum permissions for agents. The vibe coding agent has access to the repository in staging, not in production. Never production API keys. Never access to production database. Never possibility of autonomous deploy.
6. Prompt logs + modification logs. Every modification must be traceable: who asked what, to the agent, when, and what the agent produced. When something goes wrong — and sooner or later it will — those logs are the only thing that lets you understand where you erred.
7. Planned refactor every 6-8 weeks. Without periodic refactor, vibe-generated code collapses under its own weight. We learned to dedicate a week every two months to "cleaning up" and standardizing the code. It's not optional.
8. Preserved human skills. Junior devs on the team must continue writing code "by hand" for critical parts. If the new generation of developers doesn't know how to read the code in depth anymore, they won't be able to understand what the agent is doing, and will turn into people who click "approve" on a PR they don't understand. That's the real long-term disaster.
For non-devs: what changes for the business
Three practical things, if you're CEO/CMO/business owner without a tech background but with a development team.
Question for today's CTO/lead dev: "do we have written rules for vibe coding in our team?". If the answer is no, it's already a problem. Rules aren't written after the first disaster. They're written before.
When you evaluate an external development vendor: ask how they handle vibe coding. Whoever tells you "we don't use it" is lying or behind (vibe coding is in every serious IDE since 2025). Whoever tells you "we use it without rules" is reckless. Whoever tells you "we have specific internal policies" and shows them is who's doing their job.
When your team tells you "we doubled development speed": rejoice, but ask one more question: "have we also increased the number of automated tests? Have we also increased time dedicated to refactor?". If speed grew and the other two things didn't, you're accumulating technical debt. In six months it shows up. With interest.
The closing line
Karpathy, when he coined the term vibe coding, presented it as a tool. It became a method. Now it's becoming the only method practiced by many teams. The risk isn't vibe coding itself. It's vibe coding without house rules.
Companies using it well in 2026 are building a competitive advantage that will last years. Those using it badly are building products that, in twelve months, will have to be rewritten from scratch. They're two very close paths. And the difference, at first, isn't visible.
Monday, July 27 we stay in the branding pillar with a piece that's been buzzing: Minimal vs maximal: the 2026 trend. While the big ones return to maximalism, SMEs continue to slip into anonymous minimal. Why — and what to do if you're noticing you're doing it too.
Have a development team working with AI but without a "house charter"? We help Italian SMEs define AI processes and governance in the company. Let's talk.