In my last post I finished with a mention of how AI is putting pressure on software deployment because creating new apps has become easier than ever, so the bottleneck has moved to deploying those apps and making them useful.

But AI is changing software deployment in more ways than that. I thought I would write a short post to map out what I am seeing. Three changes stand out, and each is a different kind of change: more of what we already deploy, new kinds of things to deploy, and a new actor - AI itself - doing the deploying.

More Deployments

AI makes it easy to build more software. So naturally there will now be more software to deploy. This is where my last post finished: Undeployed software is like a tree falling in the forest when nobody is there. Did it make a sound?

As more teams across an organization build more apps with AI, they will put pressure on deployment teams and infrastructure to "make the apps go live". An AI generated app that can better predict tomorrow's stock price based on transaction flows will need to be deployed and granted access to the appropriate data sources in order to generate value. The volume of candidates for deployment will increase and the deployment teams will need to handle this somehow.

These apps aren't different in nature. They're the same old apps - simple batch jobs, web apps, apis, etc. What's different is the volume and rate of creation.

AI Workloads

Separately, there is now a new kind of workload that needs to be deployed - the AI workload. I see at least three flavors. Two are genuinely new: inference and training. They need access to special hardware (GPUs), which is scarce and expensive, so scheduling, bin-packing and cost controls matter in a way they don't for a typical web app. They also have different runtime characteristics, such as long-running training jobs or latency-sensitive inference serving, that stress deployment and autoscaling tooling built for stateless services.

The third flavor is agent runtimes. These are new workloads too, but architecturally they resemble ones we already know - batch jobs, orchestration systems, stateful sessions. They are not purely stateless web apps / services, but otherwise they are relatively familiar to deploy.

AI Operations

Finally, there is the fact that AI will itself be performing most of the tasks related to software deployment and operations. Personally, I have already switched to a mode where I never do operational tasks without firing up Claude Code first.

I launch it in my "techops" directory where it has access to runbooks and its own memory files. Prior to assigning a task, I grant the access I think is appropriate - config-only access, full prod access, non-prod access, etc. Then I assign the task, for example: "A user reported a temporary build failure yesterday at 9:30pm PT which later succeeded. Please investigate". The agent will use the docs, runbooks and memory to decide what to do and in most cases provide a report fairly quickly.

My current practice is still manual and experimental. But soon this will become much more formalized and more repeatable across teams and organizations. This formalization will require answering questions such as:

  • Where does the agent run?
  • How is it plugged into the workflow (slack, linear, CLIs, web UIs, etc)?
  • How does it gain the access it needs, and just that?
  • How is it specialized (you are a security debugger | troubleshooter | customer agent, etc)?
  • How does it access, and modify, context (memory, docs, etc)?
  • Is there a greater taxonomy or structure shared between agents and the systems they work on, and if so, what does it look like?

Summary

AI is changing software deployment and operations in several distinct ones. When this comes up in your organization, I think it will be useful to separate out which of these aspects you're actually talking about. Maybe one of these is more important than the others. Being specific helps with focus. And there are probably even more aspects that I have missed. Let me know what you think.

At ConfigHub, we think the complexity and criticality of software ops have reached a point where the old tools are not good enough anymore. The AI tsunami is pushing this trend into overdrive. We're working on a different kind of config management that can better meet the needs of today's and tomorrow's software operations.