AI Can Write Your Code. It Can't Have the Hard Conversation for You.
A few months ago, a junior engineer on my team opened a pull request that looked flawless. Clean abstractions, solid error handling, good naming conventions. I was genuinely impressed. Then I left a comment asking why they'd chosen that particular data structure, and the response was: "I'm not sure, Copilot suggested it."
That moment stuck with me. Not because the code was bad. It wasn't. It worked fine. It stuck with me because I realized the game had changed in a way I hadn't fully processed yet.
The playing field is flat now
Here's the thing nobody wants to say out loud: AI has made us all roughly the same level of "good" at writing code. I don't mean that experience doesn't matter. It does. But the raw output gap between a junior with Claude Code and a senior without it? It's shrinking fast. Sometimes it's already gone.
Every engineer on your team now has access to tools that can generate decent, working, sometimes even elegant code. The syntax is correct. The patterns are reasonable. The tests pass. If you're measuring engineers purely by "can they produce functioning code," then congratulations, you've got a team of interchangeable parts.
But that's never been the whole job. And I think a lot of us knew that, vaguely, in the way you know you should floss more. Now it's impossible to ignore.
The engineers who stand out in 2026 aren't standing out because of their code. They're standing out because of everything around the code. The way they communicate decisions. The way they handle conflict. The way they own their mistakes instead of deflecting. The way they make the people sitting next to them (or in the next Zoom square) better at their jobs.
Soft skills. I hate that term, honestly. There's nothing soft about telling someone their approach is wrong. There's nothing soft about admitting you broke production. But that's what we're calling them, so fine.
The PR with 23 comments
I want to tell you about the worst pull request review I've ever received. Not worst as in mean. Worst as in volume.
I was maybe two years into my career. I'd spent three days on a feature I was proud of. Opened the PR on a Friday afternoon (first mistake). By Monday morning, there were 23 comments. Twenty-three. Some were nitpicks, sure. But a lot of them were real, structural problems I hadn't seen. My abstraction was wrong. My error handling covered the happy path and basically nothing else. I'd built the whole thing around an assumption about the data shape that was only true in development.
I remember staring at my screen feeling genuinely sick. Not because the feedback was unfair. Because it was accurate, and I'd been so confident.
Here's what I did wrong: I got defensive. I replied to comments with justifications instead of curiosity. I pushed back on things I should have just fixed. I treated the review like an attack on my competence instead of what it actually was, which was a senior engineer spending their Monday morning trying to make my code better.
It took me about a week to realize how much I'd learned from that PR. And about a year to realize the real lesson wasn't technical at all. It was about how to receive feedback without letting your ego eat you alive.
I still think about that when I'm reviewing someone else's code. The way you deliver feedback matters enormously. "This is wrong" and "I think this might cause issues in production because X" contain the same information. They land completely differently.
AI makes communication more important, not less
This is the part that feels counterintuitive. You'd think that if AI handles more of the coding, communication would matter less. The opposite is true.
When a junior engineer ships AI-generated code that looks polished, the ability to explain why you made a decision becomes the thing that separates you from your tools. I can ask Claude to write me a caching layer. I can't ask Claude to sit in a sprint planning meeting and explain to the product team why caching introduces eventual consistency tradeoffs that will affect the feature they want to ship next quarter.
(Well, I guess I could try. But nobody's going to like the answer.)
The code is the easy part now. The hard part is everything humans have always been bad at. Saying "I don't understand" in a room full of people who seem to understand. Telling your tech lead that the timeline is unrealistic before it's too late, not after. Writing a design doc that a non-technical stakeholder can actually follow. Explaining to a teammate, kindly but honestly, that their approach needs to change.
The engineers who communicate well have always had an advantage. Now they have an overwhelming one.
Speaking up when it's easier not to
I once sat in a meeting where the team was about to commit to an architecture decision I thought was wrong. I had reasons. I'd worked on a similar system at a previous job and watched it fall apart under load. I had specific, relevant experience that said "this will not scale the way you think it will."
I said nothing.
Why? The usual reasons. The tech lead seemed confident. Other people were nodding. I was relatively new to the team and didn't want to be the person who slows everything down with objections in week three. I told myself I was probably wrong. I told myself it would be fine.
It was not fine. Four months later, we spent three weeks rewriting the thing I'd been worried about. During the post-mortem, I mentioned that I'd had concerns early on, and someone asked, very reasonably, why I hadn't said anything.
I didn't have a good answer.
This is something I've noticed about engineering culture generally: we default to quiet. We're trained to think before we speak, which is good, but somewhere that turns into "think instead of speaking," which is not. The cost of staying silent when you have something valuable to add is almost always higher than the cost of being wrong out loud.
Being wrong out loud is embarrassing for about ten minutes. Staying silent can cost the team months.
Imposter syndrome is a permanent roommate
I've been writing code professionally for years now. I still get that feeling. You know the one. You're in a meeting with people who seem to know more than you. You're reading a codebase that feels alien. You're staring at a problem you're supposed to solve and your brain is just producing static.
The PR with 23 comments? Part of why I got so defensive was imposter syndrome. Every comment felt like evidence of a thing I already suspected: that I wasn't good enough to be here.
Here's what I've learned since then. It doesn't go away. Seriously. I've talked to staff engineers with fifteen years of experience who still feel it. The difference is they've learned to recognize it for what it is, which is just a feeling, not a fact. They've learned that the feeling of "I don't know enough" is actually a pretty reliable indicator that you're growing.
The most dangerous engineers aren't the ones who feel like imposters. They're the ones who never do.
Feedback is a skill you build, not a personality trait
Some people think you're either good at giving feedback or you're not. Like it's a character attribute you rolled at birth. That's nonsense.
Giving good feedback is a skill. It's one I was terrible at for a long time. I used to oscillate between two modes: saying nothing useful ("looks good to me!") or being accidentally brutal ("this whole approach is wrong, we need to start over"). Neither is helpful.
The thing that changed for me was watching a senior engineer on my team handle a really difficult code review. A teammate had built something over the course of a week that, honestly, needed to be mostly rewritten. Instead of saying that, she started by identifying the parts that were solid. Then she asked questions. "What led you to this approach? Have you considered what happens when X?" She made the other person arrive at the conclusion themselves, without ever making them feel stupid.
It took longer than just saying "rewrite this." It was worth every extra minute.
The best feedback I've ever received didn't tell me what to fix. It helped me understand what I'd missed and trusted me to figure out the fix myself.
Receiving feedback without melting down
The other side of this is learning to receive feedback. I'm still working on this one, honestly. My default reaction to criticism, even constructive criticism, is a small internal panic followed by a strong urge to explain myself.
What helps: I try to wait before responding. Not long. Just long enough to ask myself, "Is this person trying to help me or hurt me?" The answer is almost always "help." Once I internalize that, the defensiveness fades and I can actually hear what they're saying.
Ownership means saying "I'll fix it" before anyone asks
There's a version of engineering where things break and the first instinct is to figure out whose fault it is. I've been on teams like that. They're miserable.
Then there's the version where something breaks and somebody just says, "I'll look into it." No finger-pointing. No "well, the AI generated that part." No digging through git blame to prove it was someone else's commit. Just ownership.
This matters more now that AI is in the loop. It's tempting, when a bug shows up in code that Copilot suggested, to feel like it's not really your fault. You didn't write it. The AI did. But you reviewed it. You approved it. You shipped it. It's got your name on it.
If it shipped under your name, it's your responsibility. Full stop. The tool that helped you write it is irrelevant.
The engineers I respect most are the ones who take ownership reflexively. When something goes wrong, their first thought isn't "who" but "how do we fix it." That attitude is contagious in the best possible way.
Mentorship when your mentee has a copilot
Mentoring junior engineers has gotten genuinely weird. I don't mean that in a bad way, but it's different now.
A junior engineer with Cursor or Claude Code can produce output that looks senior-level. The code compiles, the tests pass, the PR looks clean. But when you dig into the "why" behind their decisions, sometimes there's nothing there. They didn't make decisions. The AI made decisions, and they accepted them.
This is the real danger of AI in engineering, and it's not that juniors will become obsolete. It's that they'll skip the part where they build judgment. Writing bad code and learning from it is how you develop intuition for good code. Struggling with a problem for hours before finding the solution is how you learn to recognize that class of problem forever. If AI short-circuits that process, you end up with engineers who can ship features but can't debug them, can't explain them, and can't adapt when the requirements change in ways the AI didn't anticipate.
My approach to mentoring has shifted. I spend less time reviewing what the code does and more time asking why it does it that way. "Walk me through your thinking" is probably my most-used phrase now. If someone can't explain their own PR, that's the conversation we need to have, regardless of whether the code itself is correct.
The best engineer I've ever worked with
Her name was Sara (not her real name, but close enough). She was a senior engineer at a company I worked at a few years back. She wasn't the most technically brilliant person on the team. If you'd given everyone a LeetCode test, she probably would've landed somewhere in the middle.
But she was, without question, the best engineer I've ever worked with.
Sara had this ability to walk into a room full of people arguing about technical approaches and, within about five minutes, get everyone aligned. Not by being the loudest or pulling rank. She'd ask questions that cut right to the core of the disagreement. "What are we actually optimizing for here?" "What's the worst thing that happens if we're wrong?" She'd restate what people were saying in clearer terms than they'd used themselves, and suddenly the path forward was obvious.
She wrote clear, boring, maintainable code. She documented her decisions. She gave feedback that was direct and kind. She admitted when she didn't know something, which made everyone else feel safe doing the same. When things broke, she was the first person to jump in, not because it was her code, but because it was her team.
Sara made everyone around her better. That's the thing. The best engineer on your team might not be the best coder. They're the person who raises the average. Who makes the quiet person feel comfortable speaking up. Who turns a tense code review into a learning moment. Who takes the time to explain something they could've just fixed themselves.
That's the skill set that AI can't replicate. And it's the one that matters most.
So what do you actually do about this?
I'm not going to give you a numbered list of "actionable tips" because I think that's reductive. But I'll tell you what's worked for me.
Practice saying things out loud. In meetings, in code reviews, in Slack threads. The muscle of "I have a thought and I'm going to share it" only gets stronger with use. You'll be wrong sometimes. That's fine. Being wrong and visible is more useful than being right and invisible.
Get comfortable with discomfort. Giving honest feedback is uncomfortable. Admitting you don't understand something is uncomfortable. Owning a mistake publicly is uncomfortable. Do it anyway. The discomfort is the point. It means you're doing something that matters.
Watch the people you admire and figure out what they're actually doing. I promise you it's not writing clever algorithms. It's probably something quieter and harder to measure. It's the way they listen. The way they phrase hard truths. The way they make space for other people.
And stop measuring your worth by your code output. Especially now. Especially when an AI can match your output in a fraction of the time. Your value isn't in what you produce. It's in how you think, how you communicate, and how you make your team better.
The code writes itself now. Almost literally. The question is: what are you bringing that the machine can't?