The rise of the professional vibe coder (Category Engineering)
Lenny did it the other day. interview About Wibe coding with Lazar Jovanovic from Lovable (His title is “Professional Vibe Coder.”). And there is a perfectly formulated that how to use Lovable and not only for vibe engineering and fast delivery of features to your application. From the interview you can get many insights, including the following:
What is Vibe Engineering? (honestly) It’s a shift from “syntax micromanagement” to intention management. Previous: Write classes/cycles, Google errors, spend half a day
- Now, you're describing what should be. (UX, business logic, limitations, edge cases) You Validate as a Product and Engineer at the Same Time
I went straight to system-design.space and it really works – for an evening and part of the night I reassembled the project, optimizing performance + SEO, moved to another hosting. (I just moved out of Lovable.), added a website search. All in all, it's a very inspiring experience - the feedback cycle is short and hours go by from idea to result.
Lazar frames the work in his video as the formulation of "jinn's wishes"
- What product/feature? Who's the user? What is considered “ready” or DoD criteria (definition of done)
- Limitations. (data, access, SLA, security) And he's at Lovable for 20–40 In minutes you get a skeleton: UI, API, models, basic logic. This is the moment when “something clickable” comes out of your head and the team stops arguing with abstractions.
And I kind of start projects like this -- with a conditional visual. But then I go to Codex, and I spin what separates the demo from the production: checks, error handling, migrations, tests, logging, access rights, refactoring. I guess I can do it in Lovable, but I'm more comfortable doing it in a different way. As a result, short iterations are obtained: collected → clicked → broken → clarified the prompt → repeated. Cycle time is clocks, not sprints.
The main insight from the interview relates to non-tech n They can be really faster than engineers because they don't get sucked into "let's pick a library/perfect architecture." They have only one thing in mind: value to the user. But as a technologist and manager, I will add that quality and responsibility have not gone away – the point of application of efforts has simply shifted. And then anyway.
If you think about what this approach changes for the market and teams, then the following comes to mind: The ability to write boilerplate has been devalued. What used to be “above the code” is valued: decomposition, architecture, product taste, responsibility for risk. The roles of product managers and engineers are blurred. There is a hybrid: a product engineer who can invent and assemble a product.
- For MVP and internal bodies, this is generally a cheat code: you can close the backlog by force 1–2 People with strong product sense + discipline.
But there's also the dark side of vaiba: If you just “pump” without a frame, you get a beautiful interface with leaky security and technical debt that will explode through the block. So my rule of thumb: Vaib - for speed and shape, ия Engineering - for borders (security, access, tests, surveillance, data), Responsibility is always on people, not on models.
In short, making a product is easier, but doing it well still requires professional skills. Just now these skills are not a set of syntactic tricks, but the ability to quickly and accurately "order" the system and bring it to a reliable state.
#AI #VibeEngineering #Product #Software #Architecture #Lovable #Codex #Productivity #Management #Leadership