The commoditization of code: Why empathy is the new core engineering skill

For years, many engineering organizations made a quiet trade-off: they tolerated poor collaboration in exchange for deep technical expertise.

 

Most of us have worked with someone who fits this pattern: an engineer with exceptional knowledge of the system, whose code reviews could be blunt and who found cross-functional conversations frustrating. Often, they were also the only person who could fix critical issues in the code they had built. Because that expertise was scarce, teams accepted the friction as part of the cost of doing difficult work.

 

Generative AI is changing that trade-off.

 

As large language models (LLMs) make code generation faster and more accessible, an engineer's value increasingly depends on their ability to understand requirements, evaluate trade-offs and help teams deliver reliable software. Technical expertise remains essential, but so do the skills that allow teams to work effectively together.

 

 

When writing code is no longer the hardest part

 

Learning to code has traditionally required years of mastering language quirks, memory management, API contracts and framework behavior. A large part of what we recognized as seniority was an accumulated mental index of compiler errors, edge cases and standard design patterns.

 

LLMs can now help engineers generate services, draft unit tests, modernize legacy code and optimize queries. But generating code is not the same as delivering a reliable implementation. Someone still needs to understand the system, its constraints and the consequences of getting things wrong.

 

Writing code was never the ultimate goal of software engineering. It was a way to translate human intent into working software. As AI reduces the time required for that translation, understanding what to build and ensuring it works as intended become even more important.

 

Empathy, maintainability and collaboration have always mattered in engineering. What is different now is where the effort goes. When an engineer can generate in an afternoon what used to take a week, the cost of writing code falls, but the cost of understanding it does not. Every generated change still has to be reviewed, integrated, operated and eventually debugged by people, so faster generation simply pushes the workload downstream onto the parts of engineering that have always depended on collaboration.

 

Code review is the first place this shows. More code can arrive faster, sometimes from an author who did not reason through every line, so reviewers must understand intent rather than just check correctness and authors must make that intent easy to see. 

 

Coordination comes under similar pressure. When every engineer can produce more change in less time, teams need to agree on interfaces, priorities and boundaries. Otherwise, they risk spending the time they saved untangling conflicting work. 

 

Shared understanding also erodes more quickly. Engineers who write code by hand build a mental model of it as they go, but generated code can reach production without anyone holding that model. 

 

This changes what makes an engineer valuable. When code is commoditized, the differentiator shifts from how fast you write software to how effectively you understand human systems, articulate intent and help the engineers around you do the same.

 

 

Conway’s Law in the age of AI

 

Software engineering has never been a purely technical pursuit. Decades ago, Melvin Conway observed that organizations design systems that mirror their communication structures. Conway’s Law remains relevant because software architecture is shaped by human collaboration.

 

When systems fail in modern enterprise environments, they rarely fail because an engineer forgot how to write a binary search. They fail at the interfaces:

 

• Between product intent and technical implementation.

   

• Between security mandates and developer velocity.

   

• Between platform teams and the product teams that depend on them.

   

• Between an engineer’s assumptions and what customer’s actually need.

   

An LLM can help generate microservice or explore architectural options.

 

But people remain responsible for negotiating the trade-offs between a product manager’s aggressive deadline and a compliance officer’s regulatory requirements. It cannot sit across the table from a frustrated customer support lead, listen between the lines and discover that the feature requested is entirely different from the problem that needs solving.

 

Navigating these interfaces requires deep empathy. It requires an engineer who does not view non-technical colleagues as impediments to "real engineering," but rather as critical co-designers of the system’s constraints.

 

The ability to build shared understanding across these boundaries becomes especially valuable when AI allows teams to produce software faster.

 

 

Empathy as an operational discipline

 

In many organizations, empathy is treated as a soft, loosely defined virtue, something for HR workshops and performance reviews. In engineering, however, it works as a practical discipline that shows up directly in the artifacts we build and the operational habits we sustain.

 

1. Maintainability: Empathy for the on-call engineer

 

The classic "rockstar" developer often wrote code that showcased their own skill: dense one-liners, complex abstraction layers and unfamiliar paradigms that few teammates could easily follow.

 

Empathetic engineers write boring code.

 

They understand that code is read far more often than it is written. They design systems with explicit variable naming, intuitive architecture, good observability and clear documentation. They write with the next reader in mind, often a junior engineer debugging a cascading outage at three in the morning, six months from now. In software design, simplicity is one of the clearest expressions of empathy

 

2. Code reviews: Cultivating psychological safety

 

Code review can easily become a place to prove a point rather than improve the code. Pedantic comments, dismissive nitpicks and gatekeeping presented as high standards can wear down a team's psychological safety. When engineers worry about being criticized in their pull requests, they take fewer risks, hide their blockers and hold on to unfinished work.

 

An empathetic engineer approaches a code review as a partner stress-testing an idea. They frame their feedback around the system rather than the person: "How does this handle network latency?" instead of "Why did you write this so inefficiently?"

 

They acknowledge good architectural choices and treat mistakes as learning opportunities for the whole team.

 

This doesn't mean lowering technical standards or avoiding difficult conversations. It means making feedback useful, so engineers feel comfortable raising concerns and challenging assumptions.

 

3. Working with risk and compliance

 

In regulated industries like banking and healthcare, software must meet legal requirements, privacy controls and external auditors.

 

It is tempting to see these constraints as obstacles and compliance officers as bureaucratic roadblocks. An empathetic engineer recognizes that compliance requirements represent real risks: customer privacy, financial stability and system safety. They work with legal and security teams to build compliance directly into the automated delivery pipeline, turning regulatory hurdles into architectural guardrails.

 

 

Recognizing the multiplier

 

Most engineering organizations know that some engineers make the people around them more effective. Fewer have a reliable way to recognize that work, let alone reward it.

 

A multiplier's contributions rarely show up in individual productivity metrics. They unblock a junior developer before a deadline slips, pair on a stubborn edge case, write the design note that saves three teams a week of confusion or improve the deployment pipeline everyone depends on. 

 

The team ships more smoothly as a result, but commit history, ticket counts and individual velocity metrics credit none of it to them. As AI makes individual code output cheaper and easier to inflate, those metrics become an even weaker signal of impact.

 

Organizations can recognize this work by gathering peer input in performance reviews, treating thorough, constructive code reviews as a contribution in their own right and valuing documentation, onboarding and incident follow-ups alongside feature delivery. 

 

Team-level outcomes, such as how reliably a team delivers and how quickly new members become productive, say more about an engineer's impact than how many lines of code they committed in a week.

 

The aim isn’t to set collaboration against technical skill. Effective engineers need both. It’s to make sure the work that multiplies a team's output is counted, rather than left as an unrewarded extra for the people willing to do it.

 

 

Rewiring engineering culture

 

If software organizations are to thrive in the era of artificial intelligence, leadership must radically rethink how we attract, evaluate and promote technical talent.

 

We must dismantle interview loops that prioritize the rote memorization of algorithms over collaborative problem-solving. Asking a candidate to invert a binary tree on a whiteboard reveals nothing about their ability to communicate under pressure, receive constructive feedback or navigate ambiguous product requirements.

 

Hiring loops should evaluate candidates on their socio-technical maturity:

 

• How do they handle a code review where their solution is challenged?

   

• Can they explain a complex architectural trade-off to a non-technical stakeholder?

   

• Do they demonstrate genuine curiosity when confronted with a domain they don't understand?

   

• How do they behave when their teammates fail?

   

Engineering promotion ladders must reward organizational enablement with the same weight traditionally given to raw technical output. If an engineer mentors three junior developers into confident system contributors, that achievement must be celebrated above the developer who single-handedly refactored a subsystem while alienating their squad.

 

 

The human core of software craftsmanship

 

The democratization of code generation through AI makes clear what was always true: the hardest problems in software are human ones. Deciding what to build, aligning teams around a shared understanding and designing systems people can maintain. 

 

For engineering teams, the practical implication is that the time AI saves in writing code shouldn’t simply turn into more code. Some of it needs to be reinvested in the work that keeps code understandable: careful review, clearly documented intent, pairing and mentoring. 

 

Teams that plan for this work, and recognize the people who do it, will get lasting value from AI. Teams that treat it as optional will end up with more software that fewer people understand.