Being a Junior Software Engineer in the AI Era

In the AI era, as a junior software engineer, I can't help but feel anxious about the inevitable: being laid off.

Coding has gone from questioning what to name my variables, where to place functions, and whether code is duplicated, to a single question: "Hmm, what should I write to Claude?"

The Loss of Coding Joy

I miss the struggle. The hours spent debugging, the dopamine rush of finally solving a hard problem, and that silent victory: "YES, I actually figured it out." Now, the only time I get that feeling is on LeetCode, only to immediately catch myself thinking: "Why bother? Claude could do this in seconds." (this sounds so sad, it is )

Company tech talks have shifted from debating Scala vs. Java, compilers, and software design to AI, AI, and more AI.

Friends ask me, "Do you think about layoffs?" Of course I do, but living life constantly questioning whether you're next is no way to enjoy life. So what should I do? I've decided to adapt as best as I can.

The Productivity Paradox

Technology is one of humanity's greatest creations. The reason I went into computer science aside from financial stability was to build things that advance society. I never imagined software engineers would build the very tools that threaten their own careers.

As a junior engineer at a tech company in Thailand, I struggle with this new productivity sprint. With Claude, Codex and OpenCode, expectations have risen. We are expected to manage a fleet of tasks and pick up multiple user stories at once. There's no time to read codebases deeply and understand design decisions when an agent does it in seconds.

I feel an urgent pressure to reach senior status before I'm left behind. But to grow, you need to understand technical trade-offs, design data-intensive systems, and know your tools inside out.

Can prompting all day build that foundation? It's a paradox. Seniors use AI less than I do, but far more effectively. Their decade of foundational experience lets them prompt the model with precision.

How I'm Adapting: Four Guardrails

I decided to balance this out. I've set up four rules to shift my mindset:

1. Treat Claude as a Teacher, Not Just a Worker

I moved from blindly accepting auto-edits to manually approving each step, reviewing what the model writes, and asking questions: "Why did you do this instead of that?", "What does this syntax mean?", or "Can we do this differently?" I force myself to actually observe what the model is doing instead of scrolling through social media every time I press Enter. If it goes off track, I can pull it back immediately instead of wasting time. It also saves tokens; at this point, it's getting way too expensive with each model upgrade, and I want to prepare in case my company starts limiting usage.

2. Limit Concurrent Sessions

I limit myself to two concurrent sessions. As Elon Musk said, context switching is extremely costly. I used to think that having agents work for me made multitasking easy, but it doesn't. Agents need precise context—business definitions, stakeholder preferences, and codebase patterns—and I have to be fully focused to feed these details in correctly.

3. Focus on Iteration over Hours

Naval Ravikant once said that you don't learn by putting in 10,000 hours, but through 10,000 iterations. I use AI to accelerate my decision-making loops. I even added a rule to my local guidelines (CLAUDE.md) telling the agent to query why I want a change before executing it. It slows me down and is super annoying, but it forces critical thinking. If I make 10,000 decisions and get half of them wrong, that is still 5,000 feedback loops compounding my skills.

4. Gamify Token Conservation

As long as I deliver my stories on time, I make it a game to use AI as little as possible. For instance, I read CI/CD logs yourself instead of immediately asking an agent to parse them. I used to spam heavy models on every minor issue; now, I compete with my seniors to see who can solve tasks using the fewest tokens. Sonnet is usually more than enough. I’m still second-best on my team at this game, but it keeps my debugging muscles active.

Finding a Balance

When productivity expectations feel unsustainable, I talk to my manager. I let them know I want to slow down slightly to digest the architecture and build deep context. I am fortunate to have an empathetic manager who understands this junior-level anxiety and guides me through it.

The Future of the Industry

If coding is dead, what is left for future engineers? Honestly, I don't have the answer to that question myself. Software engineering is shifting, and while it is easier to "vibe code" now than ever. If an AI agent can write basic CRUD APIs and boilerplate code in seconds, companies may have less interest in hiringa nd training juniors. Why bother training them if senior can already ship production-ready code with AI already.

This realization is why I try to focus on the present try to learn something beyond simple coding. Recently, I've learned about system design, such as domain architecture and migrating systems using dual-read and dual-write strategies. I've picked up O'Reilly books and find them enjoyable and weirdly reassuring (what a nerd, I didn't want to expose myself). It's reassuring to learn that there is so much more to learn, and software is not that simple and still need deep human expertise, this should be the part that we focus on.

Here's an interesting question my colleague asked: If the industry stops hiring juniors for now, will the demand for juniors spike in 5 to 10 years? Seniors will eventually retire they won't be around forever and everyone has to start somewhere. How will the software industry move forward without a junior engineer pipeline?

---

How are you balancing delivery speed with actual skill-building in the age of AI coding assistants?