Conversational software development does not scale

EDIT Spring 2023: 

The term 'conversational development' I use here is about designing software over a meeting and not writing anything down. The 'conversational programming' with AI tools that are now the rage is a separate concept; this uses AI to help program. 

To that end; using AI as the design assistant, where 'conversational design' with an AI bot will be your documentation and diagramming assistant. That will be a useful companion in the goal of producing a coherent design.

Designing over a zoom meeting.....

When building a small piece of technology, or just dinner; it's easy to just 'talk it out'. If you have skilled people, or you are one yourself, you can understand the design of something small by having a conversation, and building a mental model in your head of what you are going to make.
The smarter the people are in the conversation, the more you can do. You and the people you are working with can grasp the intentions of the conversation, and together have a common understanding of what is going to be made.

Mental models 

This can work up until the mental model that your group are forming becomes too large to have an accurate common understanding of what it is. Mis-understanding form quickly, and can be tackled by more conversations in a meeting, but eventually the complexity will overwhelm the group, no matter how smart the participant are. The smarter the participants are can add to the trouble; people will assume they understand each other because they are used to dealing with large abstract structures.
What can be made successfully with conversational development techniques? Dinner, re-decorating a room, and maybe a birdhouse. Something small, or has been done before by the people involved can be repeated because the situation and the parameters around it are understood and done before.

A bit of Design

While small projects can be made with conversation, what would happen if we defined what we were making in a more formalized way? If we wrote or followed a recipe for dinner, created a blueprint with defined dimensions of the birdhouse or sketched a mock-up of the interior design? The quality of the result would improve substantially.

What about building larger projects? Applying conversational techniques to build a building would result in that building falling down? It's doubtful the building would reach completion at all. Can you imagine that work site? "Ok, Joe, make a wall over there and another over there, and when thats done line up the top of the walls so we have a roof. We can figure out the second floor when we get there". This was how building were made about 300 years ago, and as a result there were no buildings or complex structures; the process just didn't scale. Since then we have developed formalized architecture to make plan we know can be built, and developed engineering techniques to validate that plan and verify that those plans are followed while building the structure.

Design in Software

Building software is an abstract process. You don't get to see it evolve like building architecture, so to understand it you need to describe it; and in doing so you and the people describing it end up making mental models of what it does and 'talk it out'.
The visual aspects of software are catching up to this reality and have evolved to making mock-ups and sometimes even 'flows' and 'experience' design artifacts that explain the visual reality. This is big improvement over conversations but falls short of a full design because of the reality of software. The UI is about 10-15% of what the application does. Some software is more or less, but there can be the case of a well detailed mock-up for the visual 15% and no design at all for the remaining 85%. That's a big gap, and that gap will be noticeable in the final product. It might look good, but it "doesn't work".

Why does this not work as a complete design? The same way a mock-up for decorating a room is not the reference for creating the building itself. There has to be an architect-ed design that is validated by engineering to make the larger structure; even if the complexity involved seems minimal at first. It makes a better structure.

So, how to do this in software? The mental models that you make in your head and collaborate with the group need to be defined and not verbally. Things need to be written down, and measured. How the user moved through the application can be formalized in a diagram. How the containers in the application work together and how the components within them interact to fulfill their responsibilities can be formalized. This technique can scale as it does for skyscrapers.

Write it down

You probably aren't making a skyscraper, but you are probably are building something bigger than a birdhouse. Give your software project a chance to scale by formalizing your design and the intentions of the solution as you understand it yourself, and in the group. Evolve that design, version it and grow it on paper and use conversation to validate and verify that design instead of continually defining it from scratch in your collective heads. The conversion will build on and grow the formalized design to enable that large scale project you all have envisioned in your head.