Programming with human language: defining intent before the agent builds

A coding agent needs a clear definition of the system it is building. If we leave its meaning, scope and rules undefined, the agent makes those decisions while writing the code.

Development through human language lets us delegate more of software construction. We can describe an outcome and ask an agent to work out the implementation. That makes more work practical, but it also allows construction to proceed while important decisions remain unstated.

In my approach, three documents establish the system: a domain profile, invariants and intent. They give the agent the meanings, rules and purpose it needs to make implementation decisions. To understand why this matters, it helps to examine how formalisation has changed through computing history.

How formalisation moved

Formalisation is the work of turning an idea into explicit objects, relationships, operations and rules that a computer can act on.

Someone must bridge the distance between “calculate the value of these holdings” and the operations that produce the answer. Over time, we have delegated more of that translation to machines. The following progression compares what we express with what translates it into execution. These modes overlap and remain in use.

Physical configuration embodied the procedure in connections and settings. Stored-program computers made instructions available from memory, reducing the need for physical program setup. The Computer History Museum’s account of the stored program describes this transition. It changed how programs were held and modified; symbolic and higher-level languages changed how people expressed them.

Higher-level languages let programmers work further from machine instructions. A programmer could define holdings as records, collect them in a list and express a valuation calculation through functions. The language implementation handled much of the lower-level translation. The programmer still had to decide what a holding contained and how its value should be calculated.

Declarative languages delegated part of the procedure as well. A SQL query can specify which records to retrieve while leaving the database to choose an execution plan. The request still has to use the language’s vocabulary and rules.

What separates human-language development from the earlier modes is the point at which automated translation can begin. In conventional programming, we express the problem in a programming language before its compiler or interpreter can process it. With an agent, assistance can begin while we are still deciding how the problem should be represented.

Human language moves the boundary

A programming language has a defined syntax and rules for interpreting its expressions. Those rules can have gaps and implementation-specific behaviour. Even the Python language reference distinguishes its formal grammar from its prose descriptions of meaning. Nevertheless, a program is interpreted against an established language definition.

Human-language development introduces another interpretive step. Before generating a program, the agent must determine what our description means for this particular system.

“Calculate portfolio value” sounds clear until we ask which holdings belong to the portfolio, which price applies to each instrument, how currencies are combined and what happens when a required price is missing. An agent can choose answers and produce executable software. The code can run successfully while calculating something different from what we intended.

We can delegate the work of formalisation. A human and an agent can establish definitions together, explore alternatives and expose contradictions. But we still need a basis for deciding which interpretation is correct.

Asking an agent to act as an architect or backend engineer does not supply that basis. A role names a responsibility. The particular system still needs to be defined.

Three definitions for construction

The domain profile, invariants and intent answer different questions. They constrain construction together; they are not three implementation stages.

A separate engineering specification then maps these definitions into mechanisms: components, data representations, interfaces and runtime behaviour. A mechanism choice that changes the intended meaning or behaviour requires the relevant definition to be reconsidered.

The following examples use a crypto-options engine. The same separation applies wherever a short request hides substantial domain decisions.

Domain profile: establishing meaning

A domain profile establishes the concepts the system uses, what they mean, how they relate and which transformations preserve that meaning.

For an options engine, “price” is insufficient. A bid, a mark, a last trade and a settlement fixing serve different purposes. Each value needs the unit, basis, source and time required to interpret it.

A mark used to value a position does not become an executable bid. If a calculation permits substitution, the rule must be explicit and the value must retain its identity. Otherwise, an agent can connect two components through a field called price while changing the economic meaning of the calculation.

The profile also defines how operations compose. Values can be combined only when their meanings are compatible. Sensitivities require compatible factors, units and valuation contexts. Amounts in different currencies require an explicit conversion before they can form a monetary total.

Missing information needs its own meaning. If a required holding quantity is unknown, treating it as zero produces a determinate answer by discarding uncertainty. The profile must establish how that uncertainty affects the result.

Its structure follows those responsibilities:

The profile leaves strategy choices to the intent: the profile establishes what a risk measure means, and the engine’s intent establishes which limits apply.

Invariants: establishing construction rules

Invariants state the properties every acceptable implementation must preserve. Here, the document owns engineering rules; domain laws remain in the profile.

For example, an exposure calculation can receive positions and prices as inputs. If it fetches prices from an exchange during the calculation, its result also depends on timing, connectivity and external state. An invariant requiring calculations to have no hidden external actions makes that boundary explicit.

Each rule needs a recognisable violation and a way to check it:

A compact invariants document records authority, the construction model, permitted dependencies, individual laws, explicit exceptions and acceptance conditions. Each law states its property, scope, violation and the evidence that establishes it.

These rules let the agent choose implementation details without reopening ownership and boundary decisions on every task.

Loading the document does not establish compliance. Import checks can detect a forbidden dependency; they cannot prove that an exposure calculation is correct. Verification must match the property being claimed.

Intent: establishing required behaviour

Intent defines what the particular system should do. For a trading engine, it records the economic purpose, permitted activities, decision rules and required responses as conditions change.

“Build a crypto-options engine” leaves these choices open. An engine that evaluates opportunities, one that places live orders and one that manages existing positions have different mandates. If the purpose is evaluation, placing orders exceeds the intent even if the agent can implement execution.

The intent is developed jointly by a trading expert and an agent. The expert supplies or approves trading judgements. The agent helps expose ambiguity, test consistency and explore consequences. Unmade decisions remain explicit.

The document follows the engine’s economic responsibilities:

Suppose required market data is missing. A candidate that fails its trading conditions differs from one that cannot be evaluated. The intent must state what the engine may do in each case, including its obligations toward existing positions.

Concrete examples make those distinctions checkable before implementation. An example records holdings and commitments, observations and known gaps, applicable rules, alternatives, the expected decision and prohibited behaviour.

If the written rules cannot explain the expected decision, something remains undefined. The example helps locate that gap. It does not replace a missing rule or establish that a strategy will be profitable.

The engineering specification chooses how to realise the behaviour. If a proposed mechanism would change a trading decision, that choice returns to the intent for resolution.

From definition to evidence

Defining the system before construction does not require us to supply the finished program. It separates the decisions the agent may make from the decisions that establish what the system is, and records which meanings and obligations implementation choices must preserve.

I use these documents as a basis for construction and review. Their value is judged by the software: whether it preserves the defined meaning and produces the required behaviour, and how much correction it needs. A complete document is useful only when its definitions govern the implementation.

Codebase architecture is the next concern: how to organise the software so that ownership, composition and dependencies reflect the system we have defined. Enforcement follows separately, through checks, hooks and an agent control layer that provide evidence that construction followed those definitions.