Vibe coding with limits

One Saturday I got annoyed that I could not find a simple app for one small thing. I opened an editor and an hour later I had a working Mac app built with AI. I was very pleased with myself and already thinking about what else I could finish before lunch.

Then three more hours went by. The app stopped working after my first change. The model kept confidently proposing a fix that fixed nothing, I said no and asked again, and again. The fourth time I finally read the error message myself, and it was solved in two minutes. That is the real experience: one hour of magic and three hours of stubbornness. I am not a professional engineer, but this is exactly how I build my own tools.

What it is, without the polish

Vibe coding in plain words: you describe what you want, AI writes the code, you run it, see what is broken and keep talking. The loop runs until it works.

Three places where it is genuinely good. Prototypes: in one evening you find out whether an idea is worth a real developer's time, and most ideas are not, so learning that cheaply is worth a lot. Internal tools: a small app for one person or one team that nobody would ever buy. And learning: for a junior it is the best way to understand logic before syntax. The machine writes the syntax now. The logic still has to be in your head.

Three lines I do not cross

1. No sensitive data. Personal data, health information, customer lists, financial records. None of it goes into a tool built this way. Ever.
2. No keys or passwords in code I have not read myself. The model will happily write a key straight into a file and then suggest pushing it to a public repository. This is the one place where a mistake costs real money the same day.
3. No regulated or core business logic. Payroll, customer invoicing, anything an auditor checks. That needs a person who answers for it by name and can explain every line.

Everything inside that chalk circle is a fair playground. Everything outside it stops being a vibe coding question and becomes a question about who carries the responsibility.

The part nobody says on stage

The first eighty percent arrives in twenty minutes and feels like magic. The last twenty percent is repeating yourself, reading the output, and refusing to accept the model's answer. That is where the weekend goes, and that is what never makes it into a demo, because it is boring.

The people it does not work for almost always quit at the point where they needed to ask a third time.

And you still have to read. Not every line, but enough to see where the data is kept and what the app talks to over the network. If you do not know that, you are not controlling the limits, because the limits live exactly there.

Where I use this framework

All my Mac tools are built this way. They run on my machine, the data never leaves it, and nobody else uses them. Before asking for budget for a real system, I spend an evening making an ugly prototype, because the conversation that follows is nothing like a conversation about a slide. And when a young person says they want to learn to code, I tell them to start with something they actually need. Not a course. A problem.

p.s. that first Saturday app is still running. I use it maybe once a week, and I do not regret those four hours at all.