What Can an AI Builder Not Build? An Honest List
An AI builder cannot produce a 3D game, a native store binary, or a complex product that replaces a development team. It also cannot invent business rules it was never told, or handle the parts that were never software: legal approval, payment underwriting, and whether your content is true. Everything else is a question of how many edits.
We build Zugo, so a list of our own limits is an odd thing to publish. It is also the most useful page we can write, because the expensive failure is not a build that comes out wrong. It is three weeks spent pushing a tool at a job it was never shaped for.
What can an AI builder genuinely not build?
Four categories, and they are boundaries rather than difficulty levels. No amount of prompting moves you across them.
Anything that must ship as a native binary. A Zugo project is published to a web address and runs in a browser. That is the output. If your requirement is specifically an app installed from a store, the browser is not where that ends.
3D games. Games are a first-class output here, and they are 2D and browser-based. That is a genuine range and a genuine edge. A 3D engine project is a different discipline with different tooling.
Products that need a team. Zugo does not replace a development team on a genuinely complex product. A builder gets you to something real quickly; a system with years of accumulated rules, integrations and edge cases is engineering work, and pretending otherwise wastes your quarter.
The parts that are not code. Payment processing has its own approval process. Taxes, licences and regulated disclosures are yours. No generator resolves whether the claim on your landing page is accurate, and it is your name on the page.
Why can't one prompt produce specific business logic?
Because specific logic is specific, and a description is compression. "A booking form" is a shape every builder recognises. "A booking form that blocks Tuesdays in the low season unless the customer has three previous bookings" is a rule that exists only in your head until you write it down.
Generators are good at the shape and unreliable at the exception. The first pass gives you the form, the fields, the confirmation screen, and a plausible-looking rule that is not quite your rule. Reading the result and correcting it is the actual work, and it is not a failure of the tool.
The practical route is layered. Build the shape, then add one rule per edit at 3 credits each, checking after each one. Very specific business logic arrives through successive edits rather than one perfect prompt, and knowing that up front changes how you budget both credits and patience.
Where exactly does the game boundary sit?
At the third dimension and at the browser window. Inside that boundary there is more range than people expect: platformers, match-3, endless runners, shooters, idle games, playable in about a minute from a description. Outside it, the answer is a different tool.
| What you are asking for | Inside the boundary? | What it actually takes |
|---|---|---|
| A 2D browser game from a description | Yes | A build, playable quickly |
| A game embedded on your own site | Yes | A build plus a custom domain |
| A 3D first-person game | No | A dedicated 3D engine and an artist |
| A multiplayer game with live matchmaking | No | Server infrastructure and ongoing operations |
| A game published to a console store | No | A publisher pipeline and platform certification |
If you are weighing a game project specifically, can AI build a game goes through what the 2D range covers in more detail.
What about the things that are not code at all?
This is the category people forget, and it causes more stalled launches than any technical limit. A builder produces software. A business needs several things that are not software, and none of them arrive with the build.
Payment acceptance is the clearest example. Stripe is a built-in connector, so the checkout in your project can be real within minutes. Whether Stripe approves your account for your category, and on what terms, is between you and Stripe, and no builder shortens that conversation.
The same applies to anything regulated: health claims, financial advice, age restrictions, accessibility obligations in your jurisdiction. A generated page will happily render whatever you asked for. It has no view on whether you are allowed to say it, and neither does the sandbox check that confirms the build loads.
What can it build that people assume it cannot?
The list is longer than the one above, which is why the boundaries are worth stating precisely rather than vaguely.
Real databases and real login. Supabase covers stored data, authentication and file storage, so a customer portal with per-user records is an ordinary build rather than an exotic one.
Working payments. Stripe handles one-off purchases and subscriptions inside a generated project.
Multi-page structure. A platform costs 12 credits for the first three pages and 3 for each page beyond, so a site with real navigation is a normal request.
Code you keep. GitHub export puts the full source in a repository under your account, and the project belongs to you. That single fact is what makes the boundaries above survivable: when you outgrow the builder, you leave with the work.
How do you tell in advance which side of the line you are on?
Three questions, asked before you spend anything.
| Ask yourself | If the answer is yes | If the answer is no |
|---|---|---|
| Does it run in a browser? | A builder is a candidate | Look at native tooling instead |
| Can you write the rules down in plain sentences? | Build it, then refine with edits | Write the rules first, or hire someone to |
| Would a wrong version be embarrassing rather than dangerous? | Iterate freely | Get review from someone qualified before publishing |
The second question is the one that separates a good week from a bad one. If you cannot state the rule in a sentence, no builder and no developer can implement it either, and the missing piece is a decision rather than a tool.
What should you do when you hit a real limit?
Take the code and change the tool, not the goal. That is the whole reason export matters. A project that only exists inside a product is hostage to that product's boundaries; a repository under your account is a starting point for whatever comes next.
Bringing in a developer is the usual next step, and a standard repository is the handover format they already know. What that transition looks like in practice is covered in hiring a developer later.
The other honest option is to narrow the goal. A lot of projects that "need" a native app need a web page that works well on a phone, and a lot of products that "need" a team need a landing page that proves anyone wants the thing at all.
If your project sits inside the boundaries described here, the cheapest way to confirm it is to build the smallest version and look at it. Describe it at zugo.dev, and if the result runs into one of these limits, you will know within the hour rather than in month three.