Working through a real holiday-booking business this month, the pipeline hit a rule it had not built before. Staff can transfer a confirmed group booking from one group-only time slot to another in the same season. That sounds simple until you ask what happens to the seats: the old slot has to give its seats back, the new slot has to commit the same number, and both have to happen together, or the counts end up wrong.

It did not decide for itself. It stopped and asked the owner, in plain language, exactly what should happen to that seat: does it come back, and what brings it back?

Once the rule was clear, the system did not sit an AI down to write the code for it by hand. That is where mistakes come from, and we have had our share of them. Instead it added a reusable building block: a small, tested piece of the machinery that knows how to move committed seats from one slot to another all at once, so the count is never left half-done.

A rule we haven't built e.g. move a booking and its seats
Build one tested part small, reusable, deterministic
It compiles the rule correctly, for every business after
A new kind of rule becomes a reusable part, not a one-off piece of hand-written code.

The applications the pipeline generates have no hand-written business code holding them together. Everything is assembled from parts like this one, each tested on its own. So when a genuinely new kind of rule shows up, the honest choice is between guessing at the code or building the part properly. We build the part. It gets tested once, and from then on it is correct every time it is used.

And it does not only help the one business. The next company that needs to move a booking, or release and re-commit any kind of limited capacity, inherits that part already built and already tested. Your unusual rule becomes someone else's reliable feature, and the library gets richer every time a real business asks for something it has not seen.

Still rough

We will be honest about the hard part. Recognizing that a rule is genuinely new, and building exactly the right part for it, is difficult, and we have gotten rules wrong on the way there. The discipline is to turn each one into a tested building block instead of a one-off patch. Making that recognition sharp and repeatable is very much still in progress.

The goal is software assembled entirely from parts that are known to work, where the answer to something new is never to wing it, but to build one more part, once, for good.