Databasus showed an example how to use AI in large open source projects

Published: (December 29, 2025 at 05:42 AM EST)
6 min read
Source: Dev.to

Source: Dev.to

Open source projects are increasingly adopting AI tools in their development workflows

But when your project handles sensitive data like database backups, encryption keys, and production environments, the “move fast and break things” approach isn’t an option.

Databasus, a backup tool for PostgreSQL, MySQL and MongoDB, recently published a detailed explanation of how they use AI — and it’s a masterclass in responsible AI adoption for security‑critical projects.

AI usage in Databasus

The AI transparency problem in open source

Many open‑source projects quietly integrate AI‑generated code without disclosure. Some embrace “vibe coding,” where AI writes entire features with minimal human verification. For projects handling cat photos or todo lists, this might be acceptable.

But for tools managing production databases with sensitive customer data, the stakes are entirely different.

Databasus handles database credentials, backup encryption, and access to production systems used by thousands of teams daily. A single security vulnerability could expose sensitive data across multiple organizations. This reality forced the maintainers to establish clear boundaries around AI usage and document them publicly.

How Databasus uses AI as a development assistant

The project treats AI as a verification and enhancement tool rather than a code generator. You can read their full AI usage policy in the project README or on the website FAQ.

Below is their approach broken down into specific use cases:

AI Usage TypePurposeHuman Oversight
Code reviewVerify quality and search for vulnerabilitiesDeveloper reviews all findings
DocumentationClean up comments and improve clarityDeveloper approves all changes
Development assistanceSuggest approaches and alternativesDeveloper writes final implementation
PR verificationDouble‑check after human reviewDeveloper makes final approval decision

AI never operates autonomously; every suggestion passes through developer verification before reaching the codebase.

What Databasus doesn’t use AI for

The project maintains strict boundaries around AI limitations:

  • No autonomous code generation – AI doesn’t write complete features or modules.
  • No “vibe code” – Quick AI‑generated solutions without thorough understanding are rejected.
  • No unverified suggestions – Every line of AI‑suggested code requires human verification.
  • No untested code – All code, regardless of origin, must have test coverage.

AI‑generated code is treated with the same skepticism as code from junior developers. Identical quality standards apply whether code comes from AI, external contributors, or core maintainers.

Quality gates that catch bad code regardless of source

Databasus enforces code quality through multiple automated and manual checks. The same standards apply to human and AI‑generated code.

Quality GatePurposeApplies To
Unit testsVerify individual component behaviorAll code changes
Integration testsTest component interactionsAll features
CI/CD pipelineAutomated testing and lintingEvery commit
Human code reviewArchitecture and security verificationAll pull requests
Security scanningIdentify vulnerabilitiesEntire codebase

Both “bad human code” and “AI vibe code” are rejected if they don’t meet these standards.

The role of experienced developer oversight

Automated checks catch many issues, but human judgment remains essential. Databasus emphasizes verification by developers experienced in large, secure projects. This oversight evaluates:

  • Architecture decisions and long‑term maintainability
  • Security implications that tools might miss
  • Edge cases and failure scenarios
  • Code readability and documentation quality
  • Performance characteristics under production load

Fast issue‑resolution and security‑vulnerability response times show this oversight works in practice.

Why this approach matters for sensitive projects

Database backup tools sit at a critical point in infrastructure security. They read production databases, handle encryption keys, and store backups containing sensitive information. A compromised backup tool could expose an organization’s entire data estate.

Consequently, Databasus adopts a conservative AI approach:

  • Trust is earned – The tool runs in production with access to sensitive data.
  • Failures have consequences – Backup failures or breaches affect real businesses.
  • Compliance requirements – Many users operate under strict regulatory frameworks.
  • Enterprise adoption – Large organizations scrutinize security practices before deployment.

The AI policy and quality‑gate framework provide a practical blueprint for any security‑critical open‑source project.

AI Transparency and Code Quality

The ache 2.0 license allows anyone to inspect the code, but inspection only helps if the code itself is maintainable and well‑tested. AI‑generated code without proper verification would undermine this transparency.

Practical Lessons for Other Projects

Databasus provides a template for security‑conscious open‑source projects considering AI adoption. Key principles:

  • Document AI usage publicly – Don’t leave users guessing whether AI touched security‑critical code.
  • Establish clear boundaries – Define what AI can and cannot do in your development process.
  • Maintain quality standards – Apply the same requirements to all code regardless of origin.
  • Require human verification – AI suggestions should inform decisions, not make them.
  • Invest in automated testing – Let computers catch bugs so humans can focus on architecture.
  • Prioritize maintainability – Today’s AI shortcut becomes tomorrow’s technical debt.

These principles balance AI’s productivity benefits with the safety requirements of production systems.

The Middle Path Between AI Rejection and AI Dependency

Some projects reject AI entirely, fearing code‑quality degradation. Others embrace AI without guardrails, shipping whatever the model generates. Databasus demonstrates a middle path that captures AI benefits while maintaining quality standards.

Comparative Overview

ApproachCode QualityDevelopment SpeedSecurity Risk
No AI usageVaries by developerSlowerDepends on practices
Uncontrolled AIOften poorFast initiallyHigh
Databasus approachHigh (enforced)ModerateLow (verified)

The trade‑off of slightly slower development for higher quality and lower risk makes sense for projects handling sensitive data.

What the Open‑Source Community Can Learn

Databasus published its AI usage policy in the main README, ensuring every user and contributor can see it. This transparency serves multiple purposes:

  • User confidence – Deployers know AI hasn’t autonomously generated security‑critical code.
  • Contributor guidance – New contributors understand quality expectations before submitting code.
  • Industry leadership – Other projects can reference this policy when establishing their own AI guidelines.
  • Accountability – Public documentation creates pressure to follow stated practices.

The project also addresses AI‑related questions that arise in issues and discussions, showing they take community concerns seriously.

Conclusion

AI tools are transforming software development, and open‑source projects must decide how to integrate them responsibly. Databasus demonstrates that you can use AI to enhance developer productivity without compromising code quality or security.

The key insight is treating AI as a junior developer who needs supervision, not as an omniscient coding oracle. This means:

  1. Human verification of all AI suggestions.
  2. Comprehensive test coverage.
  3. Consistent quality standards applied to all code, regardless of origin.

For projects handling sensitive data in production environments, this careful approach isn’t optional—it’s a requirement. Databasus shows that responsible AI adoption involves:

  • Documenting practices publicly.
  • Maintaining strict quality gates.
  • Never letting AI operate autonomously on security‑critical code.

Other open‑source projects—especially those dealing with security, infrastructure, or sensitive data—should study this example. The middle path between AI rejection and AI dependency exists, and it’s the right choice for production‑grade open‑source software.

Back to Blog

Related posts

Read more »