[How-To] Change Control at Ludicrous Speed
How to Replace Logjams with AI and Keep Governance Without the Drag
If you’ve ever sat through a change control board or architecture review board (ARB), you probably have strong feelings about them. I do.
As a network engineer and later as an enterprise architect, I spent a lot of time in those rooms:
Environments where you had to submit a change two weeks in advance, present it to a panel, fix whatever they didn’t like, and if you missed your resubmission window you were waiting another few weeks.
ARBs that met weekly and moved quickly.
ARBs that met once a month and became a parking lot for every controversial idea.
And then there were the “emergencies.”
One of the most frustrating experiences I had was an emergency change that was time‑critical and dependent on another high‑level request. I convened an emergency CAB (eCAB), walked through exactly what was going to happen, and was very confident I could contain the impact. Most of the people in the room agreed and were ready to approve.
Except one.
The blocker wasn’t that the change was reckless. It was that this one person didn’t understand the technical approach and didn’t want to be accountable if something went wrong. I understood where he was coming from, but it was surreal to be unable to execute a solid, time‑sensitive plan simply because one person didn’t feel comfortable enough with the details.
When we finally got approval later, the approach worked exactly as designed. But the delay, the friction, and the feeling of being blocked by fear and lack of understanding, not by actual risk, is the kind of thing that made me despise traditional change control.
To be fair, part of the reason we review changes with multiple people and disciplines is to get that broader perspective. I don’t want to lose that. But in this case, the blocker wasn’t a better idea or a real risk I’d missed, it was one person’s discomfort with the technical details and the accountability that came with saying “yes.” If we’d had an integrated, efficient AI process generating a clear risk assessment and validating the plan, and that system had agreed with my approach, I suspect he would have felt a lot more at ease. It wouldn’t just be “David says this is safe,” it would be “David and an independent system both say this is safe.”
In all of these cases, the intent was the same:
Document the change.
Communicate it so no one is surprised.
Make sure there’s a solid plan and rollback path.
Avoid taking down critical infrastructure with a bad decision.
The cost was speed. Every layer of review added safety, but also latency, meetings, and human overhead. And in many orgs, ARBs turned into exactly what they were supposed to prevent: logjams and political arenas instead of collaborative design reviews.
Now that I’m spending more time in the software world, and watching what’s possible with modern CI/CD and AI, I’m convinced we can do better:
Keep the governance intent.
Drastically reduce the human friction.
Let teams move at something closer to ludicrous speed without blowing up prod.
This is a how‑to for modernizing change control.
1. What Change Control Is Actually For (Not What It Became)
At its best, change control is trying to:
Reduce blast radius – don’t take down the core network or a shared platform with a risky change.
Coordinate dependencies – let other teams know what’s changing so they can prepare.
Enforce basic hygiene – backups, rollback plans, maintenance windows, approvals.
Create an audit trail – for compliance, incident analysis, and accountability.
At its worst, change control becomes:
A place where people argue instead of design.
A calendar bottleneck (monthly CAB/ARB) that forces teams into big‑bang changes.
A paperwork factory where everyone fills out the same form, no one reads it deeply, and approvals are rubber‑stamped.
The question isn’t “should we have governance?” It’s:
How do we keep the safety and coordination while eliminating the logjam and ceremony?
Modern CI/CD and AI give us a path.
2. Move Governance Into the Pipeline, Not the Calendar
Traditional change control is calendar‑driven:
Submit a form.
Wait for the next CAB/ARB meeting.
Defend your change.
Hope you didn’t miss a field.
Modern change control should be pipeline‑driven:
As you work on a change, automation and AI:
Classify its risk.
Check the standard requirements.
Generate a clear summary and plan.
Humans only step in where judgment is actually needed.
We’re not abolishing governance; we’re moving it closer to the code and letting machines handle the boilerplate.
3. Step‑by‑Step: Change Control at Ludicrous Speed
Step 1 – Classify changes by risk
Not all changes deserve the same process.
Create a simple risk taxonomy, for example:
Standard changes – low risk, well‑understood, repeatable:
Scaling a service up/down.
Rotating certificates.
Deploying a patch release with no schema changes.
Normal changes – moderate risk:
New features.
Config changes with limited blast radius.
High‑risk changes – potentially large blast radius:
Core network changes.
Shared database schema changes.
Major infra migrations.
Then:
Encode this in your change system (Jira, ServiceNow, Linear, etc.).
Let developers/engineers propose a risk level.
Use AI as a second opinion:
Given the description, code diff, and affected systems, have an LLM suggest:
“This looks like a standard change.”
“This touches shared infra; treat as high‑risk.”
The goal: only high‑risk changes should need heavyweight human review. Everything else should flow via automation and lightweight approvals.
Step 2 – Turn checklists into automation
Most CAB/ARB forms are checklists in disguise:
Do you have a backup?
What’s the rollback plan?
What’s the maintenance window?
Who’s impacted?
Has security approved?
Instead of asking humans to retype these answers every time, do this:
Define a standard change template per risk level:
Required fields.
Required checks (tests, approvals, sign‑offs).
Required artifacts (runbook link, rollback plan, diagrams).
Wire these into your CI/CD and tooling:
CI pipeline checks:
Tests passed.
Security scans passed.
Deployment plan validated (e.g., canary, blue‑green).
Infra checks:
Backups exist.
Health checks defined.
Monitoring/alerts configured.
Use policy as code where possible:
For example, Open Policy Agent (OPA) or custom rules that say:
Infra checks:
“You can’t deploy to prod unless X, Y, Z are true.”
“High‑risk changes require two approvals.”
Now the “checklist” is mostly automated gates, not a PDF.
Step 3 – Use AI to pre‑answer CAB/ARB questions
For each change, an LLM can assemble a change brief automatically from:
The PR description and diff.
Linked tickets/issues.
Deployment strategy (from your pipeline config).
Observability setup (from your monitoring config).
Ownership metadata (who owns this service).
The AI‑generated brief can answer:
What is changing?
Summarized from the PR and diff.
Why are we changing it?
Pulled from the linked Jira/Linear ticket.
What’s the risk level and blast radius?
Inferred from which services and data stores are touched.
What’s the deployment and rollback plan?
Derived from your CI/CD config (e.g., canary, blue‑green, feature flags).
What’s the maintenance window and go‑back cut‑off time?
Calculated based on your deployment schedule and rollback strategy.
Has security/compliance signed off?
Checked via policy as code and approvals in your tooling.
Instead of humans filling out a form, they review and correct an AI‑generated brief. This way even people who aren’t deep in the technology have a clear, structured explanation of what’s happening and why, backed by an independent assessment of risk and rollback options.
For high‑risk changes, this brief becomes the input to a short, focused review, not a two‑week process.
Step 4 – Shorten the human loop
Once you have:
Risk classification.
Automated checks.
AI‑generated briefs.
You can redesign the human part:
Standard changes:
Fully automated.
Logged for audit.
No CAB/ARB meeting.
Normal changes:
Async review:
AI‑generated brief posted to a channel (Slack/Teams).
Owners have 24–48 hours to object or request changes.
Silence = consent.
Optional quick huddle if something looks risky.
High‑risk changes:
Short, focused review meeting:
Everyone reads the AI‑generated brief ahead of time.
The meeting is about trade‑offs and decisions, not filling in fields.
Decisions and conditions are captured back into the system.
You’ve kept governance, but you’ve:
Removed the calendar bottleneck for most changes.
Reduced meeting time for the rest.
Increased consistency by having AI and automation enforce the basics.
4. Examples: How This Looks at Different Scales
Enterprise example
A core database schema change is proposed.
The engineer opens a ticket and PR; the system:
Classifies it as high‑risk.
Runs all required checks in CI (tests, migrations in staging, backups verified).
Uses AI to generate a change brief:
What’s changing.
Affected services.
Risk assessment.
Deployment and rollback plan.
Go‑back cut‑off time.
The ARB meets weekly, but:
They review a queue of AI‑generated briefs, not raw forms.
Most time is spent on “Is this the right design?” not “Did you think about backups?”
After approval, the change is executed via CI/CD with:
Feature flags.
Canary rollout.
Observability watching for anomalies.
Mid‑size startup example
A startup with GitHub Actions, ECS, and Sentry:
Classifies changes as standard/normal/high‑risk in Linear.
Uses GitHub Actions and a small LLM script to:
Generate change summaries from PRs.
Post them to a #change‑log channel.
Standard changes:
Auto‑approved when CI passes.
Logged to the channel for awareness.
Normal changes:
Auto‑approved unless someone reacts in Slack within 24 hours.
High‑risk changes:
Trigger a 30‑minute design review with an AI‑generated brief as the pre‑read.
Solo dev example
Even as a solo dev, you can benefit from “change control” without bureaucracy:
Every significant change:
Has a Linear issue.
Has a PR with a clear description.
A small script or Cursor prompt:
Summarizes the change.
Asks: “What’s the rollback plan?” and “What’s the blast radius?”
You’re forcing yourself to think like a CAB, but the “board” is you plus AI, and the process is minutes, not weeks.
5. Pitfalls When Modernizing Change Control
Pitfall 1: Keeping the old meetings and adding AI on top
If you just bolt AI onto the existing CAB/ARB calendar, you’ll get better paperwork but the same bottlenecks.
Do this instead:
Use AI and automation as a reason to change the process, not just the artifacts:
Fewer meetings.
More async review.
More automation for standard changes.
Pitfall 2: Treating all changes as high‑risk
If everything is high‑risk, nothing is.
Do this instead:
Be ruthless about your risk taxonomy.
Reserve heavyweight review for truly high‑impact changes.
Let automation handle the rest.
Pitfall 3: Over‑trusting AI risk assessments
AI can help classify risk, but it doesn’t know your regulators, your politics, or your weird legacy systems.
Do this instead:
Treat AI as a second opinion, not the final word.
Make it easy for humans to override the risk level with a reason.
Pitfall 4: Ignoring the human side
If people don’t trust the new process, they’ll route around it.
Do this instead:
Start with one team or one change category.
Show that time‑to‑approval drops and incidents don’t increase.
Use that as a case study to win over skeptics.
6. Checklist: Change Control at Ludicrous Speed
Use this as a roadmap, not a test you have to pass on day one.
Risk and classification:
We have a simple risk taxonomy (standard / normal / high‑risk).
We classify changes by risk in our tooling.
We use AI as a second opinion on risk level.
Automation and policy:
Our standard CAB/ARB checklists are encoded as automated checks where possible.
We use policy as code to enforce basic rules (tests, approvals, environments).
Standard changes can be fully automated with an audit trail.
AI assistance:
We generate AI change briefs from PRs, tickets, and configs.
High‑risk changes come with an AI‑drafted summary, risk assessment, and deployment + rollback plan.
Humans review and correct AI output instead of writing everything from scratch.
Process design:
Standard changes: no meetings, just automation and logging.
Normal changes: async review with clear SLAs (for example, 24–48 hours).
High‑risk changes: short, focused reviews with pre‑reads, not long status meetings.
If you can check most of these, you’ve kept the spirit of change control: safety, coordination, auditability, while stripping away a lot of the ceremony and delay.
You haven’t abolished governance. You’ve just moved it out of the calendar and into the pipeline, with AI doing the boring parts.