Agentic Development Setup: Repo, CI, and Computer (2026)

Coding agents need far less hand-holding than they did six months ago. As models and harnesses improve, like everyone I'm finding fewer skills, plugins, and elaborate instructions necessary to keep them on track.

But good practices for managing software development with agents seem less widely shared. A glance at social shows plenty of frustration from experienced developers and new builders alike.

Even experienced developers are adjusting to managing several streams of work at once. Running multiple agents all day, each pushing code - perhaps to the same repo - introduces logistics problems that deserve more attention. Code piles up. CI backs up. Worktrees, containers, and background processes accumulate across projects. Keeping that work moving becomes a job of its own.

Here's how I set up my repos, CI, and local machine to keep multiple agents shipping throughout the day - and keep the cleanup manageable.

1. Repo and CI setup

Regardless of language or platform, define what acceptable code looks like in your repo. I'm not just talking about reminders you put in your AGENTS.md file - far more important are guardrails that anyone (agent or human) must abide by when pushing code to your repo.

These include proper testing, linting, dead code removal, and more. If you're unsure what good engineering practices look like for your repo, discuss it with your agent. Have it inspect the project, recommend checks and sensible limits for your stack, and explain the tradeoffs.

Run those checks locally before pushing, then again in GitHub CI before merging. Hooks run checks automatically before commits or pushes; required GitHub checks enforce them before merge. This gives everyone - and agents in particular - direct feedback when they try to commit / push something to your repo that your standards disallow. These go a long way to keeping your codebase organized.

Without explicit standards, agents can accumulate unused code, sprawling files, and unnecessary dependencies. If you don't define what "keeping the house clean" means, don't be surprised when they act like hoarders.

Here's some of what I enforce regularly in my repos:

Strictly enforced engineering standards locally and in GitHub CI: formatting, linting, type checking, maximum lines per file and function, dead-code and unused-dependency detection, vulnerability checks, unit and integration tests, browser tests for critical flows, and production builds. I run much of this locally every time a commit / push is made - and again in CI. For those just jumping into working with software - this may sound redundant at first, but you absolutely want this. It's failure insurance. Define shared commands that agents can run locally, as in Bugdrop’s Makefile, and run them again in GitHub CI.
Protect main and require checks and PR review before every merge. Use branch protection or rulesets to require PRs and the applicable CI checks, restrict bypass, and block force pushes and branch deletion. Make PR review part of the agent's instructions, as in Bugdrop’s AGENTS.md, and enforce the applicable review approval or review status check in GitHub. Local checks catch problems early; GitHub checks enforce the standards.
Use a merge queue for heavier integration checks. Keep fast feedback on each PR, then reserve expensive preview deployments and live integration tests for queued merge candidates. In Bugdrop’s CI workflow, preview deployment and live tests run on merge_group events, while unit and browser tests also run on relevant PR changes. Configure the queue to require the heavier results before merging; enabling a queue alone doesn't move your tests.
Regularly audit CI efficiency. As agents increase your PR volume, small CI inefficiencies multiply quickly. Schedule a weekly or monthly review of queue time, job duration, runner usage, flaky tests, and duplicate work. Cache dependencies, reuse compatible build artifacts, balance test shards, and cancel superseded PR runs where appropriate. Run checks relevant to the changes: documentation-only PRs should still get formatting and any applicable link or documentation validation, while skipping unnecessary application tests. Bugdrop’s workflow uses change-scope checks to avoid full application testing for documentation and metadata changes.
Automatically delete merged branches so completed work doesn't leave a growing pile of remote branches. Local worktree cleanup is a separate routine, covered below.

Note: Merge queues are available for public organization repos and for private organization repos on GitHub Enterprise Cloud; see GitHub’s eligibility and setup guide.

For heavy private-repo usage, Enterprise may be worth considering: GitHub offers this at $21 per user per month and 50,000 CI/CD minutes per month. Quite the deal. Compare your actual runner usage and billing terms; standard GitHub-hosted runners in public repos are already free.

2. Local machine

Running even a handful of agents day to day can put a heavy resource load on your machine, especially compared to the Before Times. Dev servers, tests, Docker containers, and simulators across multiple projects all compete for memory, CPU, and disk space.

Here are a few best practices that I incorporate on a schedule (using the Codex app):

Restart daily during heavy use. If you're running five or more agents throughout the day, my recommendation is to restart daily after saving work and stopping active jobs. Running agents, browsers, and dev servers all day can quietly increase memory pressure and trigger swapping to disk. Stop services when testing ends; if the machine remains sluggish, a restart can clear lingering processes. It won't remove accumulated files from disk.
Schedule worktree and container cleanup. In addition to RAM, you'll likely start filling up your hard drive pretty quick. Schedule regular review of stale worktrees, preserve uncommitted or unpushed work, stop their processes, then remove them through the tool that created them. Have an agent check Docker's disk usage and remove disposable containers, images, and build caches. Preserve database volumes deliberately. Start with a weekly review and increase the frequency during heavy churn.
Give local processes an owner and a stopping point. Use named local subdomains with a proxy that assigns separate ports to avoid conflicts across projects and worktrees. Heavier isolation is available, but this is a simple starting point. In AGENTS.md, tell agents to shut down services they started once QA and testing are complete, unless asked to keep them running.

Have your agent periodically inspect disk usage, memory pressure, and leftover processes. If the machine slows down again immediately after restarting, investigate the workload or reduce concurrency. Put these checks on a schedule.

Glossary

If you're new to using agents to build software - here's a handy list of definitions for repo-related items. If these are unfamiliar to you - I'd strongly suggest asking your agent to carefully explain each (especially in the context of your project).

Repository (repo): The project's files and their version history.
Branch and merge: A branch holds a separate line of work. Merging combines its changes into another branch, usually main.
Pull request (PR): A proposal to merge changes, with a place to review the code and see check results.
CI/CD: Continuous integration runs automated checks on code changes. Continuous delivery or deployment prepares or releases those changes.
Hooks: Scripts triggered by actions such as committing or pushing code. Local Git hooks can be bypassed, so required GitHub checks remain essential.
Formatting: Automatically keeping spacing, indentation, and other presentation choices consistent.
Linting: Checking code against rules that flag likely mistakes and unwanted patterns.
Type checking: Checking that values and functions are used consistently with their declared or inferred types.
File and function size limits: Rules that flag code exceeding a chosen line count, encouraging smaller, focused pieces.
Dead-code removal: Finding and deleting code the application no longer uses.
Unused-dependency detection: Finding installed libraries the project no longer needs.
Vulnerability checks: Looking for known security issues in dependencies or potentially unsafe code patterns. These checks don't catch every security flaw.
Unit tests: Tests of small pieces of logic in isolation.
Integration tests: Tests that check whether connected parts work together.
Browser tests: Tests that operate a web app in a browser to check user interactions and flows.
Production build: Turning source code into the version intended for deployment, which can reveal problems development mode misses.
Branch protection and rulesets: GitHub rules controlling changes to branches, including required checks, review approvals, and restrictions on direct pushes.
Merge queue: A system that tests proposed changes with the latest target branch and queued changes ahead of them before merging.
Preview deployment: A running version of proposed changes that can be inspected and tested before release.
Runner: The machine that executes a CI job. Runner minutes measure how long those machines work.
Cache and build artifacts: A cache saves reusable data to speed up later runs. Artifacts are outputs, such as builds or reports, saved for other jobs or inspection.
Test sharding: Splitting a test suite across multiple jobs so tests can run in parallel.
Flaky tests: Tests that sometimes pass and sometimes fail without relevant code changes.