To Code or Not to Code

For eighty years, when we have wanted a computer to make a decision, we have written down in advance how that decision was to be made. We call this “coding”, and most business software is still built that way, whatever the problem. Much of it need not be.

Every project starts with a choice that nobody puts into words: whether to write code at all. Most of the time the answer is assumed, and the business pays for that assumption every time it changes its mind.

This post goes with Making Decisions Without Code, an illustrated explanation on the SapienTronic AI website, which shows the alternative at work: an animated walker on a mountain, making fifteen decisions as the facts and her aims change, with the reasons for each one beside it.

Five weeks to change a decision

Suppose a company decides that, from today, late deliveries matter more than cheap ones. Nothing about the world has changed. The lorries, the roads and the customers are what they were yesterday. What has changed is a judgement about what counts as a good outcome. That judgement is a manager’s to make; it is her job.

In most companies, that decision now sets off a familiar (and assumed necessary) chain of events. It goes to a business analyst, who writes it up as a requirement. The requirement goes to a developer, who hunts through the code for the places where the old judgement is built in, changes them, and hopes to have found them all. A tester checks the change. A release is scheduled.

Take the manager’s decision about late deliveries and follow it through the chain, week by week. Every step of it is standard practice, and anyone who has worked in a company will recognise each one.

Week one. The manager explains what she wants in a meeting. The business analyst takes notes and goes away to write a requirement. The requirement comes back three pages long, in language that is neither hers nor the developer’s, with a diagram. She reads it, cannot quite see her decision in it, and signs it off anyway, because the alternative is another meeting.
Week two. The requirement joins a backlog of forty others. It is estimated, prioritised and argued about. The developer who finally picks it up has never met the manager and reads the requirement as a developer reads, looking for what to change. He finds the place in the code where deliveries are scored, and then a second place, and then a third that somebody added in 2019 for a customer who has since left. He changes two of them.
Week three. The tester tests what the requirement says, which is not quite what the manager meant, and passes it. The change waits for the fortnightly release.
Week five. The release goes out. The program now decides the way the manager wanted it to five weeks ago. Three days later the third place in the code, the one nobody found, produces a delivery plan that makes no sense to anyone, and a ticket is raised. Meanwhile the manager has thought again: late deliveries matter more than cheap ones, yes, but not for the two customers who agreed to slower delivery in return for a lower price. That is a new requirement. Back to week one.

Every link in that chain is a person doing their job well. The analyst was there to translate, the developer to find the code, the tester to check, the release manager to keep the system stable. The pain comes from the chain itself: one manager’s decision took four people and five weeks to reach the system, it arrived slightly wrong, and her next decision is already waiting.

Worst of all is the change that never enters the chain: the one the manager never asks for, because she knows what asking costs, so she lives with the old behaviour instead. Multiply that by every judgement in the business that can change.

And getting that project through the organisation can be a nightmarish exercise. Where every change of judgement is a project, a layer of people grows up to manage the projects: product owners to hold the backlog, project managers to track it, a change board to approve it, a steering committee to prioritise what the change board approved, status reports to tell the manager where her change has got to. Managers spend their time chasing last quarter’s decisions into the system. Everyone involved recognises the feeling: the manager who knows what she wants, can say it in a sentence, and cannot have it for five weeks and three meetings.

Why did a change of mind become a project? Because what counts as a good outcome was written into the program as code, and only the developers can change the code.

This post puts the question to anyone who commissions software: do you need to code this at all? The alternatives are set out below, and the last of them is the one shown at work in Making Decisions Without Code on the SapienTronic AI website.

Eighty years of procedural programming

The first electronic computers could do nothing until someone had set out every step for them by hand, on switches and cables. The languages that came later made the steps easier to write without changing the idea.

Most programs are written as a list of instructions carried out one after another: check this first; if it comes out one way do that, if the other way try the next thing. C, C++, Java and Python are all built for writing in this form, and the habit is now so strong that writing a program and writing out a list of steps look like the same thing.

Three decisions in every such program belong to the programmer, and the person who will live with the decisions never sees them.

Which questions exist. The program answers the questions it was written to answer. Ask it one nobody foresaw and it needs more code, or it answers without saying that the question lay outside what it was built for.
What counts as a good answer. The threshold, the weight, the scoring rule: decided at a desk, built in, and invisible in the answer. The program says best without saying by what measure or who chose it.
What the answer says about itself. Nothing it was not written to say. It will not tell you that it assumed the bridge was open, or that it would have chosen differently had the stakes been higher.

None of this is a fault in programmers; it comes with the form. A short set of rules becomes a long procedure that grows by cases, because every situation the programmer did not foresee becomes a new branch, and every new branch has to be fitted among the branches already there.

Five ways to tell a computer what to do

Writing out the steps is only one way of getting a computer to do something. There are about five, and they differ in what the person has to write down, and what the computer is left to work out:

Instructions. The programmer writes every step, and the computer follows them in order. The computer works nothing out for itself.
Rules. The programmer writes if this, then that, and an engine applies the rules to each case as it arrives. The programmer still decides which rule wins when two disagree. Business-rules engines and the expert systems of the 1980s work this way.
Goals. The modeller states what is wanted and the limits on it, and a solver searches for a way to get there. The search is general, so it is written once and used for every problem. Linear and integer programming, constraint solvers, planners, SAT and SMT solvers and answer-set programming all work this way. The modeller still decides how the problem is put to the solver, and which number it is to make as small or as large as possible.
Words. Anyone asks a question in plain words, and a language model answers in plain words. Nothing has to be written down in advance, but nothing checks how the answer was reached.
A described world. The world is written down once, as it is, together with a statement of what counts as a good outcome, and a decision engine answers questions of the kinds it supports, with no new procedure written for any of them. We come to this one last.

Further down the list, the person writes less about how to decide and more about what is the case. For the manager, the difference lies in where her judgement about late deliveries is kept. With instructions or rules, it is written into the steps or the rules themselves, and only the people who wrote them can change it. Further down the list, it can be stated on its own, where she can change it herself.

Most people assume the list is also the order of invention, with code first and the rest as recent experiments. In fact the goal-oriented methods came early. George Dantzig devised linear programming for the US Air Force in 1947. Prolog, the first widely used logic programming language, was born in Marseille in 1972, and SQL, which describes the answer wanted and leaves the database to find it, was proposed at IBM in 1974. Rules had their boom in the 1980s, with expert systems. The best known, DEC’s XCON, configured VAX computers from rules; it went into use in 1980, and had grown to 6,200 rules by 1987 and more than 10,000 by 1989.

By the early 1990s the expert-systems boom had faded, and ordinary software was being written almost entirely as instructions. This was for four primary reasons:

Rule bases grew brittle. Several thousand hand-written rules were hard to keep right as the world they described changed. Of XCON’s 6,200 rules in 1987, about half changed every year, and its maintainers found that the difficulty grew faster than the number of rules.
The search had to be steered by hand after all. A Prolog programmer who wanted an answer in reasonable time often ended up controlling the order of the search, so the promise of saying what is wanted without saying how was kept only in part.
The economics ran the other way. Cheap processors ran C well; tools, teaching and hiring grew up around procedural languages; and a procedure can be debugged by stepping through it.
Much of programming really is a sequence of actions, such as reading a file or drawing a screen, and for those a list of instructions is the right form.

The other methods carried on in particular uses, chosen by people who knew they existed. Most developers use SQL every week (58.6 per cent had used it in the past year in the 2025 Stack Overflow survey). Constraint solvers schedule airline crews, SAT solvers check chip designs, and answer-set programming configures products. In May 1999 a planner, NASA’s Remote Agent, took command of the Deep Space 1 spacecraft and met every one of its objectives. Almost everything else is written as instructions.

Death by lines of code

As a result, problems that are really a set of rules or conditions are written as procedures anyway, usually without anyone deciding to. An eligibility check, a pricing rule, a staff rota or a compliance test begins as a few statements about what is the case and what follows from it. Written as instructions, it becomes a procedure that grows a new branch for every case nobody foresaw. The manager’s judgement about late deliveries is spread through those branches, which is why the developer in week two found it in three places and changed only two.

That code has to be kept up for as long as the business runs on it, and most of its cost comes after it is written. Robert Glass’s review of the evidence put maintenance at about 60 per cent of the cost of software, and found that most of that maintenance was enhancement: changing what the program does as the business changes its mind. In Stripe’s 2018 survey of more than a thousand developers, 17 hours of a 41-hour week went on maintenance and technical debt.

Then there is the waiting. Once a developer has changed the code, the change still has to reach the system people actually use, which software teams call production. On the way it is reviewed by another developer, tested, bundled with other changes into a release, approved and installed. The time from the moment the code is changed to the moment the change is live is called the lead time for changes.

Google’s DORA research programme has measured that lead time across thousands of organisations every year for a decade. Its 2024 report sorts organisations into four groups:

Elite: a change is live in under a day. Fewer than one organisation in five works this fast.
High: between a day and a week.
Medium: between a week and a month.
Low: between one and six months.

These figures start counting only once the code has been changed. They leave out the meeting, the requirement, the backlog and the developer’s search through the code. Add those back, and the manager’s five weeks from decision to delivery would be good going for most organisations. In the slower half, her change of mind could take a quarter or more to reach the people it was meant for, and by then the business may well have changed its mind again.

The industry knows this is a problem, and two kinds of tool have grown up to work around it:

Business-rules engines take the rules out of the code and keep them in a separate place, where they can be changed without a full software release. They help where the judgement can be written as a rule, but someone still has to write it in the engine’s own language, and the rest of the system is still coded around it.
Low-code and no-code tools let people build applications by arranging ready-made pieces on a screen instead of writing code; Gartner predicted that by 2025 seven in ten new business applications would be built this way. They make simple applications faster to build. But the judgement about what counts as a good outcome is still built into whatever was assembled, by whoever assembled it, and changing it still means going back and rebuilding.

Both make the chain shorter or cheaper. Neither removes it, because in both the judgement still ends up fixed inside something built in advance, and somebody other than the manager has to go in and change it.

“A Java programmer”

There is a second reason the industry defaults to code, and it is about people: the approach has usually been decided by what the team already knows how to write.

Until very recently, a problem was solved in whatever language the people in the room could write. We hired “a Java programmer” or “a Python programmer”, and so the problem was expressed in Java or Python. A developer who has written SQL for years may never have met a constraint solver, a planner or a logic program, and would not think of a staff rota as something a solver could work out. The alternatives never came up, because nobody in the room could write them.

The way developers are hired shows this. There are about 47 million developers in the world, 36 million of them professionals, and the job is advertised by language, not by kind of problem: in IEEE Spectrum’s count of US job postings, 30 per cent asked for Java by name, 26 per cent for JavaScript and 17 per cent for Python. Very few ask for someone who can tell which kind of problem needs which kind of tool.

AI assistants loosen that limit: you are much less confined to the languages you happen to know. Assistants are now widely used by developers (in the 2025 Stack Overflow survey, 84 per cent used one or planned to), and an assistant knows the solvers, the rules engines, the query languages and the planners, and how each is written. That makes it easier to choose a solver, a rules engine or a language because it suits the problem, and not because the team already knows it. The team still has to understand and check what the assistant writes.

So it is worth knowing what is on the menu.

Alternative approaches to procedural code

Here, briefly, is what each of the main alternatives does. Some are commonplace, some more exotic:

Shortest-path search: you write down a map, as places and the cost of getting between them, and a general method finds the cheapest way through. Dijkstra’s algorithm of 1959 is the best known, and satellite navigation, internet routing and parcel delivery all rely on methods of this kind.
Linear and integer programming: you write down the quantities that can vary (lorries, hours, stock), the limits on them, and one number to make as large or as small as possible, such as cost. A solver finds the best values within the limits; “integer” means some must be whole numbers, since you cannot send half a lorry.
Constraint programming: you write down the conditions a solution must meet (no nurse works two night shifts in a row; every class needs a room big enough), and a solver searches for an arrangement that meets them all, or shows that none can. Rotas, timetables and product configuration are its natural work.
SAT and SMT solvers: the problem is written as a large set of yes-or-no conditions, and the solver says whether they can all be true at once, and if so how. Chip makers use them to prove designs correct, and package managers to work out which versions of software can be installed together.
Planners: you write down where things start, where they should end, and the actions available, each with what it needs and what it changes, and a planner works out a sequence of actions that reaches the goal. Robots, spacecraft and warehouses use them.
Language models: you ask in plain words and the answer comes back in plain words. They take on questions none of the others can, including questions about people, and in the tests in our recent paper (described below) a language model was at least as good as the decision engine at recognising when such a question was not settled. Their weakness is that the explanation is more text from the same model, so nothing checks that the answer was reached the way the explanation says.

Business-rules engines and query languages such as SQL, described above, complete the list.

Logic programming and answer-set programming

This is the least known of the approaches, and it is built for something people do all the time: reasoning from rules that have exceptions.

In logic programming, you write down facts and rules, and the computer works out what follows. The best-known language, Prolog, comes from Marseille in 1972. A fact is something like Alice is Bob’s mother. A rule is something like a person’s grandmother is the mother of one of their parents. Ask “who is Carol’s grandmother?” and the computer works it out from the facts and the rules. Nobody writes the steps for finding a grandmother.

Answer-set programming is the modern descendant, developed in the 1990s. Its special strength is rules with exceptions, which is how most real knowledge is held. Take birds fly, unless they are penguins. In ordinary logic, that rule causes trouble: once you have concluded that a bird flies, learning that it is a penguin ought to undo the conclusion, and ordinary logic cannot undo anything. Answer-set programming can. It reads the rule as a bird flies unless there is reason to think it is a penguin, and when the reason turns up, the conclusion goes. Given a set of such rules, the solver finds every consistent picture of the world they allow (each one is called an answer set), and from those it can say what must be true, what might be true, and what cannot be.

It is very useful, and far too little used. It is used in industry more than most programmers realise: to configure complex products, to plan, to schedule staff, and to solve the puzzle of which software packages can be installed together. In the paper’s tests, a carefully written answer-set program answered every one of 223 questions about people correctly.

It has one difficulty that matters here. Every rule with an exception has to be written in a particular way, and the person writing it has to decide what “unless” means: unless it is known to be a penguin, or unless it might be one? Does the absence of a conclusion mean “no”, or “we don’t know”? Those choices change the answers. In the paper’s tests, two reasonable ways of writing down the same knowledge disagreed on 119 of the 223 questions.

It sits halfway between procedural code and MINOS. Like MINOS, and unlike procedural code, you write down what is known (the facts, the rules and their exceptions) and a general solver works out what follows; nobody writes the steps. Like procedural code, and unlike MINOS, a person still has to decide how each piece of knowledge is to be read, and that decision is built into the program.

Every one of these is a real advance on writing the steps by hand, and with an assistant to hand, every one is within reach of a team that has only ever written Python. Choose the one that fits the problem.

But in every one of them, something is still decided in advance by someone other than the person whose decision it is: the number to minimise, the order in which rules fire, how an exception is read, what the model absorbed in training. And none of them gives an answer that says, as part of the answer, what it rests on.

Describing the world in MINOS

Answer-set programming took us most of the way from writing steps to describing a world. The last step is the approach our recent paper proposes. It writes down two things, and no program: a description of the world, and a statement of what kind of outcome counts as a good one. The description is written in the terms of MINOS, which describes any system as what drives it, what constrains it, and the system’s own way of holding the two together. A general decision engine, programmed once and the same for every world, takes the description, the statement and a question, works out the answer and checks it.

Here is the walker’s world as it is written down. The paper gives these lines in words, as here, and does not publish the form they are written in.

A law of the world: the cliff. No path at all, however much reaching the hut matters.
A rule: No entry on the field, at a price of 20. The path is there; taking it breaks the rule, and the answer will say so.
A hazard: the scree, which holds back 0.12 of her effort for each stretch crossed. Slope, water and loose ground all count the same way, so nobody chooses weights.
An unknown: whether the bridge is open.
A lesson from experience: the farmer lets walkers through in a storm. Defeated by lambing. Well supported by what others have seen. Advice only.
A lesson from experience: walkers new to the mountains turn back when the light goes. Defeated when the hut is the nearer shelter. Well supported. Advice only.
A report: she is new to the mountains. Said by the passer-by; nobody has checked.

And the statement of what counts as a good outcome, written by the walker herself:

The stake: how much reaching the hut is worth to her (100 on an ordinary day; more in a rescue), and how fast that falls with delay (faster in a storm).
The standard: she arrives, and she comes to no fatal harm, whichever way the ledge on the field path turns out.

Nothing is written about how to choose a route, in what order to weigh the obstacles, what to do if the bridge is closed, or how to read an exception. The farmer’s habit is written as a habit, with its exception and how well established it is, not as a certainty or a probability. The passer-by’s word is written as hearsay. The bridge is written as unknown. And the measure of a good outcome is written by the person whose goal it is, separately from the world.

Two things set it apart from everything on the list above:

The measure of a good outcome is set by the person whose goal it is, and named in every answer.
Every answer says where it stands: whether the question is settled, which lessons and reports it rests on (as far as the engine finds them), what remains unknown, and what would settle it.

The paper, Decisions Nobody Anticipated (Zenodo), tests this on one everyday world: a walker trying to reach a mountain hut before dark, with a cliff, a field with a No entry sign, a scree slope, a footbridge that may be closed, a farmer who usually lets walkers through in a storm unless his ewes are lambing, and a passer-by who says she is new to the mountains. Fifteen questions were put to one description of that world, with no code written for any of them: which way to go on a calm afternoon, when arriving matters less, when a storm is coming, and in a rescue; whether she may cross the field; whether she is likely to turn back; whether it is worth a detour to ask the farmer; and whether the best route meets a standard she set for herself, that she arrives and comes to no fatal harm.

You can watch those fifteen decisions being made, with the reasons beside each one, in Making Decisions Without Code on the SapienTronic AI website. Three things to look for as you do:

The decision engine never changes. Sometimes the facts change: the storm comes, the bridge closes. Sometimes what counts as a good outcome changes: arriving matters more, or she adds that she must come to no fatal harm. Either way the decisions follow, with no code touched. That is the manager and her late deliveries, done right: she changes the declared measure herself, and the engine applies it to every decision it supports, with no requirement to write and no procedure to rewrite.
Each answer says what it rests on, as far as the engine finds it. When the answer depends on the passer-by’s unchecked word, it says so, and it says that checking his word would settle the question. When the farmer’s usual practice is only advice and the rule on his sign binds, it keeps the two apart. When there is no route at all, it names what closes every route and what would open one.
The best route and a good route are kept apart. In the last question the best route crosses a ledge nobody has checked. It fails her standard, and the engine says which part of her standard fails and in which case, then gives the route that meets it whichever way the ledge turns out.

What the tests showed:

Questions nobody wrote code for. Language-model agents that had never seen the world wrote new questions about it afterwards. The one description, unchanged, answered or rightly declined 25 of the first 40 (21 under a stricter count, against 20 for carefully written answer-set programs) and 26 of the second 40, where the answer-set programs managed 33.
A standard met where the best route fails. On worlds built to be hard, the decision engine found a route meeting the walker’s standard on 25 of 30. Taking the best route under each way the unknowns could turn out met it on only 6 of 26.
Grounds that are tested, not narrated. What an answer says it rests on is checked by taking each lesson and report away and asking again.

The paper gives every figure, including where the engine fell short.

So: to code, or not to code?

Whether to code depends on what kind of problem you are solving:

A sequence of actions (read a file, send a message, move the money): code it. Instructions are the right form.
Routes, schedules, rotas, plans and configurations: describe the problem and its limits, and hand it to a shortest-path search, a solver or a planner.
Eligibility, pricing and approval rules: write the rules, and let a rules engine or a logic program apply them.
Questions about recorded facts: a query. Questions in plain words, drafts and summaries: a language model, with a person checking what matters.
Problems that turn on what people usually do, on what has been reported, and on a judgement about what counts as a good outcome that will change: describe the world, state what counts as good, and let the person whose judgement it is change it when they change their mind.

The industry answered “to code” for eighty years. The alternatives existed, but they sat in niches and few people could use them. Neither is true any longer. The question to ask at the start of the next project is no longer which language to write it in, but whether to write it at all.

Where to read more

Making Decisions Without Code, on the SapienTronic AI website, explains the fifth way in everyday terms, with the animated walk. The paper behind it, Decisions Nobody Anticipated: Running and Checking Declared Knowledge with a General Reasoning Engine, is on Zenodo. The earlier posts introduced SapienTronic AI (Introducing Minotaur), showed it reasoning without a language model (the deep dive), doing Aristotle’s logic by letting a system settle (Logic Without Rules), and going head to head with Claude (the showdown).

To code or not to code, that is the question