Beyond Vibe Coding: What I Learned in Practice About AI in Software Development
Going Beyond “Vibe Coding”: What I’ve Learned in Practice About Using AI in Software Development
Recently, I started reading “Beyond Vibe Coding: From Coder to AI-Era Developer” by Addy Osmani, and I’ll admit I got curious: I wanted to understand how other people are dealing with this more “vibe” way of building with AI — and, more importantly, how it fits into the real world, with deadlines, requirements, quality, and everything we know actually matters.
In the first chapters, something really stood out to me: he doesn’t talk only about vibe coding. He also mentions a practice I didn’t really know by name, but that I realized I’ve been doing for months: AI-assisted engineering.
And that’s when the reading started to feel like a mirror. I understood better why I had some resistance to “pure vibe” — and why, without even noticing, I naturally pushed my use of AI toward a more structured approach.
Two Ways to Build With AI
Over time, I’ve come to see these two practices as two different ways of getting an idea off the ground.
Vibe Coding: Validate Fast
With vibe coding, you describe what you want at a high level, almost like saying: “build a screen like this, with this flow, and that’s it.” You don’t worry too much about implementation — the logic is similar to prototyping: you want to test the idea, feel the product, validate a hypothesis.
But I’d add one honest disclaimer: think of it as a draft, not the final version. Bugs will show up, things will need adjustments, and sometimes you’ll get a “half-truth” too. Still, for exploring possibilities and shaping something quickly, it works really well.
AI-Assisted Engineering: Build With Precision
AI-assisted engineering, the way I’ve experienced it, is a different conversation. Here, you invest more time upfront: • you describe the features more clearly • you build a roadmap and phases • you define rules, responsibilities, and expectations • you organize what the system should (and should not) do
Only after that do you move into implementation. In practice, it’s like AI becomes an engineering assistant, not just a “pair of hands that types.”
Why I Gravitated Toward Engineering
I think a lot of this comes from my background.
Because my foundation in software was shaped by analysis, requirements gathering, diagramming, and UML, I’ve always had a natural tendency to understand things before building them. So when I tried to lean into vibe coding in a fully “creative mode,” I felt some friction.
Not because it didn’t work… but because I couldn’t turn off the part of my brain that asks:
- “Okay, but what about the structure?”
- “What are the domain boundaries?”
- “How will this be maintained later?”
- “What happens when it grows?”
In the end, I didn’t abandon vibe coding. I just realized it works best for me when I treat it as prototyping — and when I want something more solid, I switch back to AI-assisted engineering.
What I Noticed Across Platforms
Over the last six or seven months, I’ve used several platforms for both vibe coding and AI-assisted engineering — and one thing became clear: they all deliver part of what you expect.
Sometimes the layout isn’t exactly what you described. Sometimes a feature is right “in general,” but with messy details. At the same time, I’ve noticed this is improving quickly: newer AI models are delivering solutions much closer to what was requested. There are still discrepancies here and there, but overall tools like Kimi, Claude Code, and Gemini have been evolving a lot.
There’s another point that has also caught my attention.
I’ve noticed that AI-assisted development platforms have been trying to define standards — not only for documentation, but also for rules, workflows, and how a project should be organized. In the end, a lot of things look similar from one tool to another: sometimes it feels like more changes in naming than in the underlying idea.
And something interesting is that, despite differences in marketing and “how they sell it,” many of these standards lean on something we developers have been used to for a long time: Markdown. It’s almost like the market is converging toward a shared “contract” format between humans and AI — simple, readable, versionable, and easy to keep next to the codebase.
And maybe that’s why, in day-to-day use, I often feel these tools are becoming more similar than different. In the end, the “final effect” is often close — what changes is where each one fits best, depending on project size, implementation type, and how much control you need over the output.
How I Choose Each Approach Today
My sense is that vibe coding is extremely useful when you want something fast: validate value, try a flow, demonstrate an idea working without spending too much energy chasing perfection.
AI-assisted engineering, on the other hand, often becomes a natural evolution — including for projects that started in vibe mode. But it stands on a different foundation: focus on fundamentals, maintainability, security, organization, and predictability. It’s not that one cancels the other; very often they complement each other, depending on the project stage and the level of commitment you want to place on it.
If I had to summarize it in one line, I’d say I see them more as phases than as opposites: first you prove the idea; then you decide whether it’s worth building it properly.
Wrapping Up
I still plan to write more as I organize these ideas and gather more experiences, but I wanted to capture this slice of what I’ve been seeing: there’s a legitimate space for “vibe” — and there’s an indispensable space for engineering.
AI tools help us build faster and, often, more accurately. We spend less time on silly mistakes, repetitive details, and things that — with experience — you’ve already run into dozens of times. And at least for me, that has proven extremely useful both for learning and for productivity.
In the end, the key isn’t only the tool. It’s knowing which mode you’re operating in, and what kind of result you’re actually aiming for.