Over the past 12 months, with AI taking over seemingly everything in software development, I feel like I've lost my step a little.
The industry never really gave us time to figure out how to incorporate AI into our workflows without losing our grasp on traditional engineering practices. We went from writing most of our own code to having AI generate entire features, applications, and even architectures seemingly overnight.
Some of that is on me. I haven't been intentional enough about how I use AI. It's easy to get caught up in how quickly you can get something working without realizing how much of the problem-solving you're handing off.
And recently, I had an experience that made me realize how much I missed that part of software engineering.
Remembering why I enjoy programming
A couple of weeks ago, I was preparing for a technical interview that was a little different from the usual. Instead of LeetCode-style problems, I'd be given an existing application, its repository, and artifacts like logs, error messages, and configuration files. My job was to investigate an issue, find the root cause, implement a fix, and verify it actually worked. And I was expected to use AI throughout, not to show I could do it without AI, but to show I could use it to move faster without letting it do all the thinking.
So I worked through 8–10 debugging scenarios: authentication failures from configuration mismatches, timezone bugs, duplicate processing from retry logic, caching issues, and events arriving out of order. Some were straightforward. Others took real digging just to figure out where the problem was.
I had to read logs, trace requests through components, form hypotheses, and use the evidence to prove or disprove them. Then I had to pick the right fix, think through edge cases, and write regression tests.
AI was part of that process, but I was the one driving. I could use it to analyze logs or generate a test, but I still had to understand what was happening and decide where to look next. Sometimes that meant recognizing when AI was pointing me in the wrong direction.
And you know what?
I genuinely had fun doing it.
I had forgotten how much I enjoyed taking a problem I didn't understand, digging through the code, slowly connecting the dots, and finally having that moment where everything clicks. Even when I chased the wrong hypothesis for too long, I was enjoying the process.
It reminded me of how I used to feel when I wrote most of my code myself. And it made me realize something about how I've been using AI.
I think I've become too removed from my code
I'm not blindly vibe coding. I'm reviewing code, making architectural decisions, and making sure things work. But there's a difference between being involved in development and being deeply connected to the code you're building.
When I built things myself, I had a good mental model of how everything fit together. When something broke, I usually knew where to start looking. Now, even though I'm still involved, I sometimes find myself rediscovering parts of a codebase I would once have understood because I wrote them.
I've also noticed that when I review AI-generated code, I can't always tell whether it's actually efficient. It works, and it might even look clean. But is it using the right data structures? Is there a better algorithm? Is it adding unnecessary complexity? How will it behave as the data grows? Sometimes I honestly don't know without digging in.
Part of that is that LLMs have gotten very good at generating code. But part of it is gaps in my own knowledge and a lack of reps in certain areas. And if I'm relying on AI to write code without the fundamentals to evaluate what it produces, how effective am I really being? I might be building things faster, but am I building them better?
I've gotten so focused on getting things working that I don't always stop to ask whether it's the best approach, whether it could be more efficient, or whether I'm adding unnecessary complexity.
The irony is that AI has the potential to make us significantly better engineers, but only if we're intentional about how we use it. Someone still needs to understand the system well enough to know what happens when the code doesn't work, when it doesn't scale, or when a design decision causes a problem months later. I believe those traditional skills are even MORE important now that AI can produce so much code.
So, I'm starting over. Not from scratch in terms of my career, but I'm going back to the fundamentals to strengthen the skills that have gotten rusty and develop the ones I never spent enough time on.
The plan
Start with C. I've spent my career in Python and JavaScript/TypeScript, which abstract away a lot of what's happening underneath. I'm not trying to become a C developer. I want to understand memory management, pointers, how data is stored and accessed, and how programs interact with the operating system. I'll revisit data structures and algorithms by implementing them myself: dynamic arrays, linked lists, hash tables, memory allocation, and eventually some basic networking and storage. And I want to get comfortable struggling through problems again, which is something AI makes very easy to skip.
Move to Go and build systems from scratch. A web server, a Redis-like cache, a message queue, a basic database engine, an API gateway. I'm not trying to recreate production Redis or PostgreSQL. I want to understand how they work internally and why they're designed that way. How does a cache decide what to evict? What happens when multiple clients update the same key? What happens when a queue worker crashes mid-task, and how do you retry without duplicating work? I want to build these systems, break them, figure out why they broke, and improve them.
Think beyond making things work. I've become increasingly interested in architecture, system design, and distributed systems, which is where the difference between writing code and being a strong engineer really shows. I want to ask better questions before I start building. How should this be structured? What are the trade-offs? What happens if a dependency fails? Can it handle more traffic? Is there unnecessary complexity? I don't think good engineering means building the most sophisticated solution. Often it's finding the simplest one that meets the requirements while still accounting for what matters. Along the way I'll use load testing to find bottlenecks and inject failures to see how systems recover.
Changing how I use AI
I'm not going to stop using AI. In fact, becoming better at using AI is one of the biggest reasons I'm doing this.
I don't think the answer is to avoid it. I think the answer is to become a better engineer so I can take full advantage of it. With a stronger grasp of fundamentals, I can give AI better direction, recognize when it's making poor decisions, and judge whether generated code is actually a good solution, not just one that works. I also want to know when AI's solution beats the one I would have come up with, and understand why.
While I'm learning, I want to change AI's role. Instead of immediately asking it to implement something, I'll think through the problem first, pick an approach, weigh the trade-offs, and then use AI to challenge my thinking. What am I overlooking? Are there edge cases? Is there a simpler way? I want it to act like a senior engineer reviewing my work, a tutor, or a sounding board.
That doesn't mean I'll never have AI generate code. Sometimes that's the most efficient thing to do, and I don't plan to slow myself down just to write everything by hand. But I want to be more deliberate about what I delegate, and I don't want to give up my understanding of a system, or the enjoyment of solving problems, just to get something working faster.
What I hope to get out of this
I don't expect to be an expert in C, Go, database internals, or distributed systems at the end of this. But I do expect to be a much stronger engineer: to understand what my code is actually doing, to be comfortable with unfamiliar problems, and to have better intuition for performance, algorithms, and data structures. I want to design systems with confidence, explain why I chose one approach over another, and know how to investigate problems when they happen. And when AI generates code, I want the knowledge to critically evaluate it instead of trusting that a working solution is a good one.
I'm going to document what I learn along the way: the concepts, the systems I build, the problems I hit, and how my understanding changes. Some of it will be revisiting things I learned years ago. Some will be completely new. And I'm sure I'll find plenty of things I thought I understood but didn't, which is kind of the point.
I don't think AI is making traditional software engineering skills less valuable. If anything, it's making critical thinking, problem solving, and good engineering judgment more valuable than ever.
I don't want to just be someone who can build software quickly with AI. I want to deeply understand how to build good software so I can use AI to build it even better.
And maybe most importantly, I want to get back to enjoying the process of figuring things out, not just getting to the finished product.
That's why I'm starting over.