Daniel Gumucio is the CEO & Founder of AssureSoft, a premier nearshore software development company with development centers across Latam.
To say that AI dramatically accelerates how teams build software feels like yesterday’s news. Research from McKinsey and GitHub shows that AI-assisted development can improve productivity by 20% to 55%, depending on the tasks. The advantage is so clear that for many companies, this has stopped feeling like a competitive edge and started feeling like table stakes. But something quieter is happening underneath that progress.
For years, junior engineers learned by doing unglamorous work. Writing simple implementations, debugging messy edge cases or poking around in code that didn’t quite behave as expected. That’s because those tasks helped engineers grow a feel for how systems actually work: from watching things break and figuring out why. There was no shortcut to it. They had to sit with the problem long enough to internalize it, and that process of internalization is what eventually became instinct.
That kind of judgment doesn’t arrive in bulk. It builds up slowly, through repetition. With AI now handling more and more of that early-stage work, a structural tension is emerging. Teams ship faster, but the surface where junior engineers develop critical thinking keeps shrinking.
Speed Is Rising, Judgment Is Not
The International Journal for Multidisciplinary Research reported that junior developers experience greater productivity gains from AI tools than senior engineers. That difference sounds like good news until you look at what’s driving it.
Junior developers tend to accept AI suggestions at much higher rates, around 89% of the time. Senior engineers, on the other hand, accept closer to 62%, and they can articulate why they’re pushing back on the rest. They adjust, rewrite and reject what they know to be ineffective. The gap reflects something that took years to build: the ability to evaluate output, not just produce it.
There’s a related finding worth sitting with. Developers who slow down to validate and question AI-generated code produce higher-quality results. Those who move fast and accept suggestions more readily complete tasks more quickly, but reason through them less. The behaviors that build engineering judgment don’t always align with the metrics that appear in a sprint review.
Aside from that, there’s another security data point that reinforces this. AI-generated code introduces significantly more high-severity vulnerabilities, and a large share of those issues go undetected during code review. Developers apply less scrutiny to code they didn’t write themselves.
A Latent, Slow-Moving Risk
The real risk is a slow one. Teams can move faster and still lose depth over time. It won’t show up in velocity metrics or quarterly reviews. It shows up later, when fewer people on the team have the experience to reason through a complex system or recognize the decision that will become a problem six months from now.
If early-career engineers spend less time actually wrestling with problems, they miss the moments where that judgment forms. And over time, that creates a pipeline issue. You still have engineers capable of shipping software, but fewer people with experience needed to make sound decisions about architecture, trade-offs and long-term system behavior.
This is also a talent market issue. As AI reshapes what junior roles look like, the engineers who will be hardest to find in three to five years aren’t those who can use AI tools, but those who know when not to trust them.
Build Engineers Who Can Think, Not Just Ship
This challenge lands squarely on how companies think about development talent. If AI is taking over the work junior engineers used to do, then the role of junior engineers has to change. Not because the work is less valuable, but because the learning that used to come with it now has to be created intentionally.
That means bringing them into architectural discussions sooner, letting them observe how decisions get made and giving them real participation in postmortems rather than just access to the write-up afterward. It means treating the formation of judgment as a deliberate organizational investment rather than a byproduct of time spent on tickets.
Leaders need to create opportunities for supervised decision-making. Small decisions, with real consequences and real feedback. After all, the learning comes from understanding why something worked or didn’t, and having someone senior enough to help them process the difference.
Senior engineers have a key role to play here, making their thinking visible, explaining to juniors:
• Why are they rejecting a solution?
• What trade-offs do they consider relevant?
• What risks do they see that aren’t obvious on first read?
That kind of mentorship has always been valuable. In an AI-assisted environment, it becomes the primary mechanism for transmitting engineering culture.
The companies that figure this out early will have a structural advantage unrelated to the AI tools they use. They will have engineers who understand the systems they build, who can make judgment calls in the face of uncertainty and who know how to evaluate what the machine produces rather than just accept it. That combination is becoming rare, and in the talent market that’s taking shape, rare tends to be expensive.
Forbes Technology Council is an invitation-only community for world-class CIOs, CTOs and technology executives. Do I qualify?
