What do AWS, Stripe, and Google Analytics have in common? Terrible dashboards.

I do not like dashboards. You can argue that some dashboards are good - at least in terms of how well they follow “dashboard design best practices”. Unfortunately, even well-designed dashboards have a productivity ceiling. Once upon a time, COBOL promised us a world where we could solve anything with code (I’m not actually sure that’s what was promised, I wasn’t alive then). I think now it’s time to start delivering on that promise.

If you watched my talk at CodeBEAM America, you might recognize the title of this post. I wanted to take some time to expand a bit on my thoughts beyond just the soundbite from the talk.

Why do we have dashboards anyway?

I will admit that my historical knowledge here is limited. I started using computers when everything had a point-and-click GUI. I was only introduced to the terminal when I taught myself how to program. I fondly remember Googling “bash script matrix animation windows” so I could pretend I was doing cool things in front of my friends. I can hypothesize that in an effort to spread the gospel of personal computing, companies like Microsoft and Apple started to build more accessible interfaces for the laymen. I can sympathize, but I believe this work robbed us of computing in it’s purest form. Worse, I would argue that the GUI today acts as an unhelpful distraction on the road to LLM-based productivity.

I will also admit that my knowledge of what the “internet” looked like before web browsers, GUIs, etc. is also very limited. But, I can still hypothesize that as computers became ubiquitous in business, ambitious business folks wanted to digitize their poster boards and slide projections. Imagine if the charts we present in meetings could appear with realtime information on a website! Software-as-a-service companies took this a step further - what if we could use the web not just to share information but to also take actions.

The modern dashboard acts as a means to obtain information and perform actions which impact the world. Every modern company depends on dashboards, no matter how rudimentary - in some form or another! But, the dashboard was built for you; the dashboard was not built for an LLM.

Fish out of water

Just as soon as GPT3.5 was released in OpenAI’s API, people were demonstrating how you could use it for browsing the web or driving interfaces on the computer. I think these use cases are cool. I am also pragmatic enough to recognize that these are a natural step in the progression of LLM applications. However, I believe the world would be a better place if we stopped trying to use LLMs to browse the web (in the way that you or I do!) or use the computer. An LLM trying to use a traditional GUI-based application is genuinely like a fish out of water. It doesn’t make sense!

I think the most correct way folks interact with browsers and desktop interfaces with LLMs today likely involves prompting the LLM to write some Playwright or Macro to express the actions it wants to take. This makes sense! LLMs are great at writing code, there’s probably plenty of examples that are in-distribution, and so the end results are likely fine! The problem is that you are unnecessarily putting extra steps between the LLM and what you are trying to accomplish. Why do you want an LLM to use a web browser? Why do you want an LLM to use your computer?

There are, of course, legitimate reasons we need to use LLMs in these ways right now, but I believe they will disappear as time goes on. As ops-focused companies realize that they can deliver more value to their customers building for LLMs rather than building for humans, the need for LLMs to be able to use a computer or browse the web will likely disappear.

Just write code

LLMs are great at writing code. Code is just a set of instructions that can be executed to produce an outcome. If you can model your desired outcomes as code, you can use an LLM to do anything you want. Imagine any scenario where you might want to use an LLM to interact with a GUI, and now think about if you can model that interaction as code. I think in most cases, the answer is yes!

I believe strongly that companies should invest their time in modeling all (or as much) of their processes as code. There are several benefits to this:

1. LLMs are currently undefeated. Let’s assume the trend continues. Even if the pace of progress slows down you can assume that LLMs will get smarter, LLMs will have larger context windows, LLMs will be cheaper to use, and LLMs will get faster to use. The more processes you have which are readily automated or performed by an LLM, the better.

2. I am a programmer first and will admit I have a strong bias for reading code over basically anything else. With that said, I think that a process represented as code is easier to understand and review than a process represented as insert document in knowledge management platform here.

3. I think version control and project management for software is great. I think git and GitHub are the greatest productivity tools in the world. I would have planned my wedding on GitHub if I could have convinced my wife to create an account. If you can express your processes as code, you unlock access to these ecosystems.

The problem we have now is that most companies build their products for human interaction. This is why they build dashboards. But, what if we all just stopped? What if we focused instead on building CLIs, DSLs, and APIs that made it easy for LLMs to interact with our products? What does this look like?

• Pricing experiments or new products should just be configuration changes in the codebase
• Email/SMS marketing flows are just state machines, and can easily be represented as code
• Isn’t accounting just SQL? (Lol)

Unfortunately I’m not creative enough to think of every single use case and what it would look like represented as code. But, I believe many people are and will start to favor CLIs and APIs over GUIs in the next few years.

Just write code!