Software development as a career is something that involves more than the ability to write code, this much has been established. More often than not, fixing and extending the functionalities of existing applications is what developers do. Where things can get complicated is where clients describe their problems; communication problems at this stage can impact the overall project and/or lead to situations where the developer does more than what is needed or doesn't do what is needed.
ORGANIZATION STRUCTURE IN DEVELOPMENT TEAMS
In more structured environments, developers don't interact with clients, there are professionals who interact with the client, get the feedback of the client and convert the feedback into Business Requirement Document (BRD) or Product Requirement Document (PRD). PRDs and BRDs are sometimes used interchangeably. The existence of the middlemen between developers and clients exists because there is usually some form of friction between clients and developers and it stems from communication problems.
A RELATABLE EXPLANATION
Some clients make the mistake of telling developers how to extend or fix a problem when they should be telling the developer what the problem is in plain terms, a client who doesn't know how to write code most likely can't properly talk about how to fix problems in code. Developers also have a penchant for confusing the client because developers describe the demands of the client using software engineering terms that the client is most likely not familiar with. Asking a client to confirm the analysis makes them frustrated.
WHO WRITES THE DOCUMENTS?
Business analysts and product managers take charge of listening to the clients, getting their demands and converting them to actionable documents that developers can use to solve the problem. The BRD/PRD serves as a very reliable judge of project completion. It's easy to imagine that clients are some people who go to software development firms, however, we have internal and external clients. Within organizations, developers still have to build and maintain solutions for their organization and non-developer colleagues.
FINALLY
The tech space is so vast that I am sometimes amused by people who believe that the software engineering space is only for people who write code, there are other roles that are somewhat technical and don't involve writing code. PRD/BRD help with conflict resolution a lot, it can however be a pain if the document is written well. The key takeaway is that developers don't typically interact directly with the people they build solutions for, we also have documents that tell us what to do.