# When Software Time Begins to Loosen AI lets some implementation wait for context and lets feedback return before the event that produced it is over. Software's timeline is loosening. Its responsibilities are not. ## 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-08-17 - Tags: ai, software-engineering, runtime, delivery, feedback ## Content I built a travel-planning app during a trip. Before leaving, I had prepared more possible itineraries than there were days. Once I arrived, weather, closures, reservations, fatigue, and ordinary surprises kept changing what made sense tomorrow. The app began as a place to keep those options together. It was not finished before the trip. It was not finished after the first deployment, either. I used it, found a missing capability, changed it, checked it, deployed again, and kept using the new version during the same journey. Requirements, development, delivery, and use were still different activities. They had stopped waiting politely in line. Software maintenance after release is not new. Agile, continuous delivery, and DevOps put feedback into later versions long ago. What felt different was the length of the loop. Feedback could now return before the real-world activity that produced it had ended. A two-week application can pass through several usable versions. A system expected to live for ten years may move slowly because every change carries migration cost and risk. Lifespan does not determine delivery count. That leads to a second question: > If an implementation serves only the present context and its result can be verified independently, must the code be fixed before delivery? ## When Implementation Settles Asking AI to write a one-off data-cleaning script is easy now. The familiar path is still to generate source, run tests, then execute it in a sandbox or local environment. The code became cheaper. The shape of software did not change. Intent became source code; source code went through build and delivery; runtime executed an implementation already fixed in advance. But a process that handles one input, in an environment visible only at runtime, may not need its exact implementation so early. Later does not mean unchecked. The runtime still has to generate or select a candidate, validate it, and obtain separate authority for real effects. The only change is that not every concrete step must exist before deployment. Runtime choice is old. JIT compilers generate machine code. Query optimizers select plans from current data. They operate inside semantics defined ahead of time. AI opens a wider space. A system can use an approved purpose, present data, and execution feedback to generate queries, control flow, or tool combinations never enumerated in advance. More choices arrive with more uncertainty. Tax calculations need stability, reproducibility, and audit. They belong in deterministic programs. Quarterly data cleanup is different: fields, missing values, and anomalies change every time. Metric definitions, data boundaries, and acceptance rules can remain durable while the exact queries wait for the current dataset. The limit is practical. Delayed implementation makes sense only where results can be observed and checked. A validator can tell whether data satisfies a rule. A human still has to decide whether an analysis is useful. ## The Economics of Abstraction Traditional software reuses more than code. It reuses a shared abstraction. We build domain models, general interfaces, frameworks, and configuration systems so one implementation can cover many cases. Future users first learn how the system divides the world, then translate their problem into its language. That cost pays off when the software lives long enough and serves enough people. Runtime generation changes part of the calculation. A process built for one task may not deserve a framework designed for hypothetical reuse. The system can keep stable data structures, access boundaries, and acceptance criteria while generating the local procedure from current intent. The abstraction does not disappear. Schemas, protocols, capability interfaces, invariants, and validators become more important because generated behavior needs a hard edge. What may shrink is the application framework built to reuse short-lived procedures. Complexity moves rather than vanishes—from the codebase and the user's learning cost into intent, generation, validation, and provenance. If those cannot be inspected, dynamic generation merely trades visible structure for invisible behavior. Only concepts worth sharing for a long time deserve to be learned by everyone. ## Temporary Process, Durable Boundary Runtime generation cannot mean: give the model one sentence and let it figure everything out. "Give me a useful quarterly report" says nothing about useful, forbidden data, cost limits, or who may change the conditions. If the executor can loosen acceptance, widen permissions, or rewrite the goal whenever the task gets hard, it will eventually complete something else. The process can wait. The purpose and boundaries cannot. A system must know which data and capabilities are allowed, how much cost is acceptable, what evidence must remain, and who can change those terms. It may change plans, tools, and implementation. It may not silently change the task. Passing tests does not grant production access. A successful API call does not prove the real objective was achieved. Autonomy is not unlimited capability. It is freedom to find a process between an approved goal and a bounded set of powers. ## Delivery as a Checkpoint The travel app used ordinary source, tests, and redeployment. It did not generate its own product code at runtime. What changed was the distance between use and the next delivery. That distance is not just hours. It includes how many times a need is retold, whether the original context is still fresh, and how many people and systems a change must cross. A team can release daily without closing a real feedback loop. A model can generate code in seconds, but the loop remains open until the change is confirmed, validated, migrated, and made usable. Delivery still matters. It marks a version as usable within a defined scope and establishes recovery. It simply no longer means that the product has finished becoming. Delivery becomes a verified checkpoint. The current version can enter use here; use can push the next change from the same point. Short life no longer implies one delivery. Several checkpoints during a two-week trip do not turn the app into a permanent asset. It can still be frozen, archived, or deleted when the trip ends. ## Two Loops In-use change and runtime generation are easy to merge in conversation. They are not the same mechanism. Generating a query for the current dataset belongs to one execution. As long as purpose, authority, and acceptance stay fixed, the task remains inside one boundary. Discovering that the product cannot represent a kind of plan is different. Data structures, contracts, migrations, and delivery may need to change. That returns the work to the product layer. The loops can feed each other. A generated procedure used repeatedly may become a candidate for the product. A failure during use may reveal which process should become durable. They cannot collapse into one. Replanning a task does not create a product release. Shipping a product release does not require runtime generation. Faster feedback does not automatically create dynamic software. Runtime generation does not mean software evolves by itself. They loosen different points on the timeline. ## When Code Becomes an Asset Generated code needs more than two destinations: commit or oblivion. An implementation used once can disappear after its result and evidence are preserved. A candidate for limited reuse can be cached with its purpose, inputs, and environment, then checked again before use. Only when code becomes frequent, externally depended upon, manually maintained, or costly to fail should it be considered for long-term ownership. At that point it should be redesigned, reviewed, tested, and released—not poured straight from one runtime into the repository. We used to guess what deserved reuse before development. Some code can now prove its scope and responsibility in real execution first. The repository becomes a collection of long-term obligations, not every solution the system has ever found. ## More Than One Kind of Time Software carries at least three clocks. How long a responsibility should exist is lifespan. When an implementation must become concrete is binding time. How far use sits from the next usable version is feedback time. They influence one another. None determines the others. AI lowers enough costs to loosen the old sequence. A process can settle later. Feedback can return earlier. Code can become an asset only after proving that it deserves maintenance. Stable permissions, state machines, critical rules, protocols, validators, and recovery mechanisms still belong in deterministic programs. Context-heavy, short-lived, verifiable paths are better candidates for generation. Both regions will live in the same system. Hard real-time control, safety-critical systems, irreversible effects, and results that cannot be verified still favor implementation in advance. Faster feedback is not permission to turn production into a test environment. AI's deeper effect on software engineering may be a rearrangement of time: which responsibilities must be fixed early, which implementations can wait for context, and which feedback can return before the event that created it is over. Implementation can arrive later. Responsibility cannot. ## Related Material - [AI Software Engineering Notes](https://github.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://github.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://github.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://github.com/glenzli/plan-gacha): the travel-planning tool that continued to change while it was being used on the trip.