The Vibe Coding Paradox: Don’t Be Lazy

During my first attempts to code with AI help, a.k.a. “vibe coding,” I naively expected to be as lazy as humanly possible while creating valuable output.

Even though I am an engineer by nature and have some experience in serious code writing, I expected not to bother at all. On the other hand, I keep reading stories every day about how vibe coding is a slot-machine experience and is compared to gambling. I also read posts claiming that you cannot do serious stuff with it.

Well, I decided to prove them wrong and have so far created three unique and fully functional products. The process spanned over half a year, with varying intensity and better results each time. Many lessons were learned. So, I decided to capture those learnings in a blog post.

Why Am I Writing This?

Over a period of 6 months, I built 3 software products, 1 AI agent for internal use and experimented with vibe coding in one very large codebase.

1. Cleven – AI chat aggregator. Mostly built while vibe coding, but I had to intervene manually, and my colleague helped. Did not launch. Served as a research lab. A few weeks of work.
2. Kodis.ai – game creator agent for parents and kids. 95% built with vibe coding, including website style, logo, and brand in general. Minimal manual code intervention. A wild-shot idea. Launched it. A couple of weeks of work if condensed.
3. Planroll.io – resource management tool that is easy and free. I knew the use case to some extent. The goal was to build a fully usable and continuously used product that is 100% vibe coded. It’s more like 99%, since I found color and text tweaking far more productive with my own effort. The logo, style, brand, website, and product were all vibe coded. 5 full workdays from idea to live product.
4. Teamhood.com – end-to-end project management software for high-intensity collaboration among teams. Tried everything from smaller UI changes to full-stack capability implementations in core areas of the product. Very large codebase and high complexity.
5. Content agent – agent to work on marketing content projects from idea to research and execution. Multistep agent which is actually more like a whole workflow comprised of narrow super specialized agents.

Planroll

I am positively shocked by what I was able to build in Planroll and how quickly I was able to build it. I finally feel like my rusty coding experience is no longer an impediment but an asset. It’s as if my hands were broken, and now someone has given me new ones – robotic, faster, more powerful, sometimes even frighteningly powerful.

Lessons Learned

There is so much to tell here, so I will try to categorize. And bear in mind, this is my empirical experience; your own results may vary due to numerous reasons. Lastly, note that these lessons are based on building software products, not static marketing websites. Hence, the inherent complexity is already at least medium to high.

Planning

Don’t be lazy – think about what you want to achieve. Think upfront. Ask the AI agent to consider alternatives and provide pros and cons for each. Plan the architecture as early as possible if you think that you will build bigger things. Require the AI agent to ask clarification questions and to challenge your decisions. Spend more time on your initial prompt, which will most likely create the core project structure as well as the core architectural concepts. I always start in “planning” mode, and only when I see enough evidence that the plan is solid do I allow the agent to start actual coding.

For Planroll’s initial prompt, I was able to get both frontend and backend projects created, with baseline functionality implemented and integrated (including the database layer). I spent close to half an hour writing and discussing the initial solution before I gave the AI agent a go to code.

Architecture

Defining scalable architecture as early as possible is of crucial importance. To avoid ending up with big ball of mud, one needs to guide AI Agent on creating modular enough system so that new changes can be done as isolated as possible without breaking existing stuff. This can be added to general Agent guidelines, as a standard practice. There is a great article by MIT about modular software in AI coding world.

Guidelines

Here are things that I’ve noticed repeat every time I write prompts. So, as a rule, I transfer them to the agent’s “system prompt” or “rules” section (most agents support that). Here are the ones I found impactful:

Approach & mindset

• You are a significantly experienced software engineer who cares about code quality, maintainability, and extensibility.

Code quality & best practices

• Follow S.O.L.I.D. code design principles.
• Prefer smaller code files, functions, methods, and classes.
• Use well-known patterns and best practices.
• Avoid using niche technologies and libraries.
• Unused-code cleanup should be done as the last step in the solution plan.

Planning & problem solving

• Don’t rush to an early conclusion; investigate alternatives until you are confident about the best choice or the root cause if that’s the issue we are solving.
• Test your logic before even starting to code.
• Carefully examine what needs to be done; plan ahead; review your plans and adjust.
• When investigating issues, make sure that you either see a fully clear root cause or you know how to reproduce the issue.

Communication & task management

• Ask clarifying questions until you are absolutely clear on what is required.
• Don’t take all suggestions from the user for granted; challenge them and, if possible, propose better alternatives.
• Provide a confidence score from 0 to 10 for the solution.
• Don’t be lazy – break down work into smaller steps or tasks.

Scope Management

This one is hard, but experience combined with empirical testing will get you there. You need to get a feel for what the agent can do and how much information it requires from you to succeed. As a rule of thumb, start with a smaller task than you actually would like to. Sometimes you can take a bit more risk if, for example, it’s a common solution – like authentication or Google SSO. I was able to get it working with a one-sentence prompt, and if I recall correctly, for less than a few bucks.

If it’s something rare or less common in the existing software world, then extensive prompting, examples, and small increments are a must.

Expectation Management

Well, it’s a soft one. But I find it the most difficult to figure out what to expect if I am being vague. So first of all, don’t be vague. Manage your expectations with clarifications. Otherwise it is truly a gamble. Out of all my experiments, the most clarification needed was in agent tool, because I have envisioned architecture which would work like Pocketflow. I naively hoped that AI will clone, copy the code and we will be good to go. It was only partially successful without frameworkish (that’s my term to name something that requires future-looking implementation when ambiguity is high) approach, hardcoded input/output objects, workflow nodes not truly configurable but one workflow tailored.

Expressive Prompting

Don’t be lazy – use supporting materials such as:

• Mockups (see image below) – I was able to get exactly the same layout and UI as in my mockup with one prompt.
• Examples – help the agent understand edge cases, different use cases, or the general idea.
• When it’s important, be precise; add details to explain how it should work. Elaborate on every functional aspect.
• When it’s more exploratory, be open and don’t lead the solution – let the agent surprise you.

With the layout and UI, I was specific, and I got exactly what I wanted thanks to the mockup. Another example – I asked the agent to create an import wizard in Planroll so that users could save time when configuring the tool, and I left it open for the agent to decide how it should work. I was pleasantly surprised by how much it did – with templates, flexible choices, auto-mapping, and a great UI, by the way (might have been some luck there).

Codebase Scale Management

Ask the agent to maintain a well-structured project file system. Ask it to document the file system guidelines. DON’T BE LAZY – already a cliché, right? You will be able to scale your project’s codebase only as much as the effort you put into it. The lazier you are, the faster you’ll end up with a big ball of mud instead. As with any human engineer, the less clear, structured, and consistent the codebase is, the higher the chance of bugs, blockers, and regressions.

Another clear benefit of a well-maintained codebase is economics, which we’ll discuss later. But in this paragraph, it’s worth mentioning that your goal is to succeed as soon as possible, since every prompt, every request to fix something, and every newly added line of code burns through your budget and time.

Planroll, which is the largest product in terms of vibe-coded source code and functionality, has the following stats:

As you can see, AI agents love commenting on things. A lot of those comments are common sense – a redundant waste of bytes. I will most likely need to add a guideline for this.

Visualization

This might be the hardest part, and it requires extra understanding from a human being, not the agent. You need to know how to express your visual design guidelines in order to get a consistently looking and “beautiful” piece of software. In my experience, the most helpful thing was to explain:

• Who is the target user – for example: “engineer who works most of the day at a desktop machine, prefers darker-themed software, likes efficient design with mathematical precision.”
• What is the feeling of the system’s design – subtle, pop, monochrome, dark-themed, light-themed, flat, 3D, etc. Attach screenshots of examples if possible.
• Ask to use UI SDKs or control libraries – this can remove the necessity of maintaining a design system for the agent, though it can be harder to truly customize via the agent.
• Color palette – provide as early as possible. It’s very easy to find good-looking color palettes on the web and just feed those hex/RGB codes to the agent.
• Icons – suggest using a design-matching open-source icon library. This helps avoid the default use of emojis; at least some agents really love emojis :)).
• CSS – I hate CSS. What’s worse, I hate the CSS written by AI agents. It’s the worst part. I declare as early as possible to maintain a solid CSS library or use an existing one that can be reused whenever possible. Use variables instead of actual values. Have global constants for easy theming. But in my experience, it still feels like a constant battle – I still get raw CSS added in random places…

Things that Failed Miserably

• Expected proper architecture choices without telling what I expect
• Got my working code overwritten and with new bugs – got lazy and skipped thorough review
• Agent thought that it is using the right API spec for external tooling, no it did not. It even hallucinated non-existent API calls. Maybe a problem of over time changing API documentation, but burned quite some time for me
• Found out that each web page had it’s own header and footer hardcoded – again, got myself lazy and skipped a thorough review of a large changeset
• Agent guidelines for CSS – at some point it felt that those were skipped and agent went cowboy style all-in
• Spending 10x more on layout alignments than having full stack features implemented with CRUD and GUI (another CSS rant as well)
• Rushing to execute – sometimes I catch myself rushing to hit the execution mode and then realize that I’ve missed stuff mid process. Hence I rollback to recent checkpoint both code and context. Costs money, you know…

Other Lessons

• Review – trust but verify. Review every change or change proposal. That’s it.
• Test and re-test – regression can hit motivation hard. Just make sure you either have automated testing or retest acceptance level things yourself after larger code changes. Change reviewing helps here as well.
• Tech Debt: Like in every software product, you need to dedicate at least some time to improving the codebase instead of working only on features. This saves time, money, and your sanity.
• Tasking: This can be agent-specific, but as a rule of thumb, I would recommend always starting a new task with fresh context. Don’t let context go on for too long and build up unnecessarily; that increases cost and slows things down.
• Miscellaneous: Some agents are overly optimistic and flattering. This works against you. Ask them to be brutally honest, with no BS attitude.

Tools Used

I am an experienced coder in the Visual Studio ecosystem. My main tool of choice is VS Code. I love .NET for backend work and Vue.js for frontend development. These have influenced some of my choices but are not necessarily a must. Using more popular languages and frameworks is better because it means there was more training data for the AI model.

• Coding IDE – VS Code
• Backend – dotnet
• Frontend – Vue.js with Pinia for reactivity
• Coding agents – Cline, and Cursor
• LLM – Claude Sonnet 4.5, from my experience – the best model for writing code. Tried Gemini 2.5, Grok, GPT 4 – all inferior.
• Mockups – Figma
• Source control – git and github

Cline is my default choice for agent for now, it fit like a glove because it’s an extension to VS Code. I can keep working in my favorite IDE without moving to another platform. It allows to chose any model you want via Openrouter. What I also like about Cline is that it has design thinking built-in and can express thoughts in ASCII art.

It has great file system tooling for finding code. It also has the ability to break work down into smaller tasks on its own (recently added functionality, which makes a big difference when you are building larger projects). Cline also creates solution documentation in .md files as part of the code. Later, these .md files can be referenced by itself to continue working or extending the existing functionality.

In my most recent development I have tested Cursor. It is a bit different that regular IDE, as it’s focused on Agentic coding first. The good part is that it’s still based on VS Code fork, so a lot just works as I am used to. In the begging I chose to use agentic IDE style config instead of classic VS code config. I am not sure whether this was a good choice. I am still more confident to have code files and project structure as the main aspects of solution while agent chat is a secondary thing.

Critically important thin for a coding agent – checkpoints. It’s a must in my opinion. If your prompt or solution attempt fails, just roll back a step and start over. You can manage this with commits, but it’s code only; you also need to roll back the agent’s context to steer it better.

Cursor vs Cline – main differences

• Cline is sequential and executes everything in linear manner, though I am unsure about behind the scenes, but Cursor seems to execute coding part in parallel. Moreover, Cursor can execute multiple agents in parallel or even models. Have not leveraged multiple agents at once though…
• Cursor feels slower in planning phase, but due to parallel execution is faster in coding phase. Though this might be subjective to my still limited experience.
• VS code with Cline as plugin feels more productive than facelifted VS code of Cursor

For now, there is no clear winner in my view. I will need to dedicate more time in my experiments to get this one figured out. Finally, products change over time so my impressions are also subject to change.

Skills that Help

I am not 100% sure, but it feels that the skills I mention below have something to do with some of the successes.

• Experience in product management
• Experience in delegating work
• Experience in capturing complex problems or ideas and transforming them into tasks
• Breaking down work into smaller pieces
• Planning ahead
• Patience
• Being fearless in abandoning the current approach and starting from scratch
• Coding skills
• Software architecture skills
• Design thinking
• Being adaptive
• End-result focus
• Not being lazy
• Code change reviewing
• Testing
• Recognizing good code vs. poor code

As a product manager, I feel that I was always vibe coding – except earlier, before the agents, I was writing PRDs and specs for humans, with mockups and varying levels of detail.

Don’t be Lazy

That’s my main lesson: the quality of coding agent results is inversely proportional to your level of laziness. It never gets easier – it just gets faster.

Economics

The sad truth is that the larger the project, the higher the cost. I have experimented with Cline in Teamhood’s codebase, which is significantly larger than my pet projects. It still does the job, but at least two to three times the cost – sometimes even tenfold. Adding a new button can cost you a buck in a larger codebase, while creating a full project structure with front and back in a new project will cost you the same buck. That’s mainly due to the amount of file reads and code lookups the tool needs to do. Smaller files and a cleaner structure help a bit. Well-named variables and your own consistency in terminology also help a lot. Be clear, precise, and avoid ambiguous terms.

Final Conclusions

Coding agents are already very powerful. With the right steering, you can accomplish a lot — especially the least fun coding parts, such as boilerplate, scaffolding, common functionality like authentication, database modeling, and many, many more things.

What they cannot replace yet is that edge of professional software craftsmanship, where every detail matters.

What’s Next?

I have gotten away without doing tests, which is not very professional. But since I have succeeded in my proof of concept, tests are the next thing I will do. I already have a live product with active users, so I need to start being more careful: avoid regression, and spend more time on quality than on speed.