Fun

Forty-plus candidates screened, four engineers hired, and a taxonomy I wasn't expecting to find. Making AI fluency a hard requirement filtered the applicant pool, but the more interesting result was the spectrum it exposed among everyone who made it through: non-users, reluctant adopters who reach for it on boilerplate and tests, green users who accept whatever the tool suggests, collaborators who push back on it, and vibe coders who can ship a demo but can't explain the architecture underneath it.

The gap that matters sits between the third stratum and the fourth, and it's nearly invisible on a resume. Both groups produce working code. One follows the AI, the other leads it. A take-home that required AI usage, plus a presentation on the process rather than the output, was the only thing that reliably told them apart.

A CSV import that reported failure but had actually succeeded, a 60-second load balancer timeout, and fifty sequential calls to the Mailgun API stacked up inside a loop. The old version of this debugging session takes two hours on a good day: dashboard to codebase to database client and back, assembling the picture piece by piece and holding it all in your head.

With New Relic's MCP server, MongoDB's, and the full codebase live in one Claude Code session, the picture assembles itself. Diagnosed, fixed, and deployed in a single sitting, along with a silent behavior gap no alert would ever have flagged, because from the system's perspective nothing was wrong.

The Star Trek Communicator & Away Team Action Playset shipped for webOS in 2009: fourteen characters, hundreds of voice clips, a draggable phaser dial, and a communicator grill that actually opened and closed. Then Palm died, and the app went with it.

Sixteen years later I handed the whole thing — Mojo scene assistants, sprite sheets, 8.5MB of assets — to Claude Code and played domain expert while it wrote every line of React. Here is how the port went: the invisible overlay swallowing clicks, the border-image-slice fill keyword nobody remembers, the fifteen years of border-box muscle memory that turned out to be exactly wrong, and the phaser overload easter egg, restored.

An MCP bridge from Claude Desktop to MAME gave the model a full development loop on a 1981 TI-99/4A: write TMS9900 assembly, compile a cartridge, launch it, look at a screenshot, try again. It knew the memory maps and VDP registers cold. It had never run a single instruction on the hardware.

That gap showed up fast. Direct memory writes came back mangled by the datamux, a bus width converter the documentation mentions but never warns you about. A green backdrop came out purple because the console's own startup routine was fighting the code. A dozen iterations later, the logo was on screen in light red, since the 15-color palette has no orange.

The interview industrial complex broke in two directions. The FAANGs over-optimized until leetcode prep became its own industry; startups never built the rigor in the first place and hired for velocity. Both missed the same thing. Code was never the hard part. Knowing what to build and why was always the hard part.

I started as the engineering department at a startup and hired every person who came after, and I filtered for how people reason through ambiguity rather than how they perform while someone watches them type. Some people thought that wasn't rigorous enough. Then AI commoditized code production and the startup math got brutal: one thinker with AI tools does what used to take a thinker plus two implementers. Here's what I hire for now, and how the interviews changed.

The 10x productivity narrative assumes AI has changed the equation. It has, but not where most people are looking. AI makes architected work faster; unarchitected work just fails faster.

The shift happened for me while debugging authentication across three platforms and three languages — two days of coordination compressed into an hour. From there it became a method: a workspace where the model sees the whole stack at once, MCP connections to the real database instead of guesses about it, and planning documents that get stress-tested, argued with, and revised right up until the feature ships. What the method still needs is someone who already knows what good output looks like.

It is 11:47 PM, I am debugging prod, and my two-year-old has just delivered a request for cold water containing nested clauses, exception handling, and a default fallback. I dropped my laptop. Not because I was tired, though I was.

What follows is the five-stage framework I have derived from watching Luna acquire language: the naming explosion, the possessive pronoun wars, the discovery of AND, the arrival of BUT ALSO, and the final form where because and however and even though all arrive at once. Each one maps onto something a junior developer does. Each one deserves celebration rather than correction. I am shaking, and I am writing a book about it.

The machine already worked fine on its native 68000, the built-in 1.3 ROM, and Workbench 1.3. That's charming from a historical perspective, but I never built the cable to get RGB into my odd Sony display, and I'd like something a bit newer under me before I start playing with old graphics software and drawing tablets.

So: a piStorm standing in for a much faster 68000, and an rgb2hdmi board sending video out over HDMI. Both are part of a whole world of Raspberry Pi projects for reviving retro computers, and I've barely scratched the surface of what they can do. Here's where things stand so far.

The animatronic skeleton I built for last Halloween worked, but only after a last-minute compromise: there wasn't enough memory to hold the animation sequences for both the songs and the patter, so I loaded the patter and left it at that. This year the skeleton is going to sing, which means loading the animation files on demand instead of all at once.

I also want to spend less of the night running sequences by hand, so there will be a jukebox mode that lets it perform without intervention. Last year's code is up on GitHub, and the first job is reworking that repo to clean it up and strip out the options I never ended up using.

Someday there will be a proper writeup, and probably a video. For now, a placeholder: an archived message from an Amiga BBS in which Joe Smith explains how he got a Sony KV-25XBR talking to an Amiga, after discovering that nobody at any computer store, any Sony dealer, or Sony customer service knew where to find the cable.

He bought the service manual, decided the official PX-34 connector was overpriced and the SMK-0001 cable a gamble, and wired up his own breakout box instead: a 9-pin Amiga video connector, six RCA jacks, and two switches for sync-on-green and TV audio. The full 34-pin and 9-pin pinouts follow, along with the reference links he gathered.