A friend built an employee leave tracker over a weekend.

He wasn’t a developer. He described the screens to an AI coding tool, copied a few error messages back into the chat, and kept clicking “accept” whenever new code appeared. By Sunday evening, the app looked surprisingly good. Employees could request leave. Managers could approve it. There was even a dashboard with coloured charts.

Monday’s demo went well.

Then somebody asked what happens when a manager is on leave too.

Nobody knew.

That, to me, is the whole vibe coding debate in one ordinary story. AI can help almost anyone turn an idea into something that looks like software. Sometimes it really is software. Sometimes it’s a confident collection of files waiting for the first awkward question.

The first 80 percent feels suspiciously easy

Starting a software project used to involve a long stretch where nothing looked impressive.

You installed tools, created folders, configured a database and spent half an evening discovering that one package required a different version of another package. After all that, perhaps a button appeared.

AI has changed this experience. You can describe an expense tracker, customer portal or browser extension and watch the basic shape appear quickly. Forms work. Pages connect. Sample data fills the dashboard. It feels slightly illegal the first time.

This is genuinely useful.

The problem is that visible progress and actual progress are not the same thing. A login screen can appear finished while storing passwords badly. A checkout flow can work with one test card and fail when a payment is delayed. A dashboard may display beautiful numbers pulled from completely wrong queries.

AI makes the easy-looking part very fast. It doesn’t automatically make the hidden part correct.

Borrowing skill is still valuable

Some developers dislike vibe coding because people without traditional programming experience can now build things.

I don’t share that concern.

A marketing manager should be able to create a small tool for cleaning campaign data. A founder should be able to test a booking idea without hiring a full team. Someone tired of copying information between Gmail and a spreadsheet should be able to automate the job.

Software development has spent years turning minor business problems into ticket queues. If AI lets the person with the problem build a rough solution, good.

The funny part is that many professional developers already work this way, just with better judgement. They ask AI to create boilerplate, rewrite a function, explain unfamiliar code or suggest tests. They don’t call it vibe coding because professionals prefer serious names for the same behaviour.

The difference isn’t who typed the code.

It’s who can tell when the code is lying.

The bug arrives after the applause

Vibe-coded apps often look strongest during a demo.

The data is clean. The internet connection works. The person presenting knows which buttons to avoid. Nobody enters a surname containing an apostrophe or uploads a twelve-megabyte photo from airport Wi-Fi.

Real users are less cooperative.

They refresh while a payment is processing. They open the app in an old browser. They click twice because nothing happened immediately. They paste an entire email into a field designed for a phone number.

Then there are less visible problems: permissions, backups, failed integrations, unexpected cloud bills and dependencies that quietly stop being maintained.

This doesn’t mean every AI-generated app is dangerous. It means “it runs” has always been a weak standard for software, and vibe coding makes reaching that weak standard extremely easy.

Reading code matters more now, not less

People keep asking whether learning to code is becoming pointless.

Typing every line manually may become less important. Understanding what the system is doing will not.

In fact, reading code is becoming more valuable because AI can produce so much of it. You may not write the authentication flow, but you need enough knowledge to notice that every user has administrator access. You may not create the database query, but somebody has to realise it downloads the entire customer table whenever the homepage opens.

A person working with AI-generated code needs to ask basic questions.

Where is the data stored? What happens when this service fails? Who can access this page? Which part sends information to an outside provider? How would I reverse this change?

You don’t need to understand every character before using the tool. That standard would make little sense; developers have always depended on libraries they didn’t fully understand.

But blind acceptance is not a workflow.

It’s a gamble with nicer buttons.

Some projects deserve to stay scrappy

Not every app needs architecture meetings, automated test suites and a security review.

I once made a tiny script to rename downloaded invoices. It was messy, specific to my folders and probably offensive to anyone who enjoys elegant Python. It saved me time for years.

That was enough.

Vibe coding works wonderfully for prototypes, personal tools, one-off automations and internal experiments with limited consequences. If a script fails and you manually rename six files, nobody needs an incident report.

The standards change when customers depend on it, money moves through it, or private information enters the system.

A weekend tool sometimes becomes popular inside a company. Then ten people use it, then fifty, and suddenly the person who built it is being asked about backups and audit logs. The prototype did nothing wrong. The mistake was pretending it never changed categories.

At some point, the vibe has to become engineering.

Beginners face a strange new trap

AI gives beginners a faster and more enjoyable way to start. That matters. Blank screens have discouraged plenty of capable people.

But instant results can hide missing knowledge.

A beginner asks for a feature, receives two hundred lines and feels productive. Then one line fails. The AI suggests another change, which creates a different error. After six rounds, nobody—including the conversation—seems to remember how the original system worked.

This is where curiosity matters more than speed.

Ask the tool to explain the change. Run the code after small edits. Keep versions that worked. Learn Git before the project becomes precious. Test one feature at a time instead of requesting the complete app in a single heroic prompt.

You don’t need to pause building until you finish a computer science degree. Just make sure the project is leaving some understanding behind.

Keep the speed. Lose the fantasy

Vibe coding is not hot air. Too many useful things are already being built this way for that argument to hold.

It also isn’t the end of software engineering.

The lasting change is simpler: producing code is becoming cheaper. Deciding what code should do, checking whether it actually does it, and keeping it useful after six months remain stubbornly human jobs.

That leave tracker eventually worked, by the way. My friend asked a developer to review it, rebuilt the approval rules and removed one feature that was causing most of the trouble.

The charts survived.

They were never the difficult part.