Book a Free Call
No commitment required
Not long ago, joining a new engineering team meant weeks of confusion. You’d read a ton docs that were half outdated, ask senior devs the same questions everyone asks, and spend a lot of time just trying to figure out how pieces fit together. It was slow. Sometimes painful. But something was happening in that process that we didn’t really appreciate until it started disappearing.
Now tools like Claude Code, Cursor, and others can walk a new dev through a codebase in hours. They can explain dependencies, suggest how things work, point out patterns. And yeah — engineers are getting up to speed faster. That part is real. A controlled study by Peng et al. (2023) found that developers using AI assistance completed tasks 55.8% faster than those working without it.[1] GitHub’s own research showed that between 60–75% of Copilot users reported feeling less frustrated and more able to focus on work they actually find meaningful.[2]
However, faster is doing a lot of heavy lifting in that sentence.
Setup. Environment config. Understanding what a function does. Mapping out how services talk to each other. These are the parts that used to eat days — the kind of stuff that makes new developers feel lost even when they’re not. AI handles this well and there’s no reason to be precious about it.
When someone can ask “why does this service call that one before hitting the database” and get a decent answer at 11PM without bothering anyone — that’s genuinely useful. It removes friction that shouldn’t have been there in the first place.
The problem isn’t that AI explains things. It’s that it explains things so well you can stop thinking you need to understand them yourself.
There’s a difference between knowing how something works and knowing why it was built that way. AI can tell you the first. The second usually lives in someone’s head, or buried in a Slack thread from two years ago, or in the scar tissue of a decision that looked bad at the time but turned out okay.
When developers skip that — when they move fast because the tool lets them — they can look productive for a while. They ship things. Code passes review. But ask them to make a call on architecture six months in and there’s a gap. Not because they’re not smart, but because they never had to sit with the system long enough to develop any real judgment about it.
John Sweller’s Cognitive Load Theory (1988) makes this point in a more formal way: reducing unnecessary obstacles to learning is good, but the effortful part — the thinking, the confusion, the working through it — is not a bug.[3] That friction is what builds what he calls germane cognitive load: the mental work that transfers into lasting understanding. If AI does too much of that work, the model never fully forms.
Research backs this up more broadly. A 2024 study from Microsoft and Carnegie Mellon found that while AI tools improve efficiency, they also reduce critical engagement — particularly in routine tasks — raising concerns about long-term over-reliance and diminished independent problem-solving.[4] The researchers put it bluntly: by mechanizing routine tasks, you deprive the person of the practice needed to strengthen their judgment. When the exception arises, they’re unprepared.
The long-term risk isn’t just weaker onboarding. It’s weaker organizational memory. Engineering teams historically developed judgment by forcing newer developers to spend time inside the system — tracing decisions, understanding constraints, seeing the consequences of tradeoffs over time. AI compresses that exposure dramatically.
Research around expertise development has pointed to this dynamic for decades. In The Reflective Practitioner (1983), Donald Schön argued that professional judgment is built through reflection-in-action: the process of engaging with uncertainty, mistakes, and imperfect situations directly.[5] Engineering intuition doesn’t usually emerge from explanations alone. It forms through repeated contact with ambiguity.
The danger is that teams may end up scaling execution faster than they scale understanding. And those two things are not the same.
Not banning AI tools — that’s not the point and it wouldn’t work anyway. It’s more about being intentional with where the human element shows up.
Design reviews. Pairing sessions. Conversations about the product itself — not just the code but what it’s trying to do and why certain calls were made. Those things don’t scale as easily and they’re harder to measure, but they’re where a developer starts to actually own the system they’re working on instead of just navigating it.
AI can explain what a piece of code does. A teammate can explain why it matters to the customer, why the tradeoff was made, what would break if someone changed it without knowing the history. That second conversation is the one that builds engineers who make good decisions, not just engineers who ship fast.
Being able to write code on day one is great. Knowing when not to write it — that’s what you’re actually trying to develop.
The teams that get this right aren’t the ones that restrict AI. They’re the ones that protect the rituals AI can’t replace. The design discussion that forces a new hire to defend a decision out loud. The moment where someone has to explain a tradeoff and realizes they don’t fully understand it yet — and that’s okay, because that’s the point.
The Stack Overflow 2025 survey has a finding worth sitting with: only 17% of developers using AI agents agreed it had improved collaboration within their team — by far the lowest-rated impact, well below personal productivity gains.[6] AI is helping individuals move faster. It’s not, on its own, building the team.
As AI keeps getting better at execution, the value of an engineer shifts. Not toward writing more code but toward judgment. Context. Knowing when the technically correct answer is wrong for this team, this product, this moment.
Onboarding should be where that starts forming. If we measure success only by how fast someone pushes their first PR, we’re optimizing for the wrong thing.
The companies that navigate this well probably won’t be the ones that simply move faster with AI. They’ll be the ones that build systems capable of scaling understanding alongside execution — through mentorship, strong engineering culture, and teams that can integrate into complex environments without reducing engineering to transactional output.
At Wawandco, we’ve seen how much faster modern teams can move with AI-assisted workflows. The harder part — and probably the more important one long-term — is making sure speed doesn’t come at the expense of the engineering judgment complex systems still require.
[1] Peng, S., Kalliamvakou, E., Cihon, P., & Demirer, M. (2023). The Impact of AI on Developer Productivity: Evidence from GitHub Copilot. arXiv:2302.06590. arxiv.org/abs/2302.06590
[2] GitHub. (2022). Research: Quantifying GitHub Copilot’s impact on developer productivity and happiness. GitHub Blog. github.blog
[3] Sweller, J. (1988). Cognitive load during problem solving: Effects on learning. Cognitive Science, 12(2), 257–285. doi.org/10.1207/s15516709cog1202_4
[4] Microsoft & Carnegie Mellon University. (2024). The impact of generative AI on critical thinking in knowledge workers. Presented at CHI 2025. https://www.microsoft.com/en-us/research/wp-content/uploads/2025/01/lee_2025_ai_critical_thinking_survey.pdf
[5] Schön, D. A. (1983). The Reflective Practitioner: How Professionals Think in Action. Basic Books.
[6] Stack Overflow. (2025). 2025 Developer Survey — AI section. survey.stackoverflow.co/2025/ai