Next article might be called “I scaled a Postgres database while skydiving.”
Last Sunday, I was supposed to go to a photography exhibition. But just before leaving, I couldn’t let go of my side project — a state many developers know all too well.
Rather than fight it, I tried an experiment: open a pull request from my phone, while walking through the exhibition.
A feature I would never have coded myself
I ask Claude Code on my phone to implement a feature in Plan mode — one I probably would never have taken the time to build with my own hands. What happens next feels almost unreal.
Claude Code spins up an instance, breaks down and designs the feature, implements it, creates the tests — all governed by extremely demanding code quality rules. It runs unit tests, functional tests and linting, opens the pull request and generates a preview environment.
Meanwhile, I’m walking between two series of black and white prints.
I receive the preview. I test. I validate. I merge. The feature is deployed to production. All of this from a photo exhibition.
Is it impressive?
Yes. Clearly. A few years ago, this would have looked like science fiction. Friction has become almost zero. Execution, instant. The limit is no longer technical.
Is it satisfying?
Surprisingly… no. Something is missing.
Not that familiar feeling of a job well done. Not that small moment where you look at your code and think: “It’s clean. It holds.”
Instead, an urge to go further. To add even more features. Because I didn’t encounter any resistance. Because I didn’t hit any limit. The effort disappeared. And with it, part of the satisfaction.
The flip side of magic
If we can add features at this speed — without friction, without fatigue, without apparent constraint — what are we building in the long run?
Probably phenomenal technical debt and heightened bug risks — all made invisible by ease.
The natural difficulty of development served as a regulator. It forced us to prioritize, to simplify, to let go. Today, that brake is gone. The real question may no longer be 'what can we build?' but 'what framework do we set for ourselves so we don't break everything?'
Explore More