I Asked an AI to Design My Camera App End to End. It Produced 148 Screens and a List of What It Could Not Do.
I have been building an Android camera app called CinematiQ Pro. Camera2, OpenGL ES rendering, fifteen-odd Gradle modules, a beauty pipeline, cinematic video with depth blur. The engineering has been running for months. The design had not.
So I tried something. I handed an AI my own engineering documents, connected it to Figma, and asked it to design the whole product. Not one screen. The whole thing, end to end.
This is what came back, what it got right, and the part I think matters most: the list it wrote of everything it could not verify.
What it actually produced
| Output | Count |
|---|---|
| Primary Figma screens | 34 |
| Supporting flow screens | 114 |
| Total frames | 148 |
| Nodes carrying interaction reactions | 1,041 |
| Feature and state routes represented | 239 |
| Exported PNG boards | 38 |
| Self-contained HTML prototypes | 2, around 881 KB each, run offline |
The design coordinates are 412 × 915 for the phone, with a landscape 915 × 412 arrangement and a 360px viewport checked for horizontal overflow.
The prototypes are the part I did not expect. They are not pictures. They are two HTML files that open with no server and no internet, where the filter carousel scrolls, the strength slider changes actual rendered pixels, hold-to-compare restores the original and releases back to the selected look, and recording starts, pauses, resumes and stops with the look snapshot saved at the start of the take.
It is a build, not a drawing
The thing that made this feel different from a design handoff was opening the folder and finding a build script.
The two prototypes are generated. There is one prototype.html, one feature-routes.json holding the 239 routes, one photograph used as the viewfinder source, and a build.py that assembles them into the Stage 1 and Stage 2 files. Change a route, run the script, get both prototypes again.
That is a small detail and it changes the nature of the artifact. A Figma file is a thing you look at. This is a thing you can regenerate, which means it can be corrected without anyone redrawing anything.
The part I did not expect: it told me what it could not do
The package ships with a verification table. Not a summary. A table with a row per claim and a result.
Plenty of rows say PASS, and they are the ones you would expect: every route renders, every visible navigation target exists, tapping a filter changes real browser pixels, the carousel scrolls on a wheel event, the closed strip keeps the selected look, Photo and Cinematic hold separate selections, landscape controls do not overlap, zero page errors across the whole interaction suite.
Then the rows that made me trust the rest of it:
- Real finger swipe on a physical Android device: Not verified. Everything was browser wheel, keyboard and pointer simulation.
- Real camera, beauty, depth, AI, AR and remote capture: Not verified. The prototype simulates them.
- Android accessibility, 48dp touch targets, font scale, display cutouts: Not verified.
- APK, physical cameras, performance, saved media, release: Not verified.
- Continuous interaction inside the Figma player: LIMITED. The HTML is authoritative for sliders and scrolling.
And one line in the handoff that I have since written down and kept:
A route is not proof of Android implementation.
That sentence is the difference between a design package you can work from and a pile of pictures that make you feel finished. 239 routes exist in the mockup. That says nothing about whether 239 things work in the app, and the document refuses to let you confuse the two.
The QA pass found five real bugs
This is the part nobody publishes, so here it is. Before handoff, the browser test pass found and fixed:
- Three internal navigation destinations that went nowhere.
- An overlap on the Studio Export control.
- A landscape layout where the strength slider and the Compare control sat on top of each other.
- Horizontal page overflow at mobile width.
- A Beauty adjustment surface so opaque that the viewfinder disappeared behind it, which defeats the entire point of adjusting a live preview.
There was also a test passing for the wrong reason. A selector was targeting the preview element’s data attribute rather than the filter buttons, so it would have reported success without proving a tap did anything. That got corrected too.
None of these are exotic. They are the ordinary defects any real design review produces, and the fact that the pass produced them rather than a clean sheet is the reason I believe the PASS rows.
Where it was genuinely good
The visual direction is a full replacement, not a patch. Edge-to-edge viewfinder behind the status bar, the controls, the lens chips, the shutter and the mode row. Bare white line icons instead of opaque toolbar buttons, with a warm yellow selected state and a content-adaptive edge gradient so white icons stay readable over a bright sky.
Zoom and Filters share one row, and Filters is labelled rather than hidden behind a gesture. The open carousel is a background-free row of circular photographic thumbnails with the look name and a strength value, and closing it keeps your selection. Beauty and Depth sit directly above it and open translucent trays so the preview stays visible while you adjust it.
It also understood something about camera apps that is easy to get wrong in a mockup: Photo, Cinematic and Video should each remember their own look. You do not want your portrait filter following you into a video.
Where a mockup structurally cannot help
Two things, and they are worth stating because this is where AI design stops and engineering starts.
It cannot know what the phone supports. A camera app admits features based on measured device capability: lens chips, ISO and shutter ranges, resolutions, frame rates, HDR, Log, RAW, stabilisation, live depth. The sample 4K/24 values and battery figures in the mockup are visual fixtures. Every one of them has to be gated behind real capability admission in the app, and a feature that is not supported has to be absent with a reason rather than present and broken.
It cannot make the saved file match the preview. This is the single hardest promise a camera app makes. The handoff is blunt about it: apply the same look, intensity, beauty, crop and depth policy to the JPEG or MP4 that you showed in the viewfinder, and never render a look only in the UI while saving an unchanged file. It adds a specific rule I liked, that a monitor LUT while recording Log is preview-only and must never be silently baked into the recording.
A mockup can specify that contract. Only the pipeline can keep it.
What I would tell someone trying this
Give it your real documents. The reason this produced something usable is that it was working from actual engineering state, including the parts that said things were incomplete, not from a one-paragraph description of a camera app.
Ask for the verification table. If a design package comes back with no statement of what was not checked, you have a set of pictures and an unknown amount of confidence.
And read the Not verified rows first. They are the honest map of where your work still is.
CinematiQ Pro is still in development. Stage 1 is built and Stage 2 is in progress, and none of the above means a feature works on a phone. That was rather the point.
