Nobody Reviews My Code Anymore: How to Grow as a Junior Developer in the AI Era

Software development in the AI era is not what it used to be. When I got my first role five years ago, I had a tech lead, a senior engineer, and then me, the bright-eyed newbie.

Even then, I knew that improving would mean staying open-minded, studying books, and watching the patterns my senior colleagues followed. Another big help was that my seniors were top of the line and their code reviews were in-depth. On the small features they let me contribute, I got tons of comments asking me to explain my thought process and design decisions. When time allowed, they would even drop reference links on what to study and which gaps in my knowledge needed work. That greatly shaped the developer I am today.

The AI era, however, has broken the feedback loop that grows engineers from junior to staff level:

1. The grunt work that juniors used to do is gone. Tiny bug fixes, a broken CI, “change the button on page xxx to blue”: one Claude prompt and it’s fixed.
2. Seniors now carry a lot more mental load. Understandably, it is hard for them to read a junior’s code meticulously and leave comments.
3. Things are moving faster, and no one wants to be caught lacking. There is no time for mentoring like before.

If none of this applies at your company, great! Take full advantage of all the feedback and keep learning, so more software experts are born. We are going to need a lot of them for all the slop features being released into the wild.

But my time organizing PHP meetups in my community has put me in touch with a lot of juniors who feel this way. Their question is: “How do I improve if no one is telling me what is wrong and what to do to grow?”

My advice comes down to three points, which I’ll explain one by one:

1. Read a lot of code (a lot of it).
2. Be your own reviewer.
3. Take the commits your seniors add to your PR very seriously.

Read a lot of code

After learning a language’s syntax and building a couple of projects, you get the hang of building things. Take a todo list, everyone’s favorite project. You finish the programming crash course, you write a todo item, and it appends to the list. Hurray, step one of becoming a software developer is complete.

But building real software products is a lot harder. Real products must be:

1. Something customers will actually use
2. Bug free
3. Maintainable and easy to extend
4. Easy to collaborate on with colleagues

To get to that point, you need to read a lot of code. It opens your mind to patterns you would never spot if all you did was write and ship.

Start with the codebases at work and look for patterns. Ask yourself, “Why do they do it this way?” You can use AI here too. Ask it about implementation details. It can use the commit history to show how a file has changed, and the related PRs to explain why a solution was the best one given certain constraints. Sometimes it even spots bugs that you can raise with the team, so issues get fixed before they happen. Where AI can’t help, ask a senior colleague. Most will help. Trust me, nothing makes smart people happier than showing off their knowledge.

When you have exhausted the company’s codebase, go read open source code. Start with the external dependencies your company’s codebase uses, then move on to popular tools in the ecosystem. To this day, as a mainly PHP developer, I still study code from Freek Van Der Herten, Nuno Maduro, and many others. When any of these guys releases a new open source package, I skim through the files, observe the patterns, and build a mental model of how the different components interact.

Be your own reviewer

After writing a feature (or prompting it, both are fine), read through what the AI agent created and ask yourself:

• Does it look right?
• Does it follow the project’s conventions? Trust me, even with guidelines in AGENTS.md, some agents just write whatever they feel like.
• Is the code tested?
• Do the tests even make sense? Current agents write tests for a lot of unnecessary stuff. A good test should:
  • Assert a specific feature criterion
  • Not test an external dependency
  • Skip the unnecessary. You won’t always know what that looks like at first, but you will learn it as you grow.
• Are the edge cases covered? Most agents implement the happy path (the ideal scenario) and ignore the small details that could cause issues.

Take your seniors’ commits to your PR very seriously

If your seniors don’t have time to comment on your PR, look at the commits they made before merging:

• What edge cases did they consider?
• How did they prefer the code to be written?

Code review can be very subjective, but eventually you will get a general idea of what’s acceptable. You can also ask follow-up questions. Don’t ask so many that it becomes annoying, but ask enough to start understanding the reviewer’s thought process.

Conclusion

There are many more things to consider, but this is generally what I did then, and what I still do now as I grow from senior to staff level. If you are a junior with extra tidbits to share, or a senior or staff engineer with more advice, please drop them in the comments below.