From AI Experiment to a Dependable Business Service
AI makes useful tools cheaper to create. A dependable business service still needs explicit rules, tested outcomes, a...
Your Coding Agent Is Not a Deployment Pipeline
8 min read
The Fix Is Live. The Checkout Is Dead.
10.11.2026, By Stephan Schwab
The shop owner asks her coding assistant to fix a small checkout problem. It changes a few files on the server and announces success. The home page loads. Customers still can't place an order. The assistant offers another fix, but the owner needs the last version that worked. AI lets people build useful software before they learn how to release it. A capable assistant should show them how to test a complete version and recover from a bad release before customers have to find out what happens without either.
Yesterday’s Shortcut Has Become Today’s Procedure
A change that works once can teach exactly the wrong lesson about the next change.
Imagine a shop owner who has built a small ordering application with an AI assistant. She understands her customers and knows the awkward exceptions in her business. Software releases are new territory. The first version worked on her laptop, so she copied it to a rented server. Customers placed orders. Excellent.
The next change worked too. Soon the assistant was editing files on the server itself. No copying required. Apparently, progress.
Then a change to delivery charges updates one part of the application while another still expects the old format. A customer reaches checkout halfway through the update. The application can display the basket but cannot finish the order. The owner reloads the home page. That works. Her colleague tries an actual purchase. That does not.
Customers could use the application while the assistant was still changing it. Success depended on when they placed an order and whether the old and new pieces could work together. Nobody had checked either.
Blaming the agent is comforting. It also leaves the next agent standing in precisely the same hole.
A Release Needs an Identity
You need to know which complete version passed the checks and which version customers are using.
Start with a simple question: what, exactly, is running?
“The files on the server” describes a location. It does not identify a release. If some came from yesterday’s laptop and others from this morning’s repair, the directory may contain a combination that has never existed anywhere else.
Put the application source and the instructions needed to build it under version control. Record a particular source version. Produce a versioned release package from it using a repeatable process, with dependencies fixed well enough to reproduce the intended result. Keep configuration that varies by environment separate, and keep secrets in the appropriate secret store.
That package is often called a build artifact. It might be a container image, an application archive, or a directory of static files packaged for release. The format depends on the application. The important property is that a particular package has an identity and survives unchanged while you test and deploy it.
DORA’s deployment-automation guidance recommends using the same packages in each environment, separating environment configuration, and keeping deployment scripts under version control. Those are practical ways to avoid discovering that production received something different from the thing that passed the checks.
Building again for production can introduce a different dependency or a different generated file. Changing the package after the tests certainly changes what the evidence applies to. A green result belongs to the version that earned it.
There is nothing especially glamorous here. That is one of its better features.
The Home Page Loads. Try Placing an Order.
Check the behavior people depend on, including the parts a successful page load never exercises.
For the shop, the valuable check is whether a customer can place an order with the correct delivery charge and whether the shop receives a usable record. Other checks should cover payment failures, repeated submissions, and whatever the application promises about stock.
Run fast automated checks whenever changes are integrated. Exercise the built package in a separate test environment before promoting it to production. That environment needs enough similarity to production to expose the failures you care about, using test accounts and suitable sample data. It does not need a copy of every customer’s private information.
Rehearse the deployment itself. A small shop might install the new package alongside the old one, check that it starts and can reach the services it needs, then switch incoming traffic to it. If those checks fail, customers can keep using the old version. Both versions still need compatible data while they share a database.
Martin Fowler describes a deployment pipeline as stages that build confidence through successive checks. Fast feedback comes early; more expensive checks follow. Some stages can include a deliberate human decision. The point is a visible path from a change to evidence that it can be released.
With continuous integration, developers combine changes frequently and run automated checks on the result. Continuous delivery keeps the software ready to release on demand. The owner can choose when customers get a change. Releasing every passing change automatically is continuous deployment.
A tiny application may need only a few checks and a short deployment script. Proportionality is useful. Omitting the checkout from a checkout application’s release checks is a different achievement.
A Way Back Has to Work With Today’s Data
Restoring yesterday's code does not restore yesterday's world.
Keep the last known working release available and establish how to switch back. Rehearse that procedure before treating it as a recovery plan. Check the service after promotion, too: a running process can still be failing every purchase.
Now the inconvenient part. Suppose the new version has changed how delivery charges are stored. The old version might not understand orders created since the update. Switching application packages back could exchange one failure for another.
Plan database changes so old and new application versions can coexist during the transition where possible. Adding a new field, moving usage gradually, and removing the old field later is often easier to recover from than replacing everything in one step. Some changes still require a specific forward repair or a carefully planned recovery procedure.
A backup protects against data loss. Restoring it may discard legitimate orders placed after it was taken. A refund already sent to a payment provider will not politely disappear because a database was restored. Recovery needs to account for those external effects.
For the owner, the practical question is understandable without a vocabulary exam: if the new checkout fails after three successful purchases, can we restore service while preserving those purchases and their payment records?
Ask that before the fourth customer supplies the experiment.
The Assistant Should Explain the Missing Step
Someone asking for an app online may not know which release questions to ask.
When someone asks, “Put my app online,” the assistant should find out what the app will do and where it will run. Is this a disposable demonstration, an internal tool, or a service taking customer money? What deployment process already exists? Who owns the production data? What may the assistant change?
Then it should make the proposed work concrete: record the change, run the relevant checks, build an identifiable package, try the release process in the appropriate environment, and establish recovery before promoting the result. If the project already has a launcher and deployment workflow, use them. Creating another route because it saves a prompt is a peculiar definition of efficiency.
An agent can help build and operate that process. It can inspect a failed check, improve the release script, or invoke an authorized deployment. Its session should not be the only place where the release procedure exists. Durable configuration and evidence need to survive the conversation.
Give the deployment job the permissions it needs to install an approved package and record which version went live. The assistant can edit and test code with its own, separate permissions.
Emergency repairs sometimes require exceptional action. Record what changed, bring the repair back into the normal source, and restore a known release state afterward. Otherwise, the exception quietly becomes tomorrow’s deployment system.
Easy Creation Never Included Free Operations
A provider can hide operational work from its user. The work still has an owner.
People built useful departmental applications with Visual Basic, spreadsheets, and macros long before conversational coding arrived. A helpful tool could grow into something colleagues depended on without its creator suddenly acquiring experience in testing, releases, access control, and recovery. AI can shorten the trip from idea to that responsibility.
Provider-hosted creation tools can hide much of the release machinery. That can be a sensible purchase: the provider operates a platform, and its user works within the platform’s supported boundaries. Check those boundaries, particularly where customer data and external services enter the picture.
Moving code onto your own server changes who must answer the operational questions. The experience of clicking a share button elsewhere has not answered them for you. Neither has the assistant’s enthusiasm.
There is no need to invent a secret vendor plot to explain the gap. A quick demonstration is easy to see. A reliable second release is harder to show in a launch video.
The shop owner deserves both. Turning a useful experiment into a dependable service includes making future changes ordinary enough that her colleague can keep packing orders while they happen.
The next time she asks the assistant to fix the delivery charge, there should be a complete version to test, a known way to release it, and a credible answer if it fails. Customers have enough to think about when they see what delivery costs.
Talk It Through
Tell me what is happening. I listen, ask a few practical questions, and reflect back what I see: where the risk may sit, what may be blocking delivery, and what looks worth checking next. No pitch, no obligation. Confidential and direct.
Talk it through. Practical reflection, no pitch.
Start a Conversation
