Vibe Coding Works. That’s Exactly What Makes It Interesting

A while ago, I was looking for a todo app. Not because there’s any shortage of todo apps. Quite the opposite. But the apps I tried never quite matched the way I wanted to work. There were SaaS apps that came pretty close, but I quickly ran into the limits of their free plans.

Then I had a thought that would have sounded fairly ridiculous a few years ago: for the price of one of those subscriptions, I might as well have a coding agent build the application for me.

That became Priora (the name was AI-generated).

I deliberately chose a todo app. It’s more or less the standard project beginners use to learn programming. The rules are straightforward, the domain is easy to understand, and as a user it’s relatively easy to determine whether something works. At the same time, I already wanted a todo app that better suited the way I work.

That made it a good project for trying something I deliberately don’t do professionally: full-on vibe coding.

The agreement I made with myself was simple. I would focus on what the application should do, test whether it worked, and feed my findings back to the agent.

But I wouldn’t look at the code.

An Experiment That Simply Worked

I built Priora using Cursor and a high-end model. The way I prompted it was actually quite similar to how I would give an assignment to a junior developer. I described what I wanted to achieve and provided enough context to get started, without prescribing the technical solution upfront.

Of course, I can’t completely separate that from my technical background. Once you’ve been developing software for long enough, you automatically describe certain problems differently. When something goes wrong, I sometimes already have an idea of roughly where the problem might be. With certain functionality, I know there’s probably a relationship or junction table somewhere. But I didn’t check whether there actually was one.

The cycle was roughly the same each time: describe a feature, let the agent implement it, use Priora, test it functionally, and feed the results back to the agent.

That probably took twelve hours or more. So vibe coding certainly doesn’t mean typing a few sentences, going for coffee, and returning to a finished product. Even when an agent writes virtually all of the code, building software is still work.

In this case, though, the result genuinely was a useful application.

Priora now has an inbox, projects, labels, and priorities. There’s a Today view and an Upcoming view. I can reschedule overdue tasks. Tasks can have different states, such as OnHold and InProgress. I can add notes, and descriptions are Markdown-first, including highlighting and preview.

There’s also an Activities view that acts as an audit trail, showing what happened to a task. I can even restore a deleted task from there. And, of course, there’s authentication.

But the length of that feature list isn’t really the point. I use Priora every day. For the purpose I built it for, the application works.

I Have No Idea How It Was Built

That’s where this experiment gets a little strange.

I’m a software developer. I use an application every day that I had built for myself, yet I don’t know how that application works internally.

I don’t know how the database mappings are set up. I don’t know whether the application uses vertical slices, attempts to follow DDD, mostly consists of services, or ultimately became a collection of classes in a single project. I don’t know how responsibilities are divided or how much technical debt accumulated during those twelve hours.

I was curious about all of that. Especially because these are exactly the things I would normally look at automatically. But not doing so was part of the experiment. If I opened the solution every time I encountered an interesting decision just to see what the agent had done, I would have been testing something else.

So I didn’t.

Even when something went wrong, I stayed on the outside. I didn’t open the logs or dig through the code to find the cause. I described the problem I observed and gave that back to the agent.

My experience as a developer didn’t disappear. It influenced my instructions and helped me recognize problems and describe them more precisely. But I didn’t use that experience to inspect the implementation.

I validated the product. Not the software architecture behind it.

CalDAV Without Building CalDAV

One of Priora’s more interesting features is its CalDAV integration.

I wanted to use functionality already available on my phone, such as reliable on-device notifications and offline editing, without also having to build my own native app. CalDAV is a standard, which means I can connect Priora to existing apps and switch clients relatively easily later on.

My instruction to the agent was roughly: add CalDAV support. For each project, I wanted at least a list with support for labels, titles, descriptions, and the todo/done state. I also wanted to preserve things like priorities and recurring tasks.

The agent built it.

I then connected Priora to Apple Reminders and tested whether it worked.

It worked.

And as a result, CalDAV is currently more or less a black box to me.

I don’t know which libraries it uses. I don’t know how synchronization state is tracked or exactly how the implementation handles conflicts. I haven’t inspected the internal mappings. I don’t know what happens if synchronization fails halfway through.

For my current use, I haven’t needed to know any of that.

That may be one of the strongest arguments in favor of vibe coding: today, you can build and use software without understanding how every part of it is technically implemented.

At the same time, that is exactly where I draw the line when it comes to professional software.

Would I Give This Application to a Hundred Customers Tomorrow?

No.

Not in its current form.

That answer has surprisingly little to do with whether Priora works well. I use it every day. By now, I have quite a lot of confidence in its functional behavior for my own use case and for a single user.

But suppose a hundred people started using Priora tomorrow and paid me to store their tasks in it.

Functional testing alone would be nowhere near enough.

I would want to know how data is stored and modified. I would want to know what happens when an operation fails halfway through. I would want to understand how relationships in the data model are structured and what changing them would mean for existing data. I would want to know whether filtering happens in the database or whether complete datasets are being loaded into memory somewhere. I would want to know what happens under load and which parts of the system are likely to fail first.

Most importantly, if something does go wrong, I don’t want an incident to be the first time I become acquainted with my own implementation.

With a todo app, that isn’t even a theoretical concern. People put tasks into a system precisely so they no longer have to remember them. If the application loses a task, there’s no guarantee the user will know what disappeared. The fact that the information is stored externally is exactly why that information no longer needs to live in someone’s head.

That changes the responsibility.

For my own installation, I accept a very different risk profile. Priora runs locally. I have backups I can restore. If I ever want to move away from the current implementation, I could even ask the agent to export all the data to Markdown so I can import it somewhere else. If that fails, it’s mainly my own problem. I don’t consider that an acceptable way to handle customer data.

For Professional Software, This Is Unacceptable

That’s why I would never apply the way I built Priora one-to-one to professional software for which I’m responsible.

Not because a coding agent wrote the code.

That distinction matters to me. I have little objection in principle to an agent generating ninety or even one hundred percent of the lines of code. Pressing the keys on the keyboard yourself is no guarantee of good software, just as generated code isn’t automatically bad software.

The problem with my Priora experiment is that I deliberately built up no technical understanding of the final implementation.

I can tell you what the application does. I can demonstrate that CalDAV synchronizes. I can delete a task and restore it through the Activities view. I use the application every day and, as a result, have accumulated a substantial amount of functional validation.

But if you ask me why the implementation is reliable, where the main technical risks are, or what happens when the system runs under different conditions, I currently can’t give you an answer.

For a personal experiment, I’m fine with that.

For professional software, I find that unacceptable.

If I take responsibility for a system, I need to understand enough of that system to evaluate technical decisions, recognize risks, make changes responsibly, and solve problems when they occur. Especially when other people depend on the availability and integrity of their data.

Priora didn’t teach me that vibe coding doesn’t work.

Quite the opposite.

The application works surprisingly well. I actually use it, and I got functionality that would probably have taken me considerably more time otherwise. That success made the distinction between vibe coding and professional development with agents much clearer to me.

The difference isn’t who typed the code. The difference is how much responsibility you can take for what was ultimately built.

If an agent can eventually handle virtually all of the implementation, how do you make sure, as a developer, that you still understand the software well enough to take professional responsibility for it?