An AI agent I was running committed code directly to main. The code was excellent. It worked, followed our architecture, and met the requirement. There was no defect waiting to vindicate our code review process.
I made the agent revert it and put the work in a feature branch anyway.
The work went onto the appropriate branches, became pull requests, and passed through the same review process required for code written by a human developer. That may sound like ceremony for its own sake. The work was already done, and the result was good. Reverting it created additional steps without changing the final code.
That was exactly why the decision mattered. Standards are easy to defend when they catch a problem. They are harder to defend when the shortcut worked.
The Successful Shortcut Is the Real Test
Most teams do not abandon a standard by announcing that it no longer matters. They make one reasonable exception. The code is already working. The developer is senior. The change is small. The deadline is close. The AI produced exactly what we wanted.
Why slow down now?
You do not follow review standards only when you expect a problem. You follow them because you cannot know which change contains the problem until the review happens. Our pull request did not expose a hidden defect, but that does not make the process wasteful. It means this particular change survived the control designed to give another person an opportunity to inspect it.
The next change may not.
If I had accepted the direct commit because the code was excellent, I would have taught the team that the standard applies only when the outcome looks uncertain. I also would have created a new argument for every future exception: this code looks good too. The successful shortcut is dangerous because it appears to prove the safeguard was unnecessary.
Principles Require Judgment
Constantia was the Roman virtue of firmness, steadiness, and consistency. In engineering leadership, it is the ability to keep your operating principles intact when pressure or convenience makes an exception attractive. That does not mean refusing to adapt.
I tell my teams I prefer principles over rules. A rule says, “Do this.” A principle explains what the rule is protecting and gives you enough context to recognize when an exception is justified.
The rule was that changes to main arrive through pull requests. The principle was that production code deserves review, traceability, and a clear record of how it entered the codebase.
Real exceptions happen. A production outage might require an emergency change before the normal review cycle can complete. The business may rationally accept that risk to restore service. Constantia does not require pretending every situation is identical. It requires naming what changed, understanding which protection is being suspended, limiting the exception, and restoring the normal process afterward.
Refusing every exception regardless of circumstance is stubbornness in Roman clothing. Allowing every convenient exception is not flexibility. It is drift.
The Standard Matters Most When It Costs You
At a healthcare SaaS company, we deployed updates for a new reporting feature after the changes had been tested and looked good in the test environment. After deployment, the first production report was run, and it brought SQL Server to its knees. The report took almost 15 minutes to complete.
The first suggestion was to roll back. That was reasonable. Production was affected, the night was already long, and rollback is often the cleanest path back to safety. I believed the query could be tuned, and that the report could still be made useful without abandoning the deployment entirely.
We did the work to fix the query. Then the next temptation appeared: apply the fix directly in production and be done with it.
That would have made the night shorter. It also would have bypassed the code approval process at the exact moment when the team was tired, pressure was high, and everyone wanted the problem to be over. The query change needed to be tracked in source control and show the same progression through the system as every other piece of code.
I made the call to follow the process all the way through. The fix went through the normal approval path before it reached production. It added about another hour to an already long night.
I still believe it was the right call. The standard had a cost, but it also preserved value. At my level, this is moral discipline as much as technical discipline. I have an obligation to preserve business information for my employer. Source control, review history, and deployment progression are part of that information.
A process that only matters when everyone is rested, calm, and ahead of schedule is not a standard. It is a preference with good branding.
The Developer Changed. The Standard Did Not.
AI-assisted development makes this distinction more important because AI can remove the friction that once gave teams time to notice they were bypassing their own process. An agent can produce a working feature, commit it, and move to the next task before a human developer would have finished typing the first version. That speed is useful. It also makes a completed result feel inevitable.
Once good code exists on main, reverting it feels wasteful. The team can see the desired outcome, and the process begins to look like an obstacle between working software and production. But the control was not created because human developers type slowly. It was created because software changes carry risk.
The developer changed. The standard did not.
Our AI agents receive the same stories as human developers, in the same format, with the same acceptance criteria. They work through branches, create pull requests, receive review, and meet the same definition of done. That consistency is not punishment for the agent. It protects the codebase from treating speed as evidence of correctness.
Exceptions Need a Record
Healthy teams make exceptions. The difference is whether the exception remains visible. If an emergency change goes directly to main, record why normal review was bypassed. Name the risk accepted, create the follow-up review or remediation work, and make clear when the exception expires.
This is the same discipline required for technical debt. A tradeoff can be rational. It becomes neglect when the original reason and ongoing cost disappear from view.
The record matters because organizations forget. The person who approved the exception moves on. The emergency becomes a story nobody remembers clearly. The code remains, and the next developer assumes the unusual path must be normal.
Receipts preserve intent.
They let the team say, “We broke from our process for this reason, accepted this risk, and restored the control afterward.” Without that record, exceptions quietly become precedent.
Consistency Protects the Team
Standards that apply selectively are political tools. If a junior developer must use the pull request process but a senior developer can bypass it, the standard is about rank. If human-written code receives scrutiny but AI-generated code receives a pass because it arrived quickly, the standard is about convenience.
Consistent process gives the team something sturdier than personality to rely on. A developer does not need to win an argument with the most senior person in the conversation. They can point to the shared principle and the control that supports it.
That protects quiet people, and it also protects leaders. The manager does not have to invent a new judgment for every change. The operating model already answers the normal case, leaving leadership attention for the situations that genuinely require an exception. Consistency reduces the emotional and political cost of doing the work correctly.
Keep the Opportunity to Catch the Problem
The direct-to-main incident did not end with a dramatic discovery. No reviewer found a dangerous bug, and the rewritten pull requests did not save production. The process worked in a less theatrical way.
It preserved the opportunity for review, kept the commit history traceable, confirmed that our standards applied to AI-generated code, and prevented one successful shortcut from becoming permission for the next one.
That is what constantia looks like in practice: not rigid obedience to every rule or leadership maxims repeated while conditions are easy, but a stable operating principle applied when bypassing it would be faster and the immediate result appears safe.
Everyone has standards until they become inconvenient. Constantia is what keeps them real.
Receipts
- Direct-to-main incident: An AI agent committed working, standards-compliant code directly to
main. The team required the commits to be reverted and recreated on the appropriate branches. - Normal process restored: The changes returned through pull requests and code review under the same process used for human developers.
- Outcome: Review found no defect. The value of the intervention was preserving traceability, consistent enforcement, and the opportunity to catch an issue before production.
- Reporting incident: At a healthcare SaaS company, a deployed reporting update caused a production SQL Server report to run for almost 15 minutes. The query was tuned, but the fix still went through source control and the normal approval process instead of being patched directly into production.
- Related principle: The treatment of explicit exceptions and visible tradeoffs connects to Tech Debt Is a Choice, Not a Failure.