Inspiration

Everyone is told to get better at prompting, but there is nowhere to practise it the way LeetCode lets you practise code: a clear target, an attempt, and a score you can trust. We wanted that loop for prompting.

What it does

PromptDyno gives you a goal: a web page, a multi-page site or a 3D model. You write a prompt, a model builds from it, and a grader scores what came out against the goal.

The score is not an opinion. No AI is involved in grading, and the same submission always gets the same score, so a leaderboard means something.

  • Three things are scored. Does it work (the right content, in the right structure, with working links), is it well engineered, and does it look right. Working and being well built count for more than looks: something pretty that does not work is useless.
  • Engineering is real engineering. Size, estimated load time on four simulated devices from a budget phone on slow 3G to a desktop on fibre, accessibility, and clean code. The weakest of them sets the engineering score, so a weakness cannot be averaged away. A site that looks perfect but is many times too heavy loses marks.
  • Sites have to hold together. A page nobody can reach keeps only half its marks, and dead links cost the whole score.
  • 3D is real code. The model writes Three.js. We run it locked down, take the shape it builds, and compare it with the goal's from four fixed angles.
  • You are told what to fix. Every score comes with plain-words feedback, most costly first: "Nothing links to the pricing page, so visitors cannot reach it", "The button is green where the goal's is blue", "Uses 88 times as many triangles as the goal".
  • You can beat the reference. Match the goal exactly with a site that is smaller and faster than ours and you score above 100.

How we built it

  • The site is a Node back end with a static front end, hosted on Vercel, with accounts in MongoDB Atlas.
  • The grader is TypeScript. It renders the goal and the submission in a headless Chromium that cannot run page scripts or reach the network, reads what a person would actually see (text, boxes, images, with their positions and colours), and compares the two. Colour differences use CIEDE2000, so a shade nobody could tell apart costs nothing. It judges what is rendered, not which tags were used: the same page built with a table or with a grid scores the same.
  • For 3D we wrote a small software renderer, so scores never depend on a graphics card, and we compare solid shapes on voxel grids, so a chair built from five boxes and the same chair built as one mesh score the same.
  • The grader runs as its own service in a container on a Vultr server, with the browser's own sandbox switched on, and the site calls it.
  • We built with Claude Code: one session coordinating, and coding agents each working on separate files.

Challenges we ran into

  • Making "a person would say that is right" repeatable. Pixel comparison is too harsh (a two-pixel shift fails everywhere) and structure alone ignores how the page looks. We ended up scoring several things a reviewer would check, each with a tolerance for what the eye does not notice.
  • Our own examples were not enough. We wrote tests of rules that must hold for any page (removing content never helps, adding junk never helps, moving something further never helps) and ran them over generated pages. They found 16 scoring bugs that hand-picked examples had missed: a background colour difference too small to see cost 12 points; a sentence in Chinese counted as a single word; a goal site with one dead link scored 60 against an exact copy of itself.
  • People will try to game a grader. Hidden text, a correct page under a white cover, a site whose pages frame themselves to stall the server, a file named to crash the renderer. Each is now a test.
  • A headless browser does not run on a serverless host, so the grader had to become a separate service, and getting a sandboxed browser to start inside a locked-down container took three attempts.

Accomplishments that we're proud of

  • 268 automated tests on the grader, including the tests over generated pages.
  • A grade that is reproducible to the decimal.
  • Feedback a player can act on, taken from the same arithmetic as the score.
  • Three kinds of challenge on one scoring model.

What we learned

  • Fair grading is mostly about what you refuse to charge for.
  • Tests of general rules find bugs that examples do not.
  • A score people can argue with needs to explain itself.

What's next for PromptDyno

  • [Finish before the final deadline: the full loop on the live site, from prompt to model to grade to leaderboard.]
  • Leaderboards by number of prompts used: one-shot, two-shot, and so on.
  • A second 3D language, OpenSCAD, for models you could 3D print.
  • A choice of models, with more capable ones costing more credits.
  • More goals, each ranked by people so the grader keeps agreeing with them.
Share this project:

Updates

Submission history