Why I think the developer role is moving closer to the client

Nikos Katsikanis - April 8, 2026

I think AI is absorbing the first translation pass

When a client describes a problem, I no longer feel that I need to wait for every idea to be translated through a separate business layer before anything useful happens. I can use AI to shape the rough idea, explore options, draft task breakdowns, and surface questions much faster than I could before.

That does not mean I do not value product owners, analysts, or other domain people. It means I need fewer handoffs just to get to a usable first draft, and I can stay closer to the client while the thinking is still alive instead of waiting for a polished requirements packet.

I still need to decide what actually matters, what is risky, what is vague, and what should be challenged before it becomes code.

I spend less time waiting for a perfect brief

I used to see a lot of time disappear into the gap between a business idea and a development-ready explanation. AI compresses that gap for me. I can get a first pass on requirements quickly, then move into the conversation that actually matters: what the client is trying to achieve, what they are trying to avoid, and what tradeoffs they are willing to make.

That also means I do not need to be spoon-fed every feature from a chain of other roles before I can think clearly. I can do more of that translation work myself, which makes the delivery loop shorter and the conversation more direct.

I wrote more about the delivery side of that shift in Why I think fullstack architects matter more with AI. The more AI compresses the distance between idea and implementation, the more I want the same person to understand the business, the system, and the delivery tradeoffs.

I think interpersonal skill is becoming a technical advantage

If AI handles more of the drafting, I think the human part of the job becomes more visible. I need to listen better, ask sharper questions, notice when the client is really worried about risk instead of the literal feature request, and keep people calm when the work gets messy.

I do not see that as a soft skill add-on. I see it as part of delivery. The better I understand the person on the other side, the better I can translate the work into something they can trust.

I prefer long-term relationships that feel human

I recommend turning long-term client relationships into friendships where it makes sense, because I think it reduces stress and improves job satisfaction. I do not mean blurring boundaries or losing professionalism. I mean I prefer enough familiarity that I can be honest, ask for help, and talk through tradeoffs without performing a reset every time I open my laptop.

I wrote about the downside of shallow delivery in The Hidden Cost of Short-Term Outsourcing. Short engagements often optimize for speed, but I think long-term relationships optimize for understanding, and understanding is what makes the work easier to carry.

I do not want to act like a requirements machine

I do not see myself as a robot that turns requirements into code. I think the better model is a joint success path: the client brings domain reality, I bring technical judgment, and both sides keep iterating until the product matches how the organisation actually works.

That model is slower to fake and faster to trust. It lets me build fewer wrong things, say no earlier, and spend more time solving the right problem instead of cleaning up avoidable confusion later.

This is the part of the job I want more of

The more AI helps with drafting, the more I want to spend my energy on the parts of delivery that still need a human: judgment, empathy, negotiation, and relationship building. I think that is where experienced developers can stand out now.

For me, that is not a downgrade of the role. It is a better version of it.