The other day, I had this epiphany: AI is like gravity.
Before the AI era, programming felt a bit like cross-country skiing. Your distance and speed depend almost entirely on your own skills, and quad muscles of course🙃. After the AI era, programming started to feel more like Alpine skiing. Gravity is there for everyone. You can use it to accelerate, carve a smooth line, and make a fast run with much less effort. It feels powerful.
Or you can injure yourself because you lose control. A classic theme.
In my case, I have experienced both. Gravity did not always work in my favour when skiing, and AI has definitely backstabbed me a few times while coding.
I started my first software engineering job at the beginning of 2025. AI is not the full picture of software engineering, but it is impossible to pretend it is not part of the picture at all. So instead of asking whether AI is good or bad for junior engineers, I have been thinking more about the moments when I feel grateful to have this tool, and the moments when I am relieved that it is not smart enough to take the decision-making away from me.
When AI has been helpful
As juniors, we often feel intimidated about asking senior engineers “stupid” questions. Questions about syntax. Questions about the use case of a specific method. Questions about errors caused by a misspelled word or a missing keyword.
In those moments, I could direct those very basic questions to AI without worrying that I was bothering someone else. When you are in your first software engineering job, you genuinely do not know much, yet. Having a tool that can help demystify syntax, explain a method, or point out a simple mistake is immensely useful.
When AI has made me feel privileged
Another big lesson I have learned is that your dependencies are essentially part of your code. It is your responsibility to understand whether they are fit for purpose and whether they might break your application.
Here, AI has been genuinely useful as well. It has helped me read and analyse the codebases of dependencies. In Rails, you can run bundle open gem_name to inspect the source code of a gem you are using. I have always been curious about how things work behind the scenes, and I like digging deeper. Reading the source code has helped me understand edge cases, exceptions, and the cost of certain methods.
The depth and breadth of high-quality code that AI helps me make sense of at this early stage of my engineering career makes me feel privileged.
When AI made me feel powerful
It also made me feel that there were fewer problems that were “too junior” to tackle(although company culture plays a big part in that too). With the help of AI, I was able to write more complex code, adopt more ambitious strategies, and push more changes than I probably would have attempted otherwise.
When AI helped me move too fast
Obviously there have been back stabbing moments.
One time, I was working on optimising background jobs by adding a layer of verification around API responses. From what I had previously tested, and from what is generally true in many examples, a 200 response code usually means a successful response with useful data that we can process. A 400+ response usually means something has gone wrong, and there is not much useful data in the response body.
I tested this flow with one API and it worked really well. Then I asked AI to help me apply the same pattern to a dozen other APIs. Since the pattern had already been proven correct once, I felt quite confident. I pushed my PR for my colleagues to review.
Huge thanks to a colleague who actually tested the code in her environment, I realised the assumption did not hold everywhere. Some APIs return partial error responses in a different way. Even when the request is bad, or when the requested resource does not exist, they can still return a 200 response code, with the error described inside the response body itself.
That mistake humbled me. It taught me several important lessons:
First, even in the age of AI, never skip the most basic habit of programming: always, always test your code in your own environment.
Second, do not over-generalise a problem just because AI makes it easy to produce a large amount of code. It is tempting to become ambitious and “complete” more than the task actually requires.
Third, my own engineering abilities define how far I can safely leverage AI. If AI produces something far beyond my ability to maintain, reason about, or truly understand, then it has not made me more capable.
Back to my ski metaphor, it has simply placed me on a piste beyond my current ability. Well technically, you can always get down the mountain right? But hey at what cost?🤷🏻♀️
When I was glad that AI didn't take that from me
There have also been moments when I was grateful that AI did not do the thinking for me.
One of the biggest learning moments I had came from a task where I needed to write a long background job. The job had to filter users based on several different criteria and use Action Mailer to send a customised monthly report email. At first, I wrote everything inside one huge job. Then I moved on to writing tests and immediately got stuck. I did not know where to start testing the whole thing.
During a coffee break, some object-oriented programming fundamentals and the Model-View-Controller pattern suddenly popped into my head. I realised there was a much better way to structure the code.
I broke the different user criteria down into smaller methods, scopes in Rails terms, and moved them into the model layer. I created an Action Mailer to handle the email logic. By the end of the refactoring, the job itself was only a few lines long, simply assembling all the pieces together.
It felt as satisfying as building a Lego set.
I do not think this experience is unique. There is no real shortcut to comprehending something conceptual. It is by immersing yourself in the code, getting stuck, and constantly challenging whether there is a better way that you start to develop the so call "taste" and "instinct" in software design.
Had AI simply spoon-fed me the right answer from the beginning, I probably wouldn't have learned that lesson as deeply.
I wanted to write about my journey of changing jobs as a software engineer because I have just completed my first software engineering role. Mumbling this experience is my way of processing the complex feelings that came with saying goodbye to this job.
I also recently attended Brighton Ruby(for Rubyists in the UK or beyond, I highly recommend that) , where I joined a workshop discussion about AI. During that conversation, some people mentioned that juniors are drowning. Others questioned whether it is still meaningful to recruit juniors at this stage.
Well, I can only speak from my own experience. To me, it is not a replacement for learning. It is not a shortcut to judgement. But it is a new force in the environment, like gravity on a mountain.
And you still need to learn how to ski, metaphorically. You really should.
Top comments (0)