Built Your App With AI? SDAIA's Vibe Coding Guide Treats Every Line as a Draft Until a Human Reviews It

If your app, website or internal system was built with AI tools, or your developer uses them, the «Vibe Coding» guide issued by the Saudi Data and AI Authority (SDAIA) in April 2026 sets one clear rule: everything AI generates is an unapproved draft until a human reviews it, verifies it and formally approves it. The guide runs to 57 pages, is aimed at technical teams in both government and the private sector, names 4 main risks and 6 core limitations, and sets out 5 points where a human must step in before code reaches your customers. In this article we turn it into practical questions to put to your team or vendor this week.

What is vibe coding, by SDAIA's definition?

The guide defines vibe coding (in Arabic, «al-barmaja al-tawlidiya», generative programming) as an approach in which users describe what they want in plain language and AI tools write the code. It goes beyond writing, to what it calls agentic AI: tools that build code, run tests and manage deployment on their own, while a human steers the key decisions.

The guide splits use into 3 tracks: design and user experience (ideas and prototypes), coding (writing and improving code), and testing (test plans, test data and fault analysis). It cites Microsoft as saying these tools generate about 30% of the code it produces internally, and Google as saying about 25% of its new code is AI-generated and then reviewed by humans before merging. The message is clear: the largest companies use these tools every day, but inside a review system.

The key rule: AI output is a draft

The first definition in the guide is the «AI Draft»: any output the system generates remains an unapproved first draft until it goes through human review, verification and approval. It describes «Human-in-the-loop» as a mandatory governance principle within its methodology. It adds that human intervention becomes mandatory when AI tools are given execution permissions that could have a significant operational, legal or commercial impact.

In business-owner terms: if an AI tool can push an update to your app or change your customer database without anyone signing off, that is exactly what the guide warns against. To be clear, the guide is advisory, not a regulation with penalties, but it is the clearest official Saudi reference so far on what counts as «responsible use» of these tools, and it complements the National AI Risk Management Framework.

4 risks the guide names, and how they show up in your project

• Hallucination: code that looks sound but calls APIs that do not exist, or recommends fictional or unsupported packages and libraries. The result is integration errors with your other systems, and possibly a security hole if someone installs a suggested package by name without checking it.
• Overconfidence: accepting generated code without a security or functional review, or moving it straight into the live environment your customers use.
• Superficial coverage: a generic security analysis that misses vulnerabilities, and incomplete tests, giving you a false sense that all is well.
• Non-deterministic output: the same prompt produces different code each time, which makes results hard to reproduce and audit.

6 things AI does not guarantee

The guide lists 6 core limitations: AI understands your business intent only as far as you spelled it out; it cannot weigh the risks or priorities specific to your organization; it does not replace architectural thinking and design decisions; it does not guarantee that code is correct or fit for real use; it does not always produce identical results; and its output is neither formal test evidence nor a substitute for real testing. The guide says plainly that responsibility for verification, testing and approval is «entirely human».

5 human checkpoints before code reaches your customers

1. Review every code change before it is merged into the main branch.
2. Assess every release for readiness before it is deployed.
3. Oversee the decision to deploy or roll back.
4. Explain any unexpected behavior in production.
5. Approve development plans and the long-term technical roadmap.

Questions to ask your developer or vendor this week

• Who reviews AI-written code before it is merged, and is there a recorded review for every change?
• Are tests actually run against the system, or did the tool simply «say» the code works?
• What permissions do the AI tools have? Can they deploy, or reach the real database? (See what happened with coding agents that ran an attacker's command.)
• Is the test data synthetic? The guide calls for test data that follows privacy rules and prevents the use of any real or sensitive data, which matters for your customers' personal data.
• Who signs off a release before it goes live, and who owns the rollback decision if something breaks?

If you cannot get a clear answer to three of these five questions, the problem is not the AI tool but the way the work is done. If you are choosing a new development partner, add these questions to your criteria for choosing a software company.

The Origami view

We use AI tools in design, coding and testing because they save our clients real time. But we treat what they write exactly as SDAIA's guide describes it: as a draft. Every change goes through a developer's review, tests are actually run, real customer data never enters the test environment, and a human makes the deployment call. Speed without review gets paid for later in outages and security holes. If you built a prototype with AI and want to turn it into a system your customers can rely on, talk to us.