# untitled, part 2

what happened inside one ATQ is mostly an [end-to-end composition problem](https://web.mit.edu/Saltzer/www/publications/endtoend/endtoend.pdf). the user's question has to survive translation into a business definition, sql, a warehouse query, a driver connection, an http response, an arrow stream and eventually a dataframe, chart or cached answer. every surface can obey its own local rules while the whole thing still violates greg's simple expectation that closing the tab should stop the bill and never publish half an answer.

the data domain adds a temporal component. schemas change, upstream systems add and remove fields, metric definitions get argued into new shapes, permissions move with people's jobs and warehouse behaviour changes underneath the same sql. ATQ also acts back on this environment: an answer changes a campaign, a price, a forecast or somebody's next question, which changes the data and what a useful future answer means.

lehman called software embedded in changing real-world activity an [E-type system](https://en.wikipedia.org/wiki/Lehman%27s_laws_of_software_evolution). his first law says it must be continually adapted or become progressively less satisfactory; another says its complexity tends to increase unless work is done to control it. ATQ is aggressively E-type because both the data it reads and the organisation interpreting its answers keep moving.

[ashby's law of requisite variety](https://en.wikipedia.org/wiki/Variety_(cybernetics)#Law_of_requisite_variety) sounds more complicated than the useful point we need from it. if a source can rename a column, a metric owner can redefine revenue, a permission can be revoked and a user can turn an answer into a new business process, whatever maintains ATQ needs some way to notice and respond to each kind of change. adding more sources, definitions, users and actions adds more kinds of change that must be detected, understood and reconciled with the implementation.

this conclusively proves one thing: even assuming a perfect ai model capable of implementing everything knowable today, ongoing work is required to keep ATQ functional tomorrow. maintenance is a requirement. you can do it yourself, pay somebody else to absorb it or eventually hand all of it to an llm. the burden can move; it cannot disappear.

when you buy a saas, then, you are not buying a bag of code. you are paying a company to make reality's next stupid little detail its problem while you continue not giving a fuck about arrow completion markers. the promise, viewed from the customer's side, is that the software will keep working. maintenance is the same promise viewed from inside the company. the subscription pays for that obligation, not rent on the current lines of code.

this burden is easy to miss because successful maintenance is experienced as nothing happening. [star and ruhleder](https://doi.org/10.1287/isre.7.1.111) describe infrastructure as transparent during normal use and visible upon breakdown; [pipek and wulf](https://doi.org/10.17705/1jais.00195) describe design and use as one continuing process of infrastructuring. nobody notices the healer until the raid wipes or the drummer until she stops. creation is visible and exciting, so contemporary ai marketing fetishises it. repair disappears from the story because, as [steven jackson argues in "rethinking repair"](https://doi.org/10.7551/mitpress/9780262525374.003.0011), successful repair is mostly invisible.

a software company gives this invisible obligation a durable name and a human face. not because a human must personally type every patch forever, but because responsibility needs to be legible. greg needs to know who is listening, who can decide what happens when his definition of revenue collides with finance's and who will answer when the decision is wrong.

seth godin says professionals are not authentic; they are consistent: they choose a promise and keep it over and over again. that is an annoyingly perfect description of maintenance. the human face is not valuable because it looks sincerely concerned; an llm can generate that face, its apology and the founder's linkedin post before lunch. trust is the accumulated evidence that the promise was kept and that somebody took responsibility when it wasn't. the years in which a company actually shows up still have to happen one after another.

godin's alternative to treating ai as extremely cheap offshore labour is to ask how it can make a business [more human](https://www.youtube.com/watch?v=g7AxxkywiFI&t=6002s): give the doctor better tools so the doctor can spend more time with the patient, not less. the equivalent here is not preserving arrow-stream debugging as a sacred human craft. please god no. let the machine do as much of it as it can, then spend the returned attention understanding what greg is actually trying to do and keeping the promise better.

maybe createitbot-3000 eventually performs every operation required to keep ATQ alive. cool! that changes the cost of keeping the promise; it does not make the promise pointless. cheap creation does not prove the futility of saas. it clarifies what the saas was for.