Verifiable outcomes over convincing outputs.
A generated patch, an eloquent explanation, or a green dashboard is not the outcome. We ask what changed, what was observed, and what could falsify our conclusion.
A DBRE.tech practitioner statement · October 2026 · Draft v0.1
The Agentic Engineering Manifesto.
AI can generate software faster than we can understand its consequences. Engineering must therefore move the boundary of responsibility—not abandon it.
Alex Ivanov · DBRE.tech
We build with agents because they increase what one engineer or team can explore and deliver. But output is not evidence, confidence is not authority, and automation is not accountability.
This is a personal engineering proposal—not an industry standard, a claim of consensus, or a rejection of AI-assisted development. It is a set of priorities to apply when speed and reliability compete.
What we value
Five deliberate preferences.
The second term of each pair still has value. The first is what we protect when the two come into conflict.
Explicit contracts over clever implementation.
We specify expected behavior, failure paths, and boundaries before optimizing how quickly an agent produces code.
Executable safeguards over good intentions in prompts.
Isolation, access control, tests, and policy gates have authority that polite instructions do not.
Small, recoverable changes over maximum generation speed.
The ability to produce more code should not force us to deploy larger changes or accumulate uncertainty faster.
Accountable ownership over unbounded autonomy.
An agent may propose, implement, and investigate. Someone or some explicitly governed process must still own consequential decisions and their effects.
How we work
Ten commitments that can be challenged.
Principles become meaningful when they change the acceptance criteria for real work. These are working commitments, not an assurance that any particular agent or application meets them.
Specify before delegating.
An executable task begins with intent, acceptance criteria, prohibited behavior, and an understood scope.
Separate authorship from verification.
An agent cannot silently weaken the tests or policy that define its success. Independent checks matter more than independent model names.
Make the verifier prove it can fail.
Intentionally broken code must make CI fail. A harness that is always green is part of the defect.
Preserve system legibility.
We design modules, contracts, logs, and repository knowledge so a human can reconstruct what happened.
Treat permission as architecture.
Read-only exploration, draft changes, and production mutation are distinct capabilities, not stages of one implicit permission.
Keep uncertainty visible.
Unknown means unknown. We do not turn incomplete observations into successful status messages.
Optimize for maintenance, not output volume.
Generated code is a liability until someone can explain, test, operate, and improve it.
Protect the change path.
We favor small batches, compatibility checks, rollback or roll-forward plans, and progressive exposure.
Use automation to reduce toil and expose judgment.
The point is not to remove engineers from difficult decisions; it is to spend less time repeating mechanical steps.
Revise the rules when evidence disagrees.
A manifesto is not an exemption from measurement. Practices should evolve when they fail to improve results.
Put it to work
A small change can expose the entire philosophy.
Ask an agent to add a configuration check. Before it writes code, define a failing test and the forbidden side effects. Let the agent implement the change. Then deliberately break the check, confirm the CI job fails, and verify the running result—not just the generated report.
That exercise tests specification, harness integrity, independent verification, and the limits of automation. A checklist alone would not.
INTENTCONTRACTIMPLEMENTATIONFALSIFICATIONOBSERVED RESULT
Database Reliability Extension
The same values become stricter when data is at risk.
A database agent must distinguish a recommended change from an authorized one, an accepted API request from an effective setting, and a completed backup from demonstrated recovery. Read the database-specific interpretation of this manifesto.
Read the Agentic DBRE Manifesto →Origins and context
A response to a change in how software is made.
The values-over format is inspired by the 2001 Agile Manifesto, without claiming its authors' endorsement. This proposal also draws on reliability engineering and contemporary work on agent harnesses. Its wording and commitments are independent DBRE.tech editorial work.
Further reading: Harness Engineering, Google SRE: Embracing Risk, and Test-First Engineering.