5,000 People Joined UAE Vibe Codes in Its First Hour: the 3 Screening Questions I Added That Afternoon

I read the UAE Vibe Codes announcement on Thursday with a candidate’s submission still open in another tab. A clean little booking app, deployed, working, sensible folder structure. An hour earlier I had been mildly impressed by it. After reading what the Artificial Intelligence Office had just put into the hands of the entire country, I was not impressed by it any more, and that reaction is worth examining, because the submission had not changed. Only what it proved had changed.

What Launched on 29 October

The Artificial Intelligence Office in the UAE launched UAE Vibe Codes, developed in collaboration with Microsoft, as this year’s edition of UAE Codes Day. The official announcement carried by WAM describes a nationwide experience, running under a vibe coding theme, that lets people turn ideas into websites and applications using artificial intelligence without prior programming experience, through a dedicated platform. Economy Middle East reports 5,000 participants within the first hour of launch.

Two details fill in the picture. UAE Codes Day is not new: an October 2021 directive designated 29 October annually for the initiative, so this is an established national programme that has picked a new theme rather than a one-off campaign. And the promotion is deliberately mass market, with the announcement describing collaboration with Emaar and cinemas to carry the experience on their digital screens and platforms. This was built to reach people who do not read technology newsletters.

One honesty note before I build anything on that number. The 5,000 figure comes from the official launch announcement, which means it is self-reported and I could find no independent verification of it. I am going to treat it as directionally true and strategically irrelevant, for reasons that take a paragraph to explain.

This Is Not a Talent Supply Story

The tempting reading, and the one I expect to see in a dozen recruitment posts this week, is that the UAE just widened its developer funnel. It did not. Nobody acquires the ability to own a production system in an afternoon, and the programme does not claim they do. What it claims, accurately, is that people can now turn an idea into something that runs.

For an employer, the consequence is not a bigger pool. It is a broken signal. Screening developers in Dubai has leaned for years on an artefact: a portfolio, a side project, a take-home submission. That artefact worked as a proxy because producing it used to require the thing we actually wanted to measure. The proxy and the capability travelled together. They do not travel together any more, and the gap between them is now being widened on purpose by national policy.

So the pool has not changed. The measuring instrument has stopped working. Those feel similar from a distance and they call for opposite responses: one is a sourcing problem, the other is an assessment problem, and only the second one is actually in front of us.

The Three Questions I Added

Each one is built on the same principle: ask about something that does not exist in the submission. Generated code is a record of what was produced. It is not a record of what was considered and discarded, what was tried and failed, or what was never tested at all. Those three absences are where the remaining signal lives.

1. “Show me a decision here, and tell me what you rejected”

Point at a specific choice in their submission. A data model, an error handling approach, where state lives, why that library. Then ask what the alternative was and why they did not take it.

A candidate who directed the work has an answer with a shape to it: they considered two options, one had a cost they did not want to pay, they took the other. The answer does not need to be sophisticated to be real. A candidate who accepted output without engaging will describe what the code does, fluently, and then stall when asked about the road not taken, because the road not taken was never visible to them. The tell is not ignorance. It is the absence of a discarded option.

2. “What breaks this under conditions you did not build for?”

Name a condition that is plainly outside the submission’s design: the third-party call returns a 500 for an hour, two users submit the same form in the same second, the payload arrives ten times larger than expected, the token expires mid-session.

This question is the closest cheap proxy I have found for production instinct. Assistants produce code that handles the path you described and rarely the paths you did not think to describe, so the gaps are usually real and usually unknown to a candidate who did not reason about them. What I am listening for is whether they can locate the weakness in their own work without defensiveness. Engineers who have carried a pager find this question comfortable. People who have only ever shipped demos find it accusatory, and that difference in reaction is itself informative.

3. “Tell me about a bug where your first three attempts were wrong”

The most valuable of the three, and the hardest to fake, because it asks for a narrative with a specific emotional texture: the frustration of a wrong hypothesis, the moment the real cause surfaced, the thing they believed that turned out false.

Debugging is where engineering judgement is actually built, and it is the activity least represented in a finished artefact. A real story has a shape nobody invents convincingly: a plausible first theory, why it was wrong, a second theory, the accident or measurement that broke the deadlock. A candidate who has never pushed through that will give you a tidy anecdote with no wrong turns in it, which is the one answer that should always worry you, because debugging is never tidy.

What This Costs You in Practice

The honest downside is time. These three questions do not work as written screening prompts, because written answers can be generated as easily as the code was. They need a live conversation with a technical interviewer who can push on a vague answer, which means roughly forty minutes of senior engineering time per shortlisted candidate.

That is a real cost and it is smaller than the alternative. A mis-hire on a Dubai engineering team runs into months of salary, the delivery slippage that follows, the re-run of the whole requisition, and the quiet damage to the team that absorbed the gap. Teams that have not rebuilt their screen are, in effect, paying senior engineering time anyway, just later and at a worse exchange rate, usually in the form of someone rewriting work after probation. If you want the budget version of this argument, our note on project management in Dubai covers how that slippage compounds once a sprint has already been planned around a person who cannot carry the work.

The Part I Am Still Thinking About

There is a version of this story that is straightforwardly good for employers, and I do not want to lose it in the screening anxiety. If a product manager in Dubai can now assemble a rough working version of what she wants before she briefs engineering, the brief that arrives is dramatically better. Half the waste in a software project comes from the gap between what someone asked for and what they meant, and a disposable prototype closes that gap faster than any specification document. National programmes that teach non-engineers to produce one are, in that light, doing delivery teams a favour.

The failure mode to watch for is the same capability misread as sufficiency, which shows up as a stakeholder who has built a working prototype concluding the remaining work is small. It is not small. It is most of the work, and it is the part that deals with the conditions nobody demonstrated. Logistics and fintech products in the UAE both hit that wall early, which is why our notes on logistics apps in Dubai and fintech apps in the UAE spend more time on edge cases than on features.

FAQ: UAE Vibe Codes and Dubai Developer Screening