Big Problems With Little AI

You don’t need big AI, you need little commands.

And you will not need to learn programming the old way, but you do need to learn how to talk to the AI.

I suspect the single greatest breakthrough in today’s AI, reducing large code bases to little commands.

Reducing a large surface such as a powerful video editor application code-base, to commands that AI expects, that makes sense to a thing that can reason.

Think about how complex user interfaces in complex application are, people discover new stuff in programs they have been using for years.

Programming such a complex thing so that it all works together, seems completely out of the reach of little AI.

And if you use big AI, you will need a lot more than the $100/mo plan, it is that much work to keep it in the AI brain to let it fix stuff…

Unless, you spit the big User Interface, into little commands, more specifically complex components that take care of their own business.

You don’t need a big AI to create a single component, it is not that big of a program.

And you don’t need a big AI, to take 100 such components, and wire it all together, it is just a 100 things, that already make sense to AI.

What you don't want to do, you shouldn't do, is have another AI look at the result and make large changes.

After the assembly it all becomes a massive amount of unique code, you can make that manageable with XML but it is not good to edit the whole.

You can edit any of the components one at a time, or re-generate them one by one with new architectural principles.

You can stich them together with those 100 words, top down, but AI will struggle if you try to edit things bottom up, code base up.

You have the same problem when making coffee in the morning, you can perfectly adjust the amount of sugar, and the kind of coffee.

But you mix, and stir it, you will need a laboratory, to un-mix the sugar from coffee, and neither will taste the same ever again.

This is not how people end to understand using commands or toolcalls with AI, and without that caution they may be forced to ask their AI to unmix their soup.

They don’t understand they have to keep things clean, separated, and hope to re-generate rather than edit what was ready generated.

Meaning, start a new cup with the right amount of sugar. and the correct blend, rather than unpick the damn thing.

What these little components or commands, or well placed toolcalls call for is described with a singe word: Architecture.

In my morning experiment, I told AI to create components, with a note on how they are to be used, and a small demo.

So I stitched my components in their very documentation, I( will be making multiple passes to strengthen that, via Dos and DON’Ts even.

But you may wish to experiment with something richer bit more lightweight, a text based adventure game, comprised of primitives like surface, container, thing.

Where you ask a small AI to create a virtual Video Editor for example, and then you ask your AI to describe the resulting hierarchy of components.

And armed with that description, translate it into a user interface hierarchy, where the virtual components are replaced by real code.

This can be done with XML you don’t’ need a virtual world, but inside a virtual world small AI has context, simple tools, and even bots.

If you just tell it to make an XML, it hast to look a the whole thing at once, not one room at a time.

Experimental to say the least, but you need this open space that little commands create.

Because, your user interface components, must also abstract away complexity, because you also want small but capable AI in the finished application.

You don’t just want to throw a powerful user interface at the user, that time is over, AI must be part of the finished product as well.

In a clear to reason about virtual world that represents a virtual program, where buttons describe in text what has happened in the applicaion.

You can create procedures that translate well enough to the real applications, procedures that capture what commands to use to accomplish something.

This is very valuable for small AI that won’t be able to reason this way, in a real application because all the buttons and knobs will be too much.

And component documentation, as I am experimenting with, is unlikely to be the correct place for application procedures that AI can follow on user request.

You need the components in an assembled form, to talk about who to use the resulting application.

All three are good starting points for making big things tiny for little AI, but an intermediate representation of the application may just be the key.

Documentation, procedure first application assembly, virtual application, headless application, macros based on action libraries.

Good old fashioned AI with goal oriented problem solvers, that stich modules out of provides and requires properties.

You won’t know, until you find the one that works for you.

But I think it is safe to assume that little commands of components, that abstract large complexity away, is a sold step forward.