Confessions of an AI Vampire

The short version

Adapted from my ThunderPlains talk on October 21, 2026. Edited for reading.

My wife bet me I wouldn't do this in a vampire costume, so here we are. Thanks, babe.

I called this talk Confessions of an AI Vampire because I've struggled this year with being able to go to sleep. There's always one more thing I could do. When I started orchestrating several agents, I was trying to keep them going 24 hours a day. I'm pretty anti-push notifications, but I had one set up for the product manager of Codex on X because he would tweet when there was going to be a reset. At two in the morning, I'd be setting an alarm. It was chaos trying to keep all of this running.

Then I started building systems around it. That's what I wanted to walk through in this talk: how I got from using AI to help with a few functions to managing a whole lot of agents, and what I've learned about the human part of that job.

How I got here

I learned to code about ten years ago because I wanted to build a gardening app. We built Seed to Spoon, grew it to over a million users, and sold it. After the acquisition, I started working in private equity and ended up responsible for technologies I'd never worked with before.

My background was modern application development, mostly TypeScript and some C#. I was good at building CRUD apps and business software. I wasn't building my own frameworks. After the acquisition, I was responsible for technologies I hadn't worked with before, including Python and WebSphere. That coincided with ChatGPT coming out, and I started leaning heavily on AI.

At first, it was a helpful editor assistant. I used VS Code and then Cursor, but for a couple of years I was still working a few functions or files at a time. Later, I started using Codex CLI and Claude Code, and that turned into orchestrating several different agents. Before joining Untangle, I was usually managing five or six agents locally, working on different tasks.

Earlier this month, I joined Untangle, which Ryan Carson built with AI. Ryan also founded Treehouse, the website where I learned to code ten years ago. That's a pretty cool full-circle moment. We've been combining his processes with mine, and we're still learning as we go.

Moving to Devin changed a lot because the work was running in the cloud. I wasn't managing all those worktrees and running out of disk space on my laptop. Each task had its own virtual machine where I could see what was happening and work with it. The scale went from five or six local agents to up to 150 active sessions, and I needed better ways to keep track of everything coming back.

Please embrace voice mode

If there's one tip I can drive home, it's this: please embrace voice mode. It has completely changed how I work.

It started with one-way voice messages. I'd click the microphone and brain dump everything about the problem I was trying to solve. Every concern, every piece of context, everything your grandma told you might happen if you do it. Get it out. That's still the first step for me, and now I also spend a lot of time talking back and forth with Devin.

I've learned to leave room for it to have a better idea. I explain the problem, how I've solved it in the past, why we're doing it, and the things I'm worried about. I also tell it to be honest with me. If there's a better way than the thing I'm asking for, I want to hear it. I try to give it as much context as I can without deciding every technical detail up front.

Once there's a plan, I separate the work into threads. I don't have one thread do everything. Each piece gets its own context, and the decisions need somewhere permanent to live.

For me, that's Linear. If I rely on one conversation, eventually it compacts and something gets lost. Then we're back to, “Hey, I thought I told you to do that.” I use Linear as the source of truth that Codex, Claude, Devin, and my dashboard can all look at. It doesn't have to be Linear. If you're working on your own, it could be Markdown files. What matters is that it isn't just the context window.

Give the agents a manager

If you're already juggling several threads, I'd encourage you to try an orchestrator thread: one thread that manages the work below it, while you work with that one thread.

I started with one manager handling the other threads. Eventually, there was too much happening for that manager to keep up with, too. Now I have several layers, with managers responsible for different areas and builders doing the individual tasks. The handoffs matter because I need to understand what's coming back without reconstructing every conversation.

I spend much more of my time working on skills and processes now than on the code coming out of them. When something happens that I don't like, I zoom in on it. How did that happen? Go analyze it. How do we prevent it from happening again? I don't want to gloss over that part.

This is where all the experience from working in software still helps. When I'm building a skill, I think about the best people I've worked with in that role. What did they always tell me? What did they look for? I've worked in product management, QA, customer service, and development, and I'm drawing on all of those.

Getting UI that doesn't look like everything else

Last year, I spoke at ThunderPlains about how I wasn't going to make a guitar app. I've made four guitar apps since then.

For the UI, I start by getting a working prototype. I want the nuts and bolts working the way I want. Then I work with an image generation model on the visual direction. I give it screenshots, references, and another big brain dump of what I have in mind.

I'll ask for four mockups that are fairly close to what people normally do, and four where it can use its little robot heart and go wild. Those usually have some weird things in them, but there will be pieces where I think, that's cool.

Then I take the parts I like across those options and ask for four more that combine them. I have to narrow it down each round because I could do that all day. Eventually, I pick one and give that image to the coding model: make it look like this.

That process feels a lot like working with designers throughout my career. I have something in mind, I do my best to explain it, and then we iterate on it. The result can be much better than the thing I started with.

I did QA myself before I automated it

When I started building the QA process, I wanted my hands on the wheel for a bit. I needed to find out what was useful before I automated it.

As work came back, I reviewed it myself. There were questions I kept asking over and over, and other questions that didn't really go anywhere. I learned what worked and what didn't, and then built that into a skill.

One useful change was how the review videos worked. A video of an unfamiliar feature wasn't enough. I needed it to start by explaining the problem at a high level, assuming I was coming into it blind. Then, when it made sense, show me the before and after.

That gives me context before I use the app myself. I can watch the explanation, understand what changed, and then go try it. I'm not spending all that time asking what the ticket means before I can even start reviewing.

Another question I kept coming back to was, where else does this problem exist? Especially with older models, I could ask for a bug fix and get that one spot fixed while the same issue remained somewhere else. So looking for related problems and unintended side effects became part of the process, too.

The skills need maintenance. In the Q&A, someone asked about adding rules without making them too restrictive. That's one of the hardest parts for me. As models improve, I'm looking for things to prune as much as things to add. Sometimes the problem is a confusing instruction in one file and a different instruction somewhere else. More instructions aren't always helping.

The backlog needs its own attention

Once QA was finding more things, product management needed a process, too. I had issues piling up in Linear, and I needed them checked and prioritized instead of just collected.

The product management skill checks that tickets have the information I need and keeps reviewing the backlog as priorities change. Something that looked most important yesterday might not be the most important thing today. It also reconciles what the tracker says with what's actually happening in the work.

When that review catches something being dropped, I want it to help improve the engineering process, too. Fix the immediate record, but also work out why the process missed it. Having a backlog of plans that are ready to work is also what lets the agents keep going overnight.

Give it a measurable goal, and protect what matters

I used to have a general idea of how long CI took without paying that much attention to it. That changed when there was so much more work moving through it.

I spent a day trying to get the tests running faster. One thing that helped was giving the model a specific, ambitious numeric goal. I got better results than I had from just asking it to make the tests faster.

But the other half of that was protecting coverage. We looked at splitting tests into shards and auditing overlap. I wasn't saying, “Go delete half the tests.” I wanted to remove unnecessary repetition while making sure the important behavior was still covered.

Keep the human voice

Customer support is another place I've used this approach. A Slack message or video can start an investigation. Devin can pull it in, work through the issue, and bring back a summary and a change for review. I still approve the communication before anything goes back out.

I want help drafting, but I usually adjust the reply. A lot of us have spent our careers figuring out how to explain technical things to people. We know the pitfalls, we know how to talk about them, and that experience still matters.

Use your own words

I do the same thing with my own writing. I'll voice dump what I want to say, then use a writing skill to organize it and lightly clean it up. I don't want it to get far away from how I actually talk. These are my ideas and my words; I'm using AI to help turn the voice dump into something easier to read.

It's helped with ordinary messages, too. I used to overthink replies so much that my wife would have to tell me to just send something. Now I can talk through what I want to say and get it into shape. Look at me, I'm a good communicator.

What happens while I'm sleeping

There is always one more thing I could do. The night before the talk, I was working on our TV so the Thunder game could open from a calendar and take us to the right place to watch it. Then I broke the TV in the middle of the game and had to debug it. Carrie couldn't even watch the game anymore. Sorry.

Having useful work happen overnight has helped me step away. Plans that are ready can keep moving. I also have nightly reviews of the day's work, looking for gaps, repeated problems, things I had to explain over and over, and ways to improve the process. In the morning, there are recommendations to work through.

I don't rely on one AI for that. I've had good results with Claude and Codex reviewing each other's work, and now I have them doing independent audits alongside Devin. When they can't work something out, they can come to me. But they're both going to their room if they have to.

That process has made it easier to walk away at the end of the day knowing the agents are still doing something useful.

I didn't want another hobby that kept me at a computer

Carrie and I play music together, and we record our shows. That creates a lot of video editing. I didn't want another hobby where I had to sit in front of a computer, especially when half the songs I write are about being tired of sitting in front of computers.

So I've been using Codex for the editing. I give it the camera angles and audio, and it works through the set, separates songs, and creates highlight clips. Then it builds a review site we can open on our TV. We can go through the edits together and tell it what we want changed.

I'm having so much fun with AI. Personally, I still have trouble putting it down. I'm sharing these processes because I hope some of them help other people get some sleep, too.

I don't think my way is the one way to do this. It's what I'm doing, and it keeps changing. A lot of my job has always been translating between humans and computers. The computers have gotten much better, and I'm leaning on the human part of that experience as much as ever.

I've never had more fun in technology than I'm having now. We might end up in Terminator, but hey, we're in the prequel right now. It's not too bad.

The vampire entrance