# When Software's Timeline Begins to Loosen AI is letting implementation settle later and feedback return before its original context expires. Requirements, development, delivery, and use remain distinct responsibilities, but they no longer have to happen in strict sequence. ## Metadata - HTML: https://glenzli.com/en/notes/software-time-loosens/ - Markdown: https://glenzli.com/en/notes/software-time-loosens.md - Collection: Notes - Language: en - Published: 2026-07-18 - Updated: 2026-07-18 - Tags: ai, software-engineering, runtime, delivery, feedback ## Content On a recent trip, I started building a travel app on a whim. Before leaving, I had prepared more possible itineraries than there were days in the trip. Once I arrived, the choice still had to be made again each day around weather, closures, reservations, energy, and whatever changed at the last minute. The app began as a place to keep those alternatives together and switch between them without rebuilding the whole plan. It was not finished before departure, and it did not become finished after its first deployment. I used it, found abilities it lacked and assumptions that did not survive contact with the trip, then changed it. Some revisions were checked, redeployed, and used again later that same day. Requirements, development, delivery, and use remained different activities with different responsibilities, but they no longer occupied separate stretches of time. Software continuing to change after delivery is hardly new. Agile development, continuous delivery, and DevOps have been bringing usage feedback into later versions for years. What felt different was that the loop had become short enough to close while the activity the software served was still happening. In the past, a problem discovered during a trip would usually be written down and revisited later. It might reach the next release, or wait until the next trip before anyone could tell whether the fix worked. Now the revised version could return before this trip was over. Feedback no longer had to wait until its context had become a memory. In [Software Development in the AI Era](https://glenzli.com/en/notes/software-cognition-in-ai-era), I wrote about software lifetime. A tool that serves one migration, one cleanup, or one afternoon may be worth building without being worth years of maintenance. This trip exposed a separate question. Lifetime does not determine how many deliveries a piece of software will have. An app that exists for two weeks may change repeatedly during those two weeks. A system expected to last a decade may move slowly because every change carries migration cost and risk. Following that timeline in the other direction raises another question: > If an implementation serves only the present context, and its result can be verified independently, must it already exist as fixed source code before delivery? ## When Implementation Becomes Concrete Asking AI to write a one-off data-cleaning script is no longer difficult. The usual sequence is to generate the code, run tests, and then execute it in a sandbox or local environment. This changes the cost of producing code without changing software's basic shape. A requirement becomes source code; the source is built and delivered; the runtime executes an implementation that has already been decided. Even when an agent writes most of it, source code remains the intermediate object through which intent must pass before reaching the running environment. But if a process will handle only this input, and the real data and environment appear only at runtime, could the implementation wait until then? Here, “in advance” means before delivery or deployment. The runtime still has to generate or select a candidate implementation. That candidate still needs admission checks, and any real-world action still requires its own authority. The only change is that every concrete process no longer has to be written before delivery. Software already decides some things at runtime. A JIT compiler produces machine code; a query optimizer chooses a plan from the observed shape of the data. Those systems usually begin with an existing formal representation and elaborate it according to predefined semantics. AI opens a less fully enumerated possibility. A system can use an approved purpose, the data in front of it, and execution feedback to generate queries, control flow, or tool combinations that were not completely listed beforehand. That openness creates options, but it also creates uncertainty that has to be governed. Tax calculations need stability, reproducibility, and continuing audit, so they belong in deterministic programs written early. A quarterly data cleanup may be different: fields, missing values, and anomalies change from one quarter to the next. The durable part may be the metric definitions, data boundaries, and acceptance rules. The exact queries and cleanup steps can be produced after the current data is visible. There is a practical limit. Delayed implementation makes sense only where the outcome can be observed and checked with enough confidence. A rule can verify whether data has the required form. Whether an analysis is useful for a decision may still require judgment from the person who will act on it. ## The Accounting of Abstraction Changes Traditional software reuses more than code. It reuses a shared abstraction. To make one implementation cover more situations and survive more maintainers, we extract domain models, define general interfaces, introduce frameworks and configuration systems, and absorb new exceptions into the same structure. Every later user must first learn how that system divides concepts, represents state, and exposes extension points. Only then can they translate their problem into the abstraction's terms. If the software lives long enough and serves enough people, that learning and maintenance cost can be amortized. Runtime generation changes part of that calculation. A process that serves only the present task may not justify a general abstraction designed around imagined reuse. The system can preserve stable data structures, access boundaries, and acceptance rules, then generate a local process for the intent at hand. People have often had to adapt their problems to the workflow a program anticipated. More implementations can now adapt to the current problem without moving the boundary around them. Abstraction does not disappear. Schemas, protocols, capability interfaces, invariants, and validators become more important because runtime generation needs something firm to work against. What may shrink is the application-layer framework built to reuse short-lived procedures. Complexity does not vanish; it moves from a visible codebase and its learning curve into intent expression, generation, validation, and traceability. If those parts cannot be inspected, dynamic generation merely trades visible structure for invisible behavior. Abstractions need a lifetime test of their own. Only concepts worth sharing over time are worth making everyone learn. ## Processes May Be Temporary; Boundaries May Not Runtime generation cannot be reduced to giving a model one sentence and telling it to work things out. “Give me a useful quarterly report” provides a direction. It does not say what would make the report useful or what the system must not do while producing it. If the executor can change the goal, relax the acceptance criteria, or expand its permissions whenever it gets stuck, the task it completes is no longer the task that was approved. The concrete process may wait until runtime, but its purpose and boundaries need to be settled earlier. The system must at least know which data and capabilities it may use, what cost it may incur, what evidence it must preserve, and who is allowed to change those conditions. At runtime it may revise a plan, switch tools, or generate a new implementation. It may not silently rewrite what it is supposed to accomplish. A changed objective should become a new proposal for an authorized person or system to decide. Whether something should be done, whether a candidate implementation may enter a controlled environment, whether the system has authority to change external state, and whether the result counts as complete are separate questions. Code passing its tests does not grant it access to production data. An API returning success does not prove that the real objective was achieved. Autonomy does not mean receiving every capability. It means searching for a process between an approved goal and a limited set of capabilities. ## Delivery Becomes a Checkpoint The travel app still used ordinary source code, tests, and redeployment. It did not generate new product code for itself at runtime. What changed was the distance between usage feedback and the next delivery. That distance is not measured in hours alone. It also includes how many times a need must be retold, how much context is lost along the way, and how many people and systems a change must cross before it can be used. A project can release every day while repeatedly missing what users actually encountered. A model can produce code in seconds, but the loop has not closed until the change has been confirmed, verified, migrated, and made usable. Delivery therefore does not disappear. It still marks a version as usable within a stated scope and establishes a boundary for recovery or rollback. What changes is the assumption that delivery naturally ends the formation of the product. Delivery becomes a verified, usable checkpoint. The current version can be used from that point, and real use can produce the evidence for whatever comes next. This matters most for personal, short-lived, context-heavy software. When the cost of change falls far enough, feedback can return before the original activity is over. The app no longer serves only the trip imagined in advance; it can also serve the trip that is actually unfolding. A short lifetime therefore does not imply a single delivery. An app may exist for only a few days and still pass through several usable states. When the activity ends, it can be frozen, archived, or deleted. Releasing it several times so that it remains useful along the way does not turn it into a permanent asset. ## Two Loops Change during use and runtime generation are easy to blend together, but they are not the same thing. If a system generates a query or a cleanup script for the data in front of it, that change remains inside one execution. As long as its goal, authority, and acceptance conditions stay fixed, it remains within the same execution boundary. If real use reveals that the application cannot represent an important kind of plan, or that its data model, acceptance rules, or capability boundaries no longer work, the product itself must change and reach a new usable version. The first loop ends in a result, failure, or halt. The second returns to the product layer and has to deal again with code, contracts, state migration, and delivery. The loops can feed each other. A runtime implementation that is repeatedly useful may become a candidate for a later product change. A problem found in use may prompt the system's designers to reconsider which processes should be written early and which can remain late-bound. They still cannot be collapsed into one loop. Replanning within the current task does not create a new product version. Releasing a new product version does not require runtime generation. Faster feedback does not automatically create more dynamic software, and runtime generation does not mean a product evolves by itself. They loosen different points on the same timeline. ## When Code Becomes an Asset Runtime-generated code does not have to choose immediately between being committed to a repository and disappearing without a trace. An implementation that serves only the current execution can be discarded once its result has been verified and the necessary evidence retained. One with limited reuse may be cached together with the purpose, inputs, and environment for which it was valid. Before reuse, those assumptions have to be checked again. Only when an implementation is used repeatedly, acquires external dependents, requires human maintenance, or carries a rising cost of failure does it become worth considering as durable code. If promoted, it should be cleaned up or rewritten and enter the ordinary design, review, testing, and release process. A piece of code that happened to work once should not be copied from a runtime cache straight into the repository. Software teams have traditionally guessed before development which parts will deserve reuse. Some code can now demonstrate its actual range and responsibility in real executions before anyone decides that it belongs in the codebase. The codebase then becomes closer to a collection of long-term responsibilities, rather than an archive of every solution the system has ever found. Promotion is only one source of product change. User feedback, stable defects, environmental shifts, and new patterns of use can all produce another delivery without promoting any runtime artifact. Software evolution cannot be reduced to saving whatever code a model happened to write well. ## Software Has More Than One Kind of Time Looking back, I now separate several questions that are often compressed into one. How long a software responsibility deserves to persist is a question of lifetime. When a concrete implementation must be decided is a question of binding time. How far real use stands from the next usable version is a question of feedback. They affect one another, but none determines the others. Short-lived software can be released repeatedly over a few days. A long-lived system may evolve slowly because its risks are high. An implementation running once is not automatically suitable for runtime generation, and a system that generates some processes at runtime does not necessarily change its product faster than an ordinary application. The distinction matters because software has often been forced into one timeline: define the requirements, design and write the code, deliver it, use it, then collect feedback. Each stage waits for the previous one to become sufficiently complete. Software development was never truly that orderly. The cost of understanding, changing, verifying, and delivering software simply made it behave as though it were. As AI lowers some of those costs, times that were bound together begin to loosen. A concrete process can settle later. Feedback can return earlier. Code can become an asset only after proving that it deserves maintenance. Responsibility still needs a clear home. Everything no longer has to become fixed at the same moment. ## What Still Needs Long-Term Maintenance I am not describing a fully dynamic system. Permission checks, state machines, critical rules, protocols, validators, and recovery mechanisms still belong in deterministic programs maintained over time. Processes whose paths are hard to enumerate, depend heavily on present context, live briefly, and produce verifiable outcomes are the better candidates for runtime generation. Both regions will coexist in the same system. They also have different lifetimes. A rule may be maintained for years. A temporary implementation may live for minutes. Evidence from its execution may need to survive much longer for later inspection. Source code alone may no longer describe what happened: we may also need to know what was approved, which capabilities were available, and why the result was accepted. Git commits remain important, but the version boundary of software begins to extend beyond code. This approach has clear limits. Hard real-time control, safety-critical systems, outcomes that are difficult to verify, and side effects that cannot be recovered still favor deterministic implementations written in advance. When logic is stable, frequent, and depended upon for a long time, writing it early is usually simpler. Fast feedback does not turn production into a testing ground. Development and use can overlap in time while a new version is still verified in isolation before migration. The closer a change sits to real use, the less optional validation, state migration, and rollback become. AI's deeper effect on software engineering may not be that code is written faster. It may be that software's time is being rearranged: which responsibilities must be fixed early, which implementations can wait for context, and which feedback can return before the event that produced it is over. Requirements, development, delivery, and use still carry distinct responsibilities. They no longer have to happen in strict sequence. Implementation can arrive later. Responsibility cannot. ## Related Material - [AI Software Engineering Notes](https://gitlab.com/glenzli/ai-software-engineering-notes): notes on software lifetime, agentic engineering, and intent-oriented execution that provide the conceptual basis for this essay. - [In-Use Evolution](https://gitlab.com/glenzli/ai-software-engineering-notes/-/blob/main/foundations/IN_USE_EVOLUTION.md): how real use can produce another usable checkpoint before its original context expires. - [Milestone II: Intent-Oriented Execution](https://gitlab.com/glenzli/ai-software-engineering-notes/-/blob/main/milestone-2-intent-oriented-execution/README.md): a research hypothesis about implementation binding time, intent contracts, runtime generation, and artifact promotion. - [Plan Gacha](https://gitlab.com/glenzli/plan-gacha): the travel-planning tool that continued to change while it was being used on the trip.