Use plain code when the right answer is fixed, exact, or already stored somewhere: calculations, lookups, rules, and boilerplate text. Use AI when the input is unstructured language and the output needs judgment, such as drafting, summarizing, or classifying messages, and when a person can check the result. Most good features combine the two.
The rule we follow in our own products is short: boilerplate must never pass through a model. Judgment tasks can.
It came out of building the document engine in CaseCobra, which produces court documents for a criminal defense firm. Parts of every document are fixed. Parts depend on the facts. Treating those two kinds of text the same way, in either direction, causes problems. Sending fixed text through a model risks changing words that must not change. Writing code to handle open-ended language produces a brittle pile of special cases.
Choosing between the two is a design decision that should be made for each step of a process, not once for the whole product.
What is the difference between AI and regular code?
Regular code follows explicit rules and gives the same output for the same input every time. A language model generates likely text from patterns, handles input nobody anticipated, and can give different output on different runs. Code is exact and rigid. A model is flexible and can be wrong in ways that read well.
That difference decides everything else. Code can be tested once and trusted afterward. If it adds two numbers correctly today, it will tomorrow. A model's output has to be treated as a draft, because a fluent sentence and a correct sentence look the same on the page.
Code is also cheap to run and fast. A model call takes longer and is billed by the amount of text processed. That alone is a reason not to use a model for something a few lines of code can do.
When is plain code the better choice?
Plain code is the better choice whenever the answer is determined by rules or already exists as data. That covers arithmetic, dates, totals, permissions, lookups, formatting, validation, and any text that must be word for word the same each time. Code is cheaper, faster, testable, and does not surprise you.
Some examples from our own work:
- Captions and standard language. In CaseCobra, the caption, parties, and judge are filled in from the case record by code, and standard wording is stored as templates.
- Comparisons. Our Firm Mail Intake tool checks any court date mentioned in a message against the calendar. Once a date has been found, comparing it to a calendar is a job for code: the entry is there or it is not.
- Money. Totals, fees, and payouts are calculations. They belong in code and in the database.
If you can write the rule down completely, write it as code.
When is AI the better choice?
AI is the better choice when the input is unstructured language and the useful output depends on understanding it: drafting text from facts, summarizing long documents, sorting messages by what they are about, or answering a question asked in someone's own words. Rules written by hand cannot keep up with that variety.
The test we use is whether a competent person would need to read and think to do the task. Writing the middle paragraphs of a motion from the facts of a case takes judgment. So does pulling a timeline out of a stack of records. Those are the places a model saves real time.
There is a condition attached. Someone has to be able to check the result, and the design has to make checking easy. We cover where that person sits in human in the loop AI.
How do you decide between AI and code for a task?
Decide by asking whether the correct output can be fully specified in advance. If it can, use code. If it cannot, and the input is language, use a model with a review step. If it cannot and a wrong answer is unacceptable with no reviewer available, do not automate that step.
| Task | Use | Why |
|---|---|---|
| Filling a name, date, or case number into a document | Code | The value already exists in the record |
| Standard paragraphs and legal boilerplate | Code | Must be identical every time |
| Totals, taxes, fees, date arithmetic | Code | Exact answers, easy to test |
| Checking a date against a calendar | Code | A direct comparison |
| Who is allowed to see or change something | Code | Security rules cannot be probabilistic |
| Drafting paragraphs that depend on the facts | AI, reviewed | Wording varies with every case |
| Summarizing long records | AI, reviewed | Requires reading, not matching |
| Sorting free-text messages by topic | AI, spot checked | Too many phrasings for fixed rules |
| Answering visitor questions in a chat | AI, with human handoff | Questions arrive in any form |
| A final decision with legal or financial effect | A person | Accountability does not transfer |
How do AI and code work together in one feature?
In a well built feature, code does the gathering, checking, and assembling, and the model handles one narrow step in the middle. Code fetches the data, passes the model only what it needs, validates what comes back, and places it into a fixed structure for a person to review.
Our document engine works this way. Code finds the case and pulls the facts. Code lays out the document and inserts the fixed language. The model drafts only the fact-dependent paragraphs. Code puts the result into the template, and an attorney reviews it before it is used.
This arrangement also limits what can go wrong. The model cannot alter the caption because it never sees the caption. It cannot miscalculate a total because it is never asked for one. Narrowing what the model touches is one of the most effective ways to reduce AI hallucinations.
Frequently asked questions
Is AI cheaper than writing code?
For a single task that code can do, no. Code is written once and costs almost nothing to run. A model is billed on every call. AI is worth its cost when the alternative is a person spending time reading or drafting.
Can AI write the code instead?
Models can help developers write and review code. That is different from having a model do the task at run time. The finished code still behaves like code: same input, same output.
Why not let the model handle everything and fix mistakes later?
Because mistakes in fixed text and numbers are hard to spot and expensive when missed. A reviewer reading a generated document should only have to check the parts that could vary, not proofread every word of the boilerplate again.
Can a model do math reliably?
Do not depend on it. A language model predicts text and can produce a wrong figure that looks right. If a number matters, calculate it in code and hand the model the finished result to describe.
What if I am not sure which one a task needs?
Try writing the rule in plain sentences. If you can finish it, it is code. If you keep adding exceptions, a model may fit.
If you have a process and cannot tell which parts are which, describe it to us and we will mark it up.