A quick observation.
Quality software solutions based on LLMs are much harder to build than any other type of software solution.
Why? AGI is like a human; unpredictable.
A recent discussion on one of the developer forums I frequent inspired me to reflect more deeply on the challenges of building quality AI solutions. This comment stood out. It was a trigger that washed over my sensibilities with deference.
Developing [truthful] AI solutions is the last thing I would label a “party”. Could it be fun? Sure. Most development challenges involving the unknown provide me and people like you with endless joy.
I have several ongoing AI projects that I would call “experimental”. All of them have hit walls. Some might be useful, but I see many more walls ahead that need to be scaled.
Solve for (X) is one of my favorites. It builds chained AGI processes that achieve goals. The goal is stated and embellished with guideposts that serve to establish the compass heading for the AI. It sets off on a journey to produce a document based on minimal information. It’s intended to be somewhat unbounded, to be creative. The unpredictable nature of AGI is its biggest asset.
I’m building it in Coda for two reasons - I’m lazy, I want to spend the least amount of time on UI/UX while learning more about AI automation and proving this approach is viable. Secondly, I believe that solutions like this deserve a user experience that compliments the nature of the inputs and equally embraces the outputs. Coda is really a wonderful user-facing platform for just about anything content and small-data-related. Still, this will require a lot of R&D to overcome the challenges of building something valuable and reliable. I’m under no illusion - this is not easy.
The forum conversation that triggered this observation led me to explore why AI projects can be so difficult. Long after I started shaping this post, this article made a startling and timely appearance.
All the Hard Stuff Nobody Talks About when Building Products with LLMs
There’s a lot of hype around AI, and in particular, Large Language Models (LLMs). To be blunt, a lot of that hype is just some demo bullshit that would fall over the instant anyone tried to use it for a real task that their job depends on. The reality is far less glamorous: it’s hard to build a real product backed by an LLM.
A key point in this article by Phillip Carter, is prompt injection risks.
If you’re unfamiliar with prompt injection, read this incredible (and horrifying?) blog post that explains it. It’s kinda like SQL injection, except worse and with no solution today.
There are some mitigating approaches, but he’s right - no known remedy exists that makes anything you build impervious to attack. This article will make CSOs bristle.
Where AGI applications may become dangerous is when we hand them tools. Everyone is building these now because we all want them. As evidenced by Google’s Duet integration with Gmail, we most certainly want an assistant that we can depend on to read our email, draft a reply and send it under some circumstances. Be careful what you wish for because someone might quietly send your AI a command.
I anxiously await the impact of AGI on errors and omissions insurance.
Whispering Truth to AGI
I don’t like to complain without offering remedies. Here are my best suggestions.
Keep reading with a 7-day free trial
Subscribe to Impertinent to keep reading this post and get 7 days of free access to the full post archives.