Why communication is becoming an engineering advantage in the AI era.
A few years ago, I sat in on a product review where a backend engineer had built something genuinely impressive: a system that cut processing time by more than half and quietly solved a bottleneck the whole team had been fighting for months. When it was his turn to present, he opened his laptop, pulled up a diagram full of arrows and service names, and started talking. Within two minutes, the founder's eyes had glazed over. The marketing lead was checking her phone. By the end, nobody in that room, apart from the two other engineers present, understood what had actually changed or why it mattered.
Three weeks later, that same feature got credited in a company update to a completely different engineer, one who had spent ten minutes with the founder walking through what the change meant in plain terms: fewer support tickets, faster load times for customers, a clear before-and-after. He hadn't built the thing. He had explained it. And in the story the company told about its own progress, explaining it turned out to matter more than building it.
That moment has stayed with me because it captures something a lot of skilled developers still don't want to accept: being right and being understood are not the same achievement, and only one of them tends to get remembered.
The old deal is breaking
For a long time, the unspoken contract in software was simple. Write code that works, and the rest will sort itself out. Communication was a nice-to-have, something you picked up if you had the personality for it, not something anyone tied to your actual competence. The strong, silent engineer who let the work speak for itself was practically a stereotype, and in many teams it was a respected one.
That contract made sense when writing working code was the hard, scarce part. If you could take a vague requirement and turn it into a functioning system, you were valuable almost by default, because most people couldn't do that at all. Communication was a bonus skill layered on top of a already-rare one.
AI has changed the scarcity math. A model can now generate a working function, debug a stack trace, draft a migration script, or scaffold an entire feature in the time it takes to type the request. The part of the job that used to be rare, producing code that runs, is no longer rare. It's available to anyone with a laptop and a decent prompt. What's left as the differentiator is everything AI still can't do on its own: knowing which system to build, why it should work that way, what tradeoffs it carries, and how to make all of that legible to the humans who have to fund it, maintain it, or live with its consequences.
That last part, making it legible to humans, is communication. And it just moved from the nice-to-have column to the column that decides who stays relevant.
AI didn't remove the need to explain. It removed the excuse not to.
There's a version of this shift that gets misunderstood. Some developers hear "communication matters more now" and assume it means coding matters less, that the technical bar is dropping while the soft-skills bar rises to compensate. That's not quite it. The technical bar isn't dropping. If anything, it's rising, because AI raises the baseline of what "good enough" code looks like and pushes the real work upstream into decisions: which architecture fits the constraints, which shortcut will cost you in a year, which requirement the client actually meant versus what they typed.
What's changed is that those decisions used to live silently in one person's head, buried in code that only they could fully explain. Now that same person is working alongside a tool that can produce plausible-looking code for almost any instruction, correct or not. Someone has to catch the difference. Someone has to say, out loud, in words another person can follow, why this approach and not that one. If the developer can't do that, the decision-making quietly drifts to whoever can talk about it most convincingly, whether or not they understand it best.
I've watched this happen from the outside, working with founders and technical teams on how they describe their own products. The engineers who get pulled into strategy conversations, who get asked what they think before a decision is made rather than after, are rarely the ones with the most elegant codebase. They're the ones who can sit across from a non-technical founder and say, in two sentences, what a system does, why it matters, and what breaks if it's ignored. Everyone else in the room defers to that clarity, because clarity is rare and relief-inducing. It reads as competence, even when the code behind it isn't the most sophisticated in the building.
What explaining a system actually looks like
This isn't about becoming a smooth talker or learning to charm a room. Explaining a system well is its own discipline, and it shows up in smaller, more frequent moments than a big presentation.
It's the pull request description that tells a reviewer why a change was made, not just what changed. It's the Slack message to a product manager that translates "we're hitting rate limits on the third-party API" into "customers might see delays during checkout for the next hour, and here's what we're doing about it." It's the design doc that a new hire can read six months later and actually understand the reasoning, not just the outcome. It's knowing how to tell a founder that a feature they want will take three weeks instead of three days, and being able to say why in a way that doesn't sound like an excuse.
And increasingly, it's the prompt itself. Writing a clear, well-scoped instruction for an AI coding assistant is an act of technical communication. A developer who can't articulate what they actually want, who can't break a vague goal into a precise, well-reasoned request, will get vague, unreliable output back. The people getting the most out of AI tools right now aren't necessarily the strongest coders in the traditional sense. They're the ones who think clearly enough to explain a problem in a way that produces a useful answer, whether the listener is a human or a model.
Explaining a system also means being able to say what it doesn't do, and why that's fine. A lot of technical trouble starts when someone assumes a system works a certain way because nobody told them otherwise. The developer who spells out the edges and limitations of what they built isn't showing weakness. They're preventing the kind of confusion that turns into a much bigger problem three months down the line.
The career cost of staying silent
I think about that engineer from the review meeting often, not because he was untalented, he clearly wasn't, but because his silence had a cost he probably never fully saw. He kept building strong things. He kept getting quietly passed over for the conversations that shaped what got built next. Nobody in that room thought less of his skills. They just stopped including him in the decisions, because including him meant sitting through explanations nobody could follow, and eventually people stop asking.
That's the real risk for developers who treat communication as optional in this new environment. It's not that they get replaced by AI. It's that they get replaced, slowly and without much drama, by other developers who use AI the same way they do but can also explain what they're doing to the people who control budgets, timelines, and promotions. Technical skill without the ability to translate it becomes a kind of quiet ceiling. You can be excellent and still be invisible.
This is especially true now that so much routine coding work is faster to produce. When output is cheap, judgment and clarity become the expensive, visible parts of the job. The developer who can walk a non-technical stakeholder through a tradeoff, defend a decision under questioning, or write documentation someone else can actually use is doing work that AI still struggles to do convincingly on its own. That work doesn't show up in a commit history, but it shows up in who gets trusted with bigger problems.
Building the skill without faking it
None of this means turning into a different person or performing confidence you don't feel. The developers who explain things well usually aren't the loudest people in the room. Some of the clearest technical communicators I've worked with are naturally reserved. What sets them apart isn't personality. It's a habit of translation, practiced enough times that it becomes automatic.
A few things tend to build that habit faster than anything else. Writing a short summary before diving into technical detail, so the listener has something to hold onto. Asking what someone already knows before explaining, instead of assuming a shared starting point. Reading pull request comments and documentation from developers known for clarity, and noticing what they leave out as much as what they include. Practicing the version of an explanation meant for a non-engineer, even when the immediate audience is other engineers, because that discipline forces precision. None of this requires giving up technical depth. It requires treating the explanation as part of the work, not an afterthought tacked on once the real work is done.
The developers who will outlast this shift
The engineer who explained the feature in ten plain sentences didn't out-build the one with the elaborate diagram. He out-communicated him, and in doing so, he made his work visible in a way the other engineer's work never became. That's the shift happening across the industry right now, not loudly, but steadily, in every review meeting, every prompt written, every doc that either gets read or gets ignored.
Building will always matter. Nobody is arguing otherwise. But building is no longer the rare skill it once was, and rarity is what determines value. What's rare now is the developer who can take something complicated, technical, and easy to get wrong, and make it make sense to someone who didn't build it. That person doesn't just survive whatever AI changes about this profession. They become the one everyone else, human or otherwise, depends on to make sense of it.
Top comments (0)