# Software Beyond the Manual Once a user gives AI the goal, interfaces, workflows, and public APIs become recommended paths rather than the edge of actual use. Software can be taken apart, routed around, and recombined. ## Metadata - HTML: https://glenzli.com/en/notes/software-beyond-the-manual/ - Markdown: https://glenzli.com/en/notes/software-beyond-the-manual.md - Collection: Notes - Language: en - Published: 2026-07-24 - Updated: 2026-08-17 - Tags: ai, software-engineering, agents, capabilities, boundaries, lineage ## Content A common way to use software now begins with a goal handed directly to AI. "Get this done for me." Often, that is enough. The user does not need to diagnose why a file will not open, identify the right setting, select the tool, or prescribe the order. The AI meets those questions during execution. It reads the error, checks documentation and file formats, writes a script, invokes a command-line tool, converts data between applications, or supplies the one missing piece. The user supplies the purpose. The AI finds the route. For software, that changes something fundamental: the path designed for the user is no longer guaranteed to be the path the user takes. ## An Interface Is a Prediction An interface has never been mere appearance. Menu placement, button visibility, step order, and available combinations all encode a prediction about user behavior. A public API does the same thing. It gathers the capabilities a vendor is willing to support and expresses how outside systems are expected to use the product. That prediction works when humans operate the software directly. Most people search the interface. If there is no button, documentation, or API, they conclude that the product cannot do it. AI starts elsewhere. It sees the user's goal before it sees the product's workflow. A blocked interface does not imply a blocked task. If state can be read, data converted, or a capability reached another way, it may keep looking. The interface remains the recommended path. It no longer defines the practical boundary by itself. ## Software Comes Apart The important change is not that AI can click more buttons. It now translates goals into software operations. It chooses tools, skips parts of a workflow, inserts code, and discards intermediate artifacts. In one task, the same AI may act as user, integrator, maintainer, and developer. The user says less. The software may be used more deeply. A travel app can serve as a complete itinerary planner, or merely supply dates and places to a reminder tool. A publishing application can offer a full editing experience, or contribute only pagination, font checks, or PDF export. A desktop app without a public API can still enter a larger process through files, command-line tools, or automation. Complete products keep their value. They also become material that can be taken apart. For a particular task, completeness is no longer the only test. The more useful question is whether the available pieces are enough. An imperfect product plus a temporary patch and strong validation may finish today's work. A comprehensive product inside another workflow may contribute one narrow capability. Enough is local. It does not prove that the original software is correct or that the workaround deserves a permanent life. It means the combination works under the present environment, permissions, and checks. ## Constraints Reveal Their Purpose Humans once occupied a familiar role: users operated software; developers changed it. AI loosens that division. When a vendor's path obstructs the goal, AI may change a local configuration, add a wrapper, convert a file, alter the invocation, or patch an implementation rather than wait for the next release. Product conventions and system constraints used to blur together. No button, no export command, and no supported combination could all look like hard boundaries as long as most users stayed inside the interface. AI exposes the difference. Some constraints protect data integrity, account security, and irreversible operations. Others describe how the vendor chose to arrange features. The first keep the system reliable. The second select one path among many. Designers cannot reliably prevent AI from finding another route, and they cannot control what users do with code, files, and results they already possess. The question becomes: > What does this constraint actually protect? If the answer is a resource, security property, or irreversible consequence, enforce it where the effect occurs. Hiding an entrance in the interface is not a boundary. If the answer is a preferred sequence, expect it to be dismantled, recombined, or shortened. ## Software as Reference Material AI can observe software as well as use it. Inputs, outputs, interface behavior, errors, file structures, and results can reveal enough behavior to inspire another tool. That tool may wrap the original, combine several systems, or stop depending on it entirely while preserving its operational ideas. Ordinary dependency graphs cannot describe this relationship. Code may no longer load the original product while still inheriting interface habits, behavioral assumptions, and semantics. Behavior, however, is not a full specification. What the software does may reflect deliberate design, compatibility patches, historical accidents, and unfixed bugs. AI can imitate the result without knowing which parts deserve preservation. A faithful reimplementation can faithfully reproduce the mistake. Similarity is not enough. We need to know what was inherited, which behavior was intentional, which was historical residue, and why the new implementation should be trusted. ## Hidden Is Not Untouchable AI does not turn closed-source software into open source. Source access still changes the depth of audit, precision of modification, and cost of long-term maintenance. But "nobody can see the implementation" is becoming a weaker account of the boundary. AI can observe behavior, interfaces, local files, and runtime results, then reproduce a meaningful part of the capability. Closed source still blocks direct copying. It no longer guarantees incomprehension. The open–closed distinction therefore leans more heavily on licenses, contracts, service control, data ownership, and the collaboration a developer chooses to permit. The value of a product may come less from invisible implementation and more from service, data, brand, community, and the ability to keep evolving. AI will not give every project the same answer. It will make secrecy alone a less stable wall. ## Intent Leaves the Author An author can explain why software exists, recommend a workflow, and promise certain interfaces. Once AI becomes the direct user, the author cannot predeclare every downstream purpose. The software may enter a task nobody anticipated, combine with unrelated tools, or become the raw material for a different product. Its original interface survives as one path among many. Capabilities, behavior, and limits live in the software. Intent comes from the present user and task. That is why agent-specific APIs are not the only measure of whether AI can use a product. Structured interfaces are more reliable, but AI also operates software designed only for humans. The difference is the cost of interpretation, experimentation, and diagnosis. ## What Designers Still Control As long as the system controls a resource, server-side authorization, data isolation, and operation approval can limit the impact of a call. They govern accounts, data, and side effects. They do not govern how software will be understood elsewhere or what users do with their own files and local programs. Designers must separate those boundaries. Constraints that protect data, safety, or irreversible outcomes belong at the layer where the effect happens. Even if someone finds another route, the state that must not break remains protected. Preferred workflow is different. AI may take it apart. The useful question is not how to drive every user back to the official route, but which semantics must remain stable outside it. Product design still matters. Interfaces serve most people. Defaults carry experience and judgment. But recommended use is no longer final use, and an unsupported path is not an impossible path. Future users will read state, probe routes, write a little code at a gap, and place software inside combinations its developers never saw. Products do not need to expose every internal or support every automation. They do need legible capabilities: clear state, diagnosable errors, reliable data movement, and critical conditions that do not depend on a hidden button. Beyond the manual, software will be read, modified, bypassed, recombined, and made to reappear in another form. Vendors can design the default route. They can no longer expect it to cover the whole territory. ## Related Material - [Software Development in the AI Era](/en/notes/software-cognition-in-ai-era/) - [When Software Time Begins to Loosen](/en/notes/software-time-loosens/) - [AI Software Engineering Notes](https://github.com/glenzli/ai-software-engineering-notes)