What should an AI coding agent still have to decide?

This article follows three questions:

• Which decisions can the application inherit?
• Which choices should tools be able to inspect and check?
• Where should the agent write custom code, and what must it verify there?

An AI coding agent can write an approval screen. It still has to work out whose approval counts, which changes it authorizes, and what must remain true when the rules change. Some of that work belongs to the product. Some of it has already been solved many times.

How do we decide what the agent should reconstruct?

This is a question behind my work on Wildo. Coding agents make implementation more accessible, but an application still carries decisions about identity, authority, state, failures and evolution. Those decisions interact. A new action may affect permissions, a screen, an integration and the evidence needed to trust the result.

The interesting question is how to allocate that work. Which decisions can an application inherit? Which must remain under its author’s control? And can we preserve that distinction as the product changes?

My previous article explored how application knowledge can become something tools operate on. Here I want to examine the foundation underneath that knowledge: the machinery already built, the language used to express choices, and the passage into custom code when those choices are not enough.

A foundation is a set of commitments

There is no useful comparison with a completely blank slate. Every application inherits a language, libraries, infrastructure and earlier engineering knowledge. The decision is how far that inheritance should reach.

A builder does not manufacture every window or invent every material. But a house and a skyscraper do not inherit the same engineering decisions simply because both are buildings. Shared components are valuable within an appropriate set of assumptions.

Software has the same difficulty. An existing mechanism saves work when its responsibilities and assumptions match the application. If they do not, the integration may cost more than the implementation it replaces. Architectural mismatch is a longstanding engineering problem, not something the presence of an AI agent removes. 1

A domain foundation makes commitments about a family of products. It can settle how recurring operations are performed while leaving selected variations open. This follows the information-hiding tradition: a useful boundary contains a design decision so that the rest of the system need not reconstruct its implementation. 2

Those commitments also exclude possibilities. That is acceptable when the excluded possibilities do not belong to the product we need. It becomes expensive when a necessary distinction has disappeared behind the abstraction.

Consider a deliberately simple approval language that can route expenses by amount alone. It can express a threshold. It cannot distinguish two equally priced expenses with different risk classifications. We will return to that limit: it is where the quality of the foundation becomes visible.

A smaller space of choices is useful only if it contains the product we need, and if choosing within it actually does some work. “B2B applications” is a useful direction of specialization for Wildo, not proof that every B2B requirement fits every mechanism.

Fewer mechanisms to write, more meaning to work with

A foundation can contribute in two different directions:

• Inherited behavior. The engine supplies recurring mechanisms. The application selects and configures them instead of implementing their internals again.
• Operable meaning. Declarations and specifications make selected choices accessible to tools: what the application contains, how its parts relate and which consequences follow.

These contributions need each other, but neither implies the other. A reusable engine can be difficult to inspect. An elaborate specification can have no working consumer. The useful combination is implemented behavior connected to a description that tools can actually use.

Keep three layers distinct:

1. Intent: the outcome wanted and its reasons.
2. Declarations: selected choices expressed in a defined vocabulary.
3. Implementation: behavior carried out by shared mechanisms or custom code.

A vocabulary names concepts such as resource, operation and relationship. A grammar determines how expressions can be combined. Semantics determines what they mean. A schema that accepts a description does not, by itself, establish the behavior that description should produce. 3

This gives the phrase “restricting expression to enrich meaning” a concrete interpretation. Choose a smaller family of concerns, define those concerns carefully, and implement operations over them. A tool can then answer particular questions by computation instead of asking an agent to infer the answer again.

In our illustrative approval model, the distinction looks like this:

The last row has a small, concrete counterpart in Wildo. Field declarations can mark summary fields with .isSummaryField(). Shared derivation uses those markings to construct a summary schema; DTO construction and backend selection consume that information, and a frontend summary host uses the registered schema and record. The application selects the fields while established consumers perform recurring work. Evidence note

Resource schemas, business specifications and prose guidance are cooperating surfaces here. They are not one universal declaration that automatically produces every part of a correct application. Summary metadata, for example, is not proof of authorization.

A short custom function can express sophisticated behavior while exposing very little to an inspector. A longer structured declaration may expose operations, references and required members that can be checked directly. Brevity and operable meaning are different properties. Preservation note

A written norm can also be precise. The practical difference is whether a selected obligation has an executable interpretation and a faithful checker. A successful sound check establishes its named property under its assumptions. It does not decide whether the business asked for the right thing.

When the product needs more than the vocabulary

The common language will eventually be insufficient. A useful foundation needs an answer before that happens.

Return to the two equally priced expenses. Suppose one has a risk flag and should require additional approval. Every policy in our amount-only language gives both expenses the same answer. A custom handler that reads the risk flag can distinguish them.

This is a small but genuine expressiveness boundary. It is about the deliberately restricted language in this example, not a claim that every configuration product lacks the feature. If the language already contains risk conditions, choose a different requirement outside its vocabulary or acknowledge that the boundary has moved.

The important architectural choice is to permit richer expression at explicit places. A named operation can retain its identity, input contract and selected lifecycle mechanisms while an application supplies its business-specific implementation. The agent can write that implementation without necessarily reconstructing the machinery around it.

Domain expression and a general-purpose host are compatible ideas with substantial prior research. Embedded languages reuse host-language facilities while giving selected concerns their own expression. 4 The mere combination is not a new generation of programming language.

We can describe the arrangement simply:

Read the formula as three cooperating parts:

• E: the engine and its established mechanisms.
• d: the compatible declarations describing selected choices.
• h: the custom implementations attached to those declarations.

This notation identifies responsibilities; it is not a Wildo API or a correctness theorem.

Changing h can change behavior while d remains identical. Two handlers can have the same signature and operation binding while making different approval decisions. Inspection of the declaration alone cannot establish which decision the handler makes.

There is a useful distinction here between changing representation and extending expression. Algebraic and geometric descriptions may expose different ways to work with the same object. A custom implementation can do something stronger: introduce a behavior unavailable in the selected domain grammar. Translating a description and adding a new possibility carry different obligations.

Programming-language research also distinguishes expressiveness more carefully than simply asking whether a language is Turing-complete. The structure of a translation matters. 5 For an application builder, a corresponding practical question is how much surrounding work must change to express the new requirement.

Wildo exposes several routes: backend service injection and custom operation implementations; replaceable frontend components; execution views; and composite views. These let application authors supply code while retaining different kinds of declared structure. They are not interchangeable guarantees. Replacing a service through dependency injection does not automatically preserve every contract of the resource-operation pipeline.

An operation handler, a component and an entire authored view therefore need different evidence. A matching TypeScript interface does not establish correct authorization, safe effects, accessibility or business behavior. Explicit boundaries make those obligations identifiable; they do not make them disappear. Technical note

This is where coding agents can use both sides of the framework: structured domain information guides them to the relevant contract, and the host language gives them room to implement what is specific. The design objective is to change the distinctive part while retaining the surrounding work that remains useful. Whether agents accomplish that more efficiently still needs measurement.

Give the agent the distinctions its task needs

Once custom behavior exists, the framework must help an agent find it without pretending to know everything about it.

A declaration may identify where a decision lives, which operation calls it and what inputs it receives. If the task asks how that decision is made, the agent needs the implementation or suitable behavioral evidence. More explanation of the binding alone cannot answer that different question.

The same principle applies when reducing context. A projection is a view selected from a richer source. It is sufficient only relative to the questions it must answer.

Suppose a view records whether each expense is above €1,000. Both €1,200 and €2,000 become “yes.” If the threshold changes to €1,500, those expenses require different answers. The old flag has erased the distinction needed for the new task. We need the amounts and current policy from a richer source.

The preservation requirement is:

Read the equation from left to right:

• q(x): answer the question using the full state.
• π(x): retain a view of that state for the task.
• q̄(π(x)): obtain the same answer from the view.

The full state is x; π(x) is the selected view. The question q must have a corresponding answer operation q̄ that gives the same result from that view. The mathematical existence of such a function is not an implementation: a usable evaluator must also be provided. Nor does the equation tell us whether we chose all the questions the change requires.

This separates two senses of information “dilution.” A projection can lose relevant distinctions. Alternatively, the information may remain present but become harder for a bounded agent to find or use. Adding irrelevant material does not mathematically erase existing information. Its effects on agent errors, time and context consumption are separate measurements. Information note

Wildo’s companion exposes scoped application information, while framework knowledge teaches agents how to discover and interpret it. The creation runtime also has declared-aspect selection and bounded widening of context. Guidance teaches the use of these mechanisms; it does not replace their execution.

Observation quality matters. In the implementation inspected for this research, some extraction failures return empty detail collections. An empty result on those paths cannot establish that the application has no such fields or operations. A trustworthy absence claim needs a complete, successful observation of the relevant scope.

The right context is therefore a view we may have to revise, not a compressed description we can trust forever. The source must remain available when a new question demands information the view omitted.

Change tests every layer

A changed requirement can challenge the implementation, its contract or the intention behind the contract.

Raising an approval threshold first requires a policy decision: which expenses, currency and effective date does it cover? The declaration changes next. Its consumers need inspection, and new evidence must establish that the intended routes hold. If the product then adds multiple currencies, a single threshold may no longer represent the policy adequately.

That is a reason to move upward as well as downward. Repeatedly editing the handler cannot settle an unresolved business decision about conversion rates or currency-specific thresholds.

This is the useful sense of recursive introspection: reconsider consequences within a level, and move between intent, specifications, implementation and evidence when the findings require it. Neither a dependency graph nor a sequence of instructions guarantees that every consequence will be found.

Wildo’s requirement-based maturity calculation provides a concrete example of why the model remains useful after initial generation. Adding a requirement can lower the derived maturity reading until relevant work and evidence are present. That reading is not a permission or execution gate, and an evidence reference is not automatically authenticated runtime proof.

Local success also needs integration checks. A handler may return a valid approval result for an expense while using the wrong organization’s policy. Correct types and valid routes do not by themselves establish the required organization relationship.

The right stopping point depends on independently defined acceptance conditions and current evidence, including unresolved obligations discovered along the way. New findings can increase the work still required. There is no general promise that each iteration makes the obligation list shorter.

Instructions remain useful for judgment, investigation and exceptions. Executable processes can represent state and enforce selected transitions. Reactive coordination can revisit work when circumstances change. Their detailed comparison deserves its own article; here the essential point is that inheritance must remain inspectable and revisable.

A foundation earns its place through accepted change

How would we establish that this arrangement helps?

A first successful generation is too narrow a test. Evaluate a sequence: create the initial policy, change the threshold, add a risk exception, change the view, and introduce a new evidence requirement. Define acceptance independently before comparing approaches.

The comparison needs credible alternatives. A general-purpose implementation already uses libraries, search and tools. A configuration platform may have excellent code extensions. Classify their actual capabilities rather than treating “framework” or “no-code” as an explanation of the result.

Separate costs borne by the application builder from investment in the foundation. Shared mechanisms have development, support and evolution costs. Product-line economics explicitly accounts for common assets, adoption and reuse effort, including adaptation. 6 A saving for one adopter does not establish a saving for the whole ecosystem.

A domain language also has to be usable. Its precision does not guarantee that an agent writes it correctly. A 2026 study of constraint languages found Python generally easier for its evaluated models than OCL or Alloy. Its cohort included GPT-4o and other older models, so it is counterevidence to an automatic benefit, not a ranking of today’s frontier systems. 7

Measure failures and unsupported requirements as well as successful work. More time spent on distinctive business logic is encouraging only if total effort and accepted quality improve. A high proportion of retained checks cannot compensate for losing one critical authorization check.

The position I am developing is an architectural synthesis and a research hypothesis. Reuse, domain languages and explicit extension boundaries are established ideas. The question is how their combination changes accepted delivery and evolution when coding agents do the work.

A useful foundation makes some decisions before the application exists and leaves others deliberately open. Its value depends on whether those earlier decisions remain useful when the product changes. For AI-assisted development, that is the promise worth testing: less reconstruction of common mechanisms, more usable knowledge about the application, and room to implement the parts that make it different.

Technical notes

What a declaration preserves

Historical labels such as 4GL can suggest domain-level expression, but “4th bis” is not a technical classification established here. AI assistance does not make a framework a 5GL. The useful description is domain-oriented expression embedded in a general-purpose host, with explicit extension points.

For a set of possible behaviors Ω, a declaration d selects a permitted subset S(d). Compatible commitments can reduce that set; contradictory commitments can make it empty. A smaller set is therefore not automatically a better design or a measure of saved effort.

The distinction between brevity and operability can also be stated precisely. For fixed engine E and observation O, let L_E(a) be the minimum encoded length of a compatible declaration/implementation pair whose behavior has the same observation as application a. Take infinity if no pair exists. This is a definition, not a generally computable minimum for arbitrary code. Observational equivalence implies acceptance only if O captures the independently specified acceptance criteria. Separately, let O_Q(d) be the subset of predefined questions Q for which implemented tools compute justified answers from declaration d. A shorter encoding need not support more such questions. The shared engine’s development and maintenance costs are additional.

For a family of questions Q, group states that give the same answer to every question in Q. This produces the coarsest partition preserving those answers. It does not establish the shortest textual encoding, cheapest computation or adequacy of Q for the product.

Composition adds obligations. If an expense must belong to its claimant’s organization, two paths should agree: expense → claimant → organization, and expense → charged organization. Merely checking that each link exists is insufficient. Category-theoretic knowledge models make such path equalities explicit, provided the arrows have the required functional interpretation. 8

Reading a projection and updating through it are also distinct. A view showing a threshold must not silently reset a hidden currency when edited. Bidirectional transformation research formalizes such round-trip obligations; the laws do not choose the correct business policy for us. 9

Where custom behavior becomes opaque

Let H(d) be the implementations compatible with declaration d. Projection π(d,h)=d forgets the custom body. A behavioral question q admits an answer based on d alone precisely when its answer is constant across the compatible implementations attached to d:

The practical test is simple:

• Keep the declaration fixed.
• Substitute another compatible implementation.
• If the answer changes, the declaration alone is insufficient.

The constancy condition above characterizes well-defined factorization on nonempty fibers, not an algorithm that discovers or computes the answer. Approval decisions can violate the condition while operation identity satisfies it.

To establish a property P after extension, two premises are needed: the surrounding composition preserves P for implementations satisfying an adequate contract C, and the chosen implementation actually satisfies C. Input/output typing alone may not express the relevant effects or lifecycle obligations.

The inspected Wildo operation registry, for example, rejects combining transactionalCore with OVERRIDE_ALL. This is one operational boundary, not a guarantee for arbitrary injected services. Multi-language semantics provides a formal precedent for treating crossings explicitly; Wildo’s domain APIs within TypeScript are not the ML/Scheme calculi studied in that work. 10

Information loss versus agent performance

Take four equally likely amounts: €900, €1,000, €1,200 and €2,000. Let X be the amount, Y whether it exceeds €1,500, and Z whether it exceeds €1,000. The old flag merges €1,200 with €2,000.

For finite variables with the Markov condition Y → X → Z, the lost relevant information is:

Three different operations must remain distinct:

• Reword the old flag: the missing distinction stays missing.
• Retrieve the exact amount: the new question becomes answerable.
• Add unrelated text: this does not itself erase information already present.

Here Y is determined by X, so Δ equals H(Y given Z), or 0.5 bits. No rewording of the old flag can recover the merged distinction. Retrieval of the original amount can.

By contrast, appending independent irrelevant information N leaves the mutual information unchanged: I(Y;Z,N)=I(Y;Z). Agent performance can still deteriorate under a finite processing budget; that is an empirical execution result, not a consequence of this identity. Truncation can introduce actual loss.

The information bottleneck framework formalizes compression relative to a target variable. 11 This finite example applies that perspective; it does not claim Wildo optimizes an information-theoretic objective or that semantic value can generally be counted in tokens.

Evidence and evaluation

The approval language and threshold examples are explanatory constructions. They are not a report of an expense application implemented or benchmarked in Wildo.

The framework investigation inspected summary declaration consumers, companion projections, declared-aspect context selection, maturity derivation and extension surfaces. Its September 2026 record includes 102 passing focused tests for selected specification/context/maturity mechanisms and 35 passing extension-related tests, with one pre-existing skipped case. Those runs were component evidence collected during research, not new executions performed for this article or proof of complete application behavior.

The summary trace follows PriceSchema, deriveSummarySchema, summary DTO construction, extractSummaryFields, and ResourceLayout_ReadSummary. These are different consumers, with their own options and failure behavior; no end-to-end authorization proof follows from their shared metadata.

Observation limitations include extraction failures collapsed into empty details and paths where unavailable build evidence becomes absent input. The inspected maturity caller did not supply runtime observations. These findings limit claims of complete inspection and independently observed readiness. A publication pass must recheck them against its target revision.

The proposed evaluation compares accepted changes, failure outcomes and lifecycle costs. It includes near-fit and out-of-domain requirements, not only demonstrations designed around the foundation. No controlled comparative productivity result is reported here.

Definitions

Domain foundation

Reusable mechanisms and contracts that settle recurring decisions for a family of applications while retaining selected points of variation.

Domain language

A vocabulary, legal combinations and interpretation for a selected problem domain. It may be embedded in a general-purpose programming language.

Operable meaning

Defined application meaning over which implemented tools can perform particular queries, checks, derivations or transformations.

Projection

A view of a richer source selected for a purpose. Its adequacy depends on the distinctions the task needs and the quality of the observation.

Extension contract

The inputs, outputs and relevant behavioral or lifecycle obligations at a point where custom code joins the surrounding system.

Accepted behavior

Behavior assessed against independently specified requirements and acceptance criteria, rather than inferred from successful generation or valid syntax.

References

1. Garlan, Allen and Ockerbloom. Architectural Mismatch. ICSE, 1995. Component assumptions and integration failures.

2. Parnas. On the Criteria To Be Used in Decomposing Systems into Modules. CACM, 1972. Information hiding and decision boundaries; linked transcription rather than publisher scan.

3. Harel and Rumpe. Meaningful Modeling: What’s the Semantics of “Semantics”?. IEEE Computer, 2004. Syntax, semantic domains and interpretation.

4. Leijen and Meijer. Domain Specific Embedded Compilers. DSL, 1999. Domain expression within a general-purpose host.

5. Felleisen. On the Expressive Power of Programming Languages. Science of Computer Programming, 1991. Translation-based expressiveness; not a productivity theorem.

6. Clements, McGregor and Cohen. The Structured Intuitive Model for Product Line Economics. CMU/SEI, 2005. Cost structure, adoption and reuse.

7. Delgado, Burgueño and Clarisó. Assessing code generation of constraint domain-specific languages with large language models. March 2026 author version. OCL, Alloy and Python, using the model cohort identified above; no current-frontier ranking implied.

8. Spivak and Kent. Ologs: A Categorical Framework for Knowledge Representation. PLOS ONE, 2012. Typed functions and path equations.

9. Foster and colleagues. Combinators for Bidirectional Tree Transformations. ACM TOPLAS, 2007. View-update consistency laws.

10. Matthews and Findler. Operational Semantics for Multi-Language Programs. POPL, 2007. Explicit interoperability boundaries and semantic obligations.

11. Tishby, Pereira and Bialek. The Information Bottleneck Method. Allerton, 1999. Compression relative to a target variable, especially equations 15–17.