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.

A guide to getting the most out of Copilot as a Drupal sidekick, built around knowing where its strengths stop. It will churn out boilerplate all day, but it is not a stand-in for actually understanding the code you are shipping.

That opening line matches my own experience with AI coding tools and autocompletions pretty closely. They are genuinely handy, and I would not want to give them up. But much like AI text and images, they will also confidently hand you complete nonsense, and noticing that is still your job.

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.