A developer in the Claude builder community ran a deceptively simple test. They took a single screenshot of a logistics dashboard, handed it to Claude Fable 5, and asked for a working recreation. What came back was a single-file HTML page with a real Three.js globe: a NASA night-earth texture, an atmosphere glow, animated route arcs, floating cargo tags, a glass interface, and a collapsible bottom panel. It was draggable and ran in any browser with no build step. The builder reports that earlier Claude models never reached this level of frontend fidelity in one pass.
This is a community-reported result rather than an Anthropic benchmark, so treat the specifics as one data point. The interesting part is not the demo itself. It is the prompt that produced it, which the author published in full. For any team weighing what Fable 5 changes about building internal tools, the prompt is the practical takeaway.
What actually happened
The input was a flat reference image of a logistics dashboard. The output was a functioning interactive artefact: a 3D globe you can spin, with live route animation and a UI panel that opens and closes. No scaffolding, no component library wiring, no design handoff. The model read the picture, reasoned about the structure, and wrote the code to rebuild it as something you can click.
The jump worth noting is from static mockup to working prototype in one step. Screenshot-to-code has existed for a while, but most attempts produced a brittle visual copy. Here the result was an interactive page with a genuine WebGL render behind it, close enough to put in front of a stakeholder the same afternoon.
The exact prompt, broken down
The published prompt is specific and structured. It front-loads constraints so the model has less room to drift. These are the patterns doing the work, and they transfer to almost any screenshot-to-code task you might try:
Demand fidelity in plain words. Ask the model to recreate the reference image as closely as possible, using explicit language like high-fidelity, realistic, and polished so it aims high rather than sketching.
Enumerate every element you can see. List the sidebar, the title, the route markers, the statistics, the zoom controls. Naming each piece stops the model quietly dropping the parts it finds hard.
Specify the technology up front. State the constraint early, for example Three.js for the globe rather than a static image, so the model commits to a real render instead of faking it.
Request one deliberate change. Ask for one difference from the reference, such as the panel collapsed by default, to prove the model is composing the result rather than copying pixels.
Tell it to think before it codes. End with an instruction to analyse the image first and reason it through before writing any code. That single line measurably improves the output.
None of these are exotic. They are disciplined description. The lesson is that prompt quality still decides the outcome, even with a stronger model underneath. A vague request gets a vague page. A structured brief gets something you can ship.
What this means for Australian businesses
A production-quality interactive dashboard like this, quoted through a Sydney or Melbourne agency, typically lands between $20,000 to $60,000 AUD and takes weeks of discovery, design, and build. A one-shot prototype from a screenshot does not replace that work, but it collapses the front end of it. You can put a working, clickable artefact in front of decision-makers on day one instead of week three, and have the costing conversation against something real rather than a slide.
Screenshot-to-working-code is now a realistic workflow for internal tools, admin panels, and data dashboards where the design already exists somewhere.
Single-file HTML output means zero deployment friction for internal demos. You can email a file or drop it on a static host and let people poke at it.
The prototype shifts the expensive part of a project from building the first version to deciding whether the first version is right, which is where the real risk usually sits.
The caveats worth keeping
One impressive sample does not guarantee the same result across every design, and a prototype is not a product. Authentication, real data wiring, accessibility, browser testing, and security review are all still genuine work. Treat a one-shot build as a prototype accelerator, not a finished line of business software. The honest framing for an Australian team is that this changes how fast you reach a decision, not how much production hardening you can skip.
Where this fits
If your team has a backlog of internal tools that never get built because the design-to-first-version gap is too expensive, this is worth testing on your own screenshots this week. Start with one dashboard you already have a mockup for, write the structured prompt above, and see how close Fable 5 gets in a single pass. Talk to Automata AI if you want a Claude capability assessment grounded in your own build pipeline rather than someone else's demo.
