A six-part engineering guide: from individual prompts to specification-driven probabilistic software.
Read: Prompt engineering is becoming programming →Part 1 of 6
Foundations: the shift from prompts to programs
Why prompt engineering is turning into software engineering: the deterministic shell, the probabilistic core, and what can be declared at all.
Sections 01–04
01 · The shift
Prompt programming declares what, not how
From individual prompts to specification-driven probabilistic software. Traditional programming tells the computer exactly how to produce a result. Prompt programming defines what a valid result looks like (context, constraints, capabilities) and lets a probabilistic model decide part of the how.
Traditional software
deterministic
Input
Deterministic code
Predictable output
Same input + same state usually produces the same output.
Prompt-based software
probabilistic
Instructions
+ Context
+ State
+ Tools
+ Constraints
Model
Valid output A
Valid output B
Valid output C
The system defines the operating boundaries; the model may choose different valid paths.
Output
Model(Instructions, Context, State, Tools)
The tilde is the whole point: the output is sampled, not calculated as a perfectly deterministic function.
What this means for the business
Deterministic assumptions no longer hold
Traditional software gives you a promise you can plan around: the same input produces the same output, so you test once and ship. Prompt-based software breaks that promise. The same request can produce several different valid results, which means a successful demo is not evidence that the feature works in production, and a passing test run is not evidence that it will pass tomorrow. The work does not disappear, it moves: away from writing every instruction, towards defining what a valid result is and proving that the system reaches it.
Decision
Fund specification and verification as their own line items in the plan, not as testing overhead squeezed in at the end.
02 · The core architectural principle
A deterministic shell around a probabilistic core
Use normal code wherever logic can be expressed reliably. Use the language model where interpretation, semantic reasoning, creativity or ambiguity genuinely needs it.
Deterministic shell, declared & enforced by code
Input validation
Schemas & types
Workflow orchestration
State machine
Tool permissions
Budgets
Approval gates
Verification
Logging
Probabilistic core: the model decides
Interpretation
Intent inference
Semantic reasoning
Planning
Creative generation
Task decomposition
Tool selection within boundaries
Repair proposals
Rollback
Deployment policies
Cost limits
Let the AI decide semantic and creative details.
Do not let it invent permissions, lifecycle rules, success criteria or irreversible actions.
What this means for the business
Reliability comes from the code, not from a better prompt
When something goes wrong, the instinctive response is to rewrite the prompt. That produces an endless cycle: each edit fixes one case, silently breaks another, and leaves no audit trail of why the system behaves as it does. Teams that instead put validation, permissions, retries and limits into ordinary code get failures that are reproducible, explainable and fixable once. The boundary between the two is the single most consequential architectural decision in the system.
Decision
Ask your team where that boundary sits today, and require that permissions, data writes and irreversible actions live outside the model.
03 · Architecture
A prompt program is more than a prompt
A real AI application wraps the prompt in eight further declared parts. Together they form the program.
Prompt program =
Specification
+
Typed I/O
+
Context
+
Control flow
+
State
+
Tools & permissions
+
Evaluation
+
Stopping rules
+
Runtime policies
1 · Specification
Goal · requirements · constraints · definition of done · quality thresholds.
2 · Typed inputs & outputs
Required and optional fields · valid values · structured response schemas · unrepresentable invalid states.
3 · Context
User request · relevant documents · repository state · history · design system · policies · retrieved knowledge.
4 · Control flow
Chains · branches · routes · parallel workers · loops · escalation paths.
5 · State
Current stage · completed work · failed attempts · accepted decisions · remaining tasks.
6 · Tools & permissions
Available capabilities · read/write boundaries · network access · approval requirements · side effects.
7 · Evaluation
Correctness · requirement coverage · quality · safety · functionality · compliance.
8 · Stopping rules
When to finish · retry · repair · escalate · abort · ask the user.
9 · Runtime policies
Cost · latency · model choice · token budget · logging · retry strategy · deployment mode.
What this means for the business
If you can only see the prompt, most of the system is undocumented
A production-grade prompt feature has seven parts: specification, instructions, context, state, tools and permissions, evaluation, and governance. Only one of them is the prompt. When a team can show you the prompt and nothing else, the other six live in individual heads, which is why these features are so hard to hand over, review or reproduce after the person who built them moves on. This is ordinary key-person risk wearing new clothes.
Decision
Require the seven parts as reviewable artefacts in the repository, with the same expectation you already apply to API documentation.
04 · The declaration boundary
Can we declare all possible logic?
Nearly all system logic can be declared, but not every semantic decision. Three zones, from fully declared to open-ended.
A · Fully declarable
Schemas, code, policies, explicit configuration.
Valid inputs & outputs
Available tools
Permissions
Workflow states
Routing rules
Required validations
Retry & fallback rules
Cost & token budgets
Success criteria
Stopping conditions
Approval requirements
Rollback behaviour
Data-access boundaries
Legal state transitions
Deployment rules
Implement as schemas, code, policies and explicit configuration.
B · Constrained, model-driven
The model chooses within declared boundaries.
Classify user intent
Select a predefined route
Choose an allowed tool
Decompose a task
Select a design direction
Decide if more info is needed
Propose a repair strategy
Prioritize subtasks
Summarize ambiguity
Language → structured requirements
The model chooses, but only inside declared boundaries.
C · Inherently open-ended
Cannot be enumerated in advance.
Every possible interpretation of language
Every valid creative result
Every future task combination
Every useful decomposition
Every unexpected failure
Every novel user need
Every edge case in the real world
This is where agents and generative reasoning add both value and uncertainty.
What this means for the business
Classify before you estimate
Nearly all system logic can be declared in advance. A minority genuinely cannot, because it depends on judgement, taste or situations nobody has seen yet. Confusing the two is expensive in both directions: declaring open-ended judgement produces brittle rules that fail on real users, and leaving declarable rules to the model produces variable behaviour in exactly the places that must not vary, such as pricing, permissions and lifecycle. The classification also determines how the work must be tested.
Decision
Have each requirement classified as declarable, constrained, or genuinely open before it is estimated, because the class changes both cost and test plan.
More articles
Design reliable UX for connected devices across hardware, apps, BLE, Wi-Fi, cloud, onboarding, errors, and recovery.
Read: UX for Connected Devices: Designing Experiences Across Hardware, Apps, Connectivity, and Cloud →Hardware companion apps: hard parts, partner skills, and questions that separate specialists from agencies.
Read: How to Choose the Right Companion App Partner for Your Hardware Product →