Someone answers the same operational question every week. Which records need attention? Does this request meet the requirements? What should happen next? Eventually the answer begins to feel like a program waiting to be written.
Sometimes it is. Sometimes the apparent repetition hides judgment, changing conditions, or exceptions that only an experienced person recognizes.
When should repeated knowledge become maintained software? When the task is stable enough to specify, valuable enough to repeat, and bounded enough to evaluate and maintain. The useful transition is from a demonstrated practice to an explicit process, then to software whose behavior and obligations someone can own.
AI can make implementation faster. It does not remove the need to understand the rule, preserve exceptions, verify outputs, or decide who will keep the system working after the prototype succeeds once.
Repetition is a signal, not a specification
A repeated task suggests an opportunity because the cost of discovering and implementing a process can be spread across later uses. That reasoning depends on the uses actually recurring.
If a task happens twice and then disappears, building a maintained application may cost more than doing it manually. If it happens frequently but changes every time, the software may require continuing interpretation rather than simple rules.
Begin by describing the work as it is performed. Identify the inputs, desired output, important constraints, ordinary decisions, and exceptional cases. Ask what the experienced person notices before choosing an action.
A label such as “process invoices” hides several tasks: extract fields, match orders, identify discrepancies, apply accounting rules, seek approval, and record a result. Some can be specified mechanically. Others depend on authority or missing information.
The first deliverable may therefore be a clearer process rather than code. That is useful progress. It reveals what can be standardized and what should remain a human decision.
Separate stable rules from interpretation
A stable rule can be expressed in a form that produces a checkable result. A total should equal its component amounts. A required field should be present. An approved category should belong to a defined list.
Interpretation handles ambiguity, context, and uncertain meaning. A customer description may need classification. A document may need summarizing. A request may be incomplete in a way that cannot be captured by one fixed field check.
A good design lets these jobs use different methods. Deterministic code can handle arithmetic and explicit requirements. A model can assist interpretation within a bounded role. A person can judge consequential exceptions or authorize commitments.
Combining every task into a single prompt can make the process harder to inspect. The output may be fluent while the arithmetic is wrong or the authorization is missing.
The permission architecture governs actions. Knowledge codification should also make the reason for each decision visible enough to evaluate. A system that produces the right answer for an unexplained reason may be useful experimentally, but it is harder to maintain responsibly.
Start with demonstrated practice
Before translating knowledge into software, look for evidence that the practice is useful. A familiar answer repeated confidently is not necessarily a sound method.
The learning ledger preserves the conditions under which a process helped, the evidence supporting it, and the cases where it failed. Those records provide a better starting point than an attractive description of how the process ought to work.
Suppose a business uses a checklist to prepare customer estimates. The useful question is whether the checklist reduces missing requirements or improves delivery under the relevant conditions. A software version should preserve that contribution rather than merely reproduce the checklist’s appearance.
If the practice has unresolved weaknesses, codification can amplify them. The software makes the method easier to repeat and potentially harder to question because its output appears standardized.
The appropriate next step might be another bounded trial or a simpler clarification of the process. Code should follow enough understanding to support the intended use, rather than substitute for that understanding.
The rule should include its boundary
A rule without a scope can become misleading. “Approve requests below this amount” may ignore the type of request, the recipient, the cumulative commitment, or a required authorization.
Write the conditions under which the rule applies and the conditions that route the case elsewhere. A software system needs a behavior for missing, invalid, conflicting, and out-of-scope inputs.
For a hypothetical estimate tool, ordinary cases might use known service categories and complete requirements. Unusual materials, incomplete information, or a disputed customer instruction might require review. The tool should identify that state rather than invent an ordinary answer.
A boundary also helps the user understand the output. “Draft estimate requiring review because delivery requirements are missing” is more useful than a precise-looking number based on an unstated assumption.
Codification does not mean eliminating judgment. It means deciding which judgment has been converted into an explicit rule, which remains interpretive, and which must remain with a qualified person.
Choose the simplest implementation that fits
The next step could be a spreadsheet formula, a script, a form, a checklist with validation, or a small application. A conversational model is only one possible component.
If a calculation is stable and inputs are structured, ordinary software may be simpler to evaluate and cheaper to operate. If language interpretation is necessary, a model can assist that part while deterministic checks govern the rest.
Anthropic’s December 2024 engineering guidance distinguishes fixed-path workflows from systems in which a model dynamically directs its own process. The page now warns that its tooling discussion has changed. The architectural distinction remains useful; it is not a recommendation to copy obsolete product details. Building effective agents.
The design question is whether dynamic choice is needed for this task. A flexible agent can add cost, latency, and evaluation burden when a fixed process already fits. Simplicity makes responsibility and failure behavior easier to understand.
Avoid adding a service merely because it is available. Every added dependency creates another access rule, bill, version, and possible point of failure.
A prototype is not a maintained asset
A prototype demonstrates something under limited conditions. A maintained asset must continue to serve its purpose as inputs, users, dependencies, and obligations change.
The gap can include packaging, access control, error handling, documentation, tests, monitoring, backups, and support. Not every tool needs an elaborate production system, but every relied-upon tool needs someone who understands what it does and what happens when it stops.
A small internal script might require a clear instruction, a known environment, representative checks, and a manual fallback. A customer-facing service may need much more, because other people rely on availability and correct results.
AI-generated code does not erase those obligations. It can reduce the cost of preparing an implementation while leaving the cost of ownership substantial.
The ownership chapter examines control and retained benefit. A useful software asset is something the owner can operate, inspect, change, and maintain within the applicable rights and constraints.
Use examples to make the specification concrete
A plain-language rule can leave important interpretations unstated. Examples make those interpretations visible.
Include ordinary cases, edge cases, invalid inputs, and cases that should be refused or escalated. State the expected result independently of the proposed implementation.
For a record-validation tool, examples might include a complete record, a missing field, a contradictory date, a duplicate identifier, and an input outside the permitted category. For an estimate tool, examples might include an unusual requirement that must not be priced automatically.
Preserve difficult cases discovered during use. They become evidence about the specification as well as the code. A failure may reveal that the implementation is wrong, that the rule is incomplete, or that the task was misclassified as routine.
The tests should express the intended behavior rather than mirror every line of the implementation. A test that merely reproduces the same assumption can pass while the underlying requirement remains unmet.
Evaluate the whole task
A function can work while the overall workflow fails. A parser may extract fields correctly but place the result where nobody sees it. A report may be accurate but arrive too late. A draft may omit the uncertainty a reviewer needs.
Evaluate the system against the user-facing job. Include input acquisition, interpretation, review, correction, output handling, and maintenance where relevant.
If the purpose is to save time, compare complete work under suitable conditions. If the purpose is to improve quality, define the quality standard and inspect meaningful failures. If the purpose is to create a commercial offer, technical success alone does not establish demand.
The service-first software business concerns that commercial evolution. This chapter focuses on the prior engineering judgment: whether repeated knowledge has become a reliable maintained process at all.
Keep the claim local when the evaluation is local. A tool that helps one familiar workflow has not thereby proved that it works for every organization with a similar label.
Maintenance is part of the economics
A hypothetical process used twenty times each month might save ten minutes per use. That is about 200 minutes of potential monthly capacity before maintenance, review, and correction. It is not automatically 200 minutes of realized freedom or a cash saving.
If maintaining the tool takes four hours each month, the time case may be weak unless quality or another benefit justifies it. If the saved task time enables a useful change elsewhere, the case may improve. The arithmetic is illustrative, not an observed result.
Also account for setup effort, hosting, model use, access administration, and the cost of failures. A tool that is cheap to generate and expensive to supervise may not be a good asset.
The maintenance estimate should include changes to the underlying knowledge. Prices, requirements, sources, and rules can change even when the code remains untouched. A correct implementation of an obsolete rule is still a problem.
The profitability chapter develops the financial accounting. Here the practical rule is to compare the full burden of ownership with the actual recurring benefit.
Design a path for rule changes
Someone should own changes to the specification. When a requirement changes, identify which code, examples, documentation, and permissions depend on it.
Version the rule and the implementation where practical. A result produced under an old rule should remain distinguishable from one produced under the new rule. This can matter when a customer asks why two similar requests received different treatment.
Changes should also trigger relevant evaluation. A new model or data format can affect behavior without an obvious change in the interface. A new customer group may expose cases absent from the original examples.
Do not let an AI assistant silently rewrite the operational rule because it found a more elegant implementation. Improving code and changing the policy it expresses are different actions and may require different authority.
The maintenance process should preserve that distinction. It makes software changes reviewable and prevents an implementation detail from becoming an unnoticed business decision.
Failure should leave a usable state
A maintained tool needs to communicate failure honestly. Missing information, unavailable dependencies, and uncertain completion should have understandable outcomes.
If a tool cannot read its input, it should not produce a normal-looking answer based on an empty record. If it prepared a draft but failed to save it, the status should distinguish those events. If it attempted an external update and cannot verify completion, it should not confidently claim success.
A fallback can be manual work, a delayed response, a narrower result, or a pause. The choice depends on the consequence and obligations. Continuing with guessed values is rarely a neutral default when the result affects someone else.
The owner should know how to return to the prior process. A tool becomes more useful when dependence on it is deliberate and reversible where practical.
Stopping does not remove existing promises. If customers or colleagues rely on the output, they need an understandable transition rather than a disappearing interface.
Portability protects retained knowledge
The useful knowledge should not exist only inside one provider account or one unexamined conversation. Keep the specification and important evaluation examples in a form the owner can recover appropriately. Document the data inputs and outputs so a future change of tool does not require reconstructing the entire process from memory.
Portability is not simply downloading everything. Exports can contain confidential information, lack required permissions, or omit the relationships needed to interpret a record. Retain what is lawful, useful, and necessary, with its context.
A small handoff exercise can reveal dependence. Could another competent person explain the rule, run representative cases, and identify what needs review? Could they tell which version is current and where authority comes from? The exercise is proposed; it does not establish universal maintainability.
If the answer is no, improve the documentation or simplify the process before making others depend on it. Software that works only when its original author is available may still be useful privately. It should not be presented as a durable independent asset without acknowledging that dependence.
The strongest objection: perhaps the knowledge should remain human
Some knowledge is difficult to codify because it depends on relationships, context, tacit skill, or moral judgment. Attempting to force it into software can strip away the conditions that made it useful.
A skilled negotiator might recognize that a technically available option would damage a relationship. A teacher might see that a student’s confusion is different from what the test score suggests. A service provider might know that a customer’s unusual request requires a conversation rather than a category.
Software can still assist these people. It can prepare records, check mechanical conditions, and make options visible. The appropriate boundary may be support rather than substitution.
The decision to codify should therefore ask what will be lost as well as what becomes faster. If the essential knowledge cannot yet be expressed or evaluated reliably, retain the human decision and automate the surrounding preparation.
That is a useful outcome, not an incomplete attempt to reach full autonomy.
AI Leverage in Practice
What changed: drafting code and preparing implementations can be more accessible. The bottleneck can shift toward understanding the rule, evaluating its scope, and maintaining the resulting tool.
What you can do today: choose one recurring question. Write its inputs, output, rule, exceptions, and maintenance owner. Check demonstrated usefulness. Build the simplest implementation and evaluate it against independent examples, including cases it should decline.
What may come later: stronger systems may translate more knowledge into functioning code. That should expand opportunities for useful tools while leaving scope, maintenance, authority, and consequence visible.
Retain a process you can keep useful
Repeated knowledge becomes software worth owning when the underlying practice is sound, the rule is explicit, the boundary is clear, and maintenance is feasible.
Code is one part of that asset. The specification, evidence, examples, permissions, and responsible owner make it dependable enough to reuse.
The complete Age of AI Leverage series connects codification to learning, commerce, and governance. Explore the wider AI section for related practical work.
Sources
- Anthropic, Building Effective Agents, December 2024, architectural context; its own page notes that tooling has changed.
- Anthropic, Managed Agents Architecture, April 2026, further current vendor-specific engineering context.
- NIST, AI Risk Management Framework, further context for risk-aware design and evaluation.
- Examples and time calculations are hypothetical. No deployed software experiment, customer demand result, or achieved income is claimed.
Loading comments…