Declarative Programming With AI/LLMs

 

What Is Declarative Programming

Broadly speaking, there are two ways to program/instruct a computer to perform a task, they are imperative vs declarative programming.

Imperative programming is what we do the most, we write all the code necessary for the computer to perform a task such that the only thing left for the computer to do is fetch and execute CPU instructions. If you are using Java,C#, Javascript...etc you are doing imperative programming.

Declarative programming is a higher-order form of programming, we instruct the computer to perform a task but otherwise let it "figure out" how to do it. Declarative programming requires some sort of software based execution engine. Whereas with imperative programming our code gets compiled into some machine/byte code and then run by the CPU, declarative programming requires
a layer of software that does the "magic" that allows you to use it without having to write the precise logic for completing tasks. 

I would guess Structured Query Language (SQL) and the associated Relational Database Management Systems (RDBMS) that process it represent the most prominent example of the declarative programming paradigm.

These two programming approaches represent a dichotomy that can be summarized as instructions vs directions. With declarative programming you give instructions and let the system handle the rest, with imperative programming you provide detailed directions for how the task should be performed.

In order for declarative systems to be useful, they must provide a sufficiently expressive instruction language/format (ie a domain specific language (DSL)) and provide a comprehensive set of tools to apply given instructions to. This also means that it is difficult to get declarative systems off the ground as it requires a long process of exploration and experimentation to build up the necessary tool set and DSL expressiveness to make them shine. One could liken declarative systems to whiskey, they tend to get better with age...ie if they survive long enough.

AI As Human-To-Computer Language Translator

AI/LLMs "could" solve both the instruction language/format and the tool set problem faced by declarative systems.

Not only does AI eliminate the need for developing a custom DSL, as your DSL now is just plain language, it also allows you to leverage the AI's "intelligence" to fill in the gap for tooling, ie AI CodeGen. 

There are many declarative systems out there, most are at best half-baked attempts as they tend to be fairly limited both in expressiveness and in tool set. Many large CRM/ERP/BPM platforms have some degree of declarative capabilities built into them, often referred to as rules engines.

The way you make declarative solutions useful is via tooling, however often the tool set of existing declarative systems tend to be simply exposing imperative capabilities to the declarative layer. For instance a tool might be called "list-interator" in a declarative system, wherein you pass a list and it iterates over it, this is simply a backwards way of doing imperative programming and this type of "tool" often constitutes a large part of the tool set exposed by existing declarative systems.

With AI, your tool set no longer needs to include such superfluous declarative constructs, instead they'll be actual tools that perform various tasks; even more, many of those tools can be built as simple feedback into the AI, ie AI output being used to generate more AI output.

The aim of allowing users to instruct computers vs direct them has been a pursuit that started almost as soon as computers became business tools. The syntax of venerable business application languages such as COBOL and Visual Basic lays this bare.

Consider below an example of instructions (prompt) to build an app via the Solvent-Botworx platform. This is plain language that requires no rigid syntax. *This prompt is the user's instruction, the actual prompt sent to the AI includes a more expansive preamble that instructs it on how to process this request.

Here's the same prompt converted to COBOL, courtesy of AI CodeGen

The syntactic similarities between these instruction forms are obvious. In our case we tell the AI to convert the prompt to a JSON object structure that is then further processed via custom tooling as part of a declarative execution engine. 

The AI approach means declarative systems can be built in a way that decouples them from being limited to a particular platform. Furthermore, building declarative systems in the future will be mainly about designing ways to incorporate tooling that acts on AI generated configurations that then further leads to the generation of imperative logic/functionality that can be audited,tested,reviewed before deployment.

Reliability And Consistency

A lot has been made of AI's limitation especially when it comes to accuracy, these are valid critics but are likely mainly a reflection of the initial AI gold rush. Until so-called AGI happens, if ever, ie an AI that is as capable and "sane"(ie grounded) as an intelligent and highly educated human that can simply be told what needs to be done and it will go ahead and figure out how to do it, the most reliable AI solutions are going to be those that rely less on raw AI generated output based strictly on the AI's "knowledge" but rather make use of comprehensive tooling to drive automation. 

Such solutions will rely primarily on the AI's abstract intelligence, ie the AI's ability to take instructions (including data) and generate structured output that can then be processed via tooling. It means AI as part of a declarative execution engine.

In fact it is likely we are going to end up with AI winners including some unexpected companies. Sure, I expect the likes of OpenAI, Anthropic, Google and other infrastructure service providers to profit but it is also possible some "old-school" software companies are in pole position to benefit immensely from the declarative execution capabilities of AI. 

Consider a company such as SAP, they are known for the complexity of their systems and the need to hire expensive consultants to do implementations. One could imagine SAP eventually implementing AI capabilities that exposes their complex systems in a piece-meal manner as tools that can then be glued together via declarative instruction processing, you'll probably still need those expensive consultants but likely not as many of them as you otherwise would. This would mean lower cost for SAP customers and consequently higher adoption of such a platform.


Declarative processing of configurations generated via AI is a way to ground the AI, this requires a lot of work since you don't just offload requests to an AI but rather your processing logic serves as a guardrail to ensure what's being done makes sense. In order for AI to be used in applications that require reliability, this work will need to be done. 

This will be true for agentic applications as well, the most useful ones are going to be ones that act on configurations with a definite logic that can determine if what's being proposed by a configuration step actually makes sense. What all this boils down to is, instead of simply saying AI go do X & Y, you instead say here's my instruction along with necessary data, generate a configuration that matches this configuration structure (or schema), then have you declarative processing implementation act on that configuration with all necessarily sanity and safety checks applied.

When it comes to advancing AI capabilities the momentum is towards more model training, that is certainly a prerequisite but it is likely that a declarative processing approach will for the foreseeable future be needed for use cases where reliability and consistency is a requirement. At the moment the leading models are indeed very smart, they are however still "unhinged", grounding them is a requirement for consistency and reliability.

Below is a session showing AI enabled declarative processing on the Solvent-Botworx platform: