When Domain Expertise Becomes Executable

What education must cultivate when people can act closer to technical implementation

Signal Intelligence Briefing 005

Edge line: Software is becoming cheaper to create. Consequence is not.

During the build of Visible Thinking Designer, I uploaded a photograph of a real task. The image failed before it reached the application logic. The server returned a plain-text 413 error. The fallback route then produced something worse than a visible failure: a dead end with no useful question and no way forward.

The important moment was not that the software broke. Software breaks. It was where the consequential work appeared. The coding agent could diagnose the route, alter the image pipeline, add rotation and size handling, repair the fallback and write dedicated tests. But first someone had to recognise that the experience was unacceptable, distinguish the surface symptom from the actual cause, decide what a legitimate recovery path should preserve and refuse to let an expedient fallback quietly redefine the product.

That small incident revealed a larger structural change. A domain expert can now move much closer to technical implementation than was previously practical. The distance between an idea, a body of professional knowledge and a functioning software object is contracting. Yet the difficult human work has not disappeared. It has migrated into framing, specification, judgement, correction, boundary-setting and responsibility.

Domain expertise is becoming executable. Only partly. And never without consequence.

1. Purpose of This Briefing

Primary Goal

To examine what changes when agentic systems allow people with deep domain knowledge—but without conventional software-development backgrounds—to translate more of that knowledge directly into functioning technical artefacts.

Core Strategic Premise

As technical execution becomes more accessible, scarce value moves towards the capabilities that direct and govern it: defining the problem, specifying what good means, recognising plausible failure, correcting it and knowing when professional engineering and organisational stewardship must take over.

What This Briefing Is Not

It is not an argument that software engineering has become easy or obsolete.
It is not a claim that anyone can now build production-grade software.
It is not a Build Week memoir or a celebration of vibe coding.
It is not a reprise of SIGNAL 004’s argument about learning evidence and visible thinking.
It does not claim that Visible Thinking Designer is educationally effective, production-ready or independently validated.

Desired Reader Outcome

Readers should leave able to distinguish the ability to produce a plausible software object from the capability and authority to judge, deploy and steward it. Educators and capability leaders should also see why evaluative judgement, adaptive expertise and disciplined collaboration may become more important—not less—as implementation barriers fall.

2. Executive Signal Summary

Signal 1 — The division of labour is changing

Agentic coding systems can now perform substantial parts of the implementation loop while people retain much of the planning and direction. Anthropic’s analysis of roughly 400,000 Claude Code sessions found that users made about 70 per cent of planning decisions while the agent made about 80 per cent of execution decisions. This is first-party session evidence, not proof of durable product outcomes, but it names a real movement in where work occurs.

Signal 2 — Expertise has not disappeared; it has changed position

The same study found persistent returns to task-specific expertise. Most of the gain appeared between novice and intermediate use, and more experienced users recovered from trouble more successfully. Natural-language access lowers a barrier. It does not create the conceptual command needed to frame good work, recognise an edge case or decide what should happen next.

Signal 3 — Expertise becomes executable only when it becomes specifiable

Prompts, examples, rules, schemas and tests can carry parts of a domain model into software behaviour. They can make standards operational and inspectable. They also compress, omit and sometimes distort. Tacit, situated and culturally authorised judgement does not become complete merely because some of it has been expressed in a machine-readable form.

Signal 4 — Evaluative judgement is the capability bridge

The most useful educational concept here is not generic critical thinking and certainly not prompt fluency. It is evaluative judgement: the capability to recognise quality, inadequacy and consequence against the standards of a domain, then decide what must change.

Signal 5 — A prototype can arrive before stewardship

Code generation, deployment and even automated tests can occur before privacy, security, accessibility, maintenance, ownership and retirement have been settled. The ability to produce has moved faster than the organisational ability to remain responsible.

Signal 6 — Education must preserve practice in judgement

If agents absorb more routine execution, professional formation must not reduce learners to monitors of plausible output. It must deliberately cultivate framing, comparison, correction, adaptive expertise and collaboration across domain and engineering boundaries.

3. Why This Matters

Capability is moving closer to implementation

For many domain experts, the old sequence was indirect. A practitioner recognised a problem, explained it to a product or technical team, waited for translation, reviewed what returned and negotiated the gaps. That sequence still has value, especially where consequence and complexity are high. But it is no longer the only practical route for bounded work.

A teacher, clinician, accountant, policy adviser, trades expert or community practitioner can now test a small technical hypothesis much earlier. They can put an idea into use, see where it fails and refine the underlying model before committing to a large build. For small organisations and specialist fields, that can release experiments that would never have survived a conventional procurement threshold.

The cost of being wrong has not fallen at the same rate

A plausible interface can create false confidence. A working route can conceal fragile data handling. A useful local tool can become an unowned dependency. A prototype can begin affecting learners, customers or staff before anyone has decided who maintains it, who responds when it fails or when it should be retired.

Research on low-code citizen development provides a useful historical warning. Distributed creation can support speed and local problem-solving, but studies also identify poor software quality, shadow IT and technical debt when governance and technical expertise lag behind production. Agentic construction is not identical to low-code development, but it inherits the same structural question at a greater level of expressive power: who remains responsible when the builder can make more?

The educational stakes are larger than a new tool curriculum

The obvious institutional response is to teach people how to operate coding agents. That is necessary but shallow. The deeper task is to form people who can make defensible domain judgements under conditions of technical amplification.

This means knowing what quality looks like before the agent generates it. It means being able to test a plausible answer against standards, context and consequence. It means recognising when one’s own knowledge is insufficient. And it means knowing when to stop local experimentation and bring in professional engineering, security, privacy, legal, accessibility or cultural authority.

4. Current System Reality

Coding assistance is becoming agentic execution

Autocomplete and conversational coding support helped people write or explain code. Contemporary agents can inspect repositories, plan changes, edit multiple files, run commands, execute tests and iterate against feedback. The shift is not from “human developer” to “autonomous machine”. It is from line-by-line assistance towards a negotiated work loop in which the machine can perform a larger share of execution.

Anthropic’s 2026 session study provides one of the clearest current views of that division. Yet its evidence ceiling matters. The analysis comes from Anthropic’s own product, infers features from session transcripts and cannot see whether the resulting artefacts remain useful, secure or maintainable once the session ends.

Productivity is not a settled number

The temptation is to ask for a universal multiplier. The evidence does not justify one. METR’s randomised study of experienced open-source developers found that early-2025 tools made its participants 19 per cent slower on familiar codebases. METR now marks that result as out of date. Its later experiment suggested possible speed-ups, but selection effects and concurrent agent use made the estimate unreliable.

The responsible conclusion is not that agents make experts slower or faster. It is that effects vary with the tool generation, task, codebase, user expertise, familiarity and whether review, integration and maintenance are counted. DORA’s broader organisational research reaches a compatible judgement: AI amplifies the system in which it is introduced. Strong foundations compound. Weakness and downstream disorder do too.

Domain access is widening unevenly

Anthropic found that non-software occupations could complete meaningful coding sessions at rates not far below software occupations. That is striking. It is not proof that occupational background no longer matters. The tasks that people choose, the standards they apply and the consequences they can detect differ profoundly.

The more durable interpretation is narrower: coding background may be becoming less determinative for some bounded work, while task-specific expertise remains a strong input into direction and recovery. The agent can make implementation more reachable. It cannot guarantee that the person reaching it understands the terrain.

5. What the System May Be Misunderstanding

Misunderstanding 1 — Access to code equals capability

Producing code is not the same as specifying a worthwhile product, verifying its behaviour or accepting responsibility for its effects. Natural-language access changes who can act. It does not abolish standards, architecture, security or consequence.

Misunderstanding 2 — A working prototype is a product

A prototype answers a bounded question: can this mechanism be made to work under these conditions? A product must survive more demanding questions about users, failure, integration, data, accessibility, monitoring, maintenance and retirement. Deployment begins a new phase of evaluation. It does not close the argument.

Misunderstanding 3 — Judgement is a generic human remainder

Judgement is not what humans do after the interesting technical work has been automated. Good judgement is disciplinary. It is formed through repeated encounters with quality, error, standards, ambiguity and consequence.

Tai and colleagues define evaluative judgement as the capability to make decisions about the quality of one’s own work and the work of others. They emphasise that it is contextual and domain-specific, developed through comparison, standards, exemplars, justification and feedback. Applied here, this means a person cannot reliably judge an agent-created artefact merely by being generally intelligent or AI-literate. They need a sufficiently developed conception of quality in the domain.

Misunderstanding 4 — Making expertise executable captures the expertise

The phrase is deliberately provocative, but it needs a brake. The knowledge-elicitation literature has long shown how difficult it is to acquire expert knowledge in an explicit form suitable for encoding. What experts notice is not always fully available to conscious report. What communities authorise as legitimate practice may not belong to an individual to formalise.

Executable expertise is therefore always partial. It is a model of the domain, not the domain. Its value increases when that model remains visible, testable and contestable—and when the people affected can challenge what has been encoded, omitted or flattened.

Misunderstanding 5 — More automation means less need for practice

Bainbridge’s “ironies of automation” remains an important counter-signal. When routine action is automated, people may practise the underlying skill less often while remaining responsible for the rare case in which intervention is most difficult. The transfer from industrial control to agentic knowledge work is analogical, but the warning is sharp: a generation that learns only to supervise plausible output may be least prepared to recover when plausibility fails.

6. Emerging Adaptation Patterns

Pattern 1 — Domain models before implementation

The strongest agent-mediated builds begin before the agent is asked to code. They establish the domain problem, intended user, evidence of quality, product boundary and explicit exclusions. This gives the agent something more coherent than an enthusiastic paragraph and gives the human a standard against which to judge what returns.

Pattern 2 — Staged human gates

Rather than treating the agent as a one-shot generator, teams are separating discovery, initial implementation, live-model validation, user review, repair and release. Each gate asks a different question. Does the mechanism work? Does it preserve the domain boundary? Does it fail honestly? Is the next increase in consequence justified?

Pattern 3 — Generative interpretation with deterministic boundaries

Agents are useful where interpretation and variation matter. Deterministic code remains useful where counts, limits, mappings, structural rules and safety boundaries must not drift. Structured outputs, schemas and tests become a translation surface between human intention and machine execution.

Pattern 4 — Domain–engineering pairing

Direct domain construction does not eliminate engineering collaboration. It can improve it. A domain expert can arrive with a tested mechanism, clearer requirements and evidence of where the problem bites. An engineer can then concentrate on architecture, assurance, integration, scale and stewardship rather than spending the entire engagement trying to discover what the work is actually for.

The VTD case: what the loop revealed

Visible Thinking Designer began with four governing documents, a defined educational model and explicit exclusions. Codex performed most of the technical implementation. I controlled the problem, sequence, stage gates, re-scoping, rejection, repair and release. The build accumulated 62 named contract tests and several live journeys. It also retained a substantial list of checks not performed.

The image incident was one of several negative findings. Another live output silently mapped an educational position incorrectly; a deterministic boundary was added. A review found language that was too dense, an exposed long task and a risk of silent truncation; the prompt and interface were repaired. These were not signs of autonomous success. They were the work loop itself: propose, inspect, detect, correct, test and decide whether to proceed.

The case demonstrates a mechanism: a developed domain model can be translated unusually close to working software through a governed human–agent loop. It does not demonstrate educational impact, general usability, production readiness, comprehensive security or long-term maintainability.

7. Strategic Implications

For tertiary education and professional formation

Prompting should not become the curriculum’s centre of gravity. Professional programmes need to cultivate the capacity to define quality, compare alternatives, explain decisions, detect consequential error and adapt under changed conditions. Evaluative judgement should become an explicit learning outcome across domains where AI can now perform more of the visible production.

Adaptive expertise matters alongside evaluative judgement. Hatano and Inagaki distinguish efficient routine performance from conceptual command that supports action under unfamiliar conditions. If agents absorb more routine procedure, education must preserve enough varied practice, conceptual explanation and productive failure for learners to understand why a method works and when it no longer applies.

Instruction must also remain calibrated. The expertise-reversal literature warns that guidance useful for novices can become redundant or obstructive for experts. A novice domain practitioner using a coding agent may need strong scaffolds, bounded environments and direct technical support. An experienced practitioner may need fewer prompts and more demanding opportunities to make and defend judgements. One “AI skills” course will not form both.

For domain experts

The opportunity is real: test ideas earlier, build small tools, clarify requirements and learn through interaction with a functioning artefact. The obligation is equally real: distinguish exploration from deployment, preserve evidence of decisions and seek help before the artefact carries consequences one cannot competently evaluate.

For organisations

The emerging risk is not simply shadow IT. It is shadow software: locally generated tools that become useful enough to persist but remain invisible to ownership, security, privacy, architecture and maintenance processes. Organisations need graduated thresholds rather than a blanket ban or an invitation to build anything.

Capability will therefore include governance literacy. People need to know what they may experiment with, what data may enter the system, what must remain local, when a prototype needs review and who inherits responsibility if it becomes operational.

For software engineers and technical leaders

The boundary may move towards higher-leverage work. Domain experts can bring clearer problem definitions and working hypotheses. Engineers remain essential where complexity, integration, security, reliability and lifecycle consequence rise. The valuable relationship is neither technical gatekeeping nor domain overreach. It is a more exact division of authority.

For policy and institutional governance

Procurement, risk and assurance frameworks often assume a clearer boundary between people who request software and people who build it. Agentic construction blurs that boundary. Institutions will need risk-tiered rules that attend to data, affected people, reversibility, persistence and dependency—not merely the occupational title of the person who initiated the build.

8. Intervention Options

There is no single responsible model. The appropriate intervention depends upon consequence, reversibility, data, integration and available review capacity.

Option	Suitable when	Trade-off
Open local experimentation	The work is low-consequence, reversible and does not involve sensitive data or operational dependency.	Fast learning and local agency; highest risk of sprawl, duplication and false confidence.
Bounded agent sandbox	A domain team can prototype inside explicit data, deployment, review and retention limits.	Balances access and control; requires thresholds, templates and someone able to review the result.
Domain–engineering pair	The artefact will affect other people, integrate with systems, persist operationally or carry material risk.	Stronger translation and assurance; higher coordination cost and slower iteration.
Defer, procure or stop	Regulation, security, cultural authority, complexity or stewardship burden exceeds available capability.	Foregoes speed and local control; may be the most responsible decision.

9. Emerging Directional Principles

Start with the domain decision, not the tool. Define the problem, authority, affected people and consequence before asking an agent to implement.
Make standards executable and contestable. Use examples, tests, schemas and rules, while preserving room to challenge what was formalised and what was lost.
Teach judgement through comparison and correction. Prompt fluency is insufficient without repeated practice judging quality against disciplinary standards.
Keep human gates where consequence changes. Escalate review as an artefact begins to affect people, data, systems or enduring organisational obligations.
Pair domain authority with engineering stewardship. Neither discipline should silently borrow the authority of the other.
Treat a working prototype as a question. Deployment begins evaluation. It does not conclude it.
Assign ownership before persistence. Every consequential tool needs a named maintainer, a review path, incident response and a retirement condition.

10. Watchlist

The interpretation should remain conditional. The following evidence could strengthen, weaken or materially redirect it.

Watchpoint	Would strengthen the interpretation	Would weaken or narrow it
Real-world agent studies	Durable gains for domain experts remain after review, integration and maintenance are counted.	Gains remain confined to bounded prototypes or disappear downstream.
Verification capability	Agents improve independent testing and failure discovery without circular self-confirmation.	Automated verification mainly compounds plausible error or automation bias.
Expertise distribution	Domain command continues to predict framing, correction and recovery.	Systems reliably compensate for weak domain understanding across consequential work.
Education evidence	Capability programmes improve evaluative judgement and transfer in agent-mediated work.	Training effects reduce to tool familiarity or generic confidence.
Organisational stewardship	Clear review thresholds, owners and retirement practices emerge for locally created tools.	Shadow software and incident cost grow faster than governance capacity.
Engineering boundary	Domain–engineering collaboration becomes more focused and higher leverage.	Technical debt, security and operations restore most of the previous distance.

11. Conclusion

The important change is not that people can ask an AI system to write code. It is that a person with a developed model of a domain can now move from intent to implementation through a much shorter loop.

That expands agency. It also exposes judgement. The person closest to the problem may be able to build more of the solution, but they must also decide what the solution is allowed to become, what evidence justifies confidence and when another form of expertise must take over.

Education therefore has a deeper task than adding agent tools to existing programmes. It must form people who can specify quality, test plausibility, recognise the limits of what they know, correct error and remain answerable for consequences. Those capabilities were always important. Agentic execution makes their absence faster, more visible and more expensive.

Software is becoming cheaper to create. Consequence is not.

12. References

Anthropic (2026). Agentic coding and persistent returns to expertise.

Bainbridge, L. (1983). Ironies of Automation. Automatica, 19(6), 775–779.

Becker, J., Rush, N., Barnes, B. & Rein, D. (2025). Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity.

Becker, J., Rush, N., Cunningham, T., Rein, D. & Mahamud, K. (2026). We are Changing our Developer Productivity Experiment Design.

Chai, S. H., Nicholson, B., Salijeni, G. & Sokolovskyy, L. (2025). Understanding the Impact of Generative AI on Professional Judgement.

DORA (2025). State of AI-assisted Software Development.

Evans, J. St. B. T. (1988). The knowledge elicitation problem: a psychological perspective. Behaviour & Information Technology, 7(2), 111–130.

Hatano, G. & Inagaki, K. (1986). Two Courses of Expertise.

Kalyuga, S., Ayres, P., Chandler, P. & Sweller, J. (2003). The Expertise Reversal Effect. Educational Psychologist, 38(1), 23–31.

Tai, J., Ajjawi, R., Boud, D., Dawson, P. & Panadero, E. (2018). Developing evaluative judgement: enabling students to make decisions about the quality of work. Higher Education, 76, 467–481.

Viljoen, A., Radić, M., Hein, A., Nguyen, J. & Krcmar, H. (2024). Governing Citizen Development to Address Low-Code Platform Challenges. MIS Quarterly Executive, 23(3), 305–324.

Smith, G. (2026). Visible Thinking Designer — public demonstration.

Internal case source: VTD — SIGNAL 005 Build Evidence Record. Repository-grounded project record used for bounded implementation claims; not a public effectiveness source.

13. Key Questions

Does this mean anyone can now build production software?

No. More people can create functioning prototypes and bounded tools. Production software adds demands around architecture, security, accessibility, reliability, integration, operations, maintenance and ownership.

What does “domain expertise becomes executable” mean?

It means that some domain knowledge can be translated more directly into software behaviour through prompts, examples, schemas, rules, tests and interface decisions. It does not mean that all tacit or situated expertise has been captured.

Is evaluative judgement just critical thinking with a new name?

No. Evaluative judgement is more precise and domain-specific: recognising quality, applying relevant standards, making a defensible decision and improving that judgement through repeated comparison and feedback.

What should education teach?

Alongside technical and AI fluency, education should cultivate problem framing, standards-based comparison, correction, adaptive expertise, responsible escalation and collaboration with technical specialists.

When should a domain expert involve an engineer?

As consequence rises: when a tool affects other people, handles sensitive data, integrates with systems, creates operational dependency or requires assurance beyond the builder’s competence.

What does the VTD case prove?

It demonstrates a governed mechanism for translating a developed educational model into a working prototype through a human–agent loop. It does not prove educational effectiveness, production readiness or general democratisation.

14. Continue Exploring

15. Subscribe

Signal Intelligence interprets structural changes across AI, capability, education, assessment, trust and organisational design. Subscribe to receive future briefings.

16. Tags

AI agents; human capability; evaluative judgement; adaptive expertise; domain expertise; professional formation; software stewardship; citizen development; education and AI; Signal Intelligence