Can You Really Vibe Code an App?

What

Since I’m currently working on equipping my home with solar panels, I found the lack of a proper calculator quite strange. There are a few calculators developed and owned by companies selling solar panels and systems, but they tend to be overly optimistic in their calculations. Also, when you start looking at more complex systems with an EV charger, batteries, and a heat pump, I found that even the sellers struggle to provide proper answers.

So, as a side project, I decided to vibe code an application to help others. For now, it only works for Croatia: Solar Web

How

I started coding with Google Gemini models using a prepaid plan. There is no subscription; instead, you add money, get an API key, and use it from VS Code. This is also the most expensive way to do it, since there are no included tokens and you are charged directly as you use them. I also had quite a few issues with the availability of the Gemini 3.1 Pro model, and most of the time I ran into availability errors.

I also found the Gemini models not to be particularly good for coding, so I switched to GitHub Copilot. I needed a subscription anyway for other things, so I decided to try it on this project as well. At that point, the project was not quite finished: the UI was there, but the calculations were only around 50% implemented or correct.

It took quite a few iterations. At the moment, my repository has 56 commits, which roughly means 56 iterations with the model to fix something, since each iteration I completed ended up as a PR. The project is still very much a work in progress.

To be honest, most of those iterations went into a strange bug where my Azure Function was not being deployed to Azure. In the end, it was fixed by completely excluding tests from the Function App build. It took quite a bit of time before any of the models could figure it out. In the end, it was GPT 5.6 Luna - the cheapest of all the models I tried that found the solution.

Something else also changed during the process. I started with VS Code, my dev container, and all the tools I usually have when developing at work. But with each iteration, I started using the GitHub Copilot App more and more, and by now I barely look at the code at all. I rely on tests written based on my requests, the CI/CD pipeline, and visual testing of the deployed application.

There are also two additional reasons why the Copilot App works particularly well for me:

1. Mobile app – Since I do most of my hobby projects in the evening, when I also have other family obligations, the ability to steer Copilot from my mobile phone is extremely convenient.
2. Agent merge – With this functionality, you can hand over the full PR lifecycle to your agent. It can check build failures, fix them, and even approve the PR once everything is green.

Of course, this can work well for a hobby or demo application, but the more critical the application, the more important human review, local validation, security review, observability, and operational knowledge become.

The first problem is that I now have very little idea about the quality of the code itself. My frontend development days ended a long time ago, around the time of jQuery and HTML 4, so I do not have much expertise in the modern frontend stack anyway. My own code review would therefore not add much value.

There are, of course, tools on the GitHub platform that can help with this, such as Code Quality and Copilot code review. However, since this is a hobby repository on a free tier, these features are not available to me out of the box. They would probably help me get more confidence in the code quality, but I have not used them yet.

The second problem is that my Copilot App environment does not have all the tools needed to build or validate the code locally. This means that some build issues are only discovered after I push the code and the pipeline runs. This way of working is slower and consumes more tokens, but I did not have the time to improve the setup - maybe that will be the topic of the next blog post.

Lessons learned

So, can you really vibe code an app? My answer is yes, but with an important qualification.

I was able to build a working application without manually writing most of the code, and for a hobby project, this approach can be surprisingly effective. But I did not eliminate the engineering work; I moved it somewhere else. Instead of spending my time implementing the UI and business logic, I spent it describing requirements, reviewing results through tests and deployed builds, investigating failures, and deciding whether the application was actually doing what I expected.

The biggest lesson for me is that the better your validation loop is, the further vibe coding can take you. Tests, CI/CD, visual validation, and a production environment effectively became my code review process.

At the same time, I am much less confident about the quality of the underlying code than I would be with a traditional development workflow. For a hobby application, that is a trade-off I am happy to make. For something where correctness, security, maintainability, or reliability really matter, I would not trust the same process without much stronger human review and validation.

In other words, vibe coding did not make software engineering disappear. It changed the part of engineering I spend my time on - from writing code to defining what the code should do and proving that it actually does it.