Most AI code today doesn't fail at first glance. It fails at the second one.
Open a model's replica of a real webpage and, at a passing glance, it looks fine. The hero section lines up. The nav bar sits where it should. Then you shrink the viewport, and the whole thing falls apart — because underneath that convincing screenshot is a single <div> soup held together with absolute positioning and hardcoded pixel offsets, not layout. It's a magic trick, and most people never look behind the curtain.
That's the entire premise of this role. Not "can you build a frontend" — you can already do that. The question is: can you look at someone else's frontend, tell exactly how it was built, and catch it when it's faking correctness instead of achieving it?
If that sounds like your kind of problem, keep reading.
What the work actually is
This is a remote, hourly frontend engineering contract at $90/hour, built around one task: judging AI-generated code against real, human-built reference websites.
Here's the loop. You get three things — a reference page crawled from the actual internet (full site tree, plus screenshots of every state: default view, hover, click, scroll), and two AI-model attempts to replicate it, labeled A and B. Critically, the models never saw the source. They only saw screenshots. Your job is to find out how well they reverse-engineered a working webpage from pictures alone — and where they cut corners to fake it.
You download all three, spin up a local server, render everything at 1920×1080, and interact with each build to reach every required state. Then you crack open the source of both attempts and compare:
Visual fidelity, state by state — spacing, typography, color, borders, image handling, z-order, overflow
Construction quality — is this a real rebuild, or a screenshot pasted in as an
<img>? Real document flow, or absolute-positioned duct tape?Responsiveness — does the nav bar that looks perfect at 1920px quietly break at 1400px?
Every verdict needs a specific, evidence-backed justification. Not "A looks closer" — more like: "B nests the article body in a single absolutely-positioned div, so text overlaps the footer below 1600px, while A uses normal document flow." That's the bar.
Why this role is harder than it sounds
Here's the part most applicants underestimate: the reference pages aren't clean modern React apps. They're pulled from the real, messy internet — a charter-fishing site still living in the table-and-image-map era, a corporate press page with stacked nav rows and social share widgets bolted on. If your entire career has happened inside a component framework and you've never hand-written CSS or seen a <table> used for layout, you will misjudge these pages. Not might. Will.
This isn't a knock on framework-native engineers — it's just a different skill. This work rewards people who've been around long enough to read a layout and predict what's holding it together before opening DevTools. People who've had a designer reject their build over four pixels and know exactly what that fight looks like. People who can spot a heading dressed up as a styled <span> and know why that matters.
Backend-only, ML, mobile-native, and DevOps engineers — this genuinely isn't the seat for you, however strong you are elsewhere. Same for designers who don't code: you can't grade the source axes without reading the source. This is deliberately narrow, and that's the point.
Who this is actually for
3–8 years of professional frontend or full-stack experience, shipping real interfaces
Fluency across web eras — modern flexbox and grid and legacy float- and table-based layouts you can read without flinching
DevTools as muscle memory: exact viewports, computed styles, watching what a hover handler actually mutates
Command-line comfort — unzipping, standing up a local static server, chasing down a broken relative asset path instead of grading off the screenshot
Enough JavaScript to read a script and know what it's doing to the DOM
Strong, specific, professional written English — your justification is the deliverable
Bonus points if you've done RLHF, preference-labeling, or structured code review before — that's the single strongest signal for this project. Pixel-perfect design-to-code background, accessibility chops, or a feel for how LLMs typically fail at code generation all help too.
The practical stuff, before you apply
Be honest with yourself about two things first:
Time. Each unit runs roughly 2–3 hours and is timed. This is not something you chip away at in 15-minute gaps between meetings — you need contiguous focus time.
Equipment. You need a real desktop or laptop that can display a 1920×1080 viewport, with admin rights to install and run a local server. A tablet, Chromebook, or locked-down work machine won't cut it.
You'll also need at least one prior completed engagement on the platform already delivered in full — this project isn't onboarding net-new experts.
On the logistics side: you're engaged as an independent contractor, fully remote, on your own schedule, paid weekly via Stripe or Wise. Projects can extend, shorten, or wrap based on performance and need. Note: H1-B and STEM OPT candidates can't be supported at this time, and this work never touches confidential or proprietary employer/client data.
The real question
Anyone can eyeball two screenshots and pick the prettier one. That's not what's being paid for here. What's being paid for is the engineer who can explain, in exact and falsifiable terms, why one build is structurally sound and the other is a well-disguised hack — the kind of judgment that only comes from years of actually shipping and debugging real interfaces.
If you've ever muttered "this only works because of a hardcoded pixel offset" under your breath while reviewing a PR, you already have the instinct this role is built around.
Ready to put that eye to work?
If you can read a page and tell, before opening DevTools, what's really holding it together — this is your seat.
Apply now and start grading the gap between code that looks right and code that actually is.