Vibe Coding vs Responsible AI-Assisted Building

It is Sunday evening and you have built an expense tracker. You described what you wanted to an AI assistant, accepted what it produced, pasted error messages back until things worked and now you have a running app with a login page. It took four hours. You feel like a wizard.

On Monday a friend says, "Nice, can I use it for my small business?" Now there are other people's financial records involved, a login system you did not write and cannot explain, and a database whose location you could not describe if asked. The wizard feeling gets complicated.

This article is about the choices that sit between those two moments.

• What vibe coding is and what it is not.
• When it is a reasonable choice and when it is not.
• A project workflow that uses AI heavily while keeping you in control.
• What understanding debt is and how to reduce it.
• How to describe AI-assisted projects honestly.

The term was popularised by Andrej Karpathy in early 2025 to describe a style of building where you "fully give in to the vibes" and forget that the code even exists: always accepting the assistant's changes, not reading the diffs, and pasting errors back until things work. He described it as not too bad for throwaway weekend projects.

Simon Willison drew a useful line. He defines vibe coding narrowly as building software with an LLM without reviewing the code it writes, and contrasts it with responsible use: if an LLM wrote the code, and you then reviewed it, tested it thoroughly and made sure you could explain how it works, that is software development with an AI assistant. His own rule is that he will not commit code to his repository if he could not explain exactly what it does to somebody else.

That distinction makes the debate more useful. The question is not "AI or no AI", but "did a human read, test and understand it?"

Vibe coding is not a sin. It is a tool with a risk profile.

Ask these questions about your project. The more "yes" answers, the less vibe coding is appropriate.

• Will other people use it, especially people who did not choose the risk?
• Does it handle personal, financial, health or other sensitive data?
• Does money move through it, or does it hold API keys that cost money when abused?
• Is it exposed to the internet?
• Must it keep working for months, with updates?
• Will other developers have to work on it?
• Would a failure harm someone, not just inconvenience you?
• Do you plan to put your name on it as evidence of skill?

If you said yes to the first three, or to the exposure question, treat it as a real project from day one.

This workflow is meant to work with heavy AI use. It adds structure around the assistant, and it should not slow the typing.

Write half a page: who is it for, what it must do (three to five user stories), what it will not do, what data it touches and what "done" means. This protects you from the assistant's habit of adding features, and it gives you something to check the result against.

Decide the main parts: front end, back end, database, hosting, how users sign in. Ask the assistant for options and trade-offs (see article 18), then choose and write it down in a paragraph. If you cannot describe the structure in plain words, you do not understand the project yet.

Many tools let you add a project-level instruction file, or you can paste a brief at the start of each session. Whatever the mechanism, include:

Project: expense tracker for small shops. Stack: Python 3.11, Flask, SQLite for now.Rules: no new dependencies without asking; use parameterised queries only; keepfunctions under 40 lines; write a test for every new function; do not change filesI did not mention; list assumptions before writing code.Structure: app/ (routes), core/ (logic), tests/.Not in scope: payments, multi-user teams, mobile app.

Keep it short, and update it as decisions are made. It reduces drift and repeated explanations.

Commit after each working step. If an assistant makes a mess, you can go back. Work on a branch for risky changes. This is the single most effective safety net, and it costs almost nothing.

Do not ask for the whole application. Build one slice that works end to end: "a user can add an expense and see it in a list". Review it, test it and commit. Then the next slice. Small diffs can be read. Giant ones cannot.

Apply the habits from earlier in this module:

• Read the diff. Ask about anything you do not understand.
• Write requirement-first tests, including hostile inputs.
• Break it on purpose to see that the tests can fail.
• Explain-back the new code in your own words.

Use the five-question check and the common weaknesses from article 21: input handling, authorisation, secrets, configuration, dependencies. Turn off debug modes, remove test accounts, and make sure keys live in the environment, not in the code.

A README with setup steps you have actually followed, an architecture paragraph and a list of known limitations. Future you, and any collaborator, will need it.

Start with a few trusted users. Add basic logging of errors (without personal data), and set spending limits on any paid service behind the app. Decide how you will find out if it breaks.

Dependencies need updating. Keys expire. Services change. If you cannot maintain it, say so, or keep it small enough that you can.

Understanding debt is the gap between what your code does and what anyone can explain about it. With heavy AI use it accumulates quietly: each accepted change adds a little code that nobody, including you, has fully read. Like financial debt, it has an interest rate: every future change takes longer and carries more risk, because you do not know what depends on what.

Signs you are in debt:

• You are afraid to change a file.
• A bug takes ages because you do not know where to look.
• You ask the assistant to explain your own project to you.
• Removing something breaks unrelated things.

How to pay it down:

• Explain-back sessions: once a week, pick a module and explain it aloud, without the assistant. Note what you cannot explain, and then read that part.
• Ask for a walk-through, then verify it by running the code.
• Draw the architecture from memory, then compare with the real thing.
• Delete what you do not need. AI tends to produce more code than the task requires.
• Simplify. Prefer fewer files, fewer dependencies and plain structures.
• Write tests for the parts you do not understand, as a way to learn how they behave.

If you are building to learn, the point is the learning, not the working app. A progression that keeps you in control:

1. Follow a tutorial and type the code yourself.
2. Modify it without help, then with hints from the assistant.
3. Build a small project from scratch using the assistant only for explanations and hints.
4. Build a larger one with AI drafting code that you review and understand.
5. Review other people's AI-generated code, which builds the critical eye.

If you are building to show employers, be honest about the split. Say what you designed, what the assistant drafted and what you changed. Be ready to walk through any file in an interview. A project you cannot explain is a liability, not an asset, and it undermines the real work you did. Job Descriptions, Skill Gaps and Portfolio Projects with AI takes this further.

• I can describe how it works in plain words.
• Every file is in version control, and there is a tested way to run it from a fresh clone.
• The main behaviour has tests, including bad input.
• No secrets are in the code or the history. Keys are in the environment.
• Debug mode and test accounts are off.
• Authorisation is checked wherever data is read or changed.
• Dependencies have been checked and pinned.
• I know what personal data it holds, and I have a reason to hold it.
• Spending limits are set on any paid service.
• I know how I will find out when it breaks.
• I have told users what it is and is not.

If you cannot tick most of these, it may still be a fine weekend project, but keep it private.

• Moving from toy to product without changing how you work.
• Giving the assistant the whole project in one prompt.
• Leaving keys in the code of an app that is public.
• Accepting features nobody asked for.
• Having no way to undo changes.
• Claiming a project as entirely your own work when you cannot explain it.
• Ignoring maintenance.

Project: study-planner web app for college students. Stack: Python 3.11, Flask,SQLite, plain HTML templates.Rules: ask before adding any dependency; use parameterised queries only; no secretsin code; write a test for every new function; change only the files I name; listyour assumptions before writing code.Structure: app/ (routes), core/ (logic), tests/.Out of scope: user accounts with passwords (single-user for now), notifications,mobile app, payments.

• Next: Improve Your Resume and Profile with AI, Honestly begins Module 6, on career growth.
• For deciding what to build for your portfolio, see Job Descriptions, Skill Gaps and Portfolio Projects with AI.
• For the bigger picture of learning to code now, see How to Learn Programming When AI Can Already Write Code.