# Software Development in the AI Era AI makes software easier to create for temporary use and easier to delegate to agents. Engineering standards should follow lifespan, dependency, authority, and consequence—not code volume. ## Metadata - HTML: https://glenzli.com/en/notes/software-cognition-in-ai-era/ - Markdown: https://glenzli.com/en/notes/software-cognition-in-ai-era.md - Collection: Notes - Language: en - Published: 2026-06-30 - Updated: 2026-08-17 - Tags: ai, software-engineering, agent, workflow ## Content AI has made software easier to write. Things that once survived as shell fragments, spreadsheets, or handwritten procedures can now become small tools, web pages, and automated workflows in an afternoon. The change is not merely that software arrives faster. Software itself no longer has to play one role. We used to approach almost any new code as the beginning of a durable asset. Architecture, tests, documentation, releases, and maintenance followed naturally from that assumption. Now a piece of software may exist for one migration, one cleanup, one batch of content, or one short experiment. It can be worth creating without being worth maintaining forever. That makes a different set of questions more useful at the beginning: > How long should this live? Who will come to depend on it? What data and authority will it touch? Can an agent operate it safely? When must a temporary tool graduate into a lasting system? These questions are not more sophisticated than implementation. They simply determine what kind of implementation makes sense. ## Software Is Not Necessarily an Asset Traditional software engineering carries a quiet assumption: the software will probably stick around. That is why maintainability, abstraction, reuse, testing, and release discipline are worth paying for early. Given a long enough life, the investment has time to compound. That assumption is loosening. A temporary tool is now cheap enough to build that many tools really should live for only an afternoon, a week, or one narrow phase of a project. For them, early abstraction and elaborate layering do not create durability. They spend attention on a future that may never arrive. But temporary software is not exempt from engineering judgment. A script that runs once can still touch production data, long-lived credentials, CI, scheduled jobs, billing systems, or user records. The code may disappear tomorrow. The consequences of its authority may not. Engineering standards should therefore follow lifespan and impact, not code volume. A disposable, low-authority tool with easily checked results can remain light. Software that lasts, acquires dependents, or reaches consequential systems needs structure, tests, auditability, and an owner. Temporary describes lifespan. It does not describe risk. ## Software Becomes Delegable “AI native” is often used to describe everything at once: the stack, the interface, and the product story. The more useful engineering question is narrower: > Can an agent safely read, change, run, and compose this software? The important shift is not only that software may contain AI. Software may also be operated by AI. Delegable software needs legible boundaries. A task must have a clear objective. Inputs and outputs must be inspectable. Authority must be scoped. Execution must leave evidence. Failure must have a stop condition, a rollback path, or at least a bounded cost. This is not a case for giving agents the keys and walking away. The practical model is controlled delegation. An agent can inspect code, make changes, work inside a sandbox, and return evidence. It may even coordinate several systems. But as it approaches production, money, user data, or identity, confirmation points and audit trails stop being ceremony. They become part of the control surface. Software will increasingly be used by agents as well as people. Its design has to acknowledge both. ## Context Becomes Maintainable Maintainability used to refer mainly to code: names, modules, dependencies, tests, documentation, and releases. Those were the materials from which a new maintainer reconstructed the system. With agents in the loop, context joins that list. Prompts, workflows, memory, tool descriptions, evaluation cases, permission settings, and knowledge sources become system components once a recurring execution path depends on them. Give an agent the same code without the relevant examples, authority model, or task history, and it may effectively be looking at a different project. This is also why cleverness ages badly in agent-operated systems. Agents work better with explicit structure, stable contracts, and locally understandable tasks than with implicit conventions, magic behavior, and side effects that leak across layers. A maintainable codebase now has to be understandable to both people and agents. Plain internals, visible boundaries, and provenance for important decisions often carry more value than an elegant abstraction no one can safely change. Code is only one part of the system. The context that makes the code intelligible must be maintained too. ## Correct Output Is Not Enough Traditional tests prefer deterministic claims: given this input, expect that output. That model remains essential. It is simply incomplete once the executor can plan, call tools, read files, write state, and reach external systems. An agent may complete an “update dependencies” task and leave every test green while also reading unrelated files or carrying untrusted web content into long-term memory. The final diff cannot tell you which path it took. For consequential work, verification has to cover both result and route. Important tool calls and authority changes need records. Irreversible actions need confirmation. Early runs should happen in reproducible, bounded environments whenever possible. The longer a task persists—and the closer it moves toward real data and production systems—the more visible and reversible its execution should become. ## Boundaries Matter More Than Obedience A common mistake in AI safety is to place the entire burden on the model: do not be fooled, do not follow hostile instructions, do not make the wrong decision. But whether a model is fooled is a probability. Its permissions determine the size of the mistake. For an LLM, the border between data and instruction is porous. A web page, document, issue, chat log, knowledge base, log entry, or code comment may be useful information and an attempt to steer behavior at the same time. Once an agent can bring that material into context and then act with credentials, risk travels along the permission graph. The sturdier design is not to assume perfect obedience. It is to limit what error can reach. Least privilege, revocable credentials, sandboxed execution, and approval for consequential actions usually provide a stronger boundary than another paragraph in the prompt. Short-lived software is particularly easy to excuse here. A temporary script holding production credentials is no longer a low-risk script. An experimental agent that can alter CI, publish packages, or write to a database has already crossed into a high-impact boundary. “We will delete it soon” is not a security model. ## What the Software Must Carry The code is now only part of what enters the world. Code, prompts, and tool descriptions carry intent. Permissions decide which data and systems that intent can reach. Keeping the software alive means accepting future migration, repair, and change. These are not annotations to add after the implementation works. A tool's intended lifespan, its dependents, its authority, and the extent to which it can be delegated all shape how it should be built from the first day. AI has lowered the cost of producing software. It has not lowered the responsibility software acquires when it touches reality. Once generation becomes easy, the questions to settle early are no longer limited to how the software will be written. They are whom it will affect, what it will be allowed to touch, and how long we are willing to answer for it. ## Reference Repository - GitHub: [glenzli/ai-software-engineering-notes](https://github.com/glenzli/ai-software-engineering-notes)