Last month I finished one of the largest side project of my career — an open-source framework, docs, demo, the works. Eight-years-ago me would have floated for a week.
Instead I felt… fine. Mildly pleased. Like I'd closed a well-run Jira ticket.
Here's the thing: a big part of the code was written with AI assistance. I designed everything — the concepts, the failure semantics, what the demo had to prove — and I reviewed everything. The thinking was mine. But the hours of grinding, the stupid bugs at midnight, the twentieth test run — those are gone. And apparently that's where the feeling lived.
I'm not against this. I don't actually want to hand-write boilerplate again, the same way I don't want to hand-wash clothes. But nobody warned me that the satisfaction was coupled to the struggle, and that automating one would automate away the other.
The best analogy I've found: it's the difference between cooking a meal and ordering a very good delivery. The food might even be better. But you didn't cook.
What I've been trying
- Keeping one deliberately hand-made project where AI is only allowed to explain, never to type
- Going deeper into the work AI can't do yet e.g. production debugging
- Letting "people actually use the thing I designed" become the new reward channel instead of "I typed the thing"
Jury's still out.
So, the actual question
Does anyone else feel this?
If you've been coding 5+ years and work with AI daily — where did your satisfaction move? Did it come back somewhere else, or is it just gone?
And for folks earlier in their careers: do you even relate to this, or does it sound like blacksmiths complaining about factories?
Genuinely curious what this community is feeling.
Top comments (4)
The cooking comparison is accurate. When you cook, you manage the heat and the carryover, and the outcome depends on paying attention to the pan. Ordering delivery removes the variance, so even when the meal arrives hot, there was no risk to absorb.
With assisted code, the labor changes from synthesis to review. Instead of wrestling a state machine into place, you spend the afternoon reading generated diffs and looking for unhandled edge cases. That work is necessary, but it feels like auditing someone else's books rather than building the ledger. For me, the reward moved to whether the invariants hold under production stress and whether my boundary tests caught the failure before the model shipped it. It is a quiet satisfaction, more like reconciling accounts at the end of the month than stepping back from a finished workshop table.
"Auditing someone else’s books rather than building the ledger” is exactly the sentence I was missing.
What’s interesting is you’ve found the reward on the other side of that shift: the invariants holding, the boundary test that caught it first. I had a moment like that recently — a failure-containment path I’d designed tripped correctly in production, stopped exactly the broken scope and nothing else — and it genuinely felt better.
Quieter, like you said, but real. Maybe that’s just what the reward looks like now — fewer fireworks, more “the books balance".
Ordering delivery vs cooking is a sharp way to put it. Has the hand-made project given any of that feeling back yet?
Honestly, too early to say — but I’ve already noticed something that makes me doubt the experiment. When I get stuck, the old reflex was a GitHub issue, a Stack Overflow thread, actually reading the docs. Now the fallback is AI chat, because spending an hour digging when I could have the answer in thirty seconds just feels like waste — even on a project where the digging was supposed to be the point.
So the hand-made project isn’t the solution, it’s a diet I keep cheating on. Right now I think Dean Lee has it right in another comment here — the realistic move isn’t recreating the old reward, it’s relocating it to quieter victories: the invariants holding, the boundary test that caught it first.