In some projects I've participated in, and even created and built directly, I always thought about automating the generation of components, whether in Java, Python, or even JS Backend. It's like creating cartridges and reusing them for construction. After all, computer programming accepts and receives actions and concepts from engineering and architecture.
Today, I and we see VibeCode as something very new, but the concept isn't new . This new name is the same as what we used years ago for development acceleration or reuse tools. What AI can help with will require scaling effort in architecture and high- and medium-complexity integrations. For simpler projects, we can use AI extensively in software engineering.
In programming, what we call and use DDD – Domain Driven Development – has gained a new name, with prediction platforms along with reusable development or implementation cartridges in various languages, but with reusable, registered, and typed logic, almost like a program within a program, you understand?
Vibe coding — prompt, paste, and hope — is great for quick prototypes. ONLY prototypes !
For larger projects, it quickly breaks down.
The fix isn’t “more AI,” it’s better structure. Treat AI like a junior developer: give it context, guardrails, and a clear spec. That’s Spec-Driven Development — and it’s a game changer.
Vibe Coding is FUN ? ...Until It Isn’t
When I first discovered AI coding tools, I fell into what I call the “vibe coding” phase. Need a login page? Prompt the AI. Need styling? Prompt again. Need to fix an error? Another prompt.
At first, using Cursor felt like magic. One or two prompts and boom — working code.
My entire job seemed to be clicking the “Accept All” button. I felt like I’d discovered some kind of coding cheat code.
For about two weeks, I moved fast, building features that somehow worked. This approach is actually perfect for prototypes and demos — you can go from idea to working concept in hours.
But as my project grew, the cracks appeared.
When the Magic Breaks Down
The AI started making expensive mistakes. It would rewrite entire files incorrectly, create functions that already existed, break existing functionality while adding new features. Each new feature came back with different state management, inconsistent styling, and duplicated APIs.
My app started to look like a group project where nobody spoke to each other.
Not only did this slow down development, but it was burning through money fast. All those API calls for code I’d have to throw away and regenerate.
That’s when I realized I had to start reading the code myself. I couldn’t just blindly click “Accept All” anymore. This forced me to learn TypeScript and CSS — which was terrifying at first, but also meant I could start pointing the AI to specific files: “Look at this existing function” or “Follow the pattern in this component.”
The problem wasn’t the AI — it was me.
The great Shift to Specs
In my frustration, I started reading about real software development practices: requirements gathering, design docs, architecture planning. The “serious” stuff I had always thought was overkill for side projects.
Wait. Actually, as a seasoned backend engineer, I already knew this stuff. I’d written design docs for distributed systems, gathered requirements for API features, planned database schemas. The practices weren’t foreign to me — I just hadn’t thought to apply them to frontend development.
Then it hit me: what if I applied these methods, but directed them toward AI?
I began treating AI like a capable but inexperienced teammate. Someone who’s technically skilled but needs proper direction and context.
Building Structure Into AI Development
So I started experimenting. I wrote down what I wanted: the problem, the users, what success looked like, how the feature should fit into the existing system. Then I gave the AI the context it needed: existing APIs, data structures, navigation flow, and design patterns.
The results were night and day.
Instead of vague prompts like “build user authentication,” I’d write detailed specifications:
- What the feature accomplishes and why
- How users interact with it step by step
- Technical requirements and integration points
- Clear acceptance criteria for “done”
Then I’d include project context: how my state management worked, what API patterns I was using, how I organized components.
The Context Breakthrough
Maintaining context became the single most important thing. Instead of letting the AI improvise, I created a living document of how my app worked — existing APIs, page structure, common types, styling patterns.
It was like an employee handbook for the AI.
Keep the specification alive, the build of your project, your solution alive and updated, thinking about the practice of real software architecture and implementation using AI in conjunction with it, not as an end in itself.
Many say nowadays that AI will replace AI, but those who say this don't know what they're talking about, because those who can maintain continuous and high-quality automation are the programmers, it's us. Those who believe that developing software without functional and non-functional specifications and simply pressing a button will be lost, I'm sorry to say.
Spec DDD = Specification Domain Driven Developement
