How our team ships with AI without letting the AI just wing it. A companion piece to the release train.

An AI coding agent will hand you a two-hundred-line pull request in ninety seconds. It will look plausible. The variable names will be sensible, the structure will be clean, and somewhere in the middle it will have made an assumption nobody asked for and nobody caught. You cannot review it properly, because there is no record of what it was trying to do or why. You are left grading an answer with no working shown.

This is the actual risk of AI-assisted development, and it is not that the code is bad. It is that speed without structure produces confident, wrong, unreviewable work, and it produces it faster than you can catch it. A junior engineer does the same thing for the same reason. The failure is not the writer. It is the absence of anything forcing the thinking to happen before the typing.

Our answer is a system called CasaFlow, and this is the quieter half of a story I started last week. The release train was mine, a tool the whole team feels when a deploy rolls out. CasaFlow is Zak's, and it is the opposite kind of tool: the one a single engineer drives, heads down, to turn an idea into a merged PR. He built it in his first weeks on the team, he maintains it, and by now the whole team contributes to it. Two parts of a whole. One makes shipping legible. This one makes the building itself hard to do badly.

What it is

CasaFlow is a pipeline of skills, slash commands in Claude Code, that walk a piece of work from idea to merged PR. It is emphatically not a single "write my code" prompt. It is a staged process, and every stage produces a durable artifact: a spec, a plan, the code, the tests, a QA pass, a retro. Those artifacts do not evaporate when the PR merges. They live in a docs repo as a permanent trail, so every feature we ship carries a written record of what it was for, how it was designed, and how it was checked.

We did not invent the skeleton. CasaFlow is built on Jig, an open-source workflow framework the Duro engineering team built for their own AI-assisted development and then released under MIT. Zak and I had always meant to build something like this, and Jig turned out to be a better starting base than a blank repo. The name is what sold me. Anyone who has done machine work knows a jig is the unglamorous fixture that makes precision repeatable instead of heroic. You are not a better machinist with one. You just stop producing parts that are subtly wrong in ways nobody notices until assembly. Swap "machinist" for "engineer with an AI agent" and you have the entire thesis of this post.

What it does

The pipeline runs from discovery to a shipped PR to a retro, and I will not name all eighteen commands, because that is a reference manual and this is not. What matters is where the gates are.

Work starts with a kickoff that classifies the task and files the ticket. Then, before a line of code exists, /brainstorm forces the design conversation, and it is a hard gate. No code gets written until the design is approved. From there a spec pins down acceptance criteria, non-goals, and a test plan, and a plan breaks that into small, test-first tasks with real file paths.

Building is not one big agent. /build dispatches focused agents, in parallel when the work allows, each one scoped to a piece. Review works the same way. /review sends in a swarm of specialist reviewers, each looking at exactly one thing: security, error handling, or dead code; each scored; the whole thing aggregated into a confidence number. A separate pass grades the tests on coverage and mutation testing and hands back an actual letter grade.

The piece that ties it together sits between the stages. /approve is a comprehension gate. Before you move from one stage to the next, you have to answer three questions that prove you understand what the stage produced. Not that it passed. That you understood it. You cannot hand-wave through a gate that asks you to explain the thing you just made.

Its twin is /verify, which demands evidence before anyone gets to claim something is done. Between the two, the system asks the only questions that actually matter: do you understand this, and can you prove it works. Neither one cares whether you are a person or an agent.

And when something does slip through anyway, /postmortem does not just log it. It patches the skills themselves, so the specific way we got burned this time becomes a way we do not get burned again.

Why it exists

Two things separate this from "write code with an AI and hope."

The first is the gates. Every stage is blocked on either an approved artifact or answered comprehension questions. Neither a person nor an agent can skip the thinking steps and hand you vague, plausible, unreviewable work, because the gate will not open until the thinking is on the page.

The second is the specialists. Build and review are not one monolithic model trying to do everything at once. They are fleets of focused agents, each dispatched at its own narrow job, in parallel. A reviewer looking only for async-safety problems finds things a general reviewer reads right past.

The deeper payoff is the one I did not expect. Process stops being a tax you pay on top of the work and becomes a byproduct of doing the work. We do not write specs because a policy says to. Every feature has a spec, a plan, tests, and a retro because the workflow produced all of them on the way to the merge. The documentation is the exhaust, not a second job.

What it bought us

Concretely: a small team shipping more than two hundred tickets a month, a release cadence pulled down to at least every two weeks, and new engineers opening real pull requests in their first week. That last one is the tell. They did not have to absorb a year of tribal knowledge first, because the standards live in the pipeline, not in someone's head.

And it is not finished, which is the part I would underline if I could only keep one sentence. CasaFlow is a living tool, and it evolves as our workflow does. We recently added a recon skill that searches the codebase, Jira, and open PRs for adjacent work before anyone starts building, so nobody spends a day solving a problem a teammate solved last week in a different corner of the repo. We pulled Claude Design into the flow to round out the workflow from idea through interface rather than stopping at the API boundary. Every one of those additions came from someone hitting friction and saying so at a retro. A workflow framework that stops changing is just process debt with better branding.

Where this is headed is a team where the workflow itself carries the quality bar. The gates catch the preventable mistakes, the specialists catch the subtle ones, and the humans spend their judgment where it actually belongs, on the decisions a checklist can never make for you. The release train made releasing something you can feel. CasaFlow makes quality something the process refuses to skip.

Gates, not vibes. That turns out to be the whole difference between shipping fast and just breaking things fast.

A dreaded release process, a deadpan British rail announcer, and what happens to "worth building" when delight costs days instead of months.

A voice comes over the speakers in the office. It is calm, clipped, and unmistakably British.

"This is the 14:05 service to Production Terminal, calling at Staging Parkway and Demo Central. Please mind the gap."

A steam whistle sounds. Somewhere, a deploy has just left the platform.

Yes, our release pipeline talks. It announces its own departures, calls its stations as it goes, and rings a bell when it pulls into production. It is also the most reliable, least stressful release process we have ever run, and we built the whole thing in a matter of days.

Those two facts are the same story. Here is how they became one.

The problem was never the tooling

For a long time our releases had a single point of failure, and it was me.

The process was ad hoc and quietly nerve-wracking, the kind of thing where you clear your afternoon and hope. Nobody wanted to own it, so by default it fell to the person with the most access and the most to lose, which is a polite way of saying it fell to the CTO. Every release was a small tax on the one person who could least afford to be the bottleneck.

Jez Humble has a line I have never been able to shake: if something is painful, do it more often, and bring the pain forward. The logic is that frequent, early exposure to the scary thing forces you to make it not scary. It is excellent advice, and almost nobody follows it, because "do the dreaded thing more often" is a brutal sell to actual humans. You cannot mandate enthusiasm for pain.

So we had the diagnosis right and the adoption problem unsolved. The releases were painful and un-owned. Telling people to do them more often was not going to work. We needed the pain to move forward on its own, carried by something people actually wanted to touch.

The fix started as plumbing and became a train

Underneath the whimsy is a staged pipeline that promotes a release one environment at a time: trunk to staging to demo to production. The source of truth is git, not a ticket board that went stale three sprints ago. Each stage runs an automated health check, and then it stops and waits for a human to look at it and say go. Every promotion needs two things: an automated reviewer that has to pass, and a human approval that cannot be skipped. No self-merge, no exceptions.

That is a correct and slightly abstract description of a release pipeline, and abstract is exactly the problem with most of them. Nobody carries a warm mental model of "promotion gate three." So we gave the pipeline a model people already had. Environments are stations. A release moves down the line, calling at each one. A merge is a departure. Production is the terminus, the end of the line. Suddenly a complicated staged rollout is legible to anyone who has ever stood on a platform. You can see where the train is, where it is going, and what has to happen before it moves.

We packaged the whole thing as a rotating toolkit the team runs itself: a set of Claude Code slash commands anyone on rotation can drive end to end, no CTO access required. We call it CasaPerks Rail. It did not appear from nowhere. It stands on work we had already done building out the pipeline with Claude, and on the muscle the team had built with CasaFlow, the development-side plugin Zak built and the subject of a post I still owe you. The bottleneck disappeared the moment the process stopped needing me to operate it.

Then we gave it a voice

CasaPerks Rail narrates itself out loud as it runs, in the deadpan register of a National Rail announcer who has seen everything and is surprised by none of it. Real train sounds ride underneath: a steam whistle, the chug of pulling out of a station, a platform chime, an arrival bell. Every environment is a named platform. The announcements are real.

When a release departs: "This is the 14:05 service to Production Terminal, calling at Staging Parkway and Demo Central. Please mind the gap."

When a stage is green and waiting on a human to approve the merge, it makes a last call: "...all checks are green; this service awaits the conductor's merge."

When it arrives: "This is Production Terminal. This train terminates here."

And when something fails, it delivers the news the way only a British rail announcer can, which is to say with total calm and zero comfort: "We are sorry to announce the service is delayed by approximately one sprint. This is due to leaves on the line."

The audio is best effort. It is the one part of the system allowed to fail. If text to speech hiccups or a sound file does not load, the release does not care and does not stop. The train runs whether or not anyone is listening. That distinction matters, and I will come back to it.

The voice is not decoration. It is the adoption strategy.

Here is the part I did not expect.

Remember the unsolved problem: how do you get people to willingly own a process they used to dread. It turns out the answer was to make the process a genuine pleasure to operate. People want to run the train. Rotating ownership stuck, not because we wrote a policy, but because taking your turn as conductor is actually enjoyable. The pain moved forward exactly like Humble said it should, except it stopped feeling like pain.

The metaphor does real work too. A new engineer understands the entire pipeline in one sentence, because they already know how trains work. And the audio changes the texture of the room. Release status stops being something you go check and becomes something you feel. You hear the whistle and you know a deploy just left. Ambient awareness, delivered by sound effect.

None of this replaced the rigor. The staged environments, the automated verification, the human approval gates, the git source of truth, all of it is still there and still strict. The whimsy rides on top of a genuinely careful system. Fun did not make the process less serious. It made a serious process pleasant to operate, which is the only version of serious that people actually keep doing.

The train picked up a passenger

Our Customer Activation team asked to get in the loop. They wanted to review release notes and test on staging before a release moved on. That is a classic promotion gate, and the boring version is an email and a prayer. Instead we made them a platform. When the train pulls into staging, it posts a live departure board into their Microsoft Teams channel (the same trick works in Slack, or wherever your team lives), styled like the board you would actually stand under in a station, showing which stop the train is at and the notes waiting for review. It pings them when the train is sitting on the platform and ready, and pings again when it departs.

Same principle as the audio. Status you can see at a glance, in the place you already are, instead of status you have to go hunting for. The gate got more rigorous and more pleasant at the same time.

Now the part that changed how I think about building software

A talking release pipeline with real train sounds and a live station board in a chat channel is, by any traditional accounting, a preposterous thing to spend engineering time on. Picture bringing "let us add a British train announcer to our deploy process" to a sprint planning session in 2019. It dies in the room. The cost is real and the benefit is soft, and soft benefits lose to hard costs every single time.

That math is broken now. The entire system, architecture, implementation, tests, and docs, came together across a handful of days, pair-building with an AI coding agent in the middle of live releases. Not months. Days. And that is the whole argument. When a delightful, non-essential flourish costs months, you never build it, and you are right not to. When it costs days, the calculation inverts.

This is what I most want other engineering leaders to sit with. AI-assisted development did not just make us faster at the work we were already going to do. It changed the category of what is worth doing at all. The announcer, the real train sounds, the station board, the last-call announcement: each one, on its own, would have died in a planning meeting a few years ago, and together they are exactly what made the thing work. A whole class of ideas that used to be filed under "nice, but never" is now simply affordable. Delight got cheap. The train announcer is not a story about a train announcer. It is a story about a cost curve moving far enough that whimsy became a rational engineering decision.

And we built it in the open

Not in a lab. Release by release, in the middle of actually shipping.

The first version came out of a single release. I took notes as we shipped, dropped them into Claude as we went, and that running commentary became the frame for the first cut of the plugin. We ran a real release with it, then spent an afternoon refactoring what we learned. We ran the next release on the refined version, tuned it live with Claude, and folded those notes in the next morning. Midway through one of those releases, I had Claude spec out the frankly weird idea of a train conductor narrating the whole thing. After that release, we folded in the rest and gave the train its voice. Like CasaFlow, it is a living thing, never quite finished, which is exactly the point.

Because all of this happened during real production releases, the fun kept dragging real problems into the light. We swapped the synthesized train sounds for real recorded horn and chug mid-run when the fake ones were not landing. Dogfooding the pipeline surfaced a genuine gap in how it verified web deploys, a real bug hiding behind the fun, fixed in the same session. The departure board threw a cryptic error against the real flow, and we debugged it live in minutes.

That is the pattern worth noticing. Playing with the delightful parts kept surfacing real problems, and the same velocity that made the delight cheap made the fixes immediate. The fun was not a distraction from the engineering. It was a flashlight.

What to actually take from this

Step back and the scoreboard is a little absurd. A CTO and four engineers, Zak, Sam, Temur, and Nomin, built a self-operating, team-owned, fully staged release system with automated verification and human gates, and also gave it a personality, in the time it used to take to write the design doc. What is left is a process that is serious underneath and playful on top, and a team that sweats the craft and keeps a sense of play at the same time. Those two things were never in tension. We were just always too busy to afford the second one.

None of what to steal here requires a train.

Find the process on your team that everyone dreads and nobody owns. It is usually the high-stakes, low-glory one that quietly defaults to your most senior person. That is your candidate.

Make it legible. Borrow a metaphor people already understand, so the complicated thing fits in one sentence. Half of dread is just not holding a clear mental model of what is happening.

Make it pleasant to operate. Not gamified with points and badges, which everyone sees through, but genuinely enjoyable in a way that fits your team's actual sense of humor. Enjoyable processes get owned. Miserable ones get avoided, then they rot, then they break.

And re-run the math on every "nice, but we would never build that" idea you have shelved over the years. The velocity is different now. A lot of those ideas quietly moved from months to days while you were not looking, which means a lot of them moved from fantasy to this afternoon. The flourish that makes the dreaded thing bearable is probably cheap enough to build today. That is the real unlock. Not the automation itself, but the permission to make the work delightful, backed by the fact that delightful finally costs almost nothing.

We are not done, by the way. The announcer already has a clean seam for an external trigger, which means the voice does not have to live in a laptop. The dream is a physical departure board on the office wall, or, if we are being honest about the dream, an animatronic conductor who calls the stations out loud when a release leaves for production. That one will take longer than days. Some flourishes are still worth the wait.

A 90-day reflection on a new engineering team, the data that proved my instincts wrong, and what AI actually changed.

Ninety days ago, I rebuilt my engineering team from scratch. Four engineers, one shared start date, a clean slate. I had spent weeks on the hiring: more than forty candidates screened against a deliberate read of how each one actually worked with AI, take-home challenges, the whole process. I went in with high expectations and a healthy fear that I had over-promised them to myself.

Thirty days in, the team had already shipped a real release. Not a demo, not a staging branch nobody trusts. Production. And the volume and quality of what they were putting out was higher than any team I have led.

Here is the part I am not proud of. My first reaction was not pride. It was suspicion.

I have been doing this long enough to have a reflex, and the reflex said: output this good, this fast, this early, is output you are borrowing against. Velocity at that level usually means a corner is being cut somewhere you cannot see yet. Speed today, repaid as incidents two quarters from now. And when a team has AI in the loop, the reflex gets louder. The easy story is that the AI is writing checks the codebase will eventually have to cash, and that the bill comes due right around the time everyone has stopped paying attention.

So I watched. Closely. Looking, if I am honest, for the thing that would prove the speed was a mirage.

It never showed up. Instead, the numbers got better the longer I looked.

Across the quarter, merged throughput roughly doubled. That alone would have fed my suspicion. But the rest of the picture is what changed my mind. Review coverage went from 24% to 85%, which is to say the team went from mostly self-merging to actually reviewing each other's work. The revert and hotfix rate more than halved. The share of changes that touched tests tripled. We went from no systematic per-feature documentation to a written trail behind every feature, produced as a byproduct of how the work now flows. The output did not just grow. It grew while getting more rigorous, not less.

My favorite number is the one that looks bad until you understand it. Median time-to-merge went up, from a few minutes to most of a day. Before, a typical change was merged in minutes because no one was reviewing it. After, changes wait because they are being reviewed. Slower in that one metric is the entire point.

I had seen the opposite of this before, and that comparison is what finally landed it for me. At a previous company, standing up real CI/CD and end-to-end testing from a ramshackle starting point took us the better part of a year. This team did the equivalent in under a month. I want to be careful about what that does and does not mean, because the engineers I worked with before were sharp, and this is not a story about them being slower or worse. The difference was not the caliber of the people. The difference is that this time, the team had Claude to pair with, and smart engineers were finally able to move at the speed of their own thinking.

That reframe is the whole lesson, so let me be plain about it. I had read the speed as fragility. The speed was the payoff of structure. The thing I almost slowed down in order to feel in control was the thing my own architecture had made possible.

AI does not make a team fast in a way that is inherently dangerous. It makes a team fast, full stop. Whether that speed compounds or collapses depends entirely on the structure it runs through. Give it specs, comprehension gates, and a team that owns the why, and the velocity is durable. The reason this team can safely change code that AI helped write is that no stage advances until the person responsible can explain it. That is not bureaucracy. That is the thing standing between "fast" and "fast until it isn't."

My own job through all of this was smaller than it sounds and harder than it looks: set the structure, then get out of the way and clear whatever was blocking them. Most days, the highest-leverage thing I did was unblock someone, not out-produce them.

My distrust was the wrong instinct. But interrogating it was the right move, because it forced me to find the actual reason the team was working instead of either congratulating myself or panicking, both of which would have taught me nothing. The lesson I am taking out of these ninety days is not "trust your team," even though I should have. It is more specific. When good work shows up faster than your experience says it should, the question is not "what is about to break." It is "what did we build that made this possible, and how do we protect it." That second question is the entire job now.

And it is where this goes next. We spent a quarter using AI to rebuild how we ship. The natural next move is to turn that same expertise on the product itself, and build the kind of AI-driven capability into what we sell that we just spent ninety days learning how to wield internally. The force multiplier did not stop at the team. It is becoming the product.

I spent thirty days waiting for a team this good to fall apart. It didn't, because falling apart was never in the architecture. I just had to stop distrusting the evidence long enough to read it.

I've been more productive in the last few months than at any point in my career. My team ships faster, I personally get through more in a day than I used to in three, and the gap between "I have an idea" and "the idea exists" has collapsed to almost nothing.

I'm also more exhausted at the end of the day than I've ever been.

Both of those are true, and I think the relationship between them is the actual story — not the productivity, which everyone's already writing about, but the tax that nobody mentions.

The candy store

The first thing I had to admit is that some of this is my own fault.

When the cost of attempting something drops to near zero, you attempt more. Not more of the work you were already doing — more things, period. The ambitious refactor you'd have deferred for a quarter. The "while I'm in here" cleanup. The third approach to a problem because trying it is now cheap. The tangent you'd never have chased when chasing it meant two days, but will absolutely chase now that it means twenty minutes.

I'm a kid in the candy store. The abundance is real, and my response to abundance is to consume more of it. A lot of my fatigue isn't that the work got harder. It's that I gorged.

That's worth naming honestly, because it's the part of the problem that's actually mine to manage. The tool didn't make me do the extra thing. I did, because I finally could.

The rest that used to be hidden

But the candy store only explains part of it. The rest is structural, and it took me a while to see.

My old workflow had recovery baked into it without my ever noticing. Writing out boilerplate I already understood in my head. Waiting on a build. Googling an error message. Typing code that was a foregone conclusion. Those weren't the valuable parts of my day — but they were low-intensity parts. Micro-recovery, scattered through every hour. Little stretches where my brain coasted.

That's exactly the work that's gone now. I closed all the gaps. And what's left when you remove the easy stretches isn't less work — it's a concentrate of the hard parts, with the rest stops removed.

Decision fatigue is the real bill

And the hard parts are almost all judgment.

My job used to be a mix of producing and deciding, with long runs of production between the real calls. Now it's deciding, more or less continuously. Review this output. Catch the subtle thing that's wrong in a way that looks right. Choose the direction. Accept, reject, redirect. Accept, reject, redirect. All day.

Decision-making draws down a finite resource — anyone who's ever made a great call at 9am and a terrible one at 6pm knows this in their body. I didn't reduce the number of decisions in my day. I multiplied them and packed them tighter. My decision density per hour went somewhere it's never been, and that's the bill that shows up at 5pm as a kind of tiredness that sleeping early doesn't fully fix.

Here's the reframe I keep coming back to: AI didn't reduce the work. It removed the easy work. I'm not jogging a marathon anymore. I'm running sprint intervals — covering far more ground, and paying far more per mile.

Why this is an operational problem, not a personal one

If I'm feeling this, my team is feeling it too.

That's the part that should worry any engineering leader who's celebrating a productivity number right now. "We tripled our output" can quietly also mean "we tripled everyone's cognitive load." Those are not the same sentence, and the second one doesn't show up in any dashboard. It shows up in burnout, in declining decision quality late in the day, in people who look fast on paper and feel fried in person.

I've said for a while that I don't want hero mode on my team — that a pace you can only sustain by grinding isn't a pace, it's a debt. AI makes that principle more important, not less, because it removes the natural friction that used to cap how hard a day could be. The brakes are gone. Pace is now a choice you have to make deliberately, because the work will no longer make it for you.

So is this permanent?

I genuinely don't know yet, and I'd rather say that than pretend.

Some of it is a transition cost. I'm still building the muscle for orchestrating this much output — the deciding gets cheaper as the instincts sharpen, the same way any new skill stops being exhausting once it's automatic. That part should fade.

But some of it looks structural. A workday made of pure judgment with the easy stretches engineered out may just be more tiring than the old one was, full stop. If that's true, the answer isn't to slow the tools down. It's to deliberately rebuild the rest the workflow used to give us for free — and to stop treating raw output as the only number that counts.

I'm still figuring out the candy store part. But I've stopped pretending the exhaustion is a sign I'm doing it wrong. I think it might be a sign I'm doing it right, and haven't yet learned how to pace it.

A day and a half ago I was evaluating budgeting apps. I had a spreadsheet method I'd been using for years that actually worked. The problem was the spreadsheet itself: a manual reset every month, no clean way to bring my wife into it (the budget logic was baked into the layout, and building a real UI on top of a spreadsheet wasn't worth the effort), and after a few years of history it had grown unwieldy enough that I couldn't easily run queries against my own data. So I went looking.

YNAB wanted me to adopt envelopes. Monarch wanted me connected to my bank accounts. Copilot wanted a subscription. The open source self-hosted options wanted me to learn their data model. Every option I evaluated wanted me to abandon the method I had — a method that worked — in exchange for their interpretation of how budgeting should feel.

At some point I just asked Claude: is it crazy to just build my own?

A day and a half later I had it. Built around my spreadsheet logic. Not connected to any bank. Not hosted anywhere external. Used every day.

That question — is it crazy to just build my own — is the article. Five years ago, yes. It was crazy. Today, in a growing number of cases, it isn't anymore. And the gap between those two answers is doing more to reshape software than most people are paying attention to.

The 80s called and they were budgeting

Personal finance software is not a new genre. It's one of the original genres.

Managing Your Money, by Andrew Tobias, shipped in 1984. Dollars and Sense before it. Quicken at the tail end of the decade. The software industry then was a much more distributed scene than today — dozens of small publishers shipping diskettes by mail, most of them now footnotes. The names that dominate tech now weren't yet the names that dominated tech. And before any of those apps, people were just building their own budgets in VisiCalc and Lotus 1-2-3, because that's what you did with a home computer. When the question came up — why would I buy one of these things? — balance your checkbook was right up there with play games as a top answer.

The 80s and early 90s home computer era was, in significant part, about personal software. You typed BASIC programs from magazines. You modified them. You wrote small utilities for your own life. The software you ran fit your life because you'd built it yourself, or you'd at least chosen it from a small enough pool that you knew which one matched your situation.

The decades since trained us out of that. Not by accident. Building software got increasingly punishing for individuals while consuming it got increasingly easy. SaaS won the consumer software war fair and square: cloud sync, mobile apps, multi-device, automatic updates, infrastructure you didn't have to babysit. In exchange you adopted whatever worldview the software embodied, because building your own version was a nights-and-weekends project measured in years.

That was a reasonable trade for a long time. For a lot of software it still is.

SaaS is not dead

There's a strain of AI hype right now insisting that vibe coding kills SaaS. It doesn't. I run a SaaS company. I'm not announcing my own funeral.

What actually happens is more interesting. SaaS retreats to the layers where it always belonged, and the personal layer comes back to the user.

SaaS is the right shape for multi-user coordination — anything with shared state across an organization, or a network effect, or a methodology that has to be consistent across everyone using it. No one is vibe coding a resident rewards platform that integrates with property management systems and handles payments. The whole point is that everyone in the network uses the same one.

SaaS is the right shape for compliance, security, and infrastructure burden. SOC 2, PCI, uptime guarantees, audit trails — the unglamorous load-bearing work my company spends real money on. Personal software gets to skip all of that precisely because it's personal. One user. No bank connection. No external hosting. That's a feature of personal software, but it's also why it doesn't scale to anything with real stakes for other people.

SaaS is the right shape for methodology-as-product. YNAB users love YNAB because the envelope method works for them and they want the software to enforce it. Someone adopting a new framework should absolutely buy the SaaS — the worldview is the value. Build-your-own only makes sense when you already have a method that works and the software is the friction, not the framework.

And SaaS is the right shape for infrastructure problems at scale. Stripe, Plaid, Twilio, the cloud providers themselves. No one is rebuilding payments. That layer is more entrenched than ever, and should be.

So this isn't a SaaS-is-dead piece. It's a more boring claim: SaaS expanded into the personal layer over the last twenty years because building software was too expensive for individuals, not because SaaS was the right shape for personal software. The fit was always a little strained — you've felt it every time an app told you to change how you think about something so it could help you. Now the economics correct. The personal layer goes back to the user.

Two flavors of personal software

The budget app was the cleanest version of this. Built the whole thing. The methodology was the personal part — my spreadsheet logic, my categories, my way of thinking about cash flow. No commercial option could capture that, because none of them are trying to. They're trying to sell me theirs.

Simple Chores is the other flavor, and it makes a more interesting point.

We wanted a chore tracker that fit our household — me, my wife, eventually our daughter. Something utilitarian. Just remind us what needs doing. Every option I looked at either ran on the assumption that families need gamification, scoring, leaderboards, dollar bounties for taking out the trash — or was so complex it required a separate mental model just to set up. The Home Assistant community options were either too bloated or built around scheduling logic I didn't want. None of them were really for the way we live. Chores aren't a competition in our house. They're not a market. They're the things we do to keep our home running and to function as a family. I called the app Simple Chores. The manifesto is in the name.

I didn't build the whole thing. I built it as a Home Assistant app, leveraging HA's room model, its people model, its auth. Home Assistant had already done the household-modeling work better than I'd ever want to redo. What I built on top was the part that was actually personal: how chores get assigned, what counts as done, what the interface feels like when one of us walks into the kitchen. And — being honest — partly because it sounded fun to build something I had no clue how to build.

These are two different build/buy decisions at two different layers. The budget app needed to own its full stack because the methodology was the whole point. Simple Chores stood on top of an existing platform because the platform was already exactly right for the layer underneath. Both are personal software. Both fit my life because I made them fit. Neither would have been a reasonable use of my time five years ago.

The interesting practice is not write everything from scratch. It's architect which layer is yours. Where does my mental model need to be load-bearing, and where can I gratefully use someone else's work?

The sameness is the feature

One common complaint about AI-assisted coding right now is that the UIs all look the same. Same fonts. Same gradients. Same component patterns. People treat this as evidence that something is missing — that the work is generic, that the soul is gone.

I think the opposite. The sameness is the feature.

In the BASIC and CP/M and DOS days, your UI was the default character set the machine handed you. Box-drawing characters. Inverse video. A handful of colors if you were lucky. You didn't build a visual identity, because building a visual identity wasn't on the table. You built the logic. The thing that did the thing.

That was a constraint, and it was generative. It pushed your design energy into the part of the software that was actually personal — the model, the methodology, the way it thought about your data. The visual shell was given, and the given-ness was a relief.

The AI sameness is the same gift. Personal software doesn't need a visual identity. It's not competing for attention in an app store, not trying to convey brand values, not getting reviewed on The Verge. It's a thing one person uses to do a thing. Letting the AI hand you a clean, competent default UI means you can spend all your attention on what's actually personal: the methodology, the categories, the way the thing fits your head.

The default floor has risen. Everything looks reasonably designed out of the box. For commercial software that's a problem — you need to differentiate. For personal software it's exactly right. The shell is given, so you can focus on what's yours.

The sophomore slump parallel

This is also a film school thought, so bear with me.

A first feature is often tight, weird, specific. Made on constraints — money, time, a single location, the actors you could get. The constraints aren't disciplinary. They're generative. They force decisions. They give the work a shape.

The follow-up gets ten times the budget and falls apart. It has to serve every audience the first one earned. It has to justify the investment. It loses the constraints that made the original work.

Commercial software is structurally a sophomore project. It has to serve every user, every methodology, every edge case, every potential paying customer, every accessibility requirement, every enterprise procurement checklist. That's not a criticism — that's the deal. But it explains why the experience of using commercial software so often feels bloated. It is.

Personal software stays in debut mode. Scoped, weird, specific. Mine has exactly the features I use, in exactly the arrangement that fits my head. That's not because I'm a better designer than the YNAB team. It's because I have one user.

The part nobody talks about

There's one more thing I want to surface, because the productivity framing has eaten the entire AI discourse and it's making us miss something.

I built Simple Chores partly because it was fun. I'd never done that kind of project before. I had no idea what I was doing with Home Assistant's app framework. It was an evening hobby. Same energy as typing BASIC programs out of a magazine to see what they did.

That kind of building — speculative, unprofitable, just-to-see — was a huge part of why the home computer era mattered to people who lived through it. It wasn't all productivity. A lot of it was play. You built a thing because you wanted to know if you could.

AI-assisted coding has brought that back, and almost no one is talking about it because the discourse is locked into ten-engineers-replaced-by-one framing. Some of the best output from this technology, in my own life, has nothing to do with productivity. It's the return of personal software, yes. But it's also the return of personal programming — the practice, the play, the tinkering. The part where you build something for yourself just to see what happens.

That part is harder to put in a deck. But it's real, and if you've felt it, you know.

So, is it crazy to just build my own?

For most things, still yes. Build your own payments processor: crazy. Build your own CRM: still crazy. Build your own collaboration tool for a team of fifty: crazy. SaaS continues to do exactly what SaaS is good at, and the AI hype declaring otherwise will look as silly in three years as the no-code hype did.

But for the personal layer — the budget that has to fit your method, the chore tracker that has to fit your household, the dozen little utilities that fit your life and only your life — the answer has quietly flipped.

A day and a half. Spreadsheet logic, my categories, my interface. Used every day.

It's not crazy anymore. That's the story.

What the middle looks like — and what it tells you about hiring engineers in 2026.

I just wrapped up hiring four engineers for a team I'm building from scratch. Forty-plus candidates screened. Multiple rounds. Take-home challenges that required AI-assisted development. And a discovery I wasn't expecting: AI proficiency has become the single most revealing signal in our entire interview process — more telling than years of experience, more predictive than pedigree, and almost impossible to fake.

We made AI fluency a non-negotiable from day one. Not preferred. Not a bonus. Required. That decision alone filtered our applicant pool in ways I didn't anticipate. But the real surprise wasn't who it filtered out — it was the spectrum it revealed among the people who remained.

All four engineers we hired shipped PRs in their first week. That outcome — and the process that produced it — is what this post is about.

The Five Strata

After weeks of interviews, take-home reviews, and presentations, a clear taxonomy emerged. Every candidate we evaluated fell into one of five categories.

Stratum 1: Non-Users

These candidates don't use AI tools at all. Some by choice, some by unfamiliarity. We didn't interview them. This isn't a value judgment on their engineering ability — it's a practical one. Our workflow is built around AI collaboration. An engineer who doesn't use AI tools would be working at half the velocity of the rest of the team from day one, and they'd be learning a new paradigm while simultaneously learning our codebase, our product, and our culture. That's too many ramps at once.

Stratum 2: The Reluctant Adopters

"I use it for boilerplate and tests."

This was the most common answer in early screens, and it's a tell. These engineers have tried Copilot or ChatGPT. They've asked it to write a unit test or scaffold a component. But they haven't integrated AI into how they think about building software. It's a convenience tool sitting next to their IDE, not a collaborator shaping their architecture decisions.

The reluctance sometimes comes from legitimate concern — about code quality, about understanding what's being generated, about intellectual honesty. I respect that. But in practice, these engineers are leaving 60-70% of AI's value on the table, and they don't know it yet.

Stratum 3: The Green Users

These candidates use AI more aggressively — Copilot autocomplete, ChatGPT for debugging, maybe Claude for longer explanations. But they lack the architectural thinking to guide the tool effectively. The AI suggests something, they accept it. It goes off the rails, they don't know why. They can't distinguish between a good suggestion and a plausible-sounding bad one.

This is the most dangerous stratum for hiring because it looks productive. The code ships. The take-home gets submitted. But when you ask them to walk through a design decision, you get silence or a restatement of what the AI told them. The human isn't driving — they're just holding the steering wheel.

One candidate submitted a take-home that was clearly AI-generated in a single pass. No iteration, no architectural decisions, no evidence of human judgment. The output was functional. It was also completely undifferentiated from what any other candidate could produce by typing the same prompt. That's not engineering. That's transcription.

Stratum 4: The Collaborators

This is who we hired.

These engineers use AI as a genuine thought partner. They prompt it with architectural questions and evaluate the options it presents. They accept suggestions they agree with, modify the ones that are close but not right, and reject the ones that don't serve the design. They can articulate why they made each of those decisions.

One of our strongest candidates — a fresh college graduate — submitted a take-home with a dedicated slide documenting his AI workflow: what he accepted, what he modified, what he rejected, and the reasoning behind each. He used Claude to generate architectural options, chose the ones that fit the domain (a financial ledger that needed auditability and idempotency), and pushed back when the AI suggested unnecessary complexity. The output wasn't just good code — it was evidence of good thinking.

That's the signal. Not "do you use AI?" but "can you think clearly while using it?"

Stratum 5: The Vibe Coders

On the far end of the spectrum are candidates who've gone all-in on AI but lost the plot entirely. They can prompt their way to a working prototype, but they can't explain the architecture. They can't debug without AI assistance. They can't make a design tradeoff because they've never had to — the AI made all the decisions and they just kept saying yes.

Vibe coding produces impressive demos and fragile systems. In a startup where every engineer's decisions compound into the foundation everything else gets built on, that's unacceptable. We need people who understand what they're building, not just people who can describe what they want built.

The Gap That Matters

The critical gap in this taxonomy is between Stratum 3 and Stratum 4. That's where most candidates live, and it's the hardest transition to screen for. Both groups use AI regularly. Both produce working code. The difference is in the relationship between the human and the tool.

Stratum 3 engineers follow the AI. Stratum 4 engineers lead it.

You can't detect this difference from a resume. You can barely detect it from a traditional technical interview. The only reliable way we found to surface it was a take-home challenge that explicitly required AI usage and a follow-up presentation where candidates walked through their process — not just their output.

When a candidate shows you their AI workflow and you can see the moments where they exercised judgment — where they chose Option A over Option B because it better served the domain, where they caught an AI suggestion that was technically correct but architecturally wrong, where they rejected a recommendation and explained why — that's when you know you've found a Stratum 4 engineer.

The Enterprise Lag

Most large organizations are still working out their relationship with AI development tools. Legal teams are reviewing IP implications. Security teams are evaluating data exposure. HR departments haven't updated job descriptions to reflect a world where AI fluency is a meaningful axis of engineering capability.

That's not a criticism — those concerns are legitimate, and bigger orgs have more surface area to protect. But it does create an asymmetry. Smaller teams that build AI-native hiring processes now will have a meaningful head start on talent acquisition. Not because they have bigger budgets or better brands, but because they're asking better questions.

The Stratum 4 engineers exist. They're shipping right now. The question is whether your hiring process can recognize them.

The Hiring Framework

For engineering leaders thinking about this, here's what worked for us:

Make AI fluency a requirement, not a preference. Put it in the job posting. Mention it in the screening call. Make it clear this isn't optional. This alone will filter your applicant pool in useful ways.

Design take-home challenges that require AI collaboration. Don't just allow it — require it. And ask candidates to document their process. The documentation is more valuable than the code.

Evaluate the workflow, not just the output. A polished app built by a Stratum 5 vibe coder looks identical to a polished app built by a Stratum 4 collaborator — until you ask them to present their decision-making process.

Look for the reject signal. The strongest indicator of a Stratum 4 engineer isn't what they accepted from AI — it's what they rejected and why. Anyone can say yes to a good suggestion. It takes real understanding to say no to a plausible one.

AI Still Needs an Architect

The throughline of everything I've learned in this hiring process comes back to a simple principle: AI is an extraordinary tool, but tools don't make decisions. Architects do.

The engineers I hired aren't replaceable by AI. They're amplified by it. They use AI to move faster, explore more options, and ship with higher quality — but the judgment, the taste, the domain understanding, the ability to say "this is the right approach for our product and our users" — that's irreducibly human.

For now.

And "for now" is exactly why you want engineers who can think clearly with AI rather than just use it. As these tools get better, the gap between Stratum 3 and Stratum 4 won't shrink. It will widen. The engineers who learn to lead AI today will be the ones capable of leading whatever comes next.

The ones who just follow it will be following something else.

Nate Craddock is CTO at CasaPerks, where he built an engineering team from scratch with AI fluency as a core requirement. He writes about engineering leadership, AI-assisted development, and the intersection of human judgment and machine capability at natecraddock.com.

There's a version of this job I remember clearly. A bug gets reported. You open New Relic, start building queries, copy transaction IDs into a Slack message, open the codebase in a separate tab, grep around, form a hypothesis, test it locally, go back to New Relic to validate, write a fix, deploy, and cross your fingers. On a good day, that's two hours. On a complicated day, it's two days.

New Relic was already a superpower. Having real production telemetry — actual response times, error rates, slow transaction traces — meant you were operating on evidence instead of instinct. I've been a believer for years. But even with great observability data, there was always friction: the context switch between the dashboard and the codebase, between the telemetry and the database, between what the system was telling you and where in the code it was actually happening. You'd accumulate the picture piece by piece, holding it all in your head.

What's changed recently is that the picture assembles itself.

The Setup

I run engineering at CasaPerks, a residential engagement and rewards platform built on NestJS, MongoDB, and React. Our stack is instrumented end-to-end with New Relic. Last year I started using Claude Code — Anthropic's agentic CLI tool — as my primary development environment. And once New Relic released their MCP server in beta, something clicked into place that I'm still processing.

MCP (Model Context Protocol) is a standard that lets AI assistants connect to external data sources and tools. In practice, it means Claude Code can query your New Relic account directly from the terminal — no dashboard switching, no manual NRQL construction. It can also connect to MongoDB's MCP server, which means it can inspect your actual schemas, run explain plans, and audit indexes. Combined with full access to the codebase, you have an agent that can simultaneously see your production telemetry, your database, and your code.

That's not a modest upgrade. That's a different category of debugging.

The Incident

During internal testing, we caught an error on the CSV user import flow. The upload appeared to fail — the frontend showed an error after about 60 seconds. But something was off: when we checked the system, the users were there. The welcome emails had gone out. The operation had completed. The error was a lie.

In the old workflow, this kind of misleading symptom is expensive. The error message doesn't point anywhere useful. You have to start from scratch: reproduce it, find the relevant trace in New Relic, identify which part of the operation is slow, cross-reference with the code, trace the call chain from controller to service to external dependency.

Here's what actually happened instead.

I opened a Claude Code session with the New Relic MCP and MongoDB MCP both active, and the full codebase in context. I described what the property manager had reported. Claude queried New Relic production data directly — no dashboard, no copy-pasting — and surfaced the relevant transaction traces for the bulk import endpoint. The endpoint was completing successfully on the backend. Response times for larger imports were regularly exceeding 60 seconds, which was tripping the load balancer timeout. The frontend never received the response and interpreted silence as failure.

That's the what. Then we went to the why.

Claude read through the user service and traced the bulk import method. The problem was immediately visible: for every user in the CSV, the code was calling the welcome email function individually inside the loop. Each call was a separate HTTP request to the Mailgun API. For a 50-user import, that's 50 sequential round trips to an external service — at 200-500ms each, the math is ugly fast.

The fix was straightforward: collect all users flagged for welcome emails into an array, then make a single bulk email call after the loop completes. The bulk method already existed in the codebase — it was actively used by a resend-welcome-email endpoint and a cron job, with full test coverage. It was never wired up here.

That fix was identified, implemented, and deployed in a single session.

The Bonus Find

Here's the part that still gets me.

While Claude was reading through the call chain, it noticed something else. The frontend CSV parser was already handling a column that let property managers control whether a welcome email should fire for each individual user. That data was being parsed, included in the HTTP request, and sent to the backend.

The backend was ignoring it entirely.

The field wasn't wired up on the receiving end, so the value was silently dropped. Every imported user got a welcome email regardless of what the CSV said. This wasn't in any alert. New Relic had no reason to flag it — from the system's perspective, emails were sending successfully. It was invisible unless you were reading the code in the context of the full request lifecycle.

We wired it up in the same session. Property managers now have the control they thought they already had.

No monitoring tool would have caught that. It wasn't an error, it was a silent behavior gap — the kind that lives in a codebase for years and only surfaces when someone eventually asks why the column doesn't seem to do anything. The only reason it came up is that Claude was tracing the entire path, not just the part that was broken.

What's Actually Different

I want to be precise about what changed here, because "AI writes code faster" undersells it and also misses the point.

The speed gain isn't primarily about code generation. It's about context elimination.

Traditional debugging involves constant context switching: telemetry tool to codebase, codebase to database client, database client back to the codebase. Every switch costs you — you lose the thread, you have to re-establish what you knew, you hold an increasingly fragile mental model of what's happening where. The bigger the incident, the more expensive this becomes.

When New Relic MCP and Claude Code are running in the same session alongside the full codebase, there's no switching. The agent queries production data, reads the relevant service files, and traces the call chain from the NestJS controller through to the external API call — in one continuous thread of investigation. The investigation and the fix happen in the same context, with the same agent that understands both the telemetry and the code.

New Relic was already one of the best tools in my stack for understanding what my system was doing. This integration makes it part of a feedback loop that closes in minutes instead of hours.

From "user reported an error" to "fix deployed" was a single session. The bonus bug fix came free.

The Pattern

This wasn't a one-time thing. It's become a repeatable workflow.

Report comes in. Claude Code session with New Relic MCP + MongoDB MCP + full codebase. Query the telemetry, read the code, trace the path, implement the fix. And consistently, when you're reading the full path in context, you find things that weren't in the original report.

If you're already running New Relic, the MCP integration is worth trying the moment it's available to you. What you'll find is that the observability data you've been collecting becomes dramatically more useful when an agent can act on it in the same breath it reads it.

In 2009, I built a Star Trek app for the Palm Pre. Tonight, I brought it back from the dead using Claude Code, and I didn't write a single line of code myself.

You can play it right now: communicator.natecraddock.com

The App That Time Forgot

If you were rocking a Palm Pre back in the day — first of all, respect. You had taste. webOS was ahead of its time in ways that still hurt to think about.

My contribution to that beautiful, doomed ecosystem was the Star Trek Communicator & Away Team Action Playset. It was a love letter to The Original Series crammed into a 320×480 screen. Fourteen characters across three Starfleet departments. Hundreds of original voice clips. A draggable phaser power dial. A rotating signal spinner. A communicator grill that actually opened and closed. A tricorder with cycling screen displays. A medical scanner with a hold-to-scan mechanic.

Image

And an easter egg, because of course there's an easter egg: crank the phaser to maximum power and it triggers an overload sequence — a slowly ramping sound that builds until the whole thing explodes.

The whole thing was built on the Mojo framework — webOS 1.0's answer to "what if we made mobile apps out of HTML and JavaScript before anyone was really ready for that?" Sprite sheets, CSS animations, border-image tricks for decorative frames, and a whole lot of Mojo.Event.listen. For 2009, it was pretty slick.

Then Palm died. HP bought them, fumbled the TouchPad, and webOS went to live on a farm upstate. My Star Trek app went with it.

Sixteen Years Later

I've been doing a lot of work with Claude Code lately — Anthropic's CLI coding tool that lets you pair-program with an AI right in your terminal. I use it for real production work, but I wanted to throw something weird at it. Something with ancient framework patterns, sprite sheet math, and enough quirky interaction design to really test whether it could understand intent, not just syntax.

A dead app built on a dead framework for a dead platform. Perfect.

The Conversion

Here's what Claude had to work with: 8 JavaScript scene assistants, 8 HTML templates, 5 CSS stylesheets, 2 data model files, and about 8.5MB of audio and image assets from a framework that's been dead longer than some junior devs have been coding.

I fed it everything and said make a plan. It mapped every webOS Mojo concept to a React equivalent — Mojo.Event.listen became onPointerDown, Mojo.Model.Cookie became localStorage, x-mojo-element widgets became React components. Then it scaffolded a Vite + React project, converted the data layer, and started building.

Here's the thing: my role was domain expert. I knew how the app was supposed to behave — which animations fired when, what the phaser dial felt like to drag, how the communicator grill should respond to a tap. Claude handled all the actual code. Every line of React, every CSS rule, every hook and handler came from the AI.

All seven original scenes made the trip: Title, Communicate, Phaser, Tricorder, Medical Scanner, Help, and Preferences. Navigation is just useState-based scene switching in App.jsx — no React Router needed, which honestly maps perfectly to how the original Mojo scene stack worked anyway.

The Bugs Were the Fun Part

This wasn't a mechanical translation. We hit real problems that required understanding why the original code worked the way it did.

The invisible click-blocker. The antenna grill overlay used scaleY(0) when open — visually gone, but still sitting there capturing pointer events and blocking clicks on the buttons underneath. The kind of thing that works fine in 2009 webOS and silently breaks in a modern browser. Fixed with pointer-events: none.

The incredible shrinking frames. The decorative border-image elements were rendering too small. A global border-box rule was conflicting with the original content-box sizing the entire app was designed around. We had to throw out the global box-sizing override entirely. Fifteen years of "always use border-box" muscle memory, and the right answer here was: don't.

The transparent centers. The Help page's white balloon backgrounds and the Phaser page's metal texture were rendering as empty frames — just borders with nothing in the middle. Turns out CSS border-image-slice needs the fill keyword explicitly, or it only renders the 9-slice border pieces and leaves the center transparent. That's a subtle one. The kind of thing that costs you an hour on Stack Overflow, and Claude diagnosed it in context.

Validating the Whole Thing

One part of the workflow worth mentioning: we used Playwright to validate the conversion. Rather than just eyeballing each scene and hoping nothing was off, we had automated browser testing confirming that scenes rendered correctly, interactions worked, and the navigation flow matched the original app's behavior. When you're converting something with this many interactive pieces — draggable dials, hold-to-scan mechanics, conditional animations — having a real browser validating your work catches things you'd miss on a visual pass.

Image

The Enhancements

We didn't just port it. We made it better for 2025.

A "Tap to Begin" overlay on the title screen, because modern browsers won't autoplay audio without user interaction. The transporter beam-in sound has to play on first load. Non-negotiable. Kirk doesn't materialize in silence.

Smart beam-in behavior — the animation and sound only fire on first app load. Come back to the title from another scene and everything appears immediately. No one wants to watch the same beam-in animation forty times.

The phaser overload easter egg, fully implemented with programmatic volume ramping from near-silent to full blast over the duration of the audio file. The explosion is baked into the end of the sound. It's deeply satisfying.

A full asset preloader with progress bar — all images and key audio files load before the app starts, so every scene renders instantly with no visible pop-in. This is one of those things you don't notice when it works, but you absolutely notice when it doesn't.

And an updated Help page telling the story of the app's resurrection. Because at this point, that's part of the story.

The Numbers

The final build is pretty lean for what it does:

• ~220KB JS (67KB gzipped), ~17KB CSS
• ~8.5MB of assets (7.1MB audio, 1.4MB images)
• Zero dependencies beyond Vite and React
• Plain CSS with component-level files (no CSS-in-JS, no preprocessors)
• Custom useAudio hook wrapping HTMLAudioElement (no audio libraries)
• Deployed as a static site on Netlify

What I Actually Took Away From This

This wasn't really about Star Trek. Or Palm. Or even React.

I didn't write code tonight. I directed code. I brought sixteen years of context about this app — how it should feel, what the interactions meant, why certain design decisions were made — and Claude brought the ability to translate all of that into a modern codebase, fast. Playwright confirmed we got it right.

The bugs we hit weren't trivial. They required understanding the intent behind decade-old framework decisions, not just pattern-matching syntax. That border-image-slice fill issue alone is the kind of thing where you need to understand what the original developer was trying to accomplish, not just what the code says.

That's the part that gets me. Not that AI can write a React component — that's table stakes at this point. It's that AI can take a dead framework's patterns, understand what they were for, and rebuild them in something modern while preserving all the weird, wonderful little details that made the original app worth building in the first place.

Live Long and Prosper

The Star Trek Communicator is back. Sixteen years after Palm died, it runs in any modern browser. Every voice clip, every animation, every ridiculous phaser overload explosion — all of it, exactly as weird and charming as it was in 2009. Just built on technology from this decade.

Check it out: communicator.natecraddock.com

If you've got old projects collecting dust on dead platforms, I'd genuinely encourage you to try this. Grab the source, hand it to an AI coding tool, and see what happens. You might be surprised what comes back to life.

Last night I watched Claude write TMS9900 assembly, compile it into a cartridge ROM, run it on a TI-99/4A emulator, see the result, and iterate—eventually rendering the Claude Code logo in 1980s graphics.

Claude has read every TI-99/4A programming manual ever written. It can explain the VDP register architecture, recite memory maps, describe the TMS9918A color palette. Perfect accuracy. Total confidence.

It had never run code on one.

The Pipeline

I've been building an MCP (Model Context Protocol) bridge connecting Claude Desktop to MAME. The architecture:

Claude Desktop → MCP Server → File Bridge → MAME Lua Plugin → TI-99/4A Emulator

Claude can check emulator status, compile TMS9900 assembly, launch cartridges, capture screenshots, and iterate based on what it sees. A complete development loop. The same cycle any programmer uses, just with an AI writing the code and a 44-year-old computer running it.

The Datamux Problem (Or: The Documentation Was Technically Correct)

My first approach seemed obvious: inject code directly into RAM via MAME's Lua scripting, then execute it. Claude knows the TI-99/4A memory map. The 32K expansion RAM sits at $A000-$FFFF. Write some bytes, jump to them, done.

It didn't work. The bytes we wrote weren't the bytes that appeared in memory.

We tried the scratchpad RAM at $8300. Same problem—plus the console's firmware kept overwriting it. We tried the debugger's load command. Still corrupted.

Here's what the documentation doesn't emphasize: the TI-99/4A has a 16-bit CPU but an 8-bit external data bus. A chip called the "datamux" sits between them, converting 16-bit operations to pairs of 8-bit transfers. When you write to expansion RAM through MAME's memory API, you're going through that datamux—and it mangles the data because it expects specific timing sequences that external writes don't provide.

Claude knew about the datamux. It's in the documentation. But knowing "there's a bus width converter" and knowing "this will corrupt your direct memory writes" are different things.

The pivot: Cartridge ROM at $6000-$7FFF sits directly on the 16-bit bus. No datamux. We switched to compiling actual cartridge images, and suddenly everything worked.

This is the kind of thing you can't learn from reading. The documentation is technically accurate. It just doesn't tell you what will actually bite you.

First Success

With the cartridge workflow running, the first real test was simple: display "HELLO" on screen.

Claude wrote the assembly—set up VDP write address, loop through characters, write to video RAM. Compiled clean. Launched the emulator.

It worked. First try. Text appeared exactly where expected.

Too easy. "Now display 'HELLO CLAUDE' and change the background to green."

The Color Table Incident

Claude knew that VDP register 7 controls the backdrop color. It wrote confident code. The code compiled. The emulator ran.

The background turned purple.

Not green. Purple.

Claude adjusted the color table writes. Purple with a cyan screen area. It rewrote the initialization sequence. Still wrong.

After several iterations—different color values, different registers, different timing—we finally got green. The issue: the TI-99/4A's GPL startup routine initializes VDP registers in a specific order. Claude's code was fighting with the console's own initialization. The documentation describes what the registers do. It doesn't describe the dance you have to do with the firmware.

The Logo

With text and colors working, I pushed it: recreate the Claude Code logo on TI-99/4A hardware.

This meant Graphics II mode, custom 8x8 pixel character patterns, color tables for each character group, tiles arranged in grids to form larger images. Claude's first starburst had the right idea—thin spidery lines instead of thick chunky rays. It could describe what the logo should look like. It couldn't see that its code didn't produce that.

But now it could see. After each compile, I'd capture a screenshot. Claude would analyze it: "The rays are too thin. The diagonal patterns aren't connecting. The indexing is off—character 136 falls into color group 17, not 16."

Then it would fix the code and try again.

We went through a dozen iterations. Some were disasters—one 7x7 grid attempt produced what I can only describe as a digital sneeze. Pattern data loading into wrong addresses. Characters appearing in wrong positions. But each failure taught something the documentation couldn't.

The blocky text was its own challenge. I fed Claude reference images of the logo style. First attempt: too thin. "You might be able to use multiple characters to represent one letter," I suggested. It rebuilt the entire alphabet as 3-character-tall block letters with proper spacing.

The Result

After an hour of iteration: a recognizable Claude Code logo on TI-99/4A hardware.

Orange starburst with radiating rays—well, "light red," since the 15-color palette doesn't include true orange. Blocky text. Dark background. Proper alignment.

Is it pixel-perfect? No. 256×192 resolution with 8×8 character tiles has limits. But it works. An AI that never touched this hardware wrote assembly code that runs on it—not by luck, but by iterating through failures until success.

What Actually Happened Here

There's a question that haunts AI development: does the model actually understand, or is it just sophisticated pattern matching?

I don't have the answer. But I watched something interesting.

When the memory writes failed, Claude didn't randomly try new approaches. It reasoned about the datamux architecture, hypothesized about bus timing, systematically tested the hypothesis. When the colors were wrong, it traced through the VDP initialization sequence. When the starburst patterns weren't connecting, it diagnosed indexing errors in the character definitions.

Was that understanding? Pattern matching? Does the distinction matter if the output is working code on real (emulated) hardware?

What I know: reading documentation isn't doing. Claude has absorbed more TI-99/4A technical material than any human could memorize. Turning that into working code required a feedback loop—write, run, see, fix. Theory meeting reality, repeatedly, until the gap closes.

What's Next

This is pilot work for a larger project. Next: real hardware. A physical TI-99/4A with a FinalGROM 99 flash cartridge and PICO9918 VGA output, so Claude can see its code run on actual vintage silicon and debug issues that only appear on real hardware.

Then more platforms. Commodore 64. Intellivision. Vectrex. Atari 800. Each with their own architectures, quirks, and gaps between documentation and reality.

The project is called "Claude Codes on Classic Computers." Apparently I'm going to spend 2026 teaching an AI to program machines that have been obsolete for 40 years.

Texas Instruments lost half a billion dollars on the TI-99/4A in 1983. Last night, an AI made it do something new.

More updates coming as the project develops. The MCP bridge code will be open-sourced once it's stable.

a Code is a commodity now. Here's what actually matters.

The interview industrial complex has been broken for a long time. But it's broken in different ways depending on where you sit.

At the FAANGs, it over-optimized. Leetcode prep became its own industry. Candidates spent months memorizing algorithm patterns they'd never use on the job, all to pass whiteboard rituals designed to filter volume, not identify talent. "Implement a binary search tree." "Reverse a linked list." The whole system tested whether someone could perform under artificial pressure, not whether they could build real things.

At startups, it is underdeveloped,. Solid engineering thinking was never cultivated in the first place. Companies hired whoever could ship fast and hoped for the best. No architecture. No mentorship. Just velocity and technical debt.

Both approaches missed the same thing: code was never the hard part. Knowing what to build and why was always the hard part.

The Other Side of the Table

I've built a team from zero — started as the engineering department at a startup, then hired every person who came after. But I've also spent years on the other side of the interview equation, sitting in rooms wondering why companies hire based on things that don't actually indicate the impact someone will have on their infrastructure.

This is partially self-serving. I'll admit it.

I've never liked those kinds of interviews. I've turned down opportunities when "live coding" was listed as an interview step. Not because I can't code, butheads while making a decision about a single because I don't perform well in artificial scenarios where someone watches me type. And I've learned that says almost nothing about how I'll actually contribute.

"Walk me through how you'd optimize this SQL query."

Maybe I don't think that way on command. But give me an hour with the actual system, and I'll give you an elegant solution. The interview tested the wrong thing.

I developed a philosophy: hire for how people think, not how they solve a specific problem you hand them under pressure. Look for reasoning through ambiguity. Look for the questions they ask before they start solving. Look for whether they can hold the full context of a system in their , piece of it.

Some people thought I wasn't being rigorous enough. That I was just rationalizing my own weaknesses.

Then AI showed up.

The Vindication

Everything I believed about hiring just got validated by a trillion-dollar industry shift.

"Implement a binary tree from memory."

That's what AI does now. AI can produce code. AI can reverse a linked list. AI can bang out a React component or a REST endpoint in seconds. The skill we spent decades filtering for — producing code under pressure — just became a commodity.

What AI can't do is understand why a particular architecture fits a business problem. It can't navigate ambiguity. It can't push back on a product requirement that doesn't make sense. It can't mentor a junior engineer through their first production outage. It can't sit in a room with a CEO and translate business urgency into a technical roadmap.

The thinkers are leveraging AI to multiply their output. They know what to ask for. They can architect a solution, prompt their way through implementation, and validate the output against the system they hold in their head.

The code-producers — the ones who could crank out implementations but needed architects to tell them what to build — are now competing with tools that do the same thing faster and cheaper. They're just producing more code. Faster, sure. But unarchitected code that still needs someone to review, redirect, and often rewrite.

I didn't adapt my hiring philosophy to the AI era. The AI era caught up to my hiring philosophy.

The Startup Math

This matters most where I live: startups and headcount-constrained environments.

Big companies can absorb inefficiency. They can hire specialists. They can employ layers of people whose job is to producethe code that architects designed. They have slack in the system.

Startups don't. 

When you're building a team of three to five engineers, every single person needs to operate across the whole stack and the whole problem space. You're not hiring "a React developer" or "a backend engineer." You're hiring someone who can look at a business problem, understand the constraints, architect a solution, and execute it.

Here's the new math: One thinker with AI tools now does what used to take a thinker plus two implementers. But one implementer with AI tools just produces more code that still needs an architect to review and redirect.

If you only get five hires, you need five people who can think.

AI didn't change that math. It made it brutal.

What I Hire For Now

The fundamentals haven't changed — they've just become non-negotiable:

Architectural thinking. Can they hold a system in their head? Do they understand how a decision in one layer affects three others? When I describe a problem, do they ask about constraints and tradeoffs before they start solving?

Judgment over output. I care less about how fast someone can produce code and more about whether they can evaluate code — including AI-generated code. Can they spot when a solution is technically correct but architecturally wrong?

AI fluency as baseline. Not "have you used ChatGPT" but "do you understand that prompting is architecture?" The best candidates I see now treat AI as a thinking partner, not a code generator. They front-load the reasoning.

Comfort with ambiguity. Startups don't hand you clean specs. Can they operate when the requirements are half-formed and the priorities are shifting?

Communication under pressure. Can they explain their reasoning? Can they push back on me — on the engineering leader — when they think I'm wrong? That's more valuable than any technical skill.

The Interview Shifts

I've stopped asking people to perform. Instead:

"Here's a real problem we're facing. Walk me through how you'd approach it." Then I watch how they think. Do they jump to code or do they ask questions? Do they consider the business context or just the technical puzzle?

"Tell me about a time you disagreed with an architectural decision. What did you do?" I want to see if they can advocate for their position without being a jerk. That skill matters more than ever when you're working with AI and need to override its suggestions.

"How do you use AI tools in your workflow?" This isn't a trick question. I want to understand their mental model. Are they using AI as autocomplete, or as a collaborator? Do they trust it blindly or verify its output?

The goal isn't to see if they can solve a puzzle I already know the answer to. It's to see how they'd actually work.

The Uncomfortable Implication

If code is becoming commodity, what happens to the traditional junior-to-senior pipeline?

I'm watching it compress in real-time. Juniors with strong fundamentals and AI fluency are leveling up faster than any traditional timeline. The mid-level plateau — that long stretch where developers can produce but haven't yet learned to architect — might be collapsing.

That's good for the juniors who can make the leap. It's brutal for the ones who can't.

The path forward isn't to produce more code. It's to think better. To architect better. To use AI as a lever while developing the judgment that AI doesn't have.

And for the people doing the hiring: stop testing for commodity skills. Start hiring for thinking.

The tools have caught up. Make sure your team has.

I built an engineering team from scratch at a startup and have spent years on both sides of the hiring equation. I write about engineering leadership, AI workflows, and why the old playbooks need updating.