4 min read
TL;DR
- Sort every request by risk before anyone builds it, based on the data it touches and what a failure would cost.
- Let business teams build and ship low-risk tools on their own, and require engineering review before any medium-risk tool goes live.
- Keep payments and anything that writes to core systems with engineering from day one, even when a business team could build a version faster.
- Review any tool again when it connects to live data or a second team starts using it.
AI coding assistants have changed who can build software. A finance analyst can describe a reconciliation tool in plain language and have a working prototype before lunch. Product managers can test ideas without waiting for a sprint slot.
The speed is valuable. The challenge is that a prototype built in an afternoon can end up handling customer data, feeding a monthly report, or running a process the business depends on, without anyone deciding that it should.
Why is “internal tool” a poor measure of vibe coding risk?
Many organisations use a single rule: internal tools are fine, customer-facing tools need engineering. But an internal tool that reads payroll data is riskier than a public page that lists office locations.
Risk comes from what an app can reach and who is affected if it fails, not from who uses it.
What two questions should you ask before approving a vibe coding request?
Before a vibe-coded app moves beyond a personal sandbox, ask:
- What data does it touch? Public, internal, confidential, or regulated (personal, financial or health data).
- What happens if it breaks or is wrong? A minor inconvenience, a wrong internal decision, or harm to customers, revenue or compliance.
How does a low, medium and high-risk model sort vibe coding use cases?
| Tier | Typical profile | Who owns it | Engineering involvement |
|---|---|---|---|
| Low risk | Non-sensitive data, small audience, easy to undo | Business team | Approved tools and light guidance |
| Medium risk | Internal data, shared across teams, feeds decisions | Business team with an engineering partner | Code review, access controls, monitoring |
| High risk | Regulated data, customer-facing, writes to core systems | Engineering | Full delivery process from the start |
A tier can change over time. A low-risk prototype becomes medium risk the moment another team depends on it.
What can each department build with vibe coding?
| Department | Good to build with vibe coding | Bring in engineering |
|---|---|---|
| Finance | Variance summaries, report formatting, budget calculators | Anything that posts to the ledger or touches payments |
| HR | Onboarding checklists, policy Q&A on public documents | Tools that read employee records or payroll |
| Sales & marketing | Campaign briefs, content drafts, pipeline views from exports | CRM write-backs and customer-facing forms |
| Operations | Shift planners, internal status boards | Integrations with ERP, inventory or logistics systems |
What should a vibe-coded app pass before it goes to production?
- No hard-coded credentials. Secrets live in a secrets manager or environment variables.
- Input validation against common risks such as those in the OWASP Top 10.
- Approved data sources only, with access limited to the people who need it.
- Privacy compliance with GDPR and the India DPDP Act 2023 where they apply.
- Basic automated tests, error handling and logging.
- A named owner, documentation and a support route.
- Licence checks on every dependency before anything ships to a client.
- A rollback plan and backups for any data the app writes.
Which events should trigger a review of a vibe-coded app?
- A new data source is connected, especially personal or financial data.
- The audience grows beyond the original team, or includes customers.
- The app starts writing to another system rather than only reading.
- The original builder changes role or leaves.
- The output is used in a regulated report or a customer commitment.
What should you do with requests your engineering team cannot take on?
Most organisations end up with a queue of medium-risk requests that engineering cannot pick up quickly. There are three common responses: say no, let business teams ship without review, or bring in a partner who hardens the tools on a parallel track.
Only the last option keeps the speed and puts engineering ownership on the result.
How can Mako help you build vibe coding use cases safely?
Mako helps organisations get the speed of vibe coding without the hidden risk. Our teams set up approved tools and guardrails, review apps as they move up the risk tiers, and take on medium and high-risk builds through Forward Deployed Engineers or a dedicated AI Pod.
References
- OWASP Foundation, OWASP Top 10: https://owasp.org/www-project-top-ten/ (opens in a new tab)
- Ministry of Electronics and IT, Government of India, Digital Personal Data Protection Act 2023: https://www.meity.gov.in/ (opens in a new tab)
- European Union, General Data Protection Regulation: https://gdpr-info.eu/ (opens in a new tab)
Mako Editorial Team
AI Engineering & Delivery
Insights from Mako’s engineers, architects and delivery leads on building AI and software that works in production.
