“How can I make the best use of AI while still being a junior engineer?”

That was the question that my wife’s nephew asked me over dinner. He’s in his early 20s, just a few years removed from graduating from university and with a small amount of professional work experience. While making conversation with him and asking how his work was going, he confided that while he was getting his assigned tasks done thanks to the use of AI and most of his code didn’t blow up in production, he had an inescapable feeling about never being sure if he was doing his work correctly.

Just as my wife’s nephew landed his first job in early 2024, the use of AI for coding began to increase steadily. From the start of his professional career, he not only had to learn how to use AI without much real-world experience, but he was also expected to use AI to get his work done. That's a lot to ask of anyone, but it's especially difficult for people without much time to have developed the skills to judge whether these tools are doing the right thing or not.

The day after my dinner with my wife’s nephew, I attended the DevOpsDays 2026 conference in Tokyo, my first time attending the event. After the first keynote talk and the audience had the opportunity to ask questions, someone asked the speaker the same question, down to almost the exact phrasing: “As a junior engineer, how can I best use AI to know if I'm using it correctly?” That's when I realized that this issue might be more widespread than I thought.

The Feedback Loop is Broken

Before AI-assisted coding, the path to becoming a competent engineer had a built-in feedback loop. You'd code up something new, then it would break in an interesting way, and you'd spend a weekend figuring out why, coming out the other side knowing something you didn't know before. The loop was slow and sometimes painful, but it was useful. Every single time something happened with your work, whether a minor visual bug or an issue that brought production down, it was an opportunity to build your judgment.

That create-break-fix loop is what builds “taste,” that gut feeling that tells you something is wrong with a piece of code before you can articulate why. It's not magic, and it's not tied to years of service. It's the accumulated knowledge of having been wrong many times in ways you remember. Nowadays, that loop has been compressed, and in some cases removed entirely.

When AI produces working code with a well-crafted prompt on the first try, we no longer have to spend weekends resolving issues. The output might be at the same level as what an experienced engineer would produce, but without going through the process that builds our intuition. Doing this day in and day out leads to where my wife's nephew is: shipping code with no real way to know if he's doing it right.

None of this means AI is bad for junior engineers. The same tools that break the old feedback loop also do things that genuinely help in many ways. For example, we can now get a clear grasp on an unfamiliar codebase in hours on our own instead of weeks, or we can pick up a new programming language without slogging through books or outdated Internet tutorials. These are real advantages that we didn’t have a couple of years ago. The problem is that these tools can either help boost a junior engineer’s career or silently kill it, and the difference comes down to how you use them.

How to Build Your Taste in the Age of AI

It might feel like junior engineers are doomed to using AI as a crutch, but that’s not the case. These tools aren’t going away, and they shouldn’t because they’re genuinely useful when used well. However, that’s the key point. Using AI tools well requires being intentional about how you work with them instead of surrendering complete control over to them.

As my personal usage of AI tools has increased in the past year, I’ve picked up a few habits that help me make the most out of them. Talking with a few less-experienced developers and testers over the years, including my wife’s nephew after dinner, helped me put together some advice on how to build your “taste” while still getting the benefits of using AI for daily work.

Have real conversations with the AI

When I was learning how to code during my university days, I constantly bombarded my professors with questions whenever I didn't fully understand something. It got to a point where one professor would finish a lecture and ask the class, “Does anyone have any questions?” before looking squarely at me and adding, “… Dennis?” I don't know how they took my excess curiosity, but I'm glad I did that because asking questions helped me more than reading any textbook could.

These days, we all have expert teachers right at our fingertips, built into the tools we use for our work. Sadly, I noticed most developers and testers treat AI as a transactional machine, where they give it orders and take the output without further discussion. The same tools that are generating this output can tell you what they did and why, and this is one of the easiest ways to begin building taste. Any time you don't fully comprehend why the AI wrote a specific section of code, ask it to explain what it just did. Usually, it'll give you a detailed response that will expand your learning. These moments are even better opportunities to learn, since you'll see different approaches to a problem.

You can also take it a step further and ask about tradeoffs when you begin to understand the output of the generated code. One thing I often do when using AI to generate code for me is to ask follow-up questions like “What are the downsides to this approach?” or “How else can I implement this?” These types of questions turn the AI into more of something like a mentor and can help engineers, especially less experienced ones, really sharpen their skills.

Slow down

This bit of advice is the simplest but probably the most difficult piece to implement. For most, the expectation with our work is to produce as much as we can as fast as we can, and we often don’t have the time to take it easy. The expectations have increased exponentially in the last few months, as we can spend 10 seconds writing a prompt, shove it off to AI, and get something that looks reasonably well done just a few minutes later.

But all this speed without thought is coming at the expense of quality and knowledge. It’s only been a few years since AI-assisted coding has become in vogue, but I can already see a clear spike in bugs slipping into production and a massive accumulation of technical debt in various codebases. I’ve also noticed how junior engineers have stopped developing the judgment they need to grow in their careers. Sadly, today’s culture rewards speed, and slowing down is taken as being lazy or inefficient. That's a huge mistake, because by not slowing down, you're giving up the main advantage that you have over AI, and that's thinking. Artificial intelligence doesn't think in the sense that humans do. LLMs only predict the next output based on statistical probabilities, nothing else.

For my wife's nephew, my recommendation is that he should take a few minutes before typing in a new prompt to plan out what to get out of that particular chat session. Those extra minutes that we spend mapping out what we want, how to organize and structure the code, and how the new functionality will fit with the rest of the application lead to smarter prompts and better results. It also trains our thinking muscles to help catch potential edge cases and spot problems with the AI's outputs, which in turn helps with the long-term reasoning needed to improve our work.

Write code by hand deliberately and regularly

During my university days, I remember complaining to a professor that some of the assignments she gave us felt repetitive. Her response surprised me: “Good. That means you're starting to notice the patterns, and that’s what you’ll find most of the time in the real world.” Solving similar issues in slightly different ways builds up a mental library over time. As you grow in your career, you’ll find yourself reaching back to all that work you’ve built yourself.

We can choose to bypass this and let AI deal with the repetitive nature of coding. But if you spend little to no time writing code yourself, you lose the ability to properly evaluate whatever the AI gives you. And if the person reviewing your pull request is doing the same thing, then who’s actually checking the work? The advice I have here is to simply work on a small problem without the aid of AI tooling and to be deliberate about it. Choose something that forces you to think, whether it's a minor bug that doesn't need a deep debugging session, a task that needs automating, or a part of the codebase you've been avoiding because you don't fully understand it.

The point of this practice is to keep your skills strong so that when you do produce or review AI-generated code, you're in a much better position to tell whether it's good to go or requires some tweaking. Writing code by hand is also one of the most direct ways to build taste. Every problem you work through yourself becomes something your instincts can draw upon later, even on the days when you do let AI handle the whole task.

Read other people’s code

Some of the best developers and testers I know spend almost as much time reading code as they do writing it. Reading code is one of the strongest habits engineers should possess because it's full of teachable moments. It allows us to slow down (which I recommended earlier) and observe all those patterns and conventions that make the difference between code that runs well and code that doesn't.

My recommendation is to start with what's in front of you, particularly with the code you're already working on. Pull up recent pull requests from senior team members and read them in detail, paying attention to how they structured their code and handled different scenarios. Besides the work that's in front of you, we have thousands of open-source projects available and ready to explore. Chances are you're using a few of these projects, and spending some time poking into the inner workings will really boost your coding knowledge and help you develop your personal taste as you borrow ideas from others.

I do want to include a small note of caution when taking this path, though. Since AI-generated code is getting committed everywhere nowadays, there's going to be a lot of code that looks well-written on the surface but wasn't really thought through. If you'll spend a good chunk of time reading code to learn from it, be picky about who that code is coming from. Look for projects that are maintained by engineers who you trust or older projects that are still actively in use but started before the current AI craze. Otherwise, you risk absorbing ideas and patterns that aren't actually good, which defeats the whole purpose of studying the works of others.

What This All Comes Down To

None of these habits are bulletproof. AI tools will still produce wrong code, and your manager will still expect you to ship all your features by the end of the sprint. You’ll have plenty of days when you won't have the time to slow down to review everything, nor to spend enough time reading code or writing it by hand. That's the reality of working as an engineer right now, and pretending otherwise would be dishonest.

What these habits do is give you a way to keep growing in your career despite all that pressure that we’re feeling so that the experience you accumulate over the following years sticks. Being a junior engineer right now is harder than it's ever been. If I were in my early 20s today, I'd be asking the same question my wife's nephew and the conference attendee asked. The same tools that make it easy to skip the learning can also encourage your career growth if you're deliberate about how you use them.

The engineers who will do well in the coming years will be the ones who can quickly and effectively know when the code produced by an LLM is worth keeping or not. That kind of judgment only comes from putting in the work, asking the harder questions, and being honest with yourself about what you actually understand versus what you've just copied and pasted. Put in the work now, and a few years from now you won't be a junior engineer who leaned on AI to get by. You'll be the engineer that the next wave of juniors comes to for advice.