The Joy of Building Again
How AI reminded me why I started coding in the first place
The Drift
I became an engineer because I’m curious. Not because I loved code, not at first. I wanted to understand how things work. Technology was one of those things. I’d pick something apart, try to make it do what I wanted, and when it didn’t work I couldn’t let it go. I’d stay with the problem until it did. That obsession is what pulled me into software. Code was just the tool that let me scratch that itch.
But curiosity doesn’t stay in one lane. The same thing that made me dig into how systems work made me want to understand how businesses work. How decisions get made. How teams organize around problems. How domains break down into smaller, simpler pieces. And it turned out that ability, to quickly digest a domain, understand how it works, break it apart, translated very well into leadership and eventually management.
So I followed it. I led a project. Then a team. Then a few teams. I was still close to the code at first, reviewing PRs, jumping into architecture discussions, maybe shipping a fix here and there on a weekend. But slowly, the distance grew. My calendar filled up with 1:1s, planning sessions, stakeholder syncs, hiring loops. The IDE stayed closed for longer stretches. And at some point, without a specific moment I can point to, I realized I hadn’t written anything meaningful in months.
And for a while, that was fine. The curiosity was being fed, just differently. New domains to understand, new organizational problems to break down, new people dynamics to figure out. The leverage was real. I was helping ten, twenty, fifty engineers do their best work. That mattered. But eventually, that too became familiar. The patterns repeated. The novelty faded. The same curiosity that had pushed me into management started to feel unsatisfied by it. It wasn’t enough anymore. It got boring.
And the builder in me, the one who’d gone quiet, started to feel restless.
What made it worse was the growing sense that the gap had become too wide to close. The ecosystem moves fast. New frameworks every year. New languages gaining traction. The frontend world alone had reinvented itself three times since I’d last built a UI. I’d look at a modern React codebase and feel like a tourist. I still understood the fundamentals, architecture, systems thinking, tradeoffs, but the hands-on fluency? That was gone. And with it, a quiet resignation: maybe I’m just not a builder anymore. Maybe that chapter is over.
Then AI happened.
The Barrier That Disappeared
I don’t mean AI as a concept. I mean AI as a tool you sit down with and build things. The moment I opened a code assistant for the first time, described what I wanted in plain English, and watched it produce working code, something clicked. The code wasn’t perfect. But the barrier I’d been staring at for years, the one between “I know what I want to build” and “I can actually build it,” had just gotten a lot smaller.
Think about what used to stand between an idea and a working prototype. You needed to pick a language. A framework. A build system. You needed to understand whatever frontend ecosystem was trending that year. Bundlers, state management, component libraries. You needed a backend. A database. Authentication. Deployment. Each of these was its own learning curve, its own rabbit hole. And if you’d been away from it for a few years? The rabbit holes had moved.
This was the classic fullstack problem. You know that meme?
That was every engineer who tried to do it all. You could be great at the backend and ship a UI that looked like it was built in 2008. Or you could nail the frontend and have an API that fell over under any real load. Being truly fullstack, the kind where both halves of the horse look good, was rare. It required constant investment across multiple disciplines that were each evolving on their own.
AI erased that problem. Not entirely, but enough to change the game. I don’t need to know the latest React patterns to build a decent-looking UI. I don’t need to remember the exact syntax for setting up an Express server or configuring a Docker container. I describe the intent, review what comes back, adjust, iterate. The cycle that used to take days now takes hours.
Funny enough, the first thing I built with an AI assistant was something I’d been thinking about for over a year but never started because the frontend work alone felt like a weekend I didn’t have. I had it running in a few hours. It wasn’t production-ready, it wasn’t pretty, but it worked. And I remember thinking: I haven’t felt this in a long time.
The joy came back. Having an idea on a Sunday morning and a working prototype by the afternoon. I hadn’t felt that in years. AI didn’t just lower the barrier to entry. It gave me back something I thought I’d lost.
The New Reality
This isn’t just my story. It’s happening everywhere. A designer can prototype a working app without writing a line of code. A product manager who used to file tickets and wait three sprints can now build the internal tool themselves over a weekend. I’ve seen teenagers ship real products without knowing what a framework even is. The entry point to software has moved from “learn to code” to “describe what you want.”
And that’s exciting. For personal projects, for experimentation, for scratching your own itch, this is a great time to be alive. The cost of trying has dropped to near zero. You don’t need to learn a new framework every time you want to build something. You don’t need to understand the full stack. You don’t need years of experience. AI gets that part done for you.
So should everyone code? For their own things, personal tools, side projects, things that make their lives easier, yes. Absolutely. The ability to turn an idea into working software is powerful, and AI has made it accessible to a lot more people. That’s a good thing.
But here’s where I stop.
The Profession Behind the Code
Being able to produce code is not the same as being able to produce software. AI has turned writing code into a commodity. Translating intent into syntax is something it handles well. But software engineering was never just about writing code. It was about knowing which code to write, where to put it, and what happens when it fails.
Can AI generate a login flow? Sure. Will it handle rate limiting, session management, token rotation, CSRF protection, and audit logging correctly out of the box? Probably not. Will it know that the database schema it just designed will cause a full table lock under concurrent writes? No. Will it understand that the microservice it just scaffolded violates the bounded context you’ve spent six months defining? Definitely not.
These aren’t edge cases. They’re what separates a prototype from a production system. A demo from a product. Something that works on your laptop from something that serves a million users without falling over, leaking data, or costing ten times what it should.
So when someone says “AI will replace software engineers,” I think they’re confusing coding with engineering. The typing part got easier. The thinking part didn’t. If anything, it got harder, because there’s more code being generated faster than ever, and someone still has to decide whether it should exist, whether it’s correct, and whether it belongs. Reading code now matters more than writing it.
And honestly, if I had to tell an engineer one thing about staying relevant: stop worrying about whether AI can write your code. Start worrying about whether you can tell good code from bad code when it’s generated at ten times the speed you’re used to reviewing it. That’s the real challenge now.
The Joy and the Responsibility
So here I am. Building again. Shipping side projects on weekends. Prototyping ideas that have been sitting in my head for years. The gap I thought was too wide to close turned out to be smaller than I feared. AI didn’t replace what I know. It just removed the friction that was keeping me from using it.
I still carry something that a non-engineer using the same tools doesn’t: the instinct for when something is wrong. That feeling when a pattern is off, or a dependency feels risky, or a shortcut is going to cost more than it saves. A surgeon and a first-year med student can both hold a scalpel. The difference is knowing where to cut. That’s not gatekeeping. That’s the profession.
So if you’re an engineering leader who’s been feeling the same drift, too many meetings, too far from the code, quietly convinced that modern tooling has moved on without you, just try it. Open a code assistant. Describe something you’ve wanted to build for months. Start small. You’ll be surprised how quickly the muscle memory comes back. What you know hasn’t gone anywhere. And the joy is still there.
And this isn’t just for leaders. If you’re an engineer earlier in your career, AI won’t replace what you know, it’ll amplify it, if you’re building real judgment underneath. If you’re a student, treat AI as the most patient tutor you’ll ever meet, but don’t confuse using it with learning the thing itself. And if you’re a parent, like I am, wondering what your kid should study, don’t worry about the specific degree. What matters is judgment. Understanding how things work. Being able to think clearly. AI will change most professions. It won’t change our need for people who can make good calls.
Author Notes
I wrote this article partly for myself. The transition from builder to manager is something most engineering leaders go through, and very few talk honestly about what it costs. You gain leverage and influence, but you lose the direct connection to the craft. That simple, addictive loop of write, run, see. It goes away so gradually you almost don’t notice.
AI gave me that back, and I’m grateful for it. But it also made me think about what I actually bring to the table after all these years. And I think the answer isn’t the code. It’s everything around the code. The context, the judgment, the scar tissue from systems that failed in ways you only understand after you’ve lived through them.
The tools changed. The craft didn’t.