Code is 20% of the Job
Most programmers spend about 20% of their time writing code. The other 80% is something else entirely:
- Clarifying requirements in planning meetings
- Explaining technical decisions to stakeholders
- Negotiating scope and trade-offs with product managers
- Giving feedback to colleagues
This is not a soft-skills pitch. This is about the conversations that actually determine whether your code ships, whether your features work, and whether your career advances.
AI can write code. It cannot negotiate a deadline.
Conversation 1: Requirements Clarification
The most expensive bug I've ever encountered wasn't a logic error. It was a feature that did exactly what the ticket said, but not what the stakeholder actually needed. It took three weeks to build, two more weeks to realize the mistake, and another week to fix.
The root cause was a requirements conversation that nobody had.
Requirements clarification is a skill. It involves asking questions that surface hidden assumptions, probing the "why" behind stated constraints, and getting specific about edge cases. Senior developers do this naturally. Junior developers often think requirements are just things written in tickets.
AI does not understand requirements. It does not know your company's context. It cannot ask the question that would have prevented three weeks of wasted work.
The developers who get things right the first time are the ones who had the right conversations before writing a line of code.
Conversation 2: Technical Trade-off Communication
Every architectural decision is a trade-off. You're choosing speed of development over flexibility, or simplicity over scalability. The developers who advance fastest are the ones who can articulate these trade-offs clearly — to managers, to other engineers, to stakeholders.
This matters because technical decisions often have business consequences that aren't immediately obvious. A "clean" architecture might take twice as long to build. A "quick" solution might create technical debt that slows down the team for months.
The conversation isn't just about the technical merits. It's about mapping technical reality to business constraints, and doing it in language that non-technical stakeholders can understand and act on.
AI can explain technical concepts. It cannot weigh trade-offs in the context of your specific business, team, and timeline.
Conversation 3: Scope Negotiation
"Why can't we have it all?"
Because scope is a negotiation. Features take time. Time has a cost. Resources are finite. Every "yes" to a feature is implicitly a "no" to something else — usually something implicit.
The developers who are trusted partners in product decisions are the ones who can have honest scope conversations without destroying relationships. They can say "yes, we can do that, but here's what it costs" and help find creative solutions that satisfy the underlying need without killing the timeline.
This is a conversation about priorities, about trust, about understanding what actually matters to the business. AI has no skin in the game.
Conversation 4: Feedback Delivery
The hardest feedback to give is honest feedback that might sting. The hardest feedback to receive is feedback that challenges your assumptions. The developers who get better fastest are the ones who can do both.
Giving feedback well requires reading the other person's emotional state, understanding their context, choosing the right moment, and framing the message so it lands rather than bounces off.
This is not a technical skill. It's not something you can learn from documentation. It's something you learn from actually doing it — and from getting it wrong, and trying again.
AI cannot give feedback that changes behavior. It can generate words that sound like feedback.
Conversation 5: Mentoring Handoffs
The most valuable developers don't just write code. They grow the team around them. This means mentoring junior developers through the moments that define how they think about software.
The handoff conversation is when you explain why a decision was made a certain way, what you considered and rejected, and what the junior developer should watch out for. Done well, this is worth more than any blog post or tutorial.
It's not about the code. It's about the judgment behind the code. And judgment transfer requires human connection.
Why AI Can't Do These
AI processes language. It can generate responses that sound like these conversations. It can even simulate the structure of a good negotiation.
What it cannot do is:
- Understand the specific humans involved and what they care about
- Read the room before deciding how to frame a difficult conversation
- Make the judgment call about which battle to fight and which to let go
- Build the trust that makes honest conversations possible
These conversations require you to be present. AI is never present.
Part of the AI-Proof Programmer series.
Top comments (1)
This is one of the best reminders that software engineering is still deeply human work.
AI can generate code in seconds, but it still can’t survive a meeting where three stakeholders say “urgent” with three different meanings 😄
The real seniority jump happens when developers stop only solving technical problems and start translating between business, people, and technology.
Requirements clarification alone probably saves more money than most optimization techniques ever will.
Also loved the point about mentoring — because architecture decisions are easy to copy, but judgment takes conversations, mistakes, and context.
The future probably belongs to engineers who can both use AI effectively and ask uncomfortable but necessary questions in the room.
Turns out “communication skills” were never optional DLC for programmers after all.