Full disclosure: I work at Microsoft but what you're about to read is 100% my personal opinion. Don't @ me with "dude from Microsoft claims..." please...

I've been deep in a rewrite of the AI chapter in The Imposter's Roadmap, and I'm trying to discuss the role of AI in a senior programmer's life... and I noticed something interesting as the AI discussions heat up in our industry: we both fear and want to protect junior developers.

What a weird straw man argument!

Note: this article addresses the presence of AI and might not be suitable for some readers.

The Catalyst

Microsoft and GitHub announced a free tier for Copilot a few weeks ago which has a few limits on it (2000 completion requests, 50 text sessions). The idea is that people get to try Copilot and see what they think.

This, of course, was met with "challenging" responses from people. Read the entire HN article linked, if you like, but it's a very typical HN discussion (i.e. inflammatory and not very productive). But it did make me think about one thing in particular: the simultaneous fear and guarding of junior developers.

To summarize the responses I've seen: AI is making people dumber and my job harder because I have to deal with their dumb code! Who's going to help these dumb junior programmers!

I've read over Reddit threads, BlueSky discussions, and had plenty of animated discussions with friends and colleagues, and every one of them is worried about the Big Bad/Sweet Innocent Junior Developer.

We Love Them, We Fear Them

I used to use Visual Studio back in the mid-2000s when I was writing C# on a daily basis. One of the "must-have" tools at the time was Resharper, which would help with navigation, refactoring, code exploration and a whole lot more.

For some reason it never clicked with me, but I do remember when it came out that the .NET community was up in arms over the need for a "crutch". Senior developers would forbid the junior developers from using it because it would slow their "growth" and they needed to know the underlying code and why it was good or bad. Others argued that the tool itself can help with this process.

What a weird paradox.

On one hand: yes, taking time in code reviews to help a new programmer improve their code takes time and yes, I can see how that would be insanely frustrating if it was obvious that the code came from an automated process.

On the other hand: what a great way to learn. I mean... if the code works, it works! Let's see how to improve it now, and why that's important. You get to that point either way, but I might suggest you get their faster with the automated version.

Reducing the Google - StackOverflow - Copy-Paste Cycle

I wrote about this in a previous note, but the best code you can expect from an LLM is the most predictable code. Sometimes this is good enough, sometimes it isn't. That part is up to you and your code review.

That code review should consider:

• Provenance. Is there a copyright issue?
• Readability. How well can people understand what's going on? (You can, by the way, usually ask your LLM to make the answer more readable or follow a given style).
• Performance. How well will this scale? (Big O stuff).

Here's the reality: your junior developer is going to Google whatever problem they are facing, probably end up on StackOverflow, and then copy/pasting the answer.

As a senior dev, you know this already. The only thing that's worse than these two cases is when they try on their own to figure it out and continually get it wrong, wasting everyone's time. This might be the best choice in terms of personal growth, but you've got an app to ship!

Let's try an experiment.

SQLite Transactions in Node.js

Let's ask a simple question:

The OG method to answer this question is to RTFM. Start your timer...

(10 minutes later) I give up. I know the answer is likely out there, but I checked the docs for SQLite3 and also read up on the driver. There is one mention of the word "transaction" so I know it's possible, but I have the rest of this email to write so... giving up.

Google It

I worked for 5 years as a programmer before Google came along and I don't know how I did it. It took just one search using the prompt above, and here's the answer which was, of course, StackOverflow:

This wasn't the first hit, however, which was 8 years old and I had to read through it before I realized it was out of date and didn't directly answer the question. With the code above, running serialize is the key... but if there are multiple connections to SQLite and a write comes in to the same record, apparently it causes problems.

More reading is in order, I suppose. Either way: total time spent was about 5 minutes.

Copilot

I asked Copilot the same question using the 4o model:

That took 20 seconds to type and get a response back. The code looks basically the same, and this is what I tell people all the time with respect to Copilot:

That is truly my opinion. I know others feel differently.

Reviewing The Code

Let's put our senior hats back on, shall we? When asking about the code used, we learn that the first example above was lifted from StackOverflow and then modified for clarity by our programmer.

I think we're all used to the drill by now:

For the second example, we would have the same concerns RE copyright and SQL injection. We ask for the same changes as above but, this time, our junior person is back within 10 minutes:

Our junior wrote good notes during our review and pasted them directly into Copilot as a follow up prompt...

Is This A "Good" Thing?

My goal with this post is not to come off as a "pitch man" for Copilot, I promise. I like discussions like this one because my opinions are still forming, and hearing other people's ideas are key.

Anyway: let's get right to it - if you're facing a shipping deadline, faster code is better. If you're worried about the growth of your junior developer, that's a concern here as well.

They didn't write this code, they prompted it. It's like people who call themselves brewers using computerized, all-in-one machines to handle temperature and timing! All you did was push a button!

For me, personally, I'll always take the win on this, which is shipping. In addition, and I think this is critical, is to step through the code with the junior person and:

• Ask if they understand it and how they tested it. Automated tests are OK, but they need to tell a story and the junior dev better be able to discuss that story.
• Discuss copyright exposure.

That last one is a BIG discussion, and how you and your company choose to address it is up to you. I need to sidestep going into detail on this, which I hope you understand, but I did want to recognize the need for the discussion.

So: what do you think? Does shipping something on schedule outweigh the other concerns over AI? I read every reply - so hit me up!

​

​