Let's be honest — GitHub Copilot is a bit like having a senior developer whispering in your ear 24/7. Sometimes that's a godsend, and other times, it's just plain distracting. Lately, there's been a lot of noise about whether these AI tools are actually 'rotting' the brains of our junior developers, turning them into prompt-engineers who can't debug their way out of a paper bag.

I've been watching this play out in design systems and UX engineering for a while now. While the doom-and-gloom headlines are everywhere, the actual data tells a much more nuanced story. It's not that juniors are getting worse; it's that the way they learn is fundamentally shifting. If we don't adapt our mentorship, we might indeed end up with a generation of devs who know 'what' to type but never 'why' it works.

• • •

The Data: Productivity vs. Proficiency

Here's the interesting bit: Recent research from Microsoft and MIT shows that juniors are actually the biggest winners when it comes to raw output. While senior devs might see a modest 8-13% bump in speed, juniors (and recent hires) are clocking in gains between 27% and 39%. That's massive. They are completing tasks faster and adopting the tool at much higher rates than their more cynical senior counterparts.

The 'danger zone' isn't the speed; it's the lack of friction. In the old days (you know, three years ago), if you didn't know how to centre a div or map over an array in React, you had to go to MDN or Stack Overflow. That struggle—that friction—is where the learning happened. When Copilot just hands you the answer, you skip the struggle, and sometimes, you skip the understanding too.

• • •

The 'Black Box' Implementation Trap

I see this most often in UI logic. A junior will prompt for a complex React hook or a CSS Grid layout. Copilot spits out 20 lines of code. It works! They commit it. But when a bug appears in an edge case, they're stuck because they didn't actually write the logic—they just curated it. Let's look at a practical example of where this goes wrong.

// What Copilot might suggest for a 'simple' data fetch
const UserProfile = ({ userId }) => {
  const [user, setUser] = useState(null);

  useEffect(() => {
    fetch(`https://api.example.com/users/${userId}`)
      .then(res => res.json())
      .then(data => setUser(data));
  }, [userId]);

  if (!user) return <div>Loading...</div>;
  return <div>{user.name}</div>;
};

At first glance, this is fine. But a developer who relies solely on this suggestion might miss the race conditions, the lack of error handling, or the fact that `useEffect` isn't always the best place for data fetching in modern React. The 'worse' developer isn't the one using AI; it's the one who doesn't know how to critique what the AI gives them.

• • •

How to Use AI Without Losing Your Edge

The trick is to treat Copilot as a pair programmer, not a ghostwriter. I've found that the most successful juniors use a 'Verify then Trust' workflow. They use the AI to scaffold, but they manually refactor or comment every line to ensure they understand the 'why'.

Let's look at how we can take an AI suggestion and 'Senior-ify' it by applying actual UX engineering principles. Here's a common scenario: building an accessible toggle switch.

/* AI might suggest a simple checkbox hack */
.toggle {
  appearance: none;
  width: 40px;
  height: 20px;
  background: #ccc;
  border-radius: 20px;
  position: relative;
}

.toggle::before {
  content: '';
  position: absolute;
  width: 18px;
  height: 18px;
  background: white;
  border-radius: 50%;
  transition: 0.2s;
}

.toggle:checked {
  background: #007bff;
}

.toggle:checked::before {
  transform: translateX(20px);
}

The code above looks okay, but it fails on several UX fronts: no focus states for keyboard users, hard-coded colours that won't work in dark mode, and no consideration for reduced motion. A junior who just 'tabs' through this is technically finishing the task, but they aren't growing as an engineer. A pro move is to take that scaffold and layer in the design system tokens and accessibility requirements.

• • •

The Verdict: Is It Making Us Worse?

Honestly, I don't think Copilot is making developers worse—I think it's raising the floor while lowering the ceiling for those who get lazy. If you use it to skip the fundamentals, you'll hit a plateau very quickly. But if you use that saved time (the 2-6 hours a week the data says we're gaining) to study architecture, accessibility, and system design, you'll become a powerhouse.

Wrapping Up

The data is clear: AI is a massive productivity multiplier, especially for those starting out. However, that speed comes with a hidden cost if we aren't careful about maintaining our foundational knowledge. Here's what you should take away:

  • Juniors see 27-39% productivity gains, but often struggle with debugging AI-generated edge cases.
  • The 'friction' of manual coding is vital for long-term skill retention; don't skip the 'why'.
  • Use AI for boilerplate and scaffolding, but always perform a manual audit for accessibility and performance.

If you want to go deeper and learn how to build real, production-ready CSS design systems step by step, check out my full course here: CSS Design Systems Course

Got questions or want to share how you're using this? Drop me a message on LinkedIn - I always enjoy chatting about this stuff!