Somewhere in the last year, a bunch of us who hadn’t shipped real code in years quietly started shipping again. Not reviewing it. Not architecting it in a doc and handing it off. Actually building it. And loving it.
I lead software for a living. That means my days are meetings, roadmaps, hiring, unblocking people, and saying “no” a lot. The last time “writing code” was my actual job was a long time ago. I never stopped being able to code — I stopped having the time to code. At least in my day job. There’s a difference, and every engineering leader reading this feels it in their bones.
That changed. And I’m not the only one. I’m even making more time for personal coding projects BECAUSE IT’S FUN AGAIN!
I’m Not Imagining This
Look at who’s back in the editor - well, back in the terminal now - editors are so last year.
Kent Beck — the guy who gave us Extreme Programming and helped write the Agile Manifesto — told the Pragmatic Engineer that after 52 years of coding he was kind of tired of it, and agents brought the joy back. His words: he can be “a lot more ambitious” now. He’s building things he’d shelved for years.
DHH — David Heinemeier Hansson, who created Rails — spent 2024 openly skeptical of AI coding. He said autocomplete made him “literally feel competence draining out of my fingers.” Then he reversed himself. Running a pack of agents, he says, “feels less like project management and more like wearing a mech suit.” That’s a hell of a turnaround from a very opinionated man.
Garry Tan, who runs Y Combinator, is personally back in the code with Claude Code: “I love coding but I love coding with AI even more.” He claims he re-created a startup that “took $10 million in VC capital and 10 people.” By himself.
And of course Andrej Karpathy coined “vibe coding,” then had to invent a second term — “agentic engineering” — for when you actually care about the result. Even the vocabulary can’t keep up.
Notice the pattern. These aren’t juniors discovering programming. These are veterans and leaders who’d drifted away from the keyboard, pulled back. And every one of them frames it the same way: not “I’m faster now,” but “I’m more ambitious now.”
Think about that for a minute.
The people who stopped coding didn't forget how. They ran out of time. That constraint just broke.
Years of “Someday” — Now Done Before Lunch
Here’s what this actually feels like day to day.
I keep a mental list. Every engineer with a few decades on them has this list. It’s the graveyard of “pretty sure that would work if I ever had a weekend to look into it.” Little tools. Integrations. That one gnarly automation for the house. Ideas that were obviously possible but never quite worth the multi-week tax of learning the framework-of-the-month, wiring the boilerplate, and debugging the YAML.
That list used to just… grow. Forever.
Now I go from “pretty sure this would work if only I had the time” to “yep, done — and it actually saves me time” in an afternoon.
Seriously. An afternoon.
Not a toy demo. A real thing that solves a real problem I’ve been staring at for years. The idea sat on the shelf not because it was hard to imagine, but because it was expensive to build. That expense collapsed. What’s left is the part I was always good at anyway: knowing what I wanted.
The Magic Is Only Half AI
And this is the part everybody selling you a subscription conveniently skips.
The AI is half of it. Maybe less.
The other half — the half that matters — is that I know what I want to build. I know what’s possible. I know which problems are real and which are imaginary. I know what “good” looks like because I’ve shipped enough bad to recognize it. That judgment isn’t something the model brings to the table. It’s something I bring, earned over decades of doing the work, breaking things, and being on the pager when they broke at 3am.
An agent handed to someone who doesn’t know what they want produces a confident pile of plausible nonsense. Fast. The same agent handed to someone who knows exactly the shape of the solution and can smell when it’s drifting? That’s the mech suit. That’s the leverage.
BOTH can be true. The tool is astonishing AND the tool is nothing without the human steering it. The industry keeps trying to pick one of those. Baloney. It’s both.
This is, incidentally, why I’m not worried about my job or yours — the taste, the judgment, the knowing what to build and why is the whole game now. The typing was never the hard part. We just used to think it was.
Yes, the Skeptics Have a Point
Let me not get too high on my own supply here.
There’s a real counter-argument, and smart people make it. Folks like Jim Grey and the crew at LeadDev argue that AI does not actually free managers to code, because the coordination overhead of leading humans grows faster than any tool can shrink the coding. The “player-coach” thing is a trap: you end up doing both jobs badly. And Atlassian’s research keeps reminding us that senior engineers already spend a shrinking sliver of their week actually writing code.
They’re not wrong. If you’re a leader and you start hoarding the fun coding tasks to feel productive while your team drowns, you’ve failed at the actual job. Don’t do that.
But here’s the thing. I’m not talking about pulling stories off the team’s sprint board. I’m talking about the stuff that would never have been built by anyone — the personal tools, the “software for one,” the ideas that only ever lived in my head because they were nobody’s job. That’s not stealing from the team. That’s reclaiming a part of myself that the last two decades of complexity had quietly amputated.
And let me be clear about a boundary I hold hard, even in my day job. A senior leader has no business owning a critical part of the product — not if they’re also expected to show up as part of the leadership team. I cannot take a key module in our core SaaS product. Ever. Because you never know when I’ll get pulled into some fire for a day, or a week, and suddenly I’m the long pole in the tent, blocking a release because I had the audacity to think I could be on the critical path. That’s not being a builder. That’s being a liability. Don’t do it.
But — and this is the new part — the time it takes to actually finish something useful has shrunk so much that I don’t have to own the critical path to build real things. I can do a proof of concept. I can build a small, isolable component that lives at the edge, where my getting yanked away for a week doesn’t sink anyone’s sprint. In my actual day job right now I’ve been writing new code that drives the NPU in our media player — genuinely useful, genuinely mine, and genuinely not the kind of thing that blocks the release train if I disappear into meetings for a few days. For that class of work, I get to be a builder again. I think that distinction — critical path stays with the team, isolable and exploratory work opens back up to leadership — is going to quietly change how we manage software teams. But that’s a topic for another day.
Both can be true. Again.
Software For One
Which brings me to the thing I actually want to say.
We are entering the era of software for one. (Thanks to Scott Francis for coining that term — and if you’re not reading his posts, you are really missing out.)
Software for one: a tool shaped to exactly your problem. No business case required.
For the first time in my career, it is completely rational to build a piece of software that exactly one human will ever use — because building it costs an afternoon instead of a month. A tool shaped precisely to your problem, your house, your workflow, your weird edge case that no product manager would ever prioritize. It doesn’t need a business case. It doesn’t need scale. It needs to work for you. And now it can.
That’s genuinely new. And it’s beautiful. And I have two such projects running in a terminal in another window right now.
And this, by the way, is exactly why I think software engineers are going to stay in high demand — not less. Scale “software for one” up to “software for one company.” An organization can now have precisely the thing it wants, built to its exact workflow, instead of filing a feature request and waiting eighteen months for some vendor to maybe get around to it on their roadmap. The company that can build for itself stops waiting. And building for yourself takes engineers — engineers with judgment, who know what to build and why. The demand doesn’t shrink. It moves. But that’s a whole other post!
But it stops being beautiful if it stops there.
So Give It Back
Here’s my ask. My actual point. The reason I wrote this.
If you build the little thing — share it.
I grew up as an engineer in the open source era. My first Linux kernel was before it hit 1.0. I have spent my entire career standing on a mountain of software that thousands of people I’ve never met built and then gave away. Linux. GNU. The compilers, the libraries, the tools, the endless Stack Overflow answers, the README that saved my weekend. I didn’t pay those people. I can’t pay those people. So many smart, generous folks went before us and just… gave it back.
If that’s your heritage too, then building your little slice of a solution and keeping it locked in a private repo should feel wrong. It should itch. Worse, it should make you feel sick.
And here’s the new wrinkle that makes it matter more than ever: the next person to find your code might not be a person at all.
It might be an agent. Somebody, somewhere, points their AI at a problem, and the agent goes looking — through repos, through issues, through the great commons of published human work — for a pattern, a fix, a starting point. And if your dumb little afternoon project is out there, indexed, MIT-licensed, honest about what it does and doesn’t do… it might be the exact thing that unblocks some stranger’s real problem. Delivered by a machine acting on their behalf, drawing on a gift you made.
If my slice can help someone I’ll never meet — through a human or their agent — then hell yes. That’s the whole point. That’s what the commons is.
And People ARE Doing It
Here’s what makes me genuinely optimistic: this isn’t hypothetical. Folks are already shipping the stuff. Cool, useful things I’ve wanted for years are just… showing up. AI-assisted or not — honestly, who cares — the point is they exist now, and they’re out in the open.
A couple that landed on my radar recently and made me grin:
- Bootimus — a self-contained PXE and HTTP boot server. One Go binary, auto-detects 50+ Linux distros, web UI, no router surgery, Apache 2.0, no telemetry. I have wanted exactly this for network-booting boards on my bench for longer than I care to admit. Somebody just… built it and gave it away.
- Solod — a strict subset of Go that transpiles to readable C11 with zero runtime overhead. Go’s ergonomics, C’s reach, down onto the metal. For someone who lives on both the cloud and the microcontroller, this is the kind of thing I’d have killed for. BSD-licensed. Out there. Free.
Neither of those is a toy. They’re real answers to real problems, sitting in public repos, waiting for the next person — or the next agent — to find them. I have no idea if they used AI to help build them - and I don’t care.
And yes, I’m doing my part too. My own robotic dreams have been on that “someday” list for decades, and they finally have legs: Gorai, a modern open-source robotics framework in Go, built from the ground up for the agentic era. It’s the thing I always wanted to exist and never had the runway to build. Now it exists. And it’s out there for you, too.
That’s the flywheel. You take from the commons, you build the thing you always wanted, you put it back. Someone else takes that and builds the next thing.
Even Linus Doesn’t Care
And if you’re still clutching your pearls about whether AI-assisted code belongs in the commons, well — the guy who built the commons just told you to relax.
Last week Linus Torvalds put his foot down on the Linux kernel mailing list. His position, roughly: “AI is a tool, just like other tools we use. And it’s clearly a useful one.” He flat-out refused to make Linux an anti-AI project — and told the objectors that if they have a problem with that, they can do the open-source thing and fork it, or just walk away. This is the same Linus who was openly skeptical of the hype back in 2024. He looked at the actual results and changed his mind.
Think about who that is. Linus does not hand out endorsements. He is famously, gloriously allergic to nonsense. And he looked at AI contributions to the most important open-source project on Earth and said: it’s a tool, judge the code on its merits, next question.
So when someone tells you your AI-assisted afternoon project doesn’t count, or shouldn’t be shared, or isn’t “real” — remember that the naysayers are just… being naysayers. They always show up. They showed up for the compiler, for open source, for the cloud, for every one of these shifts. And every time, the builders quietly kept building, and the world moved on without them. Judge the work, not the tool that helped make it.
Because Linux. Because GNU.
The commons was a gift from people who went before us. Keep the flame moving.
So this is my pitch to every senior engineer and every engineering leader reading this who felt that old itch come back over the last year.
You can build again. The thing that stopped you — time, cognitive load, the treadmill of learning the latest required thing — that constraint broke. The judgment you spent thirty years earning is now the scarcest, most valuable half of the equation. Go use it.
Build the thing that’s been on your list for years. It’ll take an afternoon.
Then don’t keep it. Slap an open-source license on it, write an honest README, push it somewhere public. Because Linux. Because GNU. Because a long line of smart, generous people gave it all back so that you and I could stand where we stand.
Pay it forward. Build something. Share it.
If this resonated — or if you just shipped something you’d shelved for years — I’d genuinely love to hear about it. Drop me a note on LinkedIn: linkedin.com/in/gherlein.