As soon I as I heard that there would be a surpsise reveal of the new pinball machine, I wanted to try it. It was in the Crawl Con room by Rengade Games in the Indiana Convention Center.

What is Dungeon Crawling Carl?

Well, you are about to hear about it from everyone you know. Buckle up.

Dungeon Crawler Carl is a wildly popular LitRPG series by Matt Dinniman that kicks off with a guy named Carl running outside in nothing but his boxers, a leather jacket, and his ex-girlfriend’s tight pink Crocs to catch her prized tortoiseshell Persian cat, Princess Donut. That wardrobe choice saves their lives: seconds later, aliens flatten every building on Earth, killing everyone indoors.

The survivors are herded into a colossal underground dungeon and forced to fight their way down floor by floor. The entire death trap is broadcast across the universe as a massive reality show, meaning sponsors, fan popularity, and audience bloodlust dictate who lives or dies. Carl teams up with Donut, who gains human speech and immediately weaponizes her pampered show-cat ego to manipulate the galactic viewers. Meanwhile, the dungeon’s AI develops a weird, sadistic foot fetish and actively refuses to give Carl decent lower-body armor, forcing him to fight off monsters while basically half-naked.

Because it’s LitRPG, the story includes video game mechanics like stat screens, loot drops, and system notifications. But it works perfectly as both a genuinely tense survival story and a hilarious, deeply angry satire about corporate greed and the entertainment industry. If you get into it, I recommend the audiobook. They are narrated and voiced by Jeff Hays. His performance is so good.

What is Dungeon Crawler Carl Pinball?

Dungeon Crawler Carl is a pinball machine based on the Dungeon Crawler Carl book series, written by Matt Dinniman. You play as Carl, accompanied by Princess Donut, navigating the various dungeon levels and all of the dangers and challenges it presents. Fighting mobs, battle bosses, cast spells, build your viewer count, collect friends, and figure out how to not just survive in the dungeon, but also how to get vengeance! Every aspect of the game combines to immerse you into the story. This includes a host of thematically integrated interactive mechanisms, an audio experience led by Jeff Hays voicing all of the characters, new artwork from Luciano Fleitas, Brad Albright, as well as other Dungeon Crawler Carl artwork shared by Renegade Game Studios, and game rules that connect you with all of the major events and plotlines and many of the minor plotlines as well.

After getting a chance to see the surprise reveal of the game, I got my own surprise. Matt came out to hang with the pinball players and talk about the weather… I MEAN DUNGEON CRAWLER CARL. Matt kicked off something bizarae and sweeping. Like I said, buckle up!

On my journey, I met Tasker Smith. Right from the start, Tasker had a unique point of view about pinball and life. He didn’t slam the machine, but he also had feelings about getting better. He turned failures into lessons and was always awesome to play with. Then, he says he is writing a book. And, a very Tasker thing to do is to actually write a little bit a time and couple of years go by you have a book, then it is is getting published, then he is on a book tour.

Pinball: A Quest for Mastery is about pinball, but it is also philosophy. The book is not about being a master at pinball; it is about being on the quest. The book shares history, demystifies rule complexity, gives you a primer for understanding the game, and what it takes to get better and why. I feel Tasker just shares a user manual with us on how to approach any hobby or pursuit.

I recommend the book for players of all skill levels. I find myself opening the book, flipping to a section, and learning something interesting no matter where I read. This also echoes one of Tasker’s viewpoints: take every moment to learn, get better, and make your own luck. The book is filled with advice and resources. The book doesn’t leave you feeling alone. I thoroughly enjoyed the read!

Go to your friendly local bookstore and pick up a copy.

Congrats, Tasker!

The results are gorgeous! I learned a lot and will share more of the details when I get time. You can follow the live build here: https://pinside.com/pinball/forum/topic/atari-superman-playfield-wall-art

Inserts and Plastics

When I got the playfield home, I realized that I didn’t have the complete playfield. I only had the wood and the printed art. Every insert, plastic piece, and post was removed. The original owner was planning a playfield restoration and had stopped at some point. The artwork was touched up and looked beautiful, but probably would not work for playing pinball on it. The inserts were going to be important since my goal was to place an LED behind them to make them glow.

I put out a post on Pinside looking for any old parts for the Atari Superman Pinball and got a few bites.

Soon enough, I got the original parts for this exact playfield. I got to meet up with the pinhead that donated the playfield to the museum. We chatted for hours about 70s and 80s pinball, swapped stories, and made a community connection. It was surreal to find the original owner, but the pinball community is a small niche hobby.

I also found the original Superman plafield plastic pieces. They shined right up with Novus Plastic Polish. The Novus cleaning products are a must if you work on pinball machines.

To mount the plastic pieces on the playfield, you need post mounts and post stud screws. The mounts were easy to find, but the stud screws were a challenge. New ones were about a dollar each. So, this didn’t scale well. I needed like 60 of them, so if my math is right, that’s $60. I turned to eBay and found someone selling “pounds of old pinball parts”. This came in at $90! Look at the savings. Somehow, I felt better about buying old used parts than buying new ones at a lower price… and in the process, I got a bunch of rusty parts I didn’t even need.

My old screw bucket was not happy that I bought someone else’s old screw bucket and didn’t even consult it.

Mounting all of the playfield parts took a lot of time, but you just do one at a time. I have a new respect for anyone who designs these things. 70s pinball was so much simpler than modern pinball machines, and it was still a lot of parts to track.

Flippers

I wanted to complete the top side of the playfield with flippers. So, I took old flippers from my Strikes and Spares pinball machine and cut them down for this build. Again, this will be wall-mounted, so you can’t have things sticking out too far in the back. They needed to be modded, and Dremel came to the rescue. Shooting a 6-foot stream of sparks across the room.

LED Control and CheerLights

Of course, it is connected to the CheerLights project. This was going to happen 100% of the time whenever I connected 150 LEDs to something. I used WS2811 bullet-style LEDs that you can control one at a time. They fit perfectly in the 12.5mm general illumination holes in the playfield. I used a WLED controller and a 3A power supply to control the colors, animations, and synchronization with the CheerLights MQTT server.

The insert near the flippers stays in sync with the latest CheerLights color while the rest of the inserts can have their own color or visual effects.

Out of the box, the best animation effect was Stream 2. This very much looks like an attract mode on a pinball machine.

3D Models

Part of the project was making my first 3D model to have the original pop bumpers mounted above the playfield but not connected to the original mechanism. Since this is wall art, I can’t have a mechanism sticking out 7 inches on the back. I also could not find the old-style pop bumpers on Maker World, so I designed my own… ish. Meaning it is not a pop bumper for function, it is a pop bumper to take light from an LED and let it shine through. I just published my first model!

For other parts needed, I found a person on Pinside who created a system called PinGlow. They were way ahead of me and had thought through the kind of stuff you are going to need for a wall art project like mine. They offer drop targets, stand-up targets, wall mounting kits, and even LEDs. I reached out to them on Pinside, and they offered to make a custom version of their drop targets specifically for the Atari Pinball machine. These drop targets had the Superman logo on them.

Project Demo

You might know the one if you watched MTV when it first came on cable. A flat blue screen, chunky white text, the time and the temperature in the corner. The Lions Club pancake breakfast. A birthday wish for someone named STEVE. Little League signups at the rec center. Headlines crawling along the bottom while a Muzak version of a song you almost recognized played underneath. I remember watching it for long stretches of time waiting for the flea market noticed to come back around. Our Sears CRT had the blue bars burnt in.

At some point, the Cable Bulletin Board Channel disappeared from all of our lives. NOBODY IS TALKING ABOUT IT.

Recently, I have been spending evenings learning about retro gaming and reading posts on Reddit saying that you have to game on a CRT for the proper gaming experience. This led me to Facebook Marketplace. After a few weeks at looking at photos of TVs this got me remembering the big honker in our living room… then, I uncovered a repressed memory. I had to have it back in my life.

Meet CABLE 82

CABLE 82 is a tiny web app that turns any screen into your own 1982 community bulletin board channel. Ideally that screen is an old 4:3 CRT fed by a Raspberry Pi, sitting in the corner of a room, being ambient.

It scrolls the date and time, your community messages, fun facts, dad jokes, live weather, and headlines from whatever RSS feeds you point it at. There is a crawl along the bottom, a red LATEST flag, and a little station bug in the corner, because of course there is.

You make it yours in a control room in the browser, or by editing one plain config file. It is free and open source and it runs on a Raspberry Pi.

The rest of this post is how to get it going on a Raspberry Pi and a CRT.

Step 1: Get it on the air

SSH into the Pi, or just open a terminal on it, and run:

git clone https://github.com/nothans/cable-82
cd cable-82
node server.js

Open http://localhost:1982 in a browser on the Pi. You’re on the air.

Out of the box it already looks right: the blue screens, the clock, a couple of example bake-sale messages, and real headlines pulled from a few default feeds.

Step 2: Make it your channel

Everything about the channel lives in one place. Open the control room at http://localhost:1982/config and you get the whole thing on one screen: the name, your community messages, which RSS feeds to pull, your town’s weather, the colors, the page lineup. Change something, hit Save, and the channel updates itself within about twenty seconds. Nobody has to touch the TV.

If you would rather edit a file, it all lives in config.json, and you can hand-edit that just as happily. Put your own town in the weather. Drop in the feeds you actually read. Write the messages your household needs to see, which in my house is mostly reminders that trash day is tomorrow.

Step 3: Run it on boot

You do not want to SSH in and start a server every time the power blips. Make it a service so the Pi just comes up broadcasting.

Create /etc/systemd/system/cable82.service:

[Unit]
Description=CABLE 82
After=network-online.target

[Service]
ExecStart=/usr/bin/node /home/pi/cable-82/server.js
Restart=always
User=pi

[Install]
WantedBy=multi-user.target

Then turn it on:

sudo systemctl enable --now cable82

Now the channel is always running in the background, whether anything is looking at it or not.

Step 4: Point a browser at it, full screen

Have the Pi launch Chromium in kiosk mode, pointed at the channel:

chromium-browser --kiosk --noerrdialogs --disable-infobars \
  --disable-lcd-text \
  --autoplay-policy=no-user-gesture-required \
  http://localhost:1982

Two of those flags earn their keep. --disable-lcd-text turns off subpixel font smoothing, which otherwise tints the chunky white text a faint pink on some screens. --autoplay-policy=no-user-gesture-required lets the background music start on its own at boot, so nobody has to click anything to get the beautiful-music bed going.

While you are in there, turn off screen blanking so the picture never sleeps: sudo raspi-config > Display Options > Screen Blanking > No.

Step 5: Get it onto a real CRT

This is the whole point, so let’s do it right.

The easiest and most reliable hookup works on any Pi and any TV with a coax (antenna) input. Run HDMI from the Pi into an HDMI-to-coax RF modulator, then run coax from the modulator into the TV, and tune the TV to channel 3 or 4. Your Pi is now a broadcast channel and the TV is receiving it over the air the way God and 1982 intended.

If you have an older Pi with the yellow composite jack and a TV with an RCA input, you can skip the modulator and go straight out composite instead. Add this to /boot/firmware/config.txt:

enable_tvout=1
sdtv_mode=0        # NTSC (use 2 for PAL)
sdtv_aspect=1      # 4:3

Either way, if the TV crops the edges of the picture, bump up the overscan margin in the control room until nothing important gets cut off. There are no fake scanline filters in CABLE 82, on purpose. The CRT is the filter.

Step 6: Give it a soundtrack

The real channels were never silent. Drop a few audio files into the music/ folder and CABLE 82 plays them as a continuous background bed behind the pages, looping the set, shuffling if you like. Two tracks ship with it to get you started. Aim for the sound the old channels actually used: beautiful music, easy listening, and eventually the famous smooth jazz. I generated mine, but any lounge-y instrumental works.

A channel of your own

A Pi, an old TV, a coax cable, and a folder of files, and now there is a corner of your house that runs its own quiet little channel: your messages, your weather, your headlines, your dad jokes, scrolling by all day.

It’s not useful, exactly. It’s better than useful.

CABLE 82 is open source and lives at github.com/nothans/cable-82.

Project Demo Video

Watch 6 minutes of glorious community news like it is 1982. Enjoy.

Update July 27, 2026: CheerLights Support

I can’t believe that it took me a few days to do this… CheerLights. A perfect feed (for me) is to see the latest CheerLights color scroll by every once in a while. Okay, so now you can add CheerLights feed support with a custom message if needed.

What I made

It’s called Gameroom Designer. It lays out your game room to scale, right in the browser. You set your room’s real dimensions, drop in machines at their real footprints, and slide everything around until it works, before you move a single machine.

You can try it here: https://nothans.github.io/gameroom-designer/

How it works

Start by typing your room size in feet (or meters, if that’s your thing). You get a room drawn to scale with a grid.

Then you fill it. There’s a searchable catalog of real stuff at real sizes: pinball (Stern, JJP, the Atari and generic widebodies), arcade uprights and cocktails and sit-down racers, a pool table, air hockey, foosball, shuffleboard, plus couches, bar stools, storage, the works. A 27-inch-wide pinball takes up exactly as much room next to an 84-inch sofa as it would in real life. Click an item to drop it in, or drag it straight onto the floor.

From there it’s the fun part. Drag machines around. Rotate them. Grab a whole row of pinballs, line up their edges, space them out evenly. Drop a dashed “clearance” zone around the pool table so you don’t forget you need five feet to actually swing a cue. Add doors, swing arc and all, so you can see the door won’t clip the cabinet you parked next to it. Zoom out to take in the whole room, use the minimap to get around, and when it looks right, export a PNG to show your partner exactly why the couch has to move.

There are a few example layouts built in, too, if you’d rather poke at a finished room than start from an empty one.

I built it fast, with AI

I built and shipped this fast using Agentic AI.

The interesting part was never “the code got written.” That’s kind of a solved problem now if you’re one person building one thing. The interesting part was the loop. I’d use the tool, hit something that annoyed me, and fix it right then.

Dragging a rotated block sent it flying to the wrong spot, so I fixed the math. Resizing a block didn’t stick, so I fixed that. I shrank my browser window and the whole layout looked like it had wandered off, so I wrote it up as issue #1 and fixed that too. Ideas showed up and went in the same afternoon: circular clearance zones, doors and windows, even spacing, drag-straight-from-the-library. Then a deploy to GitHub Pages, a banner, a little intro video.

None of that is magic. It’s a build-use-fix loop, run tight. The machine is fast at the typing, but knowing what to build next is still the whole job.

Your machine, your data

The whole thing runs in your browser. Your layout saves to your own machine, so there’s no account to make, no server to trust, and nothing leaving your computer. It’s free, and it’s open source under MIT, so the entire thing is on GitHub if you want to poke at it or fork it: https://github.com/nothans/gameroom-designer.

Tell me what’s missing

I just posted it over in the forum to get some real feedback, because I built this for people who have way more machines than I do.

So go break it. Tell me which machine I forgot, which part feels clunky, what you’d add. That’s the fastest way this gets any good.

I was standing in the hardware store holding a dead coin cell, squinting at it, trying to remember if the Lutron dimmer in my hallway takes a CR2032 or one of the other fourteen round silver batteries that all look exactly the same. So I guessed. I bought two of the wrong one. Classic.

Here is the thing about a house. You slowly learn a thousand tiny facts about it. The vent sizes. The filter part numbers. The spa was installed in some year you’ll never remember. The good info is scattered across manuals in a junk drawer, an email from the installer, a photo of a model plate you took and never looked at again. By the time you actually need a fact, it’s gone.

I finally fixed it. Not with an app. With a folder.

The idea I borrowed

Earlier this year Andrej Karpathy posted a little pattern he called an “LLM wiki.” Instead of the usual retrieval setup where you chop documents into chunks and stuff them in a vector database, you just keep a folder of Markdown files that the AI itself writes and maintains. The model builds the connections once, when it learns something, instead of re-deriving them every single time you ask. The internet looked at it and went “wait, it’s just a folder? why did we ever do the other thing.”

Then Google Cloud made it official. On June 12 they published the Open Knowledge Format, or OKF. It’s a tiny, vendor-neutral spec: a directory of Markdown files, one concept per file, a bit of YAML at the top, an index, links between them. No database. No SDK. Readable by a human and by any agent. That’s the whole thing.

So I pointed it at my house. The project is called Abode 101.

What I actually built

Abode 101 is an OKF folder about my home. There’s a file for the Lutron dimmer, one for the swim spa, one for the HVAC vents, one for the smoke alarms. There’s an index.md the AI reads first so it knows where to look. To use it, I don’t open an app. I just talk to it in Claude Code.

you ▸ what's the battery for the Lutron dimmer?
abode ▸ Panasonic CR2032, per the install guide (page 10).

That’s the fact I drove to the store without. Now it’s one question away, and it tells me where it got the answer.

But a folder of files just sitting there is a filing cabinet. The magic is in two things the bare spec leaves out.

Thing one: the loop

OKF standardizes the files. It says nothing about keeping them fresh. Karpathy’s original idea had the AI do the maintaining, and that’s the part I cared about most, so I built it back in as a set of playbooks.

I capture a thing by telling it “I bought X,” or by dropping a manual, a receipt, or a photo of a label into an inbox folder. It reads whatever I throw at it, pulls out the real specs, and files them. Then overnight it does the boring homework I never do. It looks up the filter I just bought, finds the replacement part, figures out how often it needs changing, and adds a reminder. I wake up and my house knows more than it did when I went to bed.

Thing two: it refuses to guess

This is the part I’m proud of. Every exact fact carries its source and a confidence level. A battery type from the manufacturer’s manual is “verified” and it gets cited. A spec from a random Amazon listing is “reported” and ranked lower. And when I ask something it doesn’t actually know, it says so.

you ▸ what size is the kitchen toe-kick vent?
abode ▸ Not recorded. It's marked TODO, needs measuring. I won't guess.

An AI that says “I don’t know” instead of inventing a confident wrong number. For house facts, where the wrong answer means a second trip to the store or a part that doesn’t fit, that refusal is the feature.

I ran a little eval suite over it to make sure. Twenty-one questions, answered cold. It got the exact facts right, with sources, and on the three questions it shouldn’t know, it refused all three. That’s the behavior I want from something I’m going to trust with my house.

Why a folder beats an app

I could have built a slick app with a database. I’m glad I didn’t. The folder is portable, it diffs in version control, it works with any model, and I own it. There’s no service to shut down, no export button I’ll go hunting for in five years. When the next better model comes out, I point it at the same folder and it just works. Try that with your smart-home app from 2014.

Get it

I open-sourced the framework. The structure, the agent instructions, the playbooks, even the eval harness are all in the repo. My actual house data stays on my machine, gitignored, because you do not need to know my spa’s gallon count. You fork it and fill it with your own home.

→ github.com/nothans/abode101

Go give your house a memory. And maybe check what battery your dimmer takes before you drive to the store. Just a thought…

Microsoft Research just shipped a tool called SkillOpt that takes that idea literally.

SkillOpt is a text-space optimizer that trains reusable natural-language skills for frozen LLM agents through trajectory-driven edits, validation-gated updates, and deployable best_skill.md artifacts.

It treats the skill markdown you hand an agent (the instructions, the system prompt, the SKILL.md) as trainable state. It runs epochs. It has a batch size. It has a learning rate. It just never touches the model weights. The weights stay frozen behind the API. The thing that gets trained is the text.

The loop is short. Run the agent on a batch of tasks. Score each one. A second model reads the failures and proposes small edits to the skill file. Keep an edit only if it improves a held-out score. Repeat. What you get at the end is a best_skill.md you drop in front of the same unchanged model.

I wanted to see it actually work, so I gave it a job…

The setup

I had OpenAI Codex do the writing. The task: take a paragraph stuffed with AI slop and clean it up. The skill it started from was short:

Improve the passage so it reads a little better. Keep the meaning and roughly the length.

No mention of slop. No list of banned words. Nothing to go on.

The verifier was the part that mattered. I wrote a dumb little counter that scans the output for the tells (the canned phrases, the em-dashes) and returns how many are left. Fewer is better. That is the whole eval. Objective, cheap, no judgment calls.

Then I let SkillOpt run.

What it wrote

The seed turned into a thirty-line deslop skill. SkillOpt wrote it.

It worked out, on its own, that “remove AI slop” is a removal constraint and not a tone nudge. It named the exact phrases that kept leaking through (“let’s dive in,” “have you ever wondered,” “it’s worth noting,” “furthermore,” “in conclusion,” “great question”). It flagged em-dashes. And it caught the sneaky failure mode I never told it about: the model dodging a banned word by swapping in a synonym. That one became its own rule, the last line of the file:

Before answering, do a quick scan to ensure none of the original flagged words remain, including close synonyms you may have introduced.

The score went from passing half the held-out passages to passing all of them. The skill it wrote is one I would actually keep.

The part worth keeping

The optimizer is the easy part.

I went in assuming the clever bit was the model proposing edits. It isn’t. The clever bit is the verifier. Give SkillOpt a score and nothing else and it does nothing. I tried that first. It saw the failures, shrugged, and changed not a single line, because “you got a 0.6” tells it nothing about what to fix. The run that worked was the one where the verifier also said which words leaked. Same model, same loop. The difference was the signal.

So the rule of thumb is less “use the self-improving optimizer” and more: can you score this cheaply, and can you tell it why it failed. If yes, the skill mostly writes itself. If no, there is nothing to train and the fancy loop sits there idle.

That is also the catch, and it is the same catch hiding under every self-improving-agent demo. A slop counter is a clean verifier. Most of what you do in a day is not. “Was this brief any good.” “Did this post land.” No cheap score, no training. The optimizer was never the bottleneck. The verifier is.

So build the verifier first. Get that right and the skill mostly writes itself.

Bonus: a taste of running it

The repo is github.com/microsoft/SkillOpt. MIT licensed, Python.

Get it:

pip install skillopt
# or, to poke at the internals:
git clone https://github.com/microsoft/SkillOpt && cd SkillOpt && pip install -e .

The mental model is one small folder per task. A loader that hands over your examples, a rollout that runs your agent and scores it, and a seed skill to start from. SkillOpt’s whole job is to grow that seed.

The config reads like a training run, on purpose:

train:
  num_epochs: 4
  batch_size: 40
optimizer:
  learning_rate: 4        # max edits to the skill per step
  lr_scheduler: cosine
evaluation:
  use_gate: true          # keep an edit only if it beats the held-out score
model:
  optimizer: gpt-5.4      # the model that proposes the edits

Then it is one command:

python scripts/train.py --config configs/yourtask/default.yaml

The only part that is really on you is the scoring. Your rollout returns, per task, a pass/fail and a number between 0 and 1:

return {"id": task_id, "hard": passed, "soft": fraction_correct}

That is the whole contract. Give it tasks, a way to score them, and a skill to start from. It runs the epochs.

One side note: keep the tasks hard enough that the agent fails some of them. If it aces everything on the seed skill, there is nothing to learn and SkillOpt politely does nothing. Ask me how I know.

I read through it expecting to roll my eyes. Instead I sat there nodding, because I’d accidentally built a tiny version of the same thing for this blog.

The pitch

gstack’s whole argument is that solo builders don’t lose to big teams because they’re worse engineers. They lose because they skip process. One person at a keyboard, prompting Claude into existence one vibe at a time, eventually ships something that works. Until it doesn’t. No review. No second opinion. No one asking “wait, should we even build this?”

So gstack bakes the process in. Every skill is a slash command, and each command plays a role in a pipeline:

Think → Plan → Build → Review → Test → Ship → Reflect

You start a project with /office-hours, which hits you with six forcing questions before you write a line of code. Then /plan-ceo-review challenges your scope. /plan-eng-review draws the data-flow diagrams and enumerates the edge cases. You build. /review does a staff-engineer pass and auto-fixes the obvious stuff. /qa opens an actual Chromium browser, clicks through your app, finds bugs, and writes a regression test for each one it fixes. /ship runs the suite and opens the PR.

Each stage feeds the next. The CEO’s decisions constrain the engineer. The engineer’s plan constrains the build. Nothing happens in a vacuum. That’s exactly the part solo work gets wrong.

There’s a whole security wing too. A /cso skill that runs OWASP Top 10 and STRIDE threat modeling. A sidebar Claude that watches for prompt injection. A /careful mode that warns you before rm -rf ruins your afternoon. It’s a lot. The point isn’t that you use all of it. The point is that the roles exist, named and on call.

Why this looked familiar

Here’s the thing. I don’t ship code through a blog. I ship words. But the moment I saw that pipeline I recognized it, because the posts you’re reading go through the same kind of relay.

When I write here, an idea doesn’t go straight from my head to WordPress. It moves through stages, and each stage has one job:

• Research does the digging and writes up a structured report. Pitch, key facts, angle, the competition check.
• Refine tightens the structure and pacing without touching the voice.
• De-slop strips out the AI tells. The em-dashes, the “it’s not just X, it’s Y,” the forced enthusiasm, the closer that tries to sound profound.
• Voice rewrites it to sound like me. Short sentences. Plain words. No throat-clearing.
• Format turns it into clean WordPress blocks.

Each one hands off to the next. Same shape as gstack. A CEO who reframes the product is doing what my research stage does for a post. A designer who catches AI slop is, almost word for word, my de-slop pass. Garry Tan built an org chart for shipping software. I built a smaller one for shipping writing, and I didn’t even notice the resemblance until his showed up.

I’m not claiming I invented anything. The idea is in the water. Once you spend enough time working alongside an agent, you stop treating it like one genius who does everything and start treating it like a team you have to manage. You give each role a narrow job and a clean handoff. That’s not a trick. It’s just how good teams have always worked, now running in a terminal.

The number everyone’s going to argue about

gstack ships with a doc making a bold claim: Garry measured his own output and found he’s writing about 810 times more code per day than he did back in 2013 when he was coding part-time around a day job. Eleven thousand logical lines a day across his first 108 days.

Your skepticism alarm should be going off. So was his. He concedes up front that lines of code is a garbage quality metric. His own line: measuring programming progress by lines of code is like measuring aircraft-building progress by weight. So he deflates the number hard. Strips comments and blanks, applies a 2x penalty for AI being verbose and defensive, and lands at something like 5,700 lines a day. Still a wild figure. Still self-reported, so take it with salt.

But the interesting claim isn’t the speed. It’s the quality holding steady while the speed goes up. A 2 percent revert rate, right in line with the open-source baseline. Two thousand-plus automated tests with CI. A 95 percent success rate across 305,000 skill runs. His actual thesis is buried under the headline number:

“Testing at multiple levels is what makes AI-assisted coding actually work.”

That one I believe without reservation, because it’s the same thing the pipeline is really about. The process isn’t there to make the agent faster. It’s there to catch the agent when it’s confidently wrong, which it will be, several times a day. Every stage is a checkpoint, a chance for something to get caught before it ships. The payoff isn’t speed, it’s fewer mistakes reaching the end.

What I did with it

I’m not installing the whole thing. gstack is TypeScript and Bun and Playwright, built for shipping web apps, and Windows is a second-class citizen in it. Not my stack. Not my use case.

So I stole the front of it instead. The skill I keep coming back to is /office-hours: six forcing questions you have to answer before you’re allowed to build anything. Who is this for. What’s the sharpest version of it. What are you quietly avoiding. It’s a CEO review for an idea that doesn’t exist yet.

That maps straight onto the worst part of blogging, which is deciding what’s even worth writing. So I pointed it at this blog. Before a topic earns a draft, I run it through the same kind of interrogation in Claude Code. What’s the one sentence. Who already wrote it better. What’s the angle only I have. Why now. Most ideas die right there, which is the point. The ones that live show up to the draft stage already knowing what they are.

This post is one of them. gstack was the raw idea. The forcing questions are what turned “gstack exists, that’s neat” into something with an angle worth your time. The tool I borrowed from is the tool that helped me write about borrowing from it.

So here’s what you should know today. gstack is out there, it’s free, and even if you never run a line of it, the shape is worth stealing. Garry Tan built that discipline for code. I run a lighter version of it on words. You can point it at whatever you make. The pipeline is the product. The agent’s just the labor.

Fine for a side-project web app. Does not work for an inverted pendulum spinning on your desk.

The Pit and the Pendulum

MathWorks just published a Tech Talk by Brian Douglas. It is worth watching if you build hardware.

The setup is a Quanser cube servo with an inverted pendulum, a Raspberry Pi running the controller, and a coding agent wired into Simulink through the Simulink Agentic Toolkit. The agent’s job is to swing the pendulum up and balance it.

Balancing an inverted pendulum is a classic control problem because it’s unstable by nature. Get the math wrong and the pendulum falls. Get the code wrong and a 12V motor jerks the cube into something it shouldn’t.

What Happens If You Just Prompt It

The tempting move is the one most of us have done with web apps. Open a chat, describe the system, ask for the code. One prompt, big blob, ship it.

The MathWorks engineers walk through why that falls apart for hardware:

“If you rely on AI to generate code directly, that process is much less structured… it’s often unclear exactly how or why a particular implementation was created, making it harder to trust and verify.”

Brian Douglas

Hardware is unforgiving. You can’t roll back a destroyed motor with a git revert. When a physical system fails, you need to know which assumption broke, which equation got the wrong constant, which sample rate the controller is actually running at. A black box of generated C code doesn’t tell you any of that.

“You don’t want to let your AI agent skip parts of your engineering workflow. That’s how you can get yourself into trouble with a final product that doesn’t meet your objective or worse, is just purely unsafe.”

Brian Douglas

The Workflow Is the Script

The answer is to keep the AI inside the workflow engineers already trust: Model-Based Design. The agent doesn’t replace the workflow. It runs each step inside it, faster.

Define quantifiable requirements. Before any code, the human and the AI agree on what success looks like. Spin-up speed. Wobble limits. The 12V motor constraint. These targets become the benchmarks for verification later.

Use a trusted model. Instead of letting the AI invent a custom physics engine, the workflow points it at an existing Simulink model. The agent runs linearization through the Simulink Agentic Toolkit and reports the system’s poles back to the human. The math comes from validated tools, not from a language model freestyling differential equations.

Use a trusted controller. Same logic. The agent is told to use the MPC Toolbox. Model Predictive Control has decades of theory behind it and a deterministic implementation. If something looks wrong, you can tune it manually. You’re not debugging an optimizer the AI invented on the fly.

Verify in layers. Three stages before the code touches hardware:

• MIL (Model-in-the-Loop): the controller runs against the theoretical model
• SIL (Software-in-the-Loop): the generated embedded C code runs on a computer, behaving exactly like the simulation
• PIL (Processor-in-the-Loop): the C code runs on the actual target Raspberry Pi

Each layer catches different bugs. Skip one and you’ll catch that bug on hardware instead.

Deploy and iterate. Only after layered verification does the code go on the real pendulum.

“Instead of asking an agent to solve your problem however it wants, you tell it to follow an engineering workflow that you understand.”

Brian Douglas

The AI executes. The human directs.

The Hardware Truth

Here’s the part of the video I liked best. They ran the verified controller on the real pendulum and it didn’t quite work. The physical hardware behaved differently from the model.

This is what the vibe-coding fantasy ignores. Reality disagrees with simulation, especially the first time. You will need to iterate. The thing that matters is whether you can.

Because the team followed the workflow, they could. The model was traceable. The requirements were quantifiable. The controller was inspectable. They used the AI to update the physics model, ran it back through MIL, SIL, and PIL, and tried again. No starting over.

The workflow doesn’t promise perfect code on the first pass. It promises code you can fix.

The Director Pattern

A few months ago, I wrote about Seth DeLand’s framing of agentic AI for engineers. The headline idea: you’re not being replaced, you’re being promoted. The engineer becomes the one who defines the problem, sets the constraints, and shapes the space where the AI works.

The MathWorks Tech Talk is what that looks like in hardware. The AI isn’t the engineer. It’s the agent. You’re the director.

“Agentic AI is powerful, but for engineering, the value comes from how you use it. You get the speed and productivity benefits of AI without sacrificing trust, safety, or understanding.”

Brian Douglas

You don’t get speed and safety together by handing the AI a prompt and crossing your fingers. You get there by keeping the workflow you trust and letting the agent move faster inside it.

Speed without losing safety. Productivity without losing traceability.

For software, vibe coding is mostly fine. The blast radius is a wasted afternoon.

For hardware, the blast radius is a sparking motor and a pendulum on the floor.

The process… in a nutshell.

Buy an untrimmed brisket. Packer cut. Trim to a quarter-inch fat cap. Rub with a rub of coarse salt and pepper (and nothing else, right). Smoke at 225°F on a Weber Smokey Mountain over post oak and pecan until the bark sets. Wrap in pink butcher paper with rendered tallow. Smoke until the probe slides in like butter. Rest in a dry cooler for hours. Slice against the grain.

I tried a few smokers over the years, but I still love my Weber Smoky Mountain (WSM). Harry Soo, who has won Grand Championships on the exact smoker said it best:

“Where else in the world can $300 and a pit get you the opportunity to cook against the best Pit Masters in the world?”

What got validated over the years

Lawry’s in the rub. The original recipe was half Lawry’s Seasoned Salt, half kosher salt, full cup of coarse Tellicherry pepper. People on the internet had opinions. Then Goldee’s in Fort Worth got named the #1 barbecue in Texas by Texas Monthly, and pitmaster Jonny White told the magazine, “Lawry’s goes on all the briskets at Goldee’s.” He called it the best secret ingredient in barbecue. I’d like it noted for the record.

Water in the pan. There’s a whole cottage industry telling you to replace the WSM water pan with sand, ceramic, or nothing. I tried them all. I went back to water. Chris Allingham at Virtual Weber Bullet said, “It’s almost impossible to run the Weber Bullet over 275°F as long as the pan is filled with water.”

The long rest. The 4-6 hour rest seemed to be perfect for brisket. Don’t skip the rest phase.

What changed in five years

Two probes, not one. This is the single biggest jump in quality. The flat and the point are two different cooks happening on one piece of meat. The point runs about 10°F hotter than the flat for most of the smoke. I used to pull when the flat hit 170°F. Now I pull on the average.

I write down every cook. Brisket weight, flat-to-point thickness ratio, ambient temp, fuel load, the time the probe-test passes. Median probe-test temp across 100 cooks: 203°F. Range: 198°F to 209°F.

I plan the rest, not the cook. I used to plan backwards from “brisket goes on the smoker.” Now I plan backwards from “brisket comes out of the cooler.”

What I’m trying next

The list for this summer:

• Buy by shape, not weight. The hypothesis is that an aerodynamic 12-pounder beats a lumpy 16-pounder every time.
• Render my own tallow every cook. I’ve used jarred Wagyu tallow. It’s fine. Tallow rendered from the trimmings of the brisket I’m cooking is the same flavor DNA as what’s on the grate.
• Fewer wood chunks, earlier. I think I’ve been over-smoking the bark in hour two. Going to try three chunks instead of five and see if the bark changes.

The short list

1. Buy by shape, not by weight.
2. Two probes. One in the flat, one in the point.
3. Salt, pepper, and Lawry’s.
4. Trust the water pan. It’s the WSM’s cruise control.
5. Rest longer than feels reasonable.
6. Keep a log.

In the year 2030…

I’m going to write the 2030 version of this post and half of what I wrote here will be updated, maybe AI will unlock more secrets of brisket smoking.

If you cook a brisket from the original guide, or from this update, tell me how it went. What you changed. What would you do differently? The more we share, the better we all get.