Demarcate deliberate and incidental decisions

Posted: 2026-03-03

Types of decisions

In the face of generative AI’s growing role in the field of software engineering, an important property for the maintainability of a software system is the ability to distinguish deliberate decisions –those representing the user’s core intent and constraints– from incidental decisions made during the implementation –perhaps by a generative AI agentic workflow.

Paradoxically, having the full implementation of a system (without context) may be less useful than knowing only the foundational principles from which the full implementation is derived. Reverse-engineering intent from code is lossy.

This is similar to knowing, in a software system, whether a parameter that has a given value was given that value explicitly by the user or it comes from a default. Even if the parameter has the same effective value as the default setting, the source of the value may be useful to know as the software evolves. Does the user care about the specific value or are they deferring the decision to the software’s developers?

Why does it matter?

Being able to distill the deliberate decisions into a canonical artifact gives the highest signal-to-noise ratio. The signal is the human intent.

Knowing the origin of particular decisions helps us infer their importance. This makes it easier to decide the right course of action to handle a new conflicting deliberate decision:

How to do this?

Specification-driven approaches solve this trivially: the specification is the entirety of the set of deliberate decisions. Everything else (the implementation) is the incidentals.

I expect other approaches to generate software through AI may also be amended to support this. For example, you could maintain some specification documentation and ensure that your AI keeps it up-to-date as it amends your software.