A few weeks ago, I was reviewing the work that Claude — an AI assistant — had done during a programming session, and I noticed something that stopped me cold. I had been using Claude Code to build an issue-tracking application, and somewhere around the sixth session, after the core API was working, Claude started doing something I never asked it to do. It began using the issue tracker to track issues with the issue-tracking application itself.

Let me say that again. The AI saw a tool for managing issues, recognized it was useful, and started using it — on its own — to manage the very project it was building. Not only that, it identified enhancements that would make the tracker work better, logged them as issues, and then implemented them.

I sat there staring at the screen, genuinely unsure what to think. Part of me was amazed. Part of me was a little unnerved. And part of me — the part that has spent decades getting sucked into programming problems — felt something I didn’t expect: relief. But I’m getting ahead of myself. To explain why that moment hit me so hard, I need to go back — way back — to when I ran track in high school.

I ran track all through junior high and high school. My older brother was a six-foot-tall track star who held the school record in the mile and two-mile runs for twenty years. I topped out at five-foot-seven in eighth grade, and that was the last year I was even somewhat competitive in individual events like the 400-yard dash. After that, everyone else grew up and left me in the dust — literally (our track was cinder).

My saving grace was that we had a small high school with a small track team, and they needed bodies for the relays. I ended up running the anchor leg. The most athletic guy on the team ran first, which helped. We rarely won, but we sometimes didn’t come in last. There was a kind of humility in that — accepting that my contribution was one piece of something larger, and that finishing the race mattered more than finishing first.

I didn’t know it at the time, but that lesson would keep showing up in my life.

After high school, I went to graduate school to become a professor of psychology. That career didn’t work out — I wasn’t able to publish my dissertation, which was pretty much a death sentence in academia. The topic, of all things, was emotional relief — I built a custom program that measured blood pressure and heart rate while college students took a test and failed, studying what happened in the body when the stress lifted. I couldn’t get the paper published. But while working on the experiment, I discovered something: I liked programming.

That discovery led me into state government — first in research, then in IT. But programming also sucked me in. Big time. I would get stuck on some challenging aspect of a program and think about it day and night until I figured out a solution. The worst part was that I usually did figure it out, which only reinforced the behavior — but only after I’d devoted far more hours and mental energy than I should have. When I eventually became an IT manager, I had trouble making the shift. I often drifted back to writing code because, frankly, it was easier than managing people. Programming problems have solutions. People problems often don’t.

I tell you all of this because it’s the backdrop against which AI showed up in my life — and why what happened with the issue tracker meant more to me than a cool tech demo.

Over the past few months, I’ve been using generative AI — specifically Anthropic’s Claude — to help with programming projects at home. My approach has evolved through several stages, each one teaching me something about letting go.

AI chat sessions have limited memory. Once a project gets complex, you bump up against that limit. So I started splitting work across multiple sessions, and at the end of each one I’d create a structured summary of what we’d accomplished, what decisions were made, and what was still outstanding. I called these summaries BATONs, because that’s what they were: something handed off between sessions so the work could continue. (And because, as I mentioned, I have a soft spot for relays.)

The BATON approach worked — until my projects grew to span multiple Claude projects, and I found myself juggling BATONs across all of them, losing track of which issues had been resolved, and occasionally feeding Claude outdated files. Then I discovered Claude Code, which integrates AI directly into my development environment. Instead of maintaining separate files, I gave Claude access to my actual project files. Each session, Claude would receive a BATON, build a plan, and execute it step by step.

This was transformative. But I still had a nagging problem: tracking issues across sessions. If something was raised in session three and revisited in session seven, you’d have to read through multiple BATONs to follow the thread. I needed something better.

So I decided to build a centralized issue tracker with a REST API that Claude could use to create, update, and query issues. I chose .NET for the API and Blazor for the front end. It took about a day and twelve sessions, and Claude produced a working application complete with integration tests and solid documentation.

And then came that moment I described at the beginning. Session six. Claude started using the tracker on its own. It saw the tool, understood what it was for, and began managing its own work with it. It even identified ways the tracker could be improved, logged those as issues, and then implemented the improvements.

I was floored. But as I sat with it, I realized why it affected me so deeply. For decades, I had been the person who couldn’t let go — who stayed up thinking about the code, who drifted back to programming when I should have been managing. And here, for the first time, I was something different. I wasn’t the programmer chasing an elusive solution. I was one part supervisor, one part consultant, one part project manager, one part customer. I was providing direction, reviewing work, and handing things off.

This time, someone else was running anchor — and bringing home a win.

This blog has always been about spiritual matters, and this post is a departure. But maybe not entirely.

There’s a pattern in my life that I’m starting to recognize. I wasn’t fast enough to run on my own, so I ran relays and learned that finishing the race mattered more than finishing first. I wasn’t able to publish my way into academia, so I stumbled into programming — work that sustained me for decades, even if it consumed me more than it should have. And now AI is offering me something I didn’t know I needed: a way to do the work I love without it swallowing me whole.

Each of these felt like a limitation at the time. Each turned out to be a kind of gift. And the relief I spent a failed dissertation trying to study? I think I’m finally starting to feel it.

I once wrote about picking up trash on the way to work and discovering that what I thought was an exercise in humility was actually a test of whether I could quiet my judgment. The real assignment was hiding beneath the obvious one. I wonder if something similar is happening here. I thought the assignment was to build a better workflow for managing AI sessions. But maybe the real assignment — the one that’s been waiting for me since high school — is learning to carry my part and trust the handoff.

If you’re interested in the issue tracker and how it works with Claude Code, you can check out my GitHub repo. I’m sure the tool will keep evolving — or something better will come along. That’s how it works when you’re a dabbler. You stay open, you keep learning, and every now and then, something you built hands you back more than you gave it.