search

peibolsang / octotype

My blogging platform
0 stars 0 forks source link

Conversational Programming #3

Open peibolsang opened 1 year ago

peibolsang commented 1 year ago

I heard multiple times Simon Wardley talking about Conversational Programming as far back as 2019, but I think it didn't strike me until I put my hands on it. Yes, as I have shared in this post, I used ChatGPT to generate about 30%-40% of the code I wrote for octotype, and I am still in awe.

Something I noticed is that the model behind ChatGPT is good enough to interpret semi-ambiguous requirements but still needs a considerable deal of detailed input that expresses my intent. The same happened when I re-trained a Stable Diffusion model with selfies to generate cyberpunk-like portraits of myself. That type of thought process to express intent and reduce uncertainty in the input is what many people call Prompt Engineering. However, I think this is precisely what Simon Wardley calls Conversational Programming.

In other words, Prompt Engineering looks a lot like Programming. When you are programming, there is a process to remove ambiguity and uncertainty, so your intent is understood by the machine, and you express that intent in a language that the machine understands, such as Javascript. Well, that's precisely what we are doing with these AI models, but instead of using a 4GL programming language, we are using our Natural Language.

I said it multiple times, but when you automate something (with AI or otherwise), you are actually constraining that something with automation, and you can only constrain something with very low levels of uncertainty. Unfortunately, high-level business requirements to create software are not something that you can automate in full. You still need a process to remove ambiguity and express your intent, and you need to do it iteratively. You still need to divide and break down your big uncertain problem into smaller, more certain chunks expressed in natural language. Basically, you are programming conversationally.

Maybe, in time, these models get more intelligent so that they offer higher-level abstractions for us to ease the process of removing ambiguity and expressing intent. That is precisely what happened when we moved from assembly to Java! In other words, we may be at the doorstep of a new generation (5GL) of programming languages based on problem-solving using constraints given to the machines rather than commands.

peibolsang commented 1 year ago

Some additional thoughts!

This is like going from Digital Transformation imperatives to Cognitive Transformation?

Also, once you know your model's output is 100% accurate (or good enough for you), you no longer spend time designing prompts and iterating programming conversationally. No. If the outcome is incorrect, re-train your model or create a new one!. It means that, in the future, we won't build apps. We will build models that generate as many apps as we want. If the outcome is wrong, we’ll retrain and redeploy the model. We need true MLOps and tools like Gradio and Hugging Face Spaces to automate how we build, test, and deploy ML models.

Programming will be training.

peibolsang commented 1 year ago

Another thought based on Karpathy's Software 2.0 article:

I disagree that Software 3.0 is about prompt engineering. Because the act of continuously iterating on a prompt to have a model provide an objectively desired response implicitly acknowledges the model is failing. Instead, as I said, we need to retrain the model.

Prompts have to be explicit, we can't rely on something magical where the user throws spells with the hope that it can get the model to do what they want. That's not what we want. As I said in the original post, we want conversational programming, where the input is goal-based rather than a chain of disconnected, hacking, magical spells.