Why Prompts Should Be Treated as Code: Engineering the Future of AI Agents

Why Prompts Should Be Treated as Programs

Prompts have evolved from static text to executable agents, requiring software‑engineering management such as separation, versioning, modular design, testing, and organized project structures.

Prompt code separation – isolate prompt logic from business code using variables and templates.

Prompt versioning – track changes as LLMs evolve, enabling rollback and inspection.

Modular prompt design – compose prompts from reusable modules, registries, or dependency‑injection patterns.

Prompt unit testing – verify output format, required fields, and tool/function calls, especially for agent scenarios.

Prompt integration testing – test end‑to‑end execution flows, including IDE interactions and model calls.

Prompt organization – structure large projects with clear directory and file hierarchies.

Example of a Decoupled Code‑Completion Prompt

补全代码。
-相关上下文：${selection.ast}
-光标前代码：${selection.before}
-光标后代码：${selection.after}

The variables allow the same prompt to be reused across different editing contexts; model‑specific tuning and post‑processing are still required.

Prompt as Executable Code

When prompts are run directly inside applications, they generate data, language, or code that is compiled or interpreted on the fly. This enables low‑code platforms, AI IDEs, and built‑in code interpreters to treat prompts as real programs.

AI platform code interpreters can generate tables, charts, and other artifacts directly.

IDE plugins can auto‑generate tests, run them, and produce fixing code when failures occur.

Low‑code platforms can execute prompt‑generated code to build full applications.

Treating a prompt as a program means it can be templated, modularized, version‑controlled, unit‑tested, and integration‑tested—just like traditional software.

The model can be expressed as DSL (Domain‑Specific Language) + Runtime . Because current LLMs cannot reliably generate complex programs on their own, the DSL must provide atomic operations (e.g., IDE interaction, model calls, file manipulation) and encapsulate complex workflows into reusable functions.

Provide atomic capabilities such as interacting with an IDE, invoking a model, or manipulating files.

Encapsulate complex logic—code generation, retrieval, analysis—into dedicated functions.

The runtime varies by environment: an AI IDE uses the IDE as its runtime, a mobile app uses the app itself, etc. For example, the /refactor command in AutoDev demonstrates a runtime‑provided operation for code refactoring.

Shire Run: A Lightweight Sharing Platform

Shire Run is a prototype platform that lets developers download, share, and browse AI agents (called “smart agents”) built with the Shire language.

One‑click download of agents for import into an IDE.

Public sharing of agents for reuse by others.

Browsing of construction processes to learn how agents are built.

Future: Online Execution of Agents

The next milestone is to enable online execution of agents directly on Shire Run, removing the need for a local IDE. The project repository is available at https://github.com/shire-lang/shire-compiler.

Conclusion

Applying software‑engineering practices—modular design, version control, testing—to prompts turns them into shareable, executable code. This expands developers’ ability to customize AI copilots, automate domain‑specific tasks, and advance collaborative AI development.