Four Ona Automations that remediate CVEs, close stale PRs, remove dead feature flags, and update docs to keep codebases clean without human involvement.
Every engineering org has stale PRs, dead feature flags, outdated docs, and unpatched CVEs. Here's how to fix all of it with a fleet of Ona Automations running in the background.
Codebases rot over time as small bits of neglected work accumulate. Pull requests sit open after the author moves on, feature flags linger long after experiments end, documentation drifts as code changes, and security vulnerabilities pile up because remediation is repetitive and rarely urgent.
None of these are hard problems on their own. They persist because they compete for attention with feature work, incidents, and deadlines, and they almost always lose. As a result, this maintenance work doesn't get done, and the codebase degrades gradually.
That degradation compounds across the organization. Stale pull requests create merge conflicts, dead feature flags add complexity to every code path they touch, outdated documentation wastes the time of every engineer who reads it, and unpatched vulnerabilities turn into audit findings. Each issue is minor in isolation, but together they slow teams down and make change riskier over time.
Ona Automations run on schedules or in response to events, execute in secure isolated environments, and work across your entire codebase. They're built for exactly this kind of work: repetitive, well-defined tasks that need to happen consistently but never get prioritized by humans.
Here are some of the hygiene automations we run at Ona. If you want to try a couple of them out yourself, check out the Ona template library.
What it does: Runs vulnerability scans (using tools like Snyk), feeds the output to an Ona agent, and iterates until all vulnerabilities are resolved, not just the first pass. It keeps scanning and fixing until the codebase is clean.
Why it matters: Most teams run security scans. Fewer actually act on every finding. Remediation is tedious: update the dependency, check for breaking changes, run tests, open a PR. Multiply that by every vulnerability across every repo and it's easy to see why CVEs pile up. This is organizational-scale work that can't be solved one developer at a time.
How it's configured: The automation integrates your existing scanning tools with Ona's agent execution. The scan output becomes the agent's task. The agent updates the dependency, runs tests in an isolated environment, and opens a PR. If the scan still shows vulnerabilities after the fix, the agent iterates. The loop runs until the codebase is clean.
What it does: Scans all open PRs across our repos. Any PR older than two weeks with no activity gets closed automatically.
Why it matters: Zombie PRs create noise. They clutter dashboards, cause merge conflicts when someone finally tries to revive them, and make it harder to see what's actually in flight. Closing them forces a clean decision: if the work still matters, reopen it with a fresh branch. If it doesn't, it's gone.
How it's configured: A scheduled Ona Automation runs daily. It checks PR age and last activity date. PRs that exceed the threshold get closed with a comment explaining why. No human involvement required.
What it does: Scans the codebase for feature flags that are no longer in use. Confirms it's safe to remove them. Opens a PR to clean them up.
Why it matters: Engineering teams experiment constantly, which is good. But every feature flag left behind adds a conditional branch that future engineers have to reason about. Over time, this accumulates into real complexity. Most teams know they should clean up old flags. Almost none do it consistently.
How it's configured: A scheduled Ona Automation runs on a regular cadence. It checks flag usage across the codebase, verifies that removing a flag won't break anything, and opens a PR with the cleanup. Engineers review and merge.
What it does: Scans the codebase daily for changes that affect user-facing behavior. Detects when docs are out of sync with code. Opens a PR with updated documentation that matches the team's tone of voice and formatting conventions.
Why it matters: Docs rot is universal. Engineers hate writing docs and hate updating them even more. The result is documentation that's perpetually out of date, which erodes trust with customers and wastes time for every new engineer onboarding to the codebase.
We wrote about this in detail in How we automated writing docs with an Ona Automation. The TLDR: we've received unprompted feedback from customers about how much our docs have improved. This automation is why.
How it's configured: A scheduled Ona Automation runs daily. It diffs recent code changes against the docs repo, identifies semantic changes (not just formatting), drafts Markdown updates, and opens a PR. A tone of voice guide in the automation's prompt ensures output matches documentation style.
No single hygiene automation is exciting. Closing stale PRs is boring. Removing dead feature flags is boring. Updating docs is boring. Patching CVEs is boring.
But engineering orgs don't slow down because of one dramatic failure. They slow down because of a thousand small things that nobody gets around to. Hygiene automations fix this by making the boring work automatic.
At Ona, these automations run every day without anyone thinking about them. The codebase stays clean, docs stay current, vulnerabilities get patched, and PRs don't pile up. The engineering team's attention stays on the work that actually requires human judgment.
This is what Ona Automations are designed for: event-triggered and scheduled AI software engineers that run in the background, across your entire codebase, handling the work that compounds when it's ignored.
The work doesn't go away just because you ignore it. Automate it and let your engineers focus on the work they want to do.
This website uses cookies to enhance the user experience. Read our cookie policy for more info.