Developers Are Human

Over 30 years ago, a CS professor of mine dropped a piece of wisdom as an aside in class. Dr. Soroka told us that every time he fixed something in a program, he got a little jolt of happiness. A little high. And he’d noticed something curious: the size of the high was not proportional to the size of the problem. Solving a big gnarly bug felt better than a tiny one, but not remarkably better. So he’d come to the conclusion that if he broke every problem into tiny problems, the frequency of those little wins would propel him through a project far faster than chasing a few big ones. Consistent quantity beats occasional quality.

This was long before anyone said “agile” or “XP.” It was just one programmer noticing how his own brain ran. And I think it’s a fantastic lens for understanding something happening right now with AI-assisted development.

The weight comes off

Marco Arment, on ATP last week, walked through some encouraging and energizing recent experience. Marco has spent years as the solo developer of Overcast, and like every solo developer, he’s carried bugs he couldn’t get to. Not because he didn’t care, but because some bugs are deep, gnarly, and expensive time-wise, and there’s only one of him. Years of that wears a person down. You see a bug report and you agree, but you also know you took a half-finished run at that and you have no idea what to do next.

Now he’s handing those longstanding bugs to AI, and getting actionable feedback. In some cases, he looks at the solution and it’s already complete. He described the same thing happening with features: ideas he’d built halfway and shelved, because he could never quite land the edge cases at Overcast’s scale, are getting polished and shipped. The monotonous work, test cases, documentation, is getting done without consuming him. It’s a running joke on ATP that Marco doesn’t write any tests (to the horror of John and Casey), but now Overcast has a bunch.

The result he described wasn’t a throughput number or a burn down chart. He said he feels energized to work on his app again, that it’s almost more fun being a “director” than the only developer. Marco was always capable of fixing those bugs or shipping those features – Overcast is a fantastic app and might be the most used app on my phone. What changed is how the work feels. The weight came off.

Tedious but necessary

His experience matches mine almost beat for beat. I started AI-assisted development cautiously: asking questions about APIs and technologies I didn’t know well, and checking my understanding as I went. “So if X occurs, I’d receive Y back from this call?” is exponentially better than simply having a giant API doc. Next, I kept writing code by hand but handed off the boilerplate of writing tests.

The lightbulb moment for me was a database rewrite. We’d built our data architecture in an older style, but the newer pattern was CQRS: separating the command side from the query side. As soon as it was brought up, I could see it was a good idea – and it meant blowing up a working implementation and writing an enormous amount of near-identical plumbing. Commands, handlers, query objects, mapping, all of it mechanical, all of it needing to be exactly right, none of it requiring much actual thought. The definition of a slog. With AI, however, it was almost embarrassingly simple. I started throwing pieces in, reviewed as it went, and the tedium just… evaporated.

So much of good architecture is simply doing the tedious but necessary things, and AI removes the tedium. The right pattern usually loses to the easy one not because teams don’t know better, but because the right pattern is a mountain of mind-numbing work. Take the mountain away and suddenly doing things correctly is affordable. Cheap code changes everything, and this is one of the places it changes most: you keep the thinking, you skip the slog.

Momentum is a job to be done

We measure AI’s impact in speed: more code, faster shipping. But developers are human, and humans don’t run on velocity. We run on momentum, and momentum is made of little wins. Jobs-to-be-done theory makes this point about the motivations that lead people to hire products: the strongest jobs are rarely functional. They’re emotional and social. We hire products to make a change in our lives that we want, as humans, and “practical” often has little to do with it. Benedict Evans put it well: “If we only ever bought things that had rational use cases and the best value, we’d all be wearing boiler suits, or hoodies.”

Developers hire their tools and their workflows the same way. A years-old bug finally closed and a stalled feature finally shipped aren’t just backlog items resolved. They’re ways of unblocking Dr. Soroka’s little highs, arriving frequently again. That’s a real job, and it was going unserved. It’s part of why the original agile insight worked, long before it calcified into ceremony: shipping continuously feels good, and the feeling compounds into trust with everyone watching the product grow.

A manager of robots

But this also reveals how AI-assisted coding can flip into the negative side as well. I’ve heard countless stories of developers who’ve been told that they must use AI to do everything. Great developers care, and telling them that they should care less about what they are shipping is not only insulting, it’s demoralizing.

About a year ago, a developer on my team told me in a 1-1 that the AI moment had him feeling low. “Everyone’s crowing about how AI is going to write all the code now. But I like writing code. It’s what I’m good at and love doing. And now it’s being taken away and I’m just a manager of robots.”

I’ve written before that AI is a fantastic tool and a terrible machine, and his fear is exactly what the machine version feels like from the inside: the human reduced to an appendage, keeping up with output instead of owning the work. AI burnout is real, and a team driven by its AI instead of driving it will end up more worn down than before, not less. Pure velocity means you don’t get the joy of shipping often, you get the worry of shipping things you now feel disconnected from.

What I told him, after listening, was that I saw it differently and that’s definitely not what we want here at BiTE. What I’ve always loved about programming was never the typing or the slog. It was the problem-solving, chasing those little highs, and what solving them unlocked: creating things with my mind that fix real problems for real people. So if AI could pick up the tasks I always felt I ought to do but rarely had the energy or time for, that’s exactly where I’d send it. He’s a developer who cares deeply about craft, and the reframe landed: You own the work. Send AI the chores. Keep the thinking parts for yourself.

Point it at the slog

Even in the AI era, software teams are made of people. And that means what Dr. Soroka figured out over 30 years ago with no AI in sight still holds: the frequency of little wins is what moves a project. And that’s where AI unlocks a lot: We have a tool that can markedly raise that frequency. Point it at the slog, buy yourself margin for the real, necessary thinking work, and enjoy the work again.