Vibe coding in MENA: what AI-built software changes, and what it doesn't

Two years ago, the first meeting with a founder in Cairo, Riyadh or Dubai usually started with a slide deck. Now it often starts with a link. "I built this over the weekend with Lovable," or Cursor, or Bolt, or Replit. "Can you just make it production-ready?"

That shift is real, and mostly positive. Andrej Karpathy coined the term vibe coding in February 2025 to describe building software by describing what you want and accepting whatever the AI produces, without really reading the code. By November, Collins Dictionary had made it the Word of the Year. In this region, it has changed who builds the first version of a product, what buyers expect to pay, and what they think engineering is for.

What it has not changed is what it costs to own software once real customers, real money and real data are flowing through it. This article covers both sides: what AI genuinely improved for businesses in MENA, where vibe-coded software tends to break, and when paying for a consultation or a specialised engineer is the cheaper decision.

What has actually changed in the MENA market

The changes are not the same everywhere in the region, but the same pattern shows up in Egypt, the Gulf and North Africa.

Founders prototype before they hire. Non-technical founders can now produce a clickable, data-backed prototype without a developer. That moves the first engineering conversation later, and changes it from "build me this" to "fix, finish or rebuild this."

The low end of the freelance market is under price pressure. Simple landing pages, CRUD dashboards and brochure apps were the entry point for junior freelancers and small shops, especially in Egypt's export-oriented freelance market. AI tools have made that work faster to produce and harder to charge for. If you are buying, quotes for simple work have come down. If you are selling simple work, the floor has dropped.

Buyers anchor on the prototype. "It already works, so why is the quote 300,000 EGP?" is now a common reaction. The prototype makes the visible part look finished, which makes the invisible part (authorisation, payments, data protection, monitoring, backups) look like padding. It is not padding. It is most of the work. I covered what a realistic budget looks like in what software development actually costs in Egypt.

Regulation is moving the other way. At the same time as building got easier, the region's data protection regimes got real teeth. Saudi Arabia's Personal Data Protection Law is in active enforcement under SDAIA, with fines of up to SAR 5 million and reach that extends to companies outside the Kingdom that process the data of people living there. The UAE has a federal data protection law, and the free zones (DIFC, ADGM) have their own. Egypt's data protection law adds restrictions on cross-border transfers, with stricter treatment for financial data, which I covered in security requirements for Egyptian fintech and e-commerce. None of these laws care which tool wrote the code.

Enterprise and government buyers are asking harder questions. Gulf enterprises and government-linked clients increasingly ask for security questionnaires, penetration test reports, data residency commitments and documented architecture before they sign. A vibe-coded product can win the demo and lose the procurement process.

The real advantages

None of what follows is hype. These are things AI tools do well, and businesses in the region should be using them.

• Validation got cheap. A founder can test whether anyone wants the product before spending a six-figure budget finding out. That is the single biggest improvement, and it kills a lot of bad ideas early, which is a good thing.
• Internal tools are nearly free. Admin panels, reporting dashboards, data clean-up scripts and one-off automations that never face the public internet are a good fit. If it breaks, an employee is annoyed, not a customer.
• Better briefs. A founder who has built a rough prototype writes a much better specification. The engineer can see the intended flows instead of guessing from a paragraph. Scoping is faster and quotes are more accurate.
• Experienced engineers move faster on the boring parts. In the hands of someone who reads every line, AI tools speed up boilerplate, tests, migrations, documentation and the first draft of unfamiliar APIs. Small senior teams can now deliver what used to need a larger mixed team.
• Arabic and bilingual content is easier. First drafts of Arabic copy, RTL layout scaffolding and translation of interface strings are faster. They still need a native reviewer, but the starting point is better.

The real disadvantages

The problems with vibe-coded software are rarely visible in a demo. They show up after launch, usually during the first busy week, the first audit, or the first incident.

Security defaults are poor, and they fail silently

AI tools optimise for "it runs," not "it is safe." Veracode's 2025 study tested more than 100 models on 80 coding tasks and found security flaws in around 45% of the generated code, with models choosing the insecure option almost half the time when a secure one was available. Cross-site scripting and log injection were left unprotected in the large majority of relevant cases. That is a vendor benchmark, not a production failure rate, but it matches what I see when reviewing AI-built code.

The most common failure in practice is authorisation. A widely reported 2025 issue (CVE-2025-48757) found that around 170 apps built with one popular AI app builder exposed their database tables because row-level security was never enabled. Anyone with the public key in the page could read, and sometimes write, other users' data. The platform disputed responsibility, and in a narrow sense it was right: the business that launched the app owns the data, and owns the breach.

"Almost right" is expensive

In the Stack Overflow 2025 Developer Survey, 84% of developers said they use or plan to use AI tools, but the most common frustration, selected by 66%, was "AI solutions that are almost right, but not quite." Almost-right code is worse than obviously broken code: it passes the demo and fails on the edge case. In MENA products, the edge cases are where the money is:

• a payment gateway webhook that arrives twice, or after the customer has already closed the tab (see choosing a payment gateway in Egypt);
• cash-on-delivery orders that need a different state machine from card orders;
• Arabic names, mixed-direction text and Arabic-Indic digits breaking search, sorting or validation;
• phone number formats that differ across Egypt, Saudi Arabia and the UAE;
• VAT and e-invoicing rules (ZATCA in Saudi Arabia, the ETA e-invoice system in Egypt) that need exact, auditable outputs.

Feeling faster is not the same as being faster

METR ran a randomised trial in 2025 with experienced open-source developers working on codebases they knew well. With early-2025 AI tools allowed, they took about 19% longer to finish tasks, while believing they had been about 20% faster. It is one study with a small sample and older tools, and other settings show real gains. But the perception gap is the useful lesson: a team, or a founder, can feel productive while accumulating code nobody understands.

Nobody owns the code

The defining feature of vibe coding is that the person shipping the code does not fully understand it. That is fine on day one. It becomes a problem on day ninety, when something breaks at 2 a.m., the original prompt history is gone, and every fix generates three new files. Maintenance is where most software cost lives, and code without an owner is expensive to maintain.

Infrastructure and cost surprises

AI-generated apps often pick infrastructure by default rather than by decision: a hosted backend with usage-based pricing, no caching, no limits, unbounded queries. That is fine at ten users. At ten thousand, the bill becomes a surprise, often in dollars while revenue is in pounds. I wrote about this pattern in the AWS cost audit guide and in managed services vs. running it yourself.

Data residency is decided by accident

Where is the database? Where are the backups? Which country are the logs in? With a vibe-coded app, the answer is usually "wherever the tool's default region was," which is rarely in the region. For a consumer app that may not matter yet. For fintech, health, government or enterprise clients in Saudi Arabia, the UAE or Egypt, it can block a contract or create legal exposure.

Vibe coder vs. specialised engineer

The difference is not whether AI is used. Good engineers use AI tools every day. The difference is who is accountable for the result, and whether they understand it well enough to be.

What a consultation actually buys you

A consultation is not a sales call for a rebuild. Done properly, it is a short, fixed-scope review that tells you which parts of what you have are safe to keep, which need fixing, and which will hurt you. For a vibe-coded product, a useful review covers:

1. Architecture and data model. Will this structure survive ten times the users and the features you have already promised?
2. Security and access control. Can one user read or change another user's data? Are secrets in the front end? Is input validated on the server?
3. Payments and money flows. Do failed, duplicated and refunded payments leave the system in a correct state?
4. Data protection and residency. Where does personal data live, who can access it, and what do PDPL obligations in your markets require?
5. Reliability. Are there backups you have actually restored, monitoring that alerts a person, and a way to deploy without downtime?
6. Cost. What will infrastructure cost at your next growth milestone, and in which currency?
7. A plan. Keep, fix or rebuild, in priority order, with an honest estimate for each.

For most early-stage products, the cheapest path is not "rebuild everything properly" and not "keep vibe coding." It is: prototype with AI, then pay for one to two weeks of senior review before you take real money or real data, and fix what the review finds. That review usually costs less than one month of a full-time engineer, and much less than a breach notification, a failed audit or a lost enterprise deal.

When you can skip the engineer, and when you can't

How to tell the difference when you hire

AI has made it easy for anyone to produce a convincing portfolio. Credentials and screenshots tell you less than they used to. Questions tell you more. Ask anyone you are considering hiring:

• "How do you make sure one user can't see another user's data?"
• "What happens in your system if the payment gateway sends the same webhook twice?"
• "Where would you host our database, and why there?"
• "How do you know when production is down, and who gets woken up?"
• "Show me something you have maintained for more than a year, not just something you launched."
• "Which parts of your work do you use AI for, and how do you review what it writes?"

A specialised engineer answers with specifics, trade-offs and some "it depends, here is on what." A vibe coder answers with the name of a tool. The last question is the most useful one: a good engineer has a clear, confident answer about where AI helps them and where they do not trust it.