# SlothOps: An Autonomous AI Coding Factory That Works While You Sleep

> Source: <https://dev.to/thrizzio/slothops-an-autonomous-ai-coding-factory-that-works-while-you-sleep-3k3j>
> Published: 2026-10-24 18:32:24+00:00

*This is a submission for the [Hacktoberfest Open-Source AI Challenge](https://dev.to/challenges/hacktoberfest) Week 3: Slow and Steady*

**SlothOps** is an autonomous software-maintenance system that takes repetitive GitHub issue-to-PR work off a developer's hands. Instead of manually investigating every issue, tracing dependencies, implementing fixes, running tests, and writing PR descriptions, you queue up eligible issues and let the factory work through them.

The goal is simple: **wake up to investigated issues, isolated code changes, test results, and draft pull requests ready for human review.** This is not another chatbot suggesting code snippets. It is a persistent engineering workflow that carries tasks across multiple steps, recovers from failures, and preserves progress without requiring a human to supervise every tool call.

The project is deliberately conservative about irreversible actions. It prepares code and draft PRs, but it does not merge its own work. Reliability and verifiability matter more than PR volume.

*Working project under active development.* The current development target is `Recon-OS`, a repository with multiple issues involving data loaders and document ingestion. The factory has been used to prepare feature PRs for plain text, Markdown, JSON, HTML, CSV, and remote URL ingestion.

Live end-to-end demonstration with real workers and review feedback is the next milestone. Recent smoke tests encountered provider timeouts and free-tier limits, which is exactly the kind of failure the orchestration layer is designed to handle gracefully.

`OmniRush`, `Antigravity`, and the `OpenCode CLI`, with different models and availability constraints. Worker selection and fallback distinguish successful execution from errors, timeouts, unavailable services, and situations requiring human intervention.
Building the happy path is only part of the project. Much of the engineering effort goes into the failure cases:

The factory is designed around deliberate constraints:

`blocked` instead of being silently treated as success.
An autonomous coding system should be allowed to do repetitive work, but it should not be allowed to redefine success just because it ran out of time or model capacity.

The broader goal is to make autonomous coding workflows inspectable, adaptable, and less dependent on a single proprietary service. Open-source agent tooling and open-weight models make it possible to:

*Note on the current implementation:* The orchestration layer is Python and SQLite, but some workers rely on hosted AI services. The current system should not be described as fully offline, fully local, or entirely powered by open-weight models. Those are deployment possibilities to investigate and demonstrate, not claims to make without evidence.

The open-source approach matters because the developer should be able to understand and change how the automation works. A closed API would make the workflow a black box—you could submit issues and hope for PRs, but you could not inspect the review logic, modify the safety gates, or run the entire pipeline on your own hardware.

*DevRelay session coming soon.* This project was built in an extended pair-programming session exploring orchestration architecture, failure classification, and worktree isolation.

**SlothOps** is designed to reward a developer for doing less repetitive work without lowering the quality bar.

Software maintenance involves a surprising amount of tedious work. Even a small issue can require reading unfamiliar code, tracing dependencies, reproducing a bug, implementing a fix, running the correct checks, preparing a PR, and responding to feedback. That is a **15–25 minute context-rebuild tax** before any real engineering starts—*per issue*.

With SlothOps, you queue an eligible issue and return to review the evidence and proposed changes. The factory handles the investigation and implementation workflow. You spend your attention on architecture, difficult decisions, and the changes that actually require human judgment.

**The central idea:** Laziness and engineering discipline do not have to conflict. Good automation handles the repetitive work while preserving the checks that make the result trustworthy.

*Categories pending final review of partner requirements. Primary fit:*

*SlothOps is a work in progress. The goal is to establish that the factory can reliably complete a task, not merely that it can start one. The strongest demonstration would begin with a real, appropriately scoped issue and end with a draft PR that includes a clear explanation, an isolated reviewable implementation, reproducible test results, independent review against the final commit, natural GitHub communication, a recoverable task history, and no hidden bypasses when a worker fails.*