The laws that shape reliable software.

Consider an illustrative scenario: a service returns query diagnostics as JSON. An AI coding agent removes duplicate formatting logic, reorganizes the response fields, and standardizes null handling. All its unit tests pass. The response remains valid JSON and is closer to the documented schema.

A downstream operational dashboard breaks because it parses an undocumented field, treats a missing value differently from an explicit null, and expects a stable sort order. The agent improved code quality locally while worsening reliability globally.

No single maxim resolves this. DRY supports consolidation; YAGNI discourages unnecessary generality; Hyrum's Law predicts hidden consumers. The engineering task is to discover which commitments the change actually affects.

With enough consumers, someone eventually depends on behavior you never promised. For databases, the implicit interface is often larger than the schema: result ordering without an explicit ORDER BY, subtle SQL dialect behavior, query latency, driver errors, connection handling, or replication timing can all become operational expectations.

That does not mean preserving every accidental behavior forever. It means discovering dependency before declaring an internal detail safe to change. Inventory consumers, observe actual requests, run compatibility tests, and communicate migration windows where necessary.

Database decision: when replacing a reporting query with a materialized read model, verify not only row-level correctness but also freshness expectations, ordering guarantees, parameter conventions, and failure behavior. An answer that is faster but stale can be a regression for a particular consumer.

The software design often reflects how teams communicate. In a large database fleet, one team may own Terraform, another the CI pipeline, another database operations, and application teams may own the actual workload. A change can pass every technical review while still having no single owner accountable for post-change verification.

This is not solved by another service or abstract base class. A useful architecture review asks: Who can authorize the change? Who understands its consumers? Who watches the rollout? Who acts when the rollback path is not available?

Agentic implication: an autonomous workflow must make these ownership boundaries explicit. Tool access is not operational authority.

A team optimizes for successful CI runs, code coverage, or the number of agent-generated pull requests. The target goes up. That tells us little about whether incidents declined, customer-facing latency improved, or recovery became safer.

A database-specific variation is equally familiar: EXPLAIN shows a new execution plan, but end-to-end p95 latency does not materially change. The plan is evidence about execution, not the final business outcome. Our local PostgreSQL case studydocuments precisely this distinction.

Use a counter-metric for every convenient proxy. If change volume rises, watch escaped defects and time to restore service. If throughput improves, watch tail latency and saturation. If tests pass, ask whether they would catch a deliberate violation.

Single Responsibility / Separation of Concerns:keep collection, policy evaluation, execution, and verification distinct. The purpose is not class count; it is limiting the blast radius when one responsibility changes.

Dependency Inversion: high-level safety policy should not depend on one AWS SDK call or the availability of a particular SQL connection. A small interface permits deterministic policy tests. The remaining SOLID principles—Open/Closed, Liskov Substitution, and Interface Segregation—are useful when variation and substitutability actually exist. They are not instructions to add inheritance to every script.

DRY: centralize one business rule instead of implementing production-approval logic independently in three places. But avoid merging two pieces of code merely because their text looks alike; they may change for different reasons.

KISS and YAGNI: start with a constrained workflow that handles one class of incidents safely. Do not build a universal database agent platform before demonstrating a useful, measurable operation. YAGNI is not a reason to skip tests, monitoring, or recovery preparation; those are what make future changes cheap.

Suppose the same organization needs an Aurora parameter inspector, a PostgreSQL index advisor, and a ClickHouse incident summarizer. They all read evidence, evaluate it, and produce recommendations. Should they share a common engine?

The strongest design may be three small tools with a shared evidence contract. Revisit the decision after real duplication emerges. This is an illustrative design exercise, not a claim about a deployed DBRE.tech product.

1. Which documented and undocumented consumers could observe this change?
2. Whose operational boundary will the change cross?
3. Which metric could improve while the real outcome gets worse?
4. What complexity are we adding for a future requirement we have not demonstrated?
5. Which regression or operational test would cause us to reject the change?

These questions are appropriate whether the patch was written by a staff engineer, an intern, or an AI agent.

Hyrum Wright — Hyrum's Law ↗

Melvin Conway — Conway's Law ↗

Martin Fowler — YAGNI ↗

Martin Fowler — Design Stamina Hypothesis ↗

Further reading: Robert C. Martin, Clean Architecture; John Ousterhout, A Philosophy of Software Design. Goodhart's Law is used here as a warning about optimizing proxies, not as a precise predictive theorem.