Here’s a claim worth examining: for a well-specified business UI, roughly 80% of the interface definition can be generated by a deterministic script — no LLM required.
The remaining 20% is genuinely undecidable from structure alone, and that’s exactly where the LLM should spend its tokens. Not on the boilerplate. On the judgment calls.
This is the thesis behind the PageDef autofill system in DarJS, and it’s worth unpacking because it changes how you think about where AI actually adds value.
What PageDef is
A PageDef is a plain JavaScript object that describes a business UI page:
module.exports = {
id: 'order',
model: 'Order',
columns: ['order_number', 'order_type', 'order_status', 'total_ttc', 'created_at'],
actions: ['create', 'view', 'update', 'delete', 'transition'],
formFields: ['order_type', 'table_id', 'notes', 'covers'],
filters: ['order_type', 'order_status'],
relations: { table_id: { model: 'Table', display: 'table_number' } },
widgets: [{ type: 'line-items' }, { type: 'activity' }],
};
From this single object, the framework generates the list view, the detail view, and the form. One config, three pages, zero additional code.
The question is: can this object be derived automatically from the model it describes?
The autofill rules
Most fields in a PageDef can be determined by inspecting the model:
columns — take all scalar, non-foreign-key fields. Exclude structural fields (id, created_by, updated_by). Put created_at last. This rule produces the right answer for every model we’ve tested.
actions — if the model has transitions, add 'transition'. Always include create, view, update, delete. This is almost always correct; the exceptions (read-only models, append-only logs) are easy to flag.
filters — take every enum field in the model. These are almost always the fields users want to filter by.
relations — find every *_id field. The referenced model is the field name without _id, PascalCase. The display field is the first string field in that model. This is a heuristic, not a rule — but it’s right ~85% of the time.
widgets — look up which mixins the model uses. ActivityTracked → activity widget. Billable → line-items widget. Commentable → comments widget. This is a lookup table, not reasoning.
formFields — include required fields, exclude audit fields and timestamps. This is right most of the time.
The 20% that remains
Five fields get flagged with // REVIEW: comments in the generated output:
columnRoles— which columns to hide per role. Requires knowing business rules, not model structure.customActions— non-CRUD operations. No structural signal for these.reports— analytics views. Domain knowledge required.formTabs— grouping fields into tabs. UX judgment, not derivable.showWhen— conditional field display. Depends on workflow logic.
These five are genuinely undecidable. No amount of model inspection tells you whether delivery_address should only appear when order_type is 'delivery'. That’s a business rule.
The autofill script generates everything else and leaves these five as explicit REVIEW markers. The developer (or LLM) reads the five flagged fields and makes judgment calls. The total effort is dramatically less than writing the PageDef from scratch.
What this proves about NLP contracts
We’ve been building an NLP contract system in DarJS for several sessions — annotating every function with @reuse-when, @complexity, @does. The PageDef autofill tool is the first concrete proof that the system delivers on its promise.
The promise was: for tasks where the answer is derivable from structure, the NLP layer handles it without LLM tokens. For tasks where judgment is required, the LLM engages with exactly the undecidable parts.
The PageDef generator is the NLP layer. It handles 80% deterministically. The REVIEW flags are the escalation signal. The LLM reads five annotations and fills in five decisions.
Without the autofill system, generating a PageDef is an LLM task from start to finish — reading the model, reasoning about field types, inferring relations, deciding on widgets. With the autofill system, it’s a script that runs in milliseconds, followed by a targeted LLM pass on the five hardest questions.
The split of labor isn’t arbitrary. It follows the complexity gradient in the @contract system: simple tasks go to the script, moderate and complex tasks go to the LLM.
The underlying pattern
The pattern generalizes beyond PageDef:
For any structured artifact, identify which fields can be derived from existing structure by deterministic rules. Generate those automatically. Flag the rest explicitly. Route only the flagged fields to the LLM.
Applied broadly: code scaffolds, migration files, test fixtures, API specs. Most of what an LLM generates for these artifacts is boilerplate that could be derived from a schema. The genuine value-add — business rules, edge cases, judgment calls — is a small fraction of the total.
The work is in identifying the boundary. What is structure-derivable? What requires judgment? Drawing that line explicitly — as the autofill spec does — is a design artifact, not just an optimization.
Once the line is drawn, automation handles one side. AI handles the other. Neither does the whole job alone.
Read time: ~5 min