I've been building software for almost twenty years, and for most of that time I thought learning a new technology followed a fairly predictable process. First you studied the framework, then you read the documentation, maybe bought a course, watched a few tutorials, built a small demo, and only after that did you start working on the project you actually wanted to build. It always felt like the responsible way to learn, so I never questioned it.
A few months ago I started a personal side project that eventually became OToolbox (https://otoolbox.com), a collection of free browser-based tools for things like image resizing, PDF conversion, URL shortening and developer utilities. The problem was that I barely knew the stack I wanted to use. I had never built anything with Next.js, my React experience was almost non-existent and Tailwind CSS was just another framework I'd seen in other people's repositories. A few years ago I would have spent several weeks learning the technology before writing a single line of code. This time I decided to do the opposite.
I started building immediately and used AI whenever I got stuck. At first I thought the biggest benefit would simply be writing code faster. It certainly helped with that, but after a few weeks I realised something much more interesting had happened. AI hadn't really changed how I programmed. It had changed what my job actually looked like.
As the project evolved, I noticed that I wasn't "learning React" in the traditional sense. I was solving one problem after another. When I needed internationalisation, I learned just enough to make that feature work. When I needed dynamic metadata for SEO, I learned that. When I decided user files should never leave the browser, I learned the browser APIs required to process images locally. The project stopped being the result of learning and became the way I learned.
Something else surprised me as well. Very few of my conversations with AI were actually about code. I almost never asked it to build a component or implement a function. Most of my prompts were architectural: how should I organise the application so it could grow without becoming a maintenance nightmare? How could I support multiple languages without duplicating logic? How should new tools fit into the existing structure? AI translated those decisions into Next.js code, but deciding whether those decisions were good or bad was still entirely my responsibility.
That ended up being the biggest lesson from the whole experience. For years I associated seniority with knowing a language or a framework inside out. Today I think experience is much more about recognising patterns, understanding trade-offs and knowing when a solution is elegant—or simply overengineered. React, Spring Boot and Next.js all have different syntax, but the problems they solve are surprisingly similar. Once I stopped focusing on the framework itself, I realised I was spending far more time thinking about architecture and product decisions than about implementation details.
Ironically, the less time I spent writing code, the more valuable experience became. The difficult questions weren't technical anymore. Should this feature even exist? Is this making the product better or just more complicated? How do I keep the architecture simple as the project grows? Why is Google indexing some pages but ignoring others? AI could suggest implementations, but it couldn't answer any of those questions for me.
The experience also changed the way I think about learning. For years my process looked like this: Learn → Practice → Build. Today it's much closer to Build → Get Stuck → Learn → Keep Building. At least for personal projects, I've found this approach far more effective because every new concept immediately solves a real problem. Instead of collecting knowledge that I might need one day, I'm learning exactly what I need at the moment I need it.
This is why I think the discussion around AI replacing developers often misses the point. In my experience, AI hasn't replaced the valuable part of my job. It has reduced the amount of time I spend translating ideas into code, leaving me with more time to understand problems, make architectural decisions and review solutions critically. After almost twenty years in software, I never expected the tool that would change my day-to-day work the most wouldn't be another programming language or another framework. It would be an AI assistant that quietly shifted my focus from implementation to decision-making.
I'm curious whether other experienced developers have noticed the same shift. Has AI simply made you write code faster, or has it changed what you actually spend your time doing?
Top comments (4)
As someone who just started and do not know anything about AI last year, I was genuinely doing what you were doing in the past. I ended up getting good at the fundamentals for HTML, CSS, and JavaScript.
When I discovered ChatGPT and the powers it can give me (and its weaknesses). I realized learning new tech is easier now. Since I already have a solid baseline, I often mirror what this part of the new tech is in "JavaScript" terms. In that way, the concept sticks better.
It's like I already have a good part of the puzzle formed but I only need to know where to put the new pieces. AI gives me that ability. But of course, I'm still super careful like cross-checking the responses with official documentation and normal Google searches.
I really like the way you described it as "fitting new pieces into an existing puzzle." I think that's exactly what experience gives us.
In my case, coming from a Java background, I wasn't really translating new concepts into JavaScript—I was translating them into architectural patterns I already understood.
And I completely agree about validating AI's output. I trust it much more as a collaborator than as an unquestionable source of truth.
Coming from a non-CS background back in 2005, this was actually how I started programming. I was interested in freelancing and I found that I could build first and learn second. It’s not bad although I did manage to not backup the data on one job and learned the hard way about why one should always do so!
You're right, the "build first, learn later" mindset existed long before AI. In fact, I worked that way many times myself.
I think what's different today is that AI lowers the cost of taking that approach, especially when you're working with a completely unfamiliar tech stack.
And yes... learning the importance of backups the hard way is probably a rite of passage for most developers. 😄 Thanks for sharing your experience!