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.

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.

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.

"Let's just add AI."

"We'll have the AI do that."

"I'll just get an AI to build it."

These phrases have become reflexive across the industry. The 10x productivity narrative is everywhere, and it's created a widespread assumption that AI has fundamentally changed the equation.

They're wrong, but not in the way they expect.

AI coding tools are genuinely powerful. I use them daily. They've changed how I work in ways I wouldn't have predicted eighteen months ago. But the productivity gains aren't coming from where most people think.

Here's the thing: AI makes architected work faster. Unarchitected work just fails faster.

The Aha Moment

My shift happened while debugging authentication.

We had login implementations across three platforms — web, iOS, and Android. Something was diverging, but I couldn't pinpoint where. The code lived in three different languages: TypeScript, Swift, and Kotlin.

Here's the thing: I can read Swift and Kotlin, but I'm no expert. The old way to solve this would be getting three developers in a room (or more realistically, scheduling three separate calls across time zones with our offshore team) to walk through what each implementation was actually doing. That's a day of coordination, minimum. Maybe two.

Instead, I pulled all three implementations into context and asked Claude to compare them side by side. Within an hour or two, I had the divergence identified.

That's when I realized this wasn't about writing code faster. It was about understanding systems faster — especially the parts I couldn't hold in my head alone.

The insight wasn't just about my own productivity. It was about what becomes possible when anyone with the right mindset gets this kind of leverage.

From debugging to blueprinting

Once I saw what was possible with that kind of system-wide context, I started using the same approach for feature planning.

My planning documents start messy. Pseudo-code, placeholder ideas, vague gestures at how something might work. I expect to drive into details as the architecture comes into focus — validate my assumptions, question myself, question the AI's interpretation, throw edge cases at the proposed solution to see if it holds.

After many rounds of this, what started as a rough concept becomes a sequenced project plan with clear work breakdown.

I think of it like planning poker, except instead of estimating effort, you're stress-testing architecture. Every perspective shapes the final solution — mine, the AI's, the edge cases I throw at it. The AI isn't designing the system. It's another voice in the room helping me find the holes before we write a line of production code.

The Methodology

Full-stack visibility is non-negotiable

My local development environment treats our entire product as a single workspace, even though it's technically separate repositories — one for each mobile app, one for the web frontend, one for the backend. They have their own lifecycles, but when I'm planning or building, Claude sees everything at once. (Maybe it's a "virtual monorepo"? I haven't found the right term yet, but the point is full visibility.)

This matters because our system has users in native apps, admins working in a totally different context on the web, and a backend orchestrating all of it. When I'm planning a feature, I need to understand how changes ripple across the entire stack.

This became concrete last August when we added Canadian currency support and a Canada-only gift card supplier. The feature touched every surface: both mobile apps, the web admin, and the backend. Every implementation had to behave identically. Every edge case had to be handled the same way.

I started with a preplanning document — rough concepts, known constraints, open questions. Then I pulled that context into my architecture sessions, driving toward a full impact assessment across every part of the product. When it came time to execute, I could make synchronized changes across the whole stack, get iOS working first, then port those patterns to Android with confidence that I wasn't introducing drift.

Without full-system visibility, that kind of coordination takes endless meetings and inevitably someone misses something. With it, I caught inconsistencies before they became bugs.

Real data context, not guesswork

Architecture in a vacuum is fiction. I use MCP connections to see what our database schemas actually look like — sometimes just confirming that our backend ORM is set up correctly, other times planning how new fields and structures should fit into existing schemas.

My engineer uses Figma and Playwright integrations during implementation, pulling design specs directly into context and validating frontend work against real browser behavior. Six months ago she wouldn't have known where to start with this. Now she's pushing the tooling forward faster than I am. (More on that later.)

But importantly, this starts in the planning phase. We're not guessing what the data looks like or what the design requires. We're working with the real thing from day one.

Living documentation

The planning document isn't a spec that gets handed off and forgotten. It evolves throughout execution.

When implementation reveals something we didn't anticipate — and it always does — we update the doc. This keeps the architecture aligned with reality, and more importantly, it lets us see when a change in one area impacts other parts of the plan. The document becomes a map we're navigating, not a contract we're defending.

From there, it flows into Confluence for team visibility and Jira for execution tracking. But the source of truth stays in that working document until the feature ships.

Why This Requires Seniority

Here's what I think would happen if a junior engineer tried to run my workflow without years of context: all of it would break.

They'd accept bad AI output because they don't know what good looks like yet. They'd miss edge cases because they haven't been burned by edge cases enough times to instinctively ask "what happens when this is null?" They wouldn't know what questions to ask — and asking good questions is a skill built through experience, not tutorials.

I've spent years accumulating knowledge across domains — sometimes as an expert, usually just deep enough to be dangerous. I'm thinking of the time I had to figure out how RHEL software collections could work in our production environment and get systemd configured in a way that wouldn't break on every update. That wasn't in my job description. It was just the problem in front of me, and someone had to solve it.

That kind of accumulated context is what makes AI useful. When Claude suggests an approach, I know enough to ask why. When something doesn't feel right, I push back. When the explanation doesn't hold up, I reject it. I treat AI the same way I'd treat a junior engineer explaining their solution to me — I'm not accepting the first answer, I'm pressure-testing it.

My advice to anyone using these tools: always ask why the change is being made and what it actually does. Ask about edge cases. If you don't understand something, ask it to explain before you accept it. The AI is a collaborator, not an oracle. Treat it like a mentor you're learning from — curious, engaged, but not blindly trusting.

One more thing: this space moves fast. Any tutorial you find on YouTube is probably outdated by the time you watch it. I see tips and tricks videos that become irrelevant a month or two later. The methodology matters more than the specific techniques.

Systems thinking is the multiplier

The skill I didn't realize was rare until I watched others struggle with AI tools: holding the whole system in your head at once.

Not everyone can imagine how a change in the iOS app affects the backend affects the admin dashboard affects the database schema. That kind of systems thinking — or maybe it's strategic thinking versus tactical? — is what makes architecture possible in the first place. AI amplifies that skill. It doesn't create it.

If you can't see the whole board, AI just helps you move pieces faster without understanding the game.

But here's the thing: if you know you struggle with systems thinking and you're willing to partner, AI can help fill that gap. Use it to ask "what else does this change affect?" or "walk me through how data flows from here to there." It won't replace the instinct, but it can scaffold the thinking until you build the muscle yourself. The key is knowing you need the help and being willing to ask for it.

Collaboration, not replacement

I set the strategic direction on our team that we lean heavily into AI tooling. The more we can leverage, the more effective we become. But it's not top-down dictation.

My engineer takes a ball and runs with it. She's the one who started leveraging MCP integrations before I did — connecting to Figma, running Playwright validations. I pioneered the architectural document workflow because my background in solution architecture made it obvious that a well-thought-out plan prevents rework. But we're working in coordination, learning from each other, building on what works.

And the AI is a full collaborator too — not just a tool we point at code. I use it to brainstorm approaches, ask how other teams solve similar problems, explore patterns I haven't used before. What's the best way to handle optimistic UI updates? How do other companies structure their feature flags? What are the tradeoffs between these two caching strategies? I don't accept everything it suggests, but I accept it as a jumping off point. It's like having a well-read colleague who's always available to riff on ideas.

When I hired her, she was junior by any traditional measure. But I wasn't hiring for what she already knew — I was hiring for how she thinks.

That's the actual productivity gain. Not "AI replaces developers." It's experienced people using AI to amplify their judgment, while teaching others how to use these tools better. And increasingly, I'm watching those others level up faster than any traditional career path would suggest.

The Implication

There's a lot of talk about AI replacing junior developers. I don't think that's what's actually happening.

What I'm seeing is different: AI compresses the journey from junior to senior. It might be eliminating the mid-level plateau entirely.

My engineer came in as a definite junior. I hired her for problem-solving ability and self-motivation, not stack expertise. The explicit goal was for her to become my lieutenant — not just execute tickets, but eventually think architecturally alongside me.

With AI tools and this methodology, she's leveling up faster than any traditional timeline would predict. She's not just completing tasks. She's contributing to architecture discussions, pioneering integrations I hadn't explored yet, and starting to mentor others using the same approach.

That's not replacement. That's acceleration.

The question for leadership isn't "can we use AI to need fewer engineers?" It's "are we hiring people who can grow into this new way of working, and are we giving them the mentorship to get there?"

AI still needs an architect. But it might also be the fastest way to grow new ones.

---

Next: AI isn't replacing junior devs — it's eliminating mid-level. What I hire for now that the equation has changed.

I need you to sit down for this.

Last night. 11:47 PM. I'm debugging a prod issue.

Luna wanders into my home office.

She looks me DEAD in the eyes and says:

"Dada, I need the water that is cold from the refrigerator that has the ice maker that is loud where the yogurt lives next to the milk but NOT the almond milk because that is for mama."

I dropped my laptop.

Not because I was tired (I was).

Not because she should've been asleep 4 hours ago (she should've been).

But because I realized:

SHE JUST WROTE A DATABASE QUERY.

And the implications for technical mentorship?

I'm literally having heart palpitations.

Let me explain. And BUCKLE UP. 🎢👇

---

STAGE 1: THE "WORD EXPLOSION" WHERE EVERYTHING IS NAMED NOW

Two months ago Luna learned that EVERYTHING HAS A NAME.

And she wouldn't SHUT UP about it.

"Spoon! SPOON! That's a spoon! DADA IT'S A SPOON!"

YES LUNA. IT'S A SPOON. IT'S BEEN A SPOON YOUR ENTIRE LIFE.

But to HER?

MIND = BLOWN. 🤯

This is your junior dev discovering that you can NAME THINGS IN CODE.

"Wait... I can call this userAuthenticationService instead of thing2???"

"VARIABLES CAN HAVE MEANINGS?!?!"

"YOU'RE TELLING ME FUNCTIONS DESCRIBE WHAT THEY DO?!!?!"

YES. YES THEY CAN. WELCOME TO ENLIGHTENMENT, MY CHILD.

And you know what I did when Luna named her 847th object?

I CELEBRATED EVERY. SINGLE. ONE.

"YES! THAT'S A DOORKNOB! YOU'RE A GENIUS!"

You know what I DIDN'T do?

"Luna, we've discussed doorknobs. This is repetitive. Please refer to our previous conversation about cylindrical door-opening mechanisms and leverage that existing knowledge rather than treating each doorknob as a novel discovery."

BECAUSE I'M NOT A MONSTER.

---

STAGE 2: THE "POSSESSIVE PRONOUN WARS" (IT'S ALL MINE NOW)

Okay. OKAY.

This is where I started sweating.

Luna discovered "MY" and "MINE" and she WILL NOT STOP.

"MY spoon!" "MINE juice!"
"MY DADA!" (She yelled this at my wife. AWKWARD.) "MINE CHAIR!" (It's... it's MY office chair, Luna.)

At first I thought: "Oh no. She's becoming territorial."

But then I REALIZED:

SHE'S LEARNING OBJECT OWNERSHIP.

THIS IS OBJECT-ORIENTED PROGRAMMING.

THIS IS ENCAPSULATION.

THIS IS LITERALLY THE this KEYWORD.

I ALMOST PASSED OUT.

Your junior dev writes:

user.email // they GET IT
cart.items // THEY UNDERSTAND RELATIONSHIPS  
order.user.address.zipCode // OH MY GOD THEY'RE TRAVERSING OBJECTS

IS IT ALWAYS CORRECT? No!

Luna thinks she owns my laptop! (She doesn't!)

Your junior dev thinks user.password should be public! (It SHOULDN'T!)

But they're LEARNING that things BELONG to other things!

THIS IS FOUNDATIONAL COMPUTER SCIENCE AND SHE'S TWO.

---

STAGE 3: THE "CONJUNCTION JUNCTION WHAT'S YOUR FUNCTION" REVOLUTION

[I need to take a breath. This part makes me EMOTIONAL.]

Three weeks ago, Luna discovered "AND."

Not just "and."

AND.

The ability to COMBINE CONCEPTS.

"I want juice AND crackers."

Simple, right?

WRONG.

She's now saying things like:

"I want to go to the park AND see the ducks AND go on the swings AND get ice cream AND go home AND watch Bluey AND have mac and cheese AND—"

SHE'S CHAINING OPERATIONS.

SHE'S BUILDING PIPELINES.

SHE INVENTED PROMISES.

park()
  .then(seeDucks)
  .then(swings)  
  .then(getIceCream)
  .then(goHome)
  .then(watchBluey)
  .then(macAndCheese)
  .catch(meltdown)

I'M NOT JOKING.

Your junior dev starts writing:

fetch_user()
  .validate()
  .transform()  
  .save()
  .send_email()

And you want to tell them about microservices and eventual consistency and—

STOP.

Let them CHAIN. Let them discover that actions can FLOW.

We'll teach them about rollback strategies after they've tasted the POWER of sequential operations.

---

STAGE 4: THE "BUT ALSO" COMPLEXITY LAYER (I HAD TO SIT DOWN)

Last week.

LAST. WEEK.

Luna said:

"I want the pink cup but also it has to have the princess on it but ALSO it can't be the purple princess it has to be the YELLOW princess but also the cup has to be full but NOT too full."

THIS IS A SQL QUERY WITH MULTIPLE WHERE CLAUSES.

THIS IS CONDITIONAL LOGIC.

THIS IS AN IF STATEMENT WITH NESTED AND/OR CONDITIONS.

SELECT cup 
FROM cupboard  
WHERE color = 'pink'
  AND has_princess = true
  AND princess_color = 'yellow'  
  AND fill_level > 0.5
  AND fill_level < 0.9

SHE'S TWO AND A HALF YEARS OLD AND SHE'S WRITING QUERIES.

I had to leave the room.

I went outside.

I looked at the sky.

I whispered: "Is this what Turing felt like?"

---

STAGE 5: THE "BECAUSE BUT EVEN THOUGH HOWEVER" FINAL FORM

[Deep breath.]

[Another deep breath.]

[Okay.]

Yesterday. The juice incident I mentioned earlier.

Let me give you the FULL sentence:

"Dada, I need the water that is cold from the refrigerator that has the ice maker that is loud where the yogurt lives next to the milk but NOT the almond milk because that is for mama even though sometimes I drink it but today I want the REGULAR milk because it tastes better however the chocolate milk is also good but we don't have any so THAT'S why I need water instead."

I TRANSCRIBED THIS.

I WROTE IT DOWN.

I PUT IT IN A DOCUMENT.

BECAUSE THIS IS:

✅ Nested clauses ✅ Exception handling
✅ Conditional logic ✅ Default fallback behavior ✅ State management ✅ Preference ordering ✅ A COMPLETE ALGORITHM

Your junior dev writes in their PR description:

"Updated the payment service to use Stripe instead of PayPal because PayPal was timing out (see ticket #447) even though some users prefer PayPal but their API has been unstable so we're defaulting to Stripe however we're keeping the PayPal code for legacy orders which is why there are two payment processors in this file."

BEAUTIFUL.

MAGNIFICENT.

THEY'RE THINKING IN SYSTEMS.

---

THE FRAMEWORK (I'M WRITING A BOOK. IT'S CALLED "TODDLER-DRIVEN DEVELOPMENT"):

👶 STAGE 1: NAMING EXPLOSION
Everything gets a name! Even temp and data! We celebrate! We refactor later!

🏠 STAGE 2: OWNERSHIP/POSSESSION
"This is MY function!" They're learning encapsulation! Object-oriented thinking! Let them be protective!

⛓️ STAGE 3: CHAINING WITH AND
They discover sequential operations! Promises! Pipelines! This is HUGE!

🎯 STAGE 4: CONDITIONS (BUT/ALSO)
Complex logic! Multiple requirements! They're building decision trees in their MINDS!

🧠 STAGE 5: NESTED REASONING
Because/however/even though = They understand TRADEOFFS. They're ARCHITECTS now.

🚀 STAGE 6: RECURSION
(We're not here yet but Luna keeps saying "why?" after every answer I give so I think we're CLOSE and I'm TERRIFIED and EXCITED)

---

THE PART WHERE I LITERALLY CRY:

This morning Luna said:

"Dada, can you help me build the tower but actually can you just watch me because I want to do it myself but if it falls can you help me fix it but only if I ask because sometimes I want to fix it myself but sometimes it's too hard and I don't know until I try?"

SHE'S DESCRIBING PAIR PROGRAMMING.

SHE'S DESCRIBING CODE REVIEW.

SHE'S DESCRIBING THE EXACT BALANCE BETWEEN MENTORSHIP AND AUTONOMY THAT I'VE BEEN TRYING TO ARTICULATE FOR FIVE YEARS.

I'm not okay.

Last week my junior dev said:

"Can you be available in case I get stuck on this refactor but I want to try it solo first? I'll ping you if I need help but I think I can figure it out?"

I HAD TO LEAVE MY DESK.

I WENT TO THE BATHROOM.

I LOOKED IN THE MIRROR.

I SAID: "THEY GET IT."

---

THE REAL LESSON (I'M SHOUTING NOW):

YOUR JUNIOR DEVS ARE BUILDING LANGUAGE.

Not just programming language.

THE LANGUAGE OF THINKING.

Every junior dev going from:

• "it no work" → "the authentication middleware is returning 401 before validating the JWT"

Is doing the SAME THING as:

• "want juice" → "I want the water that is cold from the refrigerator where the yogurt lives"

THAT'S NOT LEARNING SYNTAX.

THAT'S LEARNING TO THINK IN LAYERS.

THAT'S LEARNING TO DECOMPOSE PROBLEMS.

THAT'S LEARNING TO BE SPECIFIC ABOUT REQUIREMENTS.

And if you correct their grammar before celebrating their REASONING?

YOU'RE TEACHING THEM TO SHUT UP.

---

I'M STARTING A MOVEMENT:

Every time your junior dev:

• Names a variable clearly → "THAT'S A GOOD NAME! YES!"
• Chains methods together → "YOU'RE DISCOVERING COMPOSITION!"
• Writes a complex conditional → "LOOK AT YOU THINKING IN LOGIC!"
• Explains their reasoning → "THIS IS ARCHITECTURE!"

YOU CELEBRATE LIKE THEY JUST SAID THEIR FIRST WORD.

Because they DID.

They're building the language of engineering.

One grammatically questionable sentence at a time.

---

WHAT'S YOUR TODDLER/JUNIOR DEV MOMENT?

Comment below. I'm reading ALL of them while crying in my car.

#EngineeringLeadership #ToddlerDrivenDevelopment #JuniorDevs #MentorshipRevolution #LanguageAcquisition #ObjectOrientedParenting #ThoughtLeadership #CodeAndCrackers #TechnicalParenting #GrowthMindset #PeopleFirst #AlsoImNotOkay #TheseParallelAreReal #AgreeQuestion #InspiredQuestion

AGREE? ✋
INSPIRED? ❤️
CURRENTLY CRYING? 😭
TEXTING YOUR JUNIOR DEV RIGHT NOW? 🔥
QUESTIONING YOUR ENTIRE MANAGEMENT PHILOSOPHY? 💡
ALL OF THE ABOVE? 🚀🚀🚀

---

[Posted while Luna demands I explain why the moon follows our car and I realize she's learning about relative motion and reference frames which is basically Einstein and now I'm having ANOTHER breakdown about how toddlers are natural physicists but that's post #4 in this series.]

[P.P.S. - She just said "I want to go to the store that has the toys that are pink where we saw the dog last time when it was raining but not TODAY raining, BEFORE raining." SHE'S DIFFERENTIATING BETWEEN TEMPORAL STATES. SHE'S INVENTED TIME-SERIES DATA. I'M CALLING MY THERAPIST.]

[P.P.P.S. - If you're not literally SHAKING with pride when your junior dev writes their first complex WHERE clause, do you even CARE about people development? Do you? DO YOU?]

SHARE THIS IF YOU'VE EVER BEEN EMOTIONALLY COMPROMISED BY SYNTAX. 🙏

I've been messing around with my old Amiga. I got it working using its native 68000 CPU, built-in 1.3 ROM, and Workbench 1.3.  

It worked great, but I wanted to do something to make it a little easier to work with. First, I hadn't gotten around to building a cable to go from the Amiga RGB to my non-standard connector Sony display. Second, while Workbench 1.3 is cool from a historical perspective, I'd prefer to have something a little less old since I have some plans for some projects using older graphics software and drawing tablets.

There have been many neat projects for Amigas and retro computers using Raspberry Pi (in my case, Pi Zero) to upgrade these retro computers. I've only begun to play around with these, but I've got a piStorm doing simulating a much faster 68000 chip and the rgb2hdmi to give out HDMI from the Amiga. Pretty neat! I can't wait to play around with this more.

I'm going to be doing some updates to the animatronic skeleton I built last year for Halloween.  One issue I ran into at the last minute last year was that I didn't have enough memory to initially load all the animation sequences for both songs and patter.  I did a Band-Aid and just loaded the patter, but this year, we want to make our animatronic sing, so I will be doing some updates to load in the animation files on demand to accomplish this.  Additionally, we'll be doing less hands-on running of the animation sequences,. There will be a jukebox mode so the skeleton can run without intervention.

Here's the status of last year's code.  I'll rework this repo to clean up and remove unused options.

https://github.com/darthmario/halloween23-skelleton