A few weeks ago, I watched an AI coding agent rewrite forty files in about ninety seconds. The code was clean. The naming was sensible. Tests were included.
Then someone asked a simple question: “If this breaks production, how do we return to where we were an hour ago?”
Nobody answered immediately. That silence said more about engineering in the AI era than most product demonstrations do.
AI can generate change at extraordinary speed. Engineering must also make that change understandable, controlled, reproducible, and safe to reverse. That is why Software Configuration Management still matters.
The discipline nobody demonstrates
AI tools get the highlight reel. We see assistants completing code, creating features, and changing entire repositories while we watch. Nobody demonstrates the discipline underneath that activity, quietly making it survivable.
SCM identifies, tracks, and controls the components that make up a software system: code, configuration, dependencies, infrastructure, environments, build instructions, and release artifacts.
When it works well, a team can answer two questions at any moment:
- What exactly is running right now?
- How do we return to a known-good state?
More than Git
SCM is often reduced to “we use Git.” That is like describing air traffic control by saying, “We have radios.”
Git records changes to source code. SCM asks more: What belongs to the system? Which version is running? How was it built? What changed? Was it approved and verified? Can we reproduce or reverse it?
SCM is not simply about managing files. It is about maintaining a trustworthy understanding of a system as it changes.
The framework that shaped my thinking
When I began working in SCM, Jessica Keyes’s work strongly influenced how I understood the discipline. She presented configuration management as a framework for organizing the software lifecycle, covering identification, change control, status accounting, verification, and auditing.
That distinction stayed with me. Early in my career, I saw a quick fix reach production without a clean rollback path. It appeared to be a coding failure, but the deeper problem was that we could not confidently reconstruct the previous state.
It was a configuration-management failure wearing the clothes of a coding failure.
Why AI raises the stakes
An AI agent may change code, dependencies, configuration, tests, and deployment instructions in one session. Most changes may be useful. A few will not be.
With an AI-generated change, intent may be incomplete or reconstructed after the fact. The reliable evidence is the engineering trail: the request, diff, review, tests, configuration, artifact, deployment, and previous trusted state.
Speed without memory is not agility. It is risk arriving faster.
AI increases the speed and volume of change. SCM provides the memory needed to manage it.
Five habits I still rely on
Keep changes small
Make generated work reviewable enough to understand and reverse.
Record intent
Explain why a change exists, not only what the diff contains.
Define environments
Version infrastructure and runtime configuration wherever practical.
Protect the trail
Track dependencies, artifacts, approvals, tests, and deployments.
Plan recovery
Know how to reverse a change before production needs the answer.
The one thing worth remembering
The AI era will not reward only the engineers who can prompt fastest. It will reward the engineers who can explain what changed, why it changed, what is running, and how to undo it.
That confidence does not come from the model. It comes from engineering discipline.
So when an AI tool impresses you with how much it built in so little time, ask the boring question first:
Can we undo it?
I write these field notes to connect what engineering has taught us with what AI is changing now.