That is exactly what some of the low-code tools aim to address: by having a visual, highly productive tool, you enable better collaboration with business stakeholders.
Requirements gathering becomes an interactive process where you sit together with a business stakeholder to model your application together: by doing it in a visual manner, the stakeholder can understand what you are doing, and you can process suggestions and feedback in seconds, so that the stakeholder can immediately validate the results of a change.
Doesn't work for all requirements, but in many cases you get better software because you understand the requirements better.
This is all great until you get to the stakeholder who prototypes something in Excel (or Honeycode, I guess) and since it only "took them a few days to do this" can't understanding why scaling it up takes six months or a year and won't listen to you when you try to explain that they under-spec'd the system by an order of magnitude.
(This happened a lot when Visual Basic came out - management types would spend a weekend playing with the visual UI editor and then give the developer a week to fill in the complicated business logic behind it.)
(Developer here who has t-shirts older than a some of the people posting)
Requirements gathering becomes an interactive process where you sit together with a business stakeholder to model your application together: by doing it in a visual manner, the stakeholder can understand what you are doing, and you can process suggestions and feedback in seconds, so that the stakeholder can immediately validate the results of a change.
Doesn't work for all requirements, but in many cases you get better software because you understand the requirements better.