Scaffolded LLMs as natural language computers

I remember reading this book a long time ago and thought it had some pretty interesting concepts around agents:

https://aima.cs.berkeley.edu/

this was another one:

https://www.amazon.com/Artificial-Intelligence-3rd-Winston/d...

I agree that there are still differences between humans and AI, and vision is one of them. Humans also remember across conversations, ChatGPT doesn't. We have longer context windows. We think in our downtime, unprompted. We take input from 5 senses, today's chatGPT only takes input from text.

But--and this is a big but--the set of things that people can do better than computers has shrunk significantly over the past five months. Today, thanks to GPT4, AI can get a B in a Quantum Computing class, generate engaging stories, know that the color yellow is closer to orange than blue (despite never having seen color!), answer emotionally laden questions with the sort of facility that IMO is better than most humans, write code, rhyme, and much more. All of this stuff was unthinkable before. I personally thought it would be centuries until this stuff was possible. I was very wrong.

Several developments in Deep Learning, like the Transformers paper (https://arxiv.org/abs/1706.03762), set off this growth, as did big data and increased computing power. The insight of particular humans, like Ilya Sutskever, played a role as well. But taken together, I actually don't understand how one can argue that we aren't at the beginning of a massive exponential.

Of course there are things humans can still do better than AI, but the number of things is shrinking rapidly, while the number of things computers can do better than humans is growing rapidly.

I argue that we are indeed at the beginning of an exponential, and we'll see both new classes of products and faster development time.

After a few times, you could ask it to reduce its purpose to a couple of lines of code. Test the code, verify it. Maybe even deploy it.

That’s more expensive than writing a couple of lines of code, more than deploying it,

Sufficiently standardized, it will be significantly less expensive than paying someone to write a couple of lines of code, test it, deploy it, etc.

Is this better than just writing a couple of lines of code? That’s a different question. At scale, this can absolutely be cheaper. Eventually.

I think developing often used functions as plugins/task primitives as native code (i.e. tools that the LLM can use) would be a logical next step - as you expressed, I think.

> It seems like if you want to do this more than a few times, it's better to write a couple lines of code to do it much more cheaply

I think the problem is that natively written code will always suck at the planning part. An LLM can use the tools available to it (eg a web browser or Wolfram) in infinite ways, and hopefully in a way that will advance the task at hand. Maybe the natively written task primitives can become really big (eg a fully automatic web scraper) - great, now the LLM can gather info for its plans even faster.

The big value is certainly in the less constrained stuff. Today I wanted to experiment with a hobby project, so I wrote a page of what I want to achieve. I then presented it to GPT4 as a "spec" and told it to act as a software architect and give me suggestions and ask for clarification. It gave me mostly good suggestions, asked a few good questions, and gave some feedback I disagreed with. I updated the spec to incorporate the good bits, clarified and firmed up the wording around the choices where it had made suggestions I disagreed with, and asked it to give another round of feedback. I turned around the draft 3 times, and it added value every time.

I could have done that with a person, but then I'd need someone who was available then and there that I wasn't taking away from other stuff.

To tie that to your points: This process was exactly an exercise in nailing down details that were missing because the short prose version was leaving huge gaps.

I intend to need a back and forth of filling in detail each step toward an implementation for that reason.

And I think this kind of tooling need to be built with that in mind: Write roughly what you need unless you already know how you want to express it in code. Ask for clarifications or a proposed plan. Iterate. Maybe with tooling giving examples of where it would head if prompted to fill in more detail.

I sure as hell won't trust it to just blindly do a task for me from a brief problem statement at this point.

Just as I wouldn't for most non-trivial tasks with most humans...