In the first part I described everything hiding behind a simple free app. In the second, what the weekend looked like when that app broke.
In the first part I described everything hiding behind a simple free app. In the second, what the weekend looked like when that app broke. This part is about why a website, a web app and software blur into one thing in everyday speech, even though they carry completely different responsibility and different risk.
Three different things that look the same
With a website, you always stand between the user and the error. With a desktop app, you don't. When the app crashes, it crashes on the person's computer. If you get the permissions wrong, it reaches into their data. And when you need to fix it, you have to hope they download the new version.
What a website doesn't deal with at all
On top of the difference in risk come things you never meet with a website: signing the app, operating system permissions, behaviour on sleep and wake, different system versions, different computers, installation, uninstallation. AI can't solve any of that for you, because none of it is about writing code.
An accent in a file name broke the app's signature. A hardened macOS runtime silently switched off access to the calendar, so the app looked fine while not working. Dragging it to the bin left behind settings, launch at login and an entry in the system Keychain. None of these things added a feature for the user, and without any one of them the app couldn't be given to anyone.
Why we show this at all
Company owners and people who decide about budgets mostly don't have a technical background. That's perfectly fine, it isn't their field. But it has one practical consequence: they don't distinguish between a web page, a web app and software. It all looks like a screen on which something lights up. And when those three things merge into one, you can't estimate how much work stands behind them or who can deliver it.
Ptáček is a small app. That's exactly why it can show what small means. One day of functionality and twice as much time on things that aren't visible.
Where is the line between vibe coding and production
I have nothing against vibe coding, I teach it myself and use it daily. After five thousand hours with AI I have quite a clear picture of where the line is.
Where vibe coding works brilliantly: an internal tool for you and three colleagues, a custom calculator, a prototype you show someone on screen, a script that saves you two hours on Friday. Things where you are both the author and the only user, and where a mistake means you try again.
Where it stops being enough: as soon as someone else touches it. A customer, a colleague from another company, a website visitor, a person who downloads it. At that moment you no longer deal with whether it works, but with what happens when it doesn't. And that is a different discipline from writing code.
A few tips on vibe coding
These aren't generic tips from the internet. They are seven things we worked out on the Ptáček app, some of them painfully, on the weekend when it broke.
Test a clean install. Delete the app and all its settings and install it again as if you were seeing it for the first time. For us it revealed three things at once. By reading the code we wouldn't have found a single one of them.
Have the output challenged by a second model that doesn't know about the first. Not the same model a second time, a different one, with a different brief. When the app broke on the weekend, we ran two independent audits and neither knew about the other. They agreed on the cause, and one also corrected the other on a detail.
Ask what happens when this fails. A model only answers the questions it gets. An inherited update channel pointing at another author's repository was not mentioned by the AI itself, because nobody asked it. It can find it, you just have to know what to ask about.
Keep the last working state and be able to go back to it. In three days of fixing we made three steps back. Without that, it wouldn't have been three mistakes along the way, but one that couldn't be fixed.
Write tests mainly for whatever deletes or changes something. In Ptáček there is a single function that deletes anything, the uninstaller, and it has its own tests to make sure it deletes nothing else. The rest of the app only reads and displays.
Don't put secrets in the model's hands. A calendar address is effectively a password, whoever knows it can see when you have meetings. It doesn't belong in a config file, let alone a log.
Tell an error that crashes from an error that stays silent. A crash you see right away. An empty response that the app interprets as no meetings, while the settings glow green that all is well, is worse, because you don't know about it until you miss a meeting.
That's why we teach it this way
At vibe coding workshops we don't tell people they are now going to build a product. We tell them they will build tools for themselves and for the team, and that is enormous value.
And at the same time we show them exactly the line this article is about. So they know when they can build an app on their own and when they need someone who asks the uncomfortable questions. Because the most expensive variant is the one where someone releases an app with client data into the world and finds out only when it's too late.
You can check who you are handing the job to with anyone. Including us.
And a question for you: where is that line at your place? Where do you let vibe coding run on its own, and where do you already call someone who has years of experience in it?
The article was first published on LinkedIn. Original article on LinkedIn
