--- title: "Taking Away the Coding Tool Doesn't Retire the Code" description: "Review existing AI-built tools separately from coding access: find their owners, dependencies and credentials, then approve continued use or retirement." author: "Gunner Technology" published: "2026-11-02" url: "https://www.gunnertech.com/blog/revoking-coding-access-does-not-retire-the-code" --- # Taking Away the Coding Tool Doesn't Retire the Code When you revoke access to an AI coding tool, review the software people already built with it separately. Removing the ability to generate code doesn't necessarily stop a scheduled script, remove its credentials or tell its users what replaces it. An access change needs a plan for the work it leaves behind. ## What does the reported restriction actually tell us? It tells us who can use the coding tools, without establishing what happened to everything built during the experiment. [The Decoder reports that Goldman Sachs restricted advanced AI coding tools to engineers](https://the-decoder.com/goldman-sachs-pulls-ai-coding-tools-from-traders-and-bankers/), citing Bloomberg. The report says traders and bankers had used the tools for work including monitoring trading flows and creating content. The article describes an earlier approach in which a business employee could build a prototype and pass it to engineering for production. It reports that the bank cited productivity and risk management in explaining the restriction. It doesn't identify a particular software failure or establish that the generated tools caused an incident. For a buyer, the next question is what happens during the transition. Changing who may build is an access decision. Deciding whether existing software should keep running is an operating decision. The article doesn't describe that second process. Gunner Technology recommends treating it as a separate job, with the following checks. ## What should you find before calling the rollback complete? Find the tools still in use, the work that depends on them and the authority each one carries. Include scheduled jobs, shared scripts and local applications where they fall within the review's approved scope. A software inventory is a record of what exists and who is responsible for it. Start there, then check whether the record matches actual use. Consider a hypothetical operations script that prepares an internal report each morning. Its author loses access to the coding assistant, but the script runs under a separate account. The report still arrives. That doesn't prove the script is safe or unsafe; it shows why the coding subscription and the running software need separate checks. Ask who uses the output, which data it reads, whether it changes records and what happens if it stops. Record unknowns explicitly. Our post [Ownership Starts When the Agent Stops](https://www.gunnertech.com/blog/ownership-starts-when-the-agent-stops) covers the broader duty to operate what gets built. During an access rollback, that duty becomes an immediate question about each surviving tool. ## Who decides whether an existing tool stays? An accountable owner should decide whether to retain, restrict, replace or retire it, with engineering assessing the operating requirements. Give each decision a named owner and a reason. Being useful doesn't automatically qualify a prototype for continued operation, and being AI-generated doesn't establish that it must be discarded. For the hypothetical report, the business owner identifies which decisions depend on it and what an acceptable replacement must deliver. Engineering checks the implementation, access, dependencies and recovery route. If nobody can establish how it works, keep that uncertainty visible and restrict its use as the consequences require. Don't turn missing knowledge into an assurance. Separate temporary containment from permanent retirement. Removing write access may reduce an immediate risk while the owner arranges a replacement. If continued use is allowed temporarily, record its conditions and review date. The broader lesson in [A Citizen Developer Is Not a Software Factory](https://www.gunnertech.com/blog/a-citizen-developer-is-not-a-software-factory) applies here: the ability to request or generate software doesn't settle its operating authority. ## How do you prove a retired tool has stopped? Verify the execution paths and permissions that let it operate, then check the effect on its users. Disabling the coding assistant proves only that the assistant is unavailable through that route. A deployed application may use a service account, meaning an identity assigned to software rather than a person, with permissions of its own. For an approved retirement, stop the scheduled work, remove the access it no longer needs and check that another trigger cannot restart it. Preserve required records through the authorized retention process. Where a credential is shared, establish what else depends on it before changing it. Otherwise a cleanup can break work the owner meant to preserve. Check the business result too. In the report example, confirm that the replacement arrives and that people know which output to trust. Keep evidence of what stopped, what remained and who accepted the transition. A disabled account is useful evidence about an account. It isn't evidence that an entire workflow has been retired successfully. ## What should the next experiment do differently? Define the exit before granting access: who owns generated tools, where they may run and what happens when the experiment ends. Give prototypes an explicit route into maintained software or retirement. That makes ending an experiment a planned transition instead of a search for everything it might have left behind. In a software factory, agents can gather the inventory, inspect approved repositories, propose repairs and collect verification evidence. Keep those actions inside your accounts and access rules. People decide what should remain and judge the returned work; the machinery carries that decision through the repetitive checks. Don't hand an inventory agent blanket permission to delete what it discovers. Start with a bounded group of internal tools. Establish their owners and dependencies, make the required decisions and verify the resulting changes. Then extend the process. Turning off a build interface can be quick. Finishing the work means knowing which software still runs, why it is allowed to run and who will answer for it. In response to [Goldman Sachs pulls AI coding tools from traders and bankers](https://the-decoder.com/goldman-sachs-pulls-ai-coding-tools-from-traders-and-bankers/) by The Decoder. ## Quick answers ### Should every AI-built tool be rewritten by an engineer? No. Assess whether it meets the requirements for its intended use and has an owner who can support it; rewrite only when the evidence warrants it. ### What if a useful script has no available author? Assign responsibility for assessing it and establish its behavior and dependencies. Until those are understood, limit its use according to the consequences of failure. ### Can business employees still propose new tools? Yes, through the request route your organization approves. Permission to propose a workflow can remain separate from permission to build, connect data or deploy it.