Published / updated29 Aug 2026

Responsible Vibe Coding

Before you start

You need: the review checklist (Article 05).

Time: about 40 minutes.

Learning objective

Decide when fast AI-driven building is appropriate, and keep ownership of anything that reaches production.

Topics

• What vibe coding means
• Where it is fine
• Where it is not
• The ownership test
• Prototype to production
• Licensing and attribution
• Privacy and company policy
• Professional standards

What vibe coding means

Describing what you want and accepting what comes back, without reading it closely — building by feel, iterating on behaviour rather than code.

It is genuinely fast, and for some work it is the right approach. Dismissing it entirely is as wrong as using it everywhere.

The distinction is not the tool. It is who takes responsibility for the result.

Where it is fine

Context	Why
A throwaway prototype	Discarded before anyone depends on it
A personal script	Only you are affected
Exploring an unfamiliar library	You are learning the shape, not shipping
A hackathon demo	Nobody's data, short-lived
A one-off data cleanup	On a copy, verified by the result
A UI mock for feedback	Thrown away once the design is agreed
Generating test data	It is fake by definition

The common factor: nobody's real data is at risk and nothing outlives the session.

Prototyping this way is a legitimate skill. Building three variations of a screen in an hour to see which works is a better use of an hour than hand-crafting one.

Where it is not

Context	Why
Anything with real user data	A breach is not recoverable
Authentication and authorisation	The whole security model rests on it
Payments and fees	Money errors are legal and financial
Database migrations	Data loss is permanent
Anything a team maintains	They will have to understand it
Regulated data — student records, health	Legal obligations attach
Code you cannot explain	You cannot support it

In the School Management System, that means: never for fee handling, never for the login path, never for anything touching student or parent records.

Those systems hold minors' personal data. A leak of Student.ParentPhone or DateOfBirth is a real-world harm to real families, and the standard for that code is understanding every line — not "it worked when I tried it".

The ownership test

Before committing anything, four questions:

1. Can I explain every line? Not roughly — line by line, including why each condition is there.

2. Can I debug it at 2am? If it fails in production and you are on call, can you fix it without the AI?

3. Would I defend it in review? If a senior developer asks "why this approach?", is there an answer?

4. Do I know what it does when things go wrong? Empty input, null, a network failure, concurrent calls.

Any "no" means the change is not ready to commit.

"The AI wrote it" is not an answer in a code review, an incident, or a job interview. Committing code makes it yours, whatever produced it.

Prototype to production

The dangerous path is a prototype that quietly becomes production because it worked.

Day 1:   Vibe-coded prototype. Works. Great.
Day 3:   Demo goes well.
Day 5:   "Can we use this for the pilot school?"
Day 10:  In production, holding real student records.

Nobody decided to ship unreviewed code. It happened by not deciding.

The rule: a prototype must be rewritten or fully reviewed before it holds real data. Not skimmed — reviewed against the checklists, line by line.

Mark prototypes so the decision has to be made explicitly:

// PROTOTYPE — not reviewed, not tested, not for production.
// Rewrite before this handles real data. See #157.

README:
## Status
PROTOTYPE. Written quickly to validate the approach.
Not reviewed. No tests. Do not deploy.

Then run the checklist before it ships:

• Every query parameterised
• SchoolId from the claim, in every WHERE
• Soft-delete filters present
• Money as decimal
• Absent handled before pass
• Authorisation on every endpoint
• No hardcoded secrets
• No entity returned directly
• Tests for the edge cases
• Every line understood

Licensing and attribution

Generated code can resemble training data, and that has consequences worth understanding even though the law is still settling.

Practical positions:

Check your company's policy first. Many have one; many developers have not read it. It usually specifies approved tools and prohibited contexts.

Be careful with substantial, distinctive blocks. A standard repository method is unremarkable. A long, unusual algorithm that appears verbatim is worth searching for.

Do not paste proprietary code into a tool your company has not approved. This is the rule most often broken by accident, and it is the one with contractual consequences.

Open-source contributions may have their own rules. Some projects require a declaration; check CONTRIBUTING.md.

Follow the team's convention on disclosure. Some require a trailer in the commit message, some do not care. Both are reasonable; what matters is doing what the team agreed.

Privacy and company policy

Assume anything you paste may be retained, unless you have specific assurance otherwise from a tool your organisation configured.

Never paste:

• Connection strings, keys, tokens, passwords
• Real student, parent or staff records
• Names, phone numbers, addresses, dates of birth
• Anything under NDA
• Proprietary algorithms, without approval

Anonymise. The bug reproduces just as well.

// Wrong
new Student { Name = "Aarav Menon", ParentPhone = "+91-9876543210",
              DateOfBirth = new DateTime(2011, 4, 17) }

// Fine
new Student { Name = "Ravi Kumar", ParentPhone = "+91-9999999999",
              DateOfBirth = new DateTime(2011, 1, 1) }

Student records are a regulated category in most jurisdictions. India's DPDP Act treats children's data with additional obligations; other countries have their own. The specifics vary; the obligation to not paste it into an arbitrary web service does not.

Find out your organisation's policy before you need it. "I didn't know" has never been a successful defence.

Professional standards

Everything below is true whether AI was involved or not:

Standard	Meaning
You own what you commit	The tool is not accountable; you are
Understand it before shipping	Every line, not the general shape
Test it	Edge cases, not just the happy path
Review it	Against security and correctness, not style
Document decisions	Why, so the next person knows
Say when you are unsure	Flagging uncertainty is professional; hiding it is not

AI changes how fast you produce code. It does not change what you are responsible for.

The developers who do well with these tools are the ones who were already careful — because the tools amplify whatever practice you already have. Careful practice plus AI is fast and safe. Careless practice plus AI is fast and dangerous, and it takes longer to notice.

Being honest about what you do not understand is a professional strength. "I generated this and I am not certain about the transaction handling — can you look at that part?" is a good review request. Silently shipping it is not.

Errors you will hit

The mistake	Consequence
Vibe coding authentication or payments	A breach or a financial error you cannot explain
Letting a prototype become production	Unreviewed code holding real student records
Committing code you cannot explain	No defence in review, an incident, or an interview
Pasting real student data	Regulated personal data in a third-party service
Using an unapproved tool on company code	A contractual problem, not just a technical one

"The AI wrote it" is not an answer in a code review, an incident, or an interview.

Common mistakes

• Vibe coding authentication or payments
• Letting a prototype become production by not deciding
• Not marking prototypes as prototypes
• Committing code you cannot explain
• "The AI wrote it" as an explanation
• Pasting real student data
• Not knowing the company policy
• Using an unapproved tool on proprietary code
• Assuming AI-involved code is exempt from review
• Hiding uncertainty rather than flagging it

Practice

The course exercise is decide where AI belongs.

1. Vibe-code a throwaway prototype in 30 minutes. Note how far you get.
2. Apply the four ownership questions to it. Record every "no".
3. Take the prototype and run the production checklist. Record how long a full review takes compared with the build.
4. Add a PROTOTYPE marker to a file and a status section to its README.
5. Take a piece of generated code and try to explain every line to someone else. Mark what you could not explain.
6. Sort ten tasks from your own work into "fine to vibe code" and "not".
7. Vibe-code a login endpoint, then review it against the security checklist. Count the findings.
8. Take a real bug report with personal data and rewrite it anonymised.
9. Find your organisation's or college's AI policy and read it. If there is none, write what you think it should say.
10. Check CONTRIBUTING.md on three open-source projects for an AI policy.
11. Write a commit message for AI-assisted work that would satisfy a reviewer.
12. Ask a senior developer how their team handles AI-generated code, and what they have seen go wrong.

Exercise 7 is the demonstration. Login code is exactly where vibe coding is inappropriate, and the finding count shows why.

You can now

• Decide where fast AI building is appropriate
• Apply the four ownership questions before committing
• Mark a prototype so shipping it is a decision
• Keep regulated data out of prompts
• Know your organisation's policy

Review questions

1. What do all the "fine to vibe code" contexts have in common?
2. What are the four ownership questions, and what does a single "no" mean?
3. How does a prototype become production without anyone deciding?
4. What must never be pasted into an AI tool, and what do you do instead?

Next: AI in the Git workflow