Work

The first version launched in February: near-black, a purple gradient, and a WebGL hero where crumpled resumes fly past the camera as you scroll. It began as a scrounged-together Lovable build, and it looked very vibe coded, though I kind of liked the vibe-coded colours. I was overwhelmed by the hype of being able to design like that at the peak of the vibe coding era. I soon sobered up to the reality: it looked very SaaS, B2B, LinkedIn hype, and it needed fixing.

In April I redesigned it in light mode: a soft purple palette, a serif headline, “Hire the person, not the resume”, and every section and sub-page converted.

The flying papers stayed, but rebuilt without 3D, much more efficiently. The WebGL version was too complex to load on many devices, phones especially. It's now 32 resume cards on CSS transforms, scrubbed by scroll on a sticky stage. Positions update through refs in an animation frame rather than React state, scroll listeners only attach while the hero is near the viewport, and only the first eight images load up front.

We had just pivoted, and what I wanted to show, artistically, was that we were a quality recruitment agency: one that could sort through the field. Before, the pitch had been that we could find out a lot about a person without their resume. While the full site is held back, the home page is a single question: “Who are we hiring today?” You type a role in your own words, it pins your brief and “starts reading it”, and a field of dots appears, one per person, with an agent moving through them looking for the right one. Then it asks your name, email and phone one at a time, each answer folding away as you go.

But as much as it looked and felt like an agent, it was simply a waitlist sign up. The waitlist page uses the same field: it was the original application for it, and the agent roams, pauses, and locks onto a single dot. I was inspired by a meme of Rick from Rick and Morty walking through a field.

Rayon was an interviewing co-pilot. It helped interviewers go in ready with questions that dug deeper, and understand applicants better, so that everyone got a fairer interview. A reverse Cluely, if you will.

It sat in on a job interview. The interviewer ran a desktop app that listened, told the two voices apart, and either suggested follow-up questions as it went (copilot) or took notes quietly (intern). When the interview ended it scored the candidate against the role's rubric. The hiring team reviewed scores, transcripts and rubrics in a web dashboard afterwards.

I owned the entire user flow, and Richard built the backend. The desktop app was mine: 186 of its 220 commits came through me, written by coding agents I directed and reviewed. It was my first Electron app and the first time I'd streamed live audio anywhere. We pulled two all-nighters back to back to get it to our clients on time, and still didn't make that morning; it was more complex than we'd planned for. The Rust API and the infrastructure were Richard's.

The live screen has to work while someone is mid-conversation, so it's three calm panels: notes, suggested questions with the transcript, and the role's context with audio meters. Every line is labelled interviewer or candidate, and one click corrects a wrong label, because a score built on misattributed answers is worse than none.

Two things mattered most to me here. It had to be glanceable: someone mid-conversation should be able to take in the whole screen in a second without losing the person in front of them. And it had to be easy to know what question to ask next, so the suggestions were short, clear and written to be friendly and easy to understand for both sides of the conversation, the interviewer reading them and the candidate hearing them.

Consent comes first: nothing streams until the candidate has agreed, and withdrawing stops the stream on the spot. A dropped connection shows plainly and resumes where it left off.

In the dashboard, AI-drafted rubric criteria are never saved without a person, and the editor locks while a draft is generating so a late result can't overwrite someone's edits.

The dashboard's server was making one call to the API per interview, plus a sign-in check in front of every one of them. With 150 interviews, the overview took over three seconds to load.

So I hill-climbed it: measured every API call, cut or cached whatever I could, measured again, and kept going. With the data warm, the dashboard call went from 3.2 seconds to 24 ms, and moving between pages stopped flashing a loading screen. The very first load still pays the full price, because the real fix is a bulk endpoint in the API, which I wrote up for it.

NVIDIA's PersonaPlex-7b is a full-duplex speech model: it listens and talks at the same time, like a person on a call. It was built to be the service agent. We needed it to be the customer, so people could practise a shift against a convincing one.

Out of the box it kept slipping back behind the counter: barista phrases in the customer's mouth, talking unprompted the moment a call connected, and losing its persona halfway through.

We fine-tuned it with LoRA on 200 synthetic coffee-shop conversations with angry, nervous and friendly customers. GPT-OSS-120B wrote them, Claude Sonnet checked them, and ChatterboxTTS gave them voices.

There are two ideas on top of the fine-tune. The first weights the loss 100× towards the model's semantic codebook, so training cares about what is said more than how the voice sounds. The second, voice prompt injection, plays the model a pre-recorded barista greeting before the first turn, so it starts the call already knowing which side of the counter it's on.

With no standard benchmark for full-duplex persona work, GPT-4o judged each conversation's transcript on a five-point scale. Against the base model, emotional accuracy went from 2.2 to 3.4 and task adherence from 2.6 to 4.2, while the hallucination score dropped from 3.6 to 1.8. The voice prompt alone accounted for a large share of that: on the fine-tuned model it cut hallucinations from 2.6 to 1.8.

It's a small study, and the paper says so: a handful of conversations per setup, and no ablation yet that isolates the semantic loss weighting.

VirtualShift puts candidates into a realistic shift, so it needs realistic places for those shifts to happen. The first was the concierge lobby of a Southbank residential tower. I rebuilt it in Blender from reference photos, 414 meshes, then moved it into Unreal and spent a long time with MetaHuman getting 11 characters to carry seven scenes of about thirty seconds each. By the end the lobby looked great.

One lobby wasn't the point, though. Blender turned into a long and tumultuous build of a pipeline my Claude agent could run on its own, turning a couple of photos or a description into a working environment.

More times than I could count, but twice badly. One time an agent emailed one of our vendors without my knowledge.

Another time I told an agent to act more efficiently, and it took that to the nth degree. Instead of reading colour schemas from our database, it hard-coded everything into the beta build, subversively, and that broke our entire production VirtualShift.

I assumed shader compilation and downloads. On a software GPU the real cost was the card textures: 6.7 of the first 7.7 seconds. Almost none of it was my own maths. Reading the painted canvases back with getImageData took 4.2 seconds on its own, because it forced the browser to finish drawing and copy the pixels off the GPU. The normal-map loop took about a second.

Telling the browser those canvases would be read often, moving the normal-map maths into a pool of workers, and starting the painting as soon as the page mounts took the first frame from about 7.5 seconds to about 2. Before and after screenshots were identical within a 2 percent tolerance.

Next I compiled every shader while the cards were still painting, wherever the browser can compile in parallel. A software GPU cannot show that, so for a while it was an untested claim. On a real GPU I could finally switch it off and look.

It does what it says. About 90 milliseconds of compiling leaves the first frame, and the longest single block of main-thread work before the wallet appears shrinks from 102 to 79 milliseconds. But the wallet is on screen at the same moment either way, within noise. It is worth keeping for smoothness, not for speed.

On a real GPU with a warm cache the wallet is drawn at about 0.95 seconds. A CPU profile of that load showed the main thread was the bottleneck: it was busy for nearly all of the first 650 milliseconds, and roughly 230 of those were card painting.

Only four of the fourteen painted sides are visible when the wallet is at rest. The rest are the backs of cards and the cards in the back pockets. So the first frame now waits for those four, and the other ten are painted one at a time in idle time. They are all done a little over a second after load, long before the intro ends and clicking is allowed. The first paint moved from 935 to 893 milliseconds, every run faster than every old run, and the 3D scene mounts about 65 milliseconds sooner.

Fetching the 3D scene's code earlier, with an import at the top of the module: no change.

Putting the card painting code in the main bundle to save a round trip: no change.

Server rendering the scene wrapper so the HTML preloads its code: the scene mounted about 100 milliseconds sooner, but the first frame came about 490 milliseconds later, so I reverted it.

Switching off the lighting bake to see what it costs: 30 to 50 milliseconds, not the hidden cost I suspected.

Moving the card painting to a worker: I stopped before building it. Switching that work off entirely saves about 100 milliseconds at most, and a worker version risks changing the pictures, so painting fewer sides first was the better trade.

Everything runs on a production build with performance marks. First paint is two animation frames after the wallet's first frame, because compiling inside a frame only shows up once it has been drawn. Warm numbers are medians of 5 to 7 runs, with variants interleaved so any drift hits all of them equally, on an NVIDIA GTX 1080 with 12 cores.

The cold-network numbers come from a small throttling proxy in the repo. It is indicative, not precise: it speaks plain HTTP, and I hit cache and cancelled-request artefacts while building it, so I only trust comparisons run back to back. The software GPU numbers come from the first round, in a 4 core virtual machine. I have not measured a phone.