Introducing Dialogic Programming

Or how software gets developed in the future

Programming as a discipline is changing. It will never be the same. Everyone says AI is changing the field, but nobody has quite explained how. I’m here to show that, if there is not a single way things will go down, there is a best way. A new programming paradigm for the age of AI is called for.

It’s clear the powerful code generation abilities of LLMs will alter the nature of software engineering irrevocably. Anyone who hasn’t seen the writing on the wall yet needs to wake up. However, the end of SWE as we know it means the beginning of something newer, and, in my opinion, far more powerful, accessible, creative and enjoyable. To get there, however, will take cutting-edge, ultramodern ways of thinking about the role and skills of a developer and they relate to the production of code.

It’s time to put a name to this new way of doing things. I have it in mind to coin the name for a new type of programming paradigm, fit for the age of LLMs. Call it dialogic programming. Or conversational programming if you want to sound a bit less nerdy.

What Is Dialogic Programming?

LLM-integrated development workflows put a fresh spin on noted computer scientist and mathematician Donald Knuth’s idea of literate programming. In his article advocating for the concept of literate programming, Knuth sees a program as a “work of literature” and advocated for a twist on how programming is typically viewed. “Instead of imagining that our main task is to instruct a computer what to do, let us concentrate rather on explaining to human beings what we want a computer to do,” writes Knuth. For Knuth, the writing of comments, the non-executable, explanatory text placed alongside executable code that documents its purpose, logic, or behavior, should be the first focus of the programmer. Programs grow out of that discursive, explanatory writing process. This is contrary to the ordinary way of thinking where comments are seen as an afterthought. For Knuth a program is composed like an essay. Programmers are writers, authors, in the literary sense.

Speaking for myself as someone who is both a writer and a programmer, I always found literate programming appealing. I’ve always thought I was a better writer, and particularly an expository writer, than I was a programmer, so when these supercharged LLM chatbots came out a few years ago I couldn’t help but cackle like a mad scientist. It is so incredibly empowering for someone who has both the verbal facility and the programming knowledge.

Sadly, old-fashioned literate programming is not suited for the fast paced, hectic environments of the modern workplace—which are more deadline than dissertation. All that is changing, however. LLMs have reversed the arguments against literate programming in workplace settings. Dialogic programmers, who learn to work closely and carefully with a high-powered LLM during their work, can easily outperform and outproduce programmers who don’t embrace the technique. Literate programming is now the way to get things done. Instead of taking away from time and effort from writing code, writing comments is now directly conducive to code production.

Dialogic programming is an evolution of literate programming. Instead of explaining programs verbally to other people (although we get this for free as a human-readable conversational history) we explain them to LLMs. The future of programming is a kind of dialogue that incorporates both code and text in a self-documenting back and forth dynamic. This process is, as Knuth advocated, more essayistic, but it’s also conversational and interactive. The word “dialogic” , the adjectival form of “dialogue” emphasizes its verbally interactive character.

As with literate programmers, dialogic programmers are essentially authors first and foremost. “Such an author, with thesaurus in hand, chooses the names of variables carefully and explains what each variable means. He or she strives for a program that is comprehensible because its concepts have been introduced in an order that is best for human understanding, using a mixture of formal and informal methods that reinforce each other.” [emphasis added] Code falls out of a process that is both textual and programmatic. Natural language and programming languages are combined as part of a flowing discursive process.

Dialogic programming in essence is the practice of specifying programs to an LLM in exacting technical detail, taking its result and tweaking, customizing and extending it, or further prompting it conversationally to refine its output, or vice versa. We indeed combine formal and informal methods, much like with literate programming.

Who Is Dialogic Programming For?

Whether you are a seasoned developer looking to find a place for AI in your workflows, a newcomer seeking to enter the field for the first time and attracted to the lower barrier of entry LLMs afford, or an industry decision-maker wondering how LLMs will evolve the software business and impact teams, dialogic programming is for you.

Seasoned developers can discover ways to outsource repetitive and redundant work to the LLM, to make more space for high value architectural efforts.

Newcomers can find a lowered barrier to entry and learn to embrace the educational value of LLMs as coding teachers and assistants.

Decision makers can find new ways to integrate their teams around LLMs, and figure out exactly where LLMs belong in the development process and in their business.

Prompt Engineering is Just Dialogic Programming

Prompt engineering is often spoken of as a distinct thing from programming, and in some sense it is. But in a software development context is just a style of literate programming expressed over an LLM-enriched environment.

In a software engineering context, a prompt is just a literate program. We need to stop thinking of prompts as conceptually separated from a program. They might be distinguishable by narrow technical criteria, but for practical purposes old fashioned computer programs and LLM prompts are the same. If we define a program as “a way to get a computer to do something”, they are both ways of getting computers to do something. AI prompts are just a cloudier, more fluidic, and open-ended superset of the more targeted, precise subset of all expressible programs as ways-of-getting-computers-to-do-something.

Seeing the unity of program and prompt is the first major conceptual leap we must make as dialogic programmers. Prompts are just programs. Prompt engineering is just (literate) software engineering.

The job of the programmer has never been to just write programs, but to think programs into being. Writing the programs, as it turns out, is optional. The muscle memory of syntax memorization was never the most important part. Think about it via analogy. Some musicians, such as Mozart famously, compose sheet music by writing down music in symbolic notation. Mozart had to hear the music in his head and transcribe it to a symbolic medium, because he couldn’t have a whole symphony wait around on him all day while he composed the music. Other musicians just hear the music in their head and start playing instruments or coordinating with their bandmates or producers, or do whatever it is musicians do while making music. The point is, composing sheet music is optional for the process of creating music.

Programming, I have come to find, is similar. Writing code is just one way, the most direct way, to express programmatic thoughts. Just like a composer creates the music in their head, and either writes down the notation on a sheet to execute later when they have an instrument in their hands, or leave it up to instrumentalists to read and play, the music is still created somehow. Dialogic programmers, in my view, are a lot like symphony conductors. They aren’t necessarily writing the music (although they can), and they aren’t even playing the instruments (that’s the LLM). But they are high level orchestrators, setting the pattern, tone, mood, and general flow of development at a high level and drawing it all together as a thematic unity. Meanwhile the lower-level LLM layer is doing a lot of the fieldwork actually “playing the instruments” out on the benches.

Anticipating Some Criticisms of Dialogic Programming

Some criticisms of leveraging LLMs in development are dispelled by the defense of a conscious, self-directed dialogic approach.

- By relying on LLMs, developers cheapen their understanding of the problems and wind up worse off because of it.

This claim is nominally true for those who aren’t being deliberate in their use of the AI tools. The whole literate part of the deal figures in here prominently. Dialogic programmers on the other hand are constantly conversing with well-trained and informed LLMs and reading what they output. They learn constantly. It’s critical for a dialogic programmer to never just copy and paste what an LLM produces, but to carefully vet and work over its outputs.

- Dialogic Programming will reduce code standards.

On the contrary. Every bit of conversationally produced code is discussed and carefully considered. Moreover the conversational history is deeply self-documenting in a way that Knuth always advocated for. Dialogic programmers are not lazy or cutting corners. They are actually giving more thought to the code they write and request. Dialogic programmers still take ownership and final say over any code they push, and should be expected to be prepared to speak to it.

- LLMs can produce untrustworthy outputs

So what? So can people. LLMs are just another tool to the dialogic programmer. They are not handing everything over to a language model. They are experts at understanding the intricacies of the technology and what they are and aren’t good at. Where the LLM fails, they take over. It’s key that they look at everything an LLM says with a critical eye. A dialogic programmer is simply all about giving themselves the richest development environment conceivable. They have not stopped being programmers in the traditional sense.

- Coders should spend more time coding, less time writing

Hopefully I have already addressed the irrelevancy of this concern. Communicating to an LLM in natural language is now just as productive an act as writing code. The criticisms of Knuth’s literate programming, namely that it’s less productive for a work environment and more suited to an academic one, no longer hold.

- Dialogic programming will lead to a lot of mindless copy and pasting

Only those who are misusing or abusing the technique will uncritically copy and paste LLM outputs. The whole process of dialogic programming is extremely active and engaged. Both user and LLM contribute equally to the final product, with the user retaining the overall decision making capacity. Like any technique, you can use dialogic programming to greater or lesser effect depending on your skill level. Copy and pasting LLM output and passing it off as your own work is a bastardization of the approach.

- I’m a programmer and hate writing. So does that mean I have to be left out?

While it’s true good writing skills will disproportionately benefit dialogic programmers, one needn’t be Shakespeare to get the most out of it. You actually won’t even have to write as clearly as one should expect when communicating to another person, since a decent LLM can brute force its way through inelegant prose easily. One of the awesome benefits of its flexibility is that the proportion to prose versus code in each prompt can be left to the discretion of the developer. A good LLM is equally capable of understanding both. It’s a valid strategy to compose prompts that are verbally detailed prose essays or mostly code with some annotation and guidelines sprinkled here and there. Experiment and find out what works best for you!

- I’m a good writer but don’t know much about software. Am I left out?

It’s true that in dialogic programming software knowledge is still the engine that drives the whole process just as much as in traditional programming. Dialogic programming may, in some respects, be less painful and frustrating as traditional “bare” programming workflows, but knowledge of code is equally as important. A good student will discover how leverage LLMs excellent teaching abilities to learn about code on the fly. Dialogic programming is ideal for lifelong learners.

The Future is Now

As one who has embraced dialogic programming wholeheartedly I can attest to the merits of this approach. I’ve always felt I was a better thinker and writer than a coder. I’m a good coder, mind you, but I’m better at thinking generally and have a particular knack for English prose. It’s made me a better thinker and coder, and perhaps even a better writer. Dialogic programming enables me to combine, sharpen and hone all three skills to maximum effect. In terms of raw productivity the gains are unmatched.

I’m almost 100% certain that what I have thus described is where the industry is headed. My terminology or exact way of formulating things may not be what gets adopted, but having seen the potential of this approach the I have seen the light.

This article only scratches the surface of what dialogic programming has to offer. More detailed practical case studies, or more targeted pitches for seasoned developers, newcomers or decision makers could be put forward. For now I just want to put dialogic programming on the radar and advocate for its existence as a conscious way of getting things done.

We have entered a period of great change in how people relate to computers, and therefore, to how we get computers to do things, that is, to program. I see LLMs leading to a total deconstruction and reconstruction of how programming is accomplished. And I do believe it will enable all kinds of novel possibilities and opportunities. We’re only getting started.