A different kind of tired

Six months with AI and the code got easier. But something else got more difficult.

Hey friends,

Earlier this year I was freaked out about AI. I’ve spent the months since using it constantly, on every project, at every stage. I expected to feel replaced, or at least unsettled. Instead, something underneath the work shifted.

The hard part of my job moved. But the new version is better.

What I used to get tired from

A year ago, the hard days all had the same shape. I’d close the laptop with a specific flavor of tired: I couldn’t figure out how to make a thing work. Not “this took a while.” More like banging my head against a wall for hours, trying the same thing eighteen different ways, and still not knowing why it wasn’t working.

Framework fights. State bugs. Xcode rituals. That Rails method that should have returned the thing and didn’t. The weird edge case on Android where the webview loaded twice.

That was the work. Or at least, that was the part that drained me.

It mostly doesn’t happen anymore.

The feature I wouldn’t have touched last year

Last month I was scoping a feature for Ruby Native, my new service that lets Rails developers ship an iOS app without touching native code. The feature: monitor a private build happening on GitHub Actions, validate the inbound webhooks from Apple as the binary gets processed, and surface live progress in the Rails dashboard the whole way to TestFlight.

A year ago, I would have shied away from that idea. Not because I couldn’t write the code. Because I wouldn’t have thought it was worth the investment. Inbound webhooks from Apple, signature validation, live UI updates, error states for a service where most of the errors aren’t mine? That was weeks of yak shaving for a feature most users would never see fail.

This month, the code wasn’t the problem.

The hard part was the product decisions. How do I show the user this is working? How do I show it succeeded? How do I write the error messages so they don’t have to open App Store Connect and stare at Apple’s rejection language? How do I keep them inside my app, away from Apple’s interface, as much as possible?

That’s the hard work now. And it’s much closer to the user than anything I used to spend my time on.

I love it. It’s the work I thought I was doing all along.

That same week I got off a client call where we spent an hour brainstorming a fully native navigation bar. Custom buttons, dynamic content, state that depends on the user. A year ago I would have steered the conversation toward phase two. This time we just ironed out what it should be and built it.

The feature ideas got bigger. The implementation got smaller. That’s the trade.

Why I’m mostly settled now

Ruby Native is my second AI-led project. On my first I spent too much of it looking over AI’s shoulder. Reading every diff. Second-guessing every suggestion. Reviewing code I didn’t need to review because I didn’t yet trust the tool to get it right.

With Ruby Native I review the critical stuff. Anything that touches signing, money, or the App Store. The rest, I mostly let run.

That change, from monitoring to trusting, is what moved me from “freaked out” in January to “mostly settled” now. It wasn’t a realization. It was reps. A few weeks of building real things and watching the tool deliver.

What I miss

I want to be honest about one thing.

I used to end the day done. The sheer difficulty of getting through a hard problem was a barrier that told me to close the laptop and go be a person for a while. I’d earned the break.

Now the barrier is gone. I pick up my laptop all the time because it’s so easy to just start another thing. No context switching tax. No warm-up. No twenty minutes of remembering where I left off. Just go.

The new hard thing is knowing when to stop. I’m still figuring that one out.

What it means for the work I sell

Something else has started to change, too. How I quote projects.

I’m still figuring it out, but the shape is clear. I’m billing expertise and judgment, not code output. I can build and maintain more than I could a year ago, which means the thing I’m actually charging for isn’t “how many hours the typing took.” It’s “what should be built, in what order, with which tradeoffs, to avoid which gotchas.”

That’s the work I wanted to be paid for anyway. It’s the part I’m best at.

What’s next

The hard part of my job moved. It used to be “how do I make this work?” Now it’s “what should I actually build, and how will the user feel when they use it?”

I would rather be tired from the second question than the first.

If you’re a Rails business figuring out what to build before you write a line of code, that’s exactly what the Mobile Playbook is for. Two weeks, a framework recommendation, an architecture diagram, App Store gotchas mapped out, and a phased build plan you can hand to any developer. Including yourself. Including Claude.