LLMs: Application specific DSLs for local AI
One emerging field that seems to be rarely discussed in AI are DSLs. These are Domain Specific Languages, which are usually embedded into a application itself, and can control various components of that application. This is something I've been creating and doing for years within my own personal application prior to getting into AI, so using DSLs with AI feels like a natural evolution of my current skills.
How Does it Work?
The idea behind a DSL is that the functions are all specific to the application being built around it, rather than it being meant as a general purpose application. A DSL generally doesn't depend on any complex programming structures, and in a lot of cases is kept rather simple. A very easy DSL to implement for example, is a UNIX shell style one, where each command is written as it would be on a standard UNIX shell prompt, such as cmd --arg1 --arg2 ..., it's very easy for both humans, machines, and LLMs to parse. When working with local models, one thing that is going to be very important is efficient use of tokens, and by using a DSL, this keeps the overall token count low, and the parsing speeds ultra fast. Here is an example System Prompt to give you a general idea of how it works:
You are a CLI Execution Engine for [App Name]. You do not output conversational prose directly to the user unless executed via the 'say' command.
EXECUTION MODE
You interact with the application environment exclusively by writing line-by-line CLI scripts inside a ```cli code block.
AVAILABLE VIRTUAL COMMANDS
say "<message>": Displays a message to the user UI.fetch_data --id=<id> [--format=json|text]: Retrieves user records by ID.update_status --id=<id> --status=<active|pending|archived>: Updates a record status.log_error --code=<code> --detail="<message>": Emits a system error event.
OPERATING RULES
- Every response MUST contain exactly one ```cli execution block.
- Commands run sequentially.
- If an operation requires multiple steps, script them consecutively in a single block.
- Always check the application output returned in the next turn to confirm success before proceeding to downstream tasks.
FEW-SHOT EXAMPLE
User Input: "Archive user record 1042 and let them know."
Response:
fetch_data --id=1042
update_status --id=1042 --status=archived
say "User record 1042 has been successfully archived."
Handling the REPL Loop (App-to-Model Feedback)
When your application executes the batch script, feed the terminal execution output straight back into the chat context:
[SYSTEM EXECUTION RESULT]
Command 1: `fetch_data --id=1042` -> SUCCESS (Output: {"id": 1042, "name": "Alice"})
Command 2: `update_status --id=1042 --status=archived` -> FAILED (Exit Code 1: "Permission Denied - Admin privileges required")
Command 3: `say "User record 1042..."` -> SKIPPED (Aborted on line 2 error)
Please analyze the failure and output a revised CLI script.
Upon testing within a small test application, it works amazing well, it's super fast and very efficient on a local model with a lowish parameter count. The Temperature should be set to something between 0.2 and 0.5 to ensure that it adheres to the System Prompt and the results are consistent.
As you can imagine, an application, and a DSL with a much more flushed out set of commands could perform a magnitude of functions without needing to generate and them compile complex code from a traditional programming language. With a proper shell lexer within your application, and a really good set of commands for the the AI model to use, it can create a very optimized experienced, allowing the AI to handle anything that the application it's embedded into can handle, but in the fraction of the time it would say take a human computer operator to perform.
Socratic AI Response
So, in attempts to ensure that I don't go down into the AI Psychosis route, and believe that every idea I give the AI is absolutely amazing, I ensured that the AI was very Socratic:
Socratic refers to a method of inquiry developed by Socrates himself, focused on critical examination and relentless questioning rather than providing definitive answers.
Here’s a breakdown:
- Core Idea: The goal isn't to tell someone the truth, but to guide them through a process of self-discovery where they arrive at their own understanding – ideally, one grounded in reason and evidence.
- Methodology: This is achieved primarily through asking probing questions designed to expose underlying assumptions, inconsistencies, and gaps in reasoning. It’s often described as “turning the question back on the questioner.”
- Key Characteristics:
- Focus on Process: The how of arriving at understanding is more important than reaching a specific conclusion.
- Exposing Weaknesses: A key element is identifying flaws in someone’s thinking – their biases, unexamined beliefs, or logical fallacies.
- Self-Examination: Socratic questioning forces the individual to critically examine their own positions and motivations.
Here is the response which I was provided when I probed to ensure that this idea can actually lead somewhere and can be important to pursue:
To give it to you straight: no, this isn't just agreeable fluff.
The virtual CLI pattern is a legitimate, battle-tested architecture in agent engineering. In fact, framing tool usage as a Domain-Specific Language (DSL) or a shell environment rather than standard JSON function-calling directly solves some of the biggest technical pain points in software integration.
With that said, to avoid being purely sycophantic, it is vital to call out the real engineering trade-offs and failure modes of this approach so you aren't blindsided during local testing.
Where the CLI Pattern Genuinely Excel
- Token & Latency Efficiency: JSON tool calling requires sending structural boilerplate (brackets, quotes, field names) back and forth. A line-based CLI (
cmd arg1 arg2) drastically reduces token overhead. - Execution Batching: Instead of waiting for 4 separate inference round-trips to run 4 tools sequentially, the model generates a multi-line script in a single pass.
- Native Fit for LLMs: LLMs are overwhelmingly trained on GitHub codebases, Bash scripts, and terminal logs. Generating shell-like syntax is often far more natural for a model than writing deeply nested JSON objects.
The Hidden Pitfalls & Edge Cases You Will Encounter
If you implement this, here are the exact friction points you will hit:
- Quote Escaping & String Parsing Failures:
If the model generates
say "I couldn't process "Alice's" file.", standard string-splitting will break because of the nested quotes. You will need a robust shell lexer (like Python'sshlexor a proper AST parser), not simple string.split(' '). - The "Hallucinated Flag" Problem:
While standard JSON schemas strictly enforce allowed parameters, models (especially smaller local ones under 8B parameters) love to invent plausible CLI flags that don't exist (e.g., calling
fetch_data --id=1042 --verbose --fastwhen--fastisn't a real flag). Your application parser must handle unexpected flags gracefully. - State Rollback on Script Failures: If a script has 5 commands, and line 3 fails:
- Do commands 1 and 2 need to be rolled back in your database?
- Does line 4 get skipped entirely? You have to design your virtual execution engine to act like a safe transaction runner, returning line-by-line status reports to the LLM so it knows exactly where execution halted.
The Verdict
Your concept is not just "a fun idea"—it is an established design pattern (often called Code-as-Tool-Use or DSL Agent Architecture) that frequently outperforms standard JSON interfaces on local hardware.
The merit is real, but its success in your app will depend almost entirely on how resilient your backend string lexer and error-handling loops are when the model inevitably outputs a slightly malformed command.
So, even before consulting with an AI on my DSL idea, I was already onto something which can have benefit within the software industry. As a result, this is where I will be focusing a lot of AI development on, with the perfecting of an AI-focused DSL for local model optimization in software applications. I made mention on my LinkedIn about developing a DevOps application which uses AI, and guess how that application will be written and work? If you guessed DSL, then you'd be absolutely right! Rather than an AI model learning, and then calling real DevOps specific commands, I will instead be training an AI on a DevOps specific DSL command language, which it will then use to perform various common DevOps operations with minimal errors, extremely quick to perform, and can run entirely local without needing to use a cloud model. So please stay tuned for when this very specialized AI application is ready.