10 Engineering Tasks an AI Coworker Can Fully Own

Your engineers already run Claude Code or Codex in a terminal, one prompt at a time. That helps the person typing, and it leaves the team's recurring chores right where they were: waiting for someone with a free afternoon to remember them.

Handing a job to an AI coworker for good comes down to two things. Something other than a person's memory has to start the work, and the right result has to leave production behavior unchanged so your existing checks can grade it. When a job changes how the product behaves, the agent writes both the code and the test that grades the code, which is a polite way of saying nobody graded it.

If you're just here for a quick recommendation, here's the summary.

The short answer

• You want the safest first handoff with a trigger that already exists: Dependency updates or Red CI on a pull request.
• You want a weekly cleanup nobody on the team will miss doing: Lint and type errors or Flaky tests.
• You want higher merge rates than human pull requests get: Documentation that follows the code.
• You want a safety net before touching an old module: Tests for code that already exists.
• You have a multi-quarter rewrite sitting on the roadmap: Mechanical migrations.
• You want help on call without giving an agent the keys to production: A first fix for a production error or The first pass on an alert.

The 10 tasks at a glance

The first column I'd read is "Who starts it", because a job that waits for someone to ask is still that person's job.

What "fully own" actually means

Owning a job means the agent starts it, finishes it and comes back with proof that it worked. A person still clicks merge almost every time. At Stripe, internal agents called minions produce over a thousand merged pull requests a week with zero human-written code in them, and a human engineer still reviews every single one. If Stripe keeps the human review step at a thousand pull requests a week, you can keep it too.

Most delegation guides start with the two questions PostHog's Jina Yoon laid out in July 2026: "Is it easy to check the agent's work?" and "Is it cheap to undo an agent's mistake?" That framing is spot on, and the post calls easy to check but costly to undo "the default ceiling for most dev work today."

A third question belongs right next to those two: who starts it? If a developer has to notice a problem, open a terminal and type a prompt, that developer still owns the job.

There is also a catch hiding inside "easy to check." In March 2026, METR asked four open-source maintainers from three repositories (scikit-learn, Sphinx and pytest) to review 296 AI pull requests from agents released between mid-2024 and late 2025 that had already passed SWE-bench's automated test suite. Roughly half would be rejected in real life, about 24 percentage points below the automated grade. Green tests are weak proof when a pull request introduces new behavior, because the test suite was never written to check that new behavior.

Look across the ten jobs below and a pattern jumps out. In almost all of them, the right change leaves production behavior identical (a dependency bump, a type fix, a mechanical migration, a flake repair) or touches nothing in production at all (documentation, a triage note in Slack). Your existing checks already know how to grade "nothing broke." The jobs at the bottom of the list cross into changing runtime behavior, which is why human review gets heavier there. Public data backs that split up: in the AIDev study of over 456,000 pull requests, coding agents lagged humans the most on features, bug fixes and performance work. A July 2026 study of 9,428 agent pull requests across 489 Python repositories found the same shape: developers mostly use agents for "repetitive, low-complexity, well-structured tasks," with merge rates topping out in infrastructure, config, dependencies, typos and docs, and falling to about 60% or below on model evaluation and LLM integration.

So every task below is scored on three things:

• Who starts it: the schedule or webhook that kicks the run off without a person remembering.
• What grades it: the check that proves the agent didn't quietly break something.
• How you undo it: what recovery looks like when a bad change slips through.

The 10 engineering tasks an AI coworker can own

1. Dependency updates

The job with the longest track record, and the one place merging without a person is normal.

A dependency bump has a clear trigger (a package release or a Monday morning schedule) and a clear grade (your existing test suite passes). Classic bots like Renovate already handle the easy version of this, waiting for green status checks and an up-to-date branch before automerging lock file maintenance or patch bumps. An AI coding agent earns its keep on the step where Renovate stops: when a minor or major bump introduces a small breaking API change and 14 call sites need to be updated to match. At Spotify, background agents routinely handle library upgrades with breaking changes, such as moving data pipelines onto newer versions of Scio.

What stands out

• Dependency work sits among the categories merged at 80% or higher in the July 2026 study of 9,428 agent pull requests, and PostHog puts dependency bumps in the top tier of jobs that are both easy to check and cheap to undo.
• The agent can read the upstream changelog, update the call sites, run the test suite and leave a summary of what changed in the pull request description.

Worth knowing

• Renovate's own docs warn that pre-1.0 packages can break at any time and that automerging production dependencies only makes sense when test coverage is genuinely solid.
• Keep major framework upgrades and dependencies that touch auth or cryptography for a human review.

Trigger to set up: a weekly schedule, or a webhook on Renovate and Dependabot pull requests whose checks fail.

2. Lint and type errors

Tedious, instantly graded, and nobody will miss doing it.

Every growing codebase collects strictness debt: a directory excluded from tsconfig.json, a hundred warnings from a linter rule somebody turned on in warn-only mode six months ago, or deprecated helper calls scattered across forty files. An agent can pick up a batch on a schedule, fix ten files at a time, run the type checker and open a small pull request your team can review in two minutes.

What stands out

• The grade is binary and fast. Stripe runs a local lint check on every git push in under five seconds, so an agent finds out about a bad edit right away.
• In the July 2026 study, type-checking pull requests from agents stayed in a tight band of 76% to 82% merged across quarters, which is remarkably steady for automated cleanup.

Worth knowing

• An agent told to make errors go away will happily reach for @ts-ignore, eslint-disable or : any if you let it. Ban suppression comments and any casts in your repository instructions, and check the diff for them before merging.

Trigger to set up: a nightly or weekly schedule targeting one folder or one rule at a time.

3. Documentation that follows the code

The one category where agents already beat people in the data.

When a pull request adds a CLI flag, renames an environment variable or changes a webhook payload, the docs almost always lag behind by a week or forever. An agent watching merged pull requests can read the diff, check whether the public docs or README.md mention the changed surface, and open a follow-up docs pull request the same afternoon.

What stands out

• In the AIDev study, documentation pull requests were accepted 88.6% of the time for Codex and 85.7% for Claude Code, beating the 76.5% acceptance rate for human-written docs pull requests. The authors point to low functional risk and high reviewer confidence.
• Documentation is the single highest-volume category of agent work in the July 2026 study, and GitHub's own coding agent guide recommends it as a starter task.

Worth knowing

• Link checkers and MDX builds catch broken syntax, while no automated check catches a confident wrong sentence. Someone still has to skim the prose.
• Keep architecture explanations, pricing pages and anything a customer could read as a service commitment with a person.

Trigger to set up: a GitHub event when a pull request merges into main and touches routes, CLI flags, public schemas or config files.

4. Tests for code that already exists

The existing behavior is the answer key.

Writing unit tests for a module that already works in production flips the usual testing problem on its head. The agent reads what the code does today and locks that behavior down before somebody refactors the file next sprint. PostHog and GitHub's documentation both name test coverage as a good job to hand over, and testing ranks in the top three categories by volume in the July 2026 study.

What stands out

• You can grade the new tests automatically in two steps: first the new test file has to pass against main, and second it has to fail when the agent intentionally breaks a line in the source file (a quick mutation check).
• If a test turns out to be brittle or noisy a week later, undoing the work is deleting one test file.

Worth knowing

• A test generated from today's code will faithfully lock in today's bugs right alongside today's features. Have the agent flag any branch in the source code that looked suspicious while it was writing assertions, and don't treat a higher coverage number as proof the module is right.

Trigger to set up: a pull request event when changed files fall below your coverage threshold, or a weekly schedule pointed at untested utility modules.

5. Red CI on a pull request

The trigger is built in, and so is the grade.

An engineer pushes a branch, moves on to a meeting, and comes back two hours later to find CI failed on a snapshot mismatch, a missing import or a formatting check. An agent subscribed to failed check runs can pull the failure log, reproduce the error, push a fix commit (or post a suggested diff) and let CI run again before the author even opens the tab.

What stands out

• CI and build fixes sit in the highest merge band in the July 2026 study, often clearing a 90% merge rate.
• The feedback loop is already wired up in every repository that runs continuous integration.

Worth knowing

• Without a hard ceiling, an agent can burn through tokens in an endless edit-and-push loop or make the test pass by deleting the assertion. Stripe caps its minions at two CI rounds (initial push plus one repair attempt), and Sentry Seer also caps automatic CI iteration to stop runaway loops. Copy that rule, and forbid editing the failing test unless the prompt explicitly asks for a snapshot update.

Trigger to set up: a GitHub check suite or workflow run completing with a failure status on an open pull request.

6. Flaky tests

Everybody's problem and nobody's job, which makes it a fine first assignment.

Every team has a list of tests that fail once every thirty runs because of a shared database row, a timezone assumption or an unawaited promise. Nobody wants to spend a Tuesday hunting them down, so people click re-run until the build goes green. Stripe's CI runs over three million tests, and when it detects flaky tests it creates automated tickets that prompt people to fix the problem with a minion.

What stands out

• You have a clear numeric grade: run the repaired test 50 or 100 times in isolation and under load, and require zero failures.
• Even a partial hit rate pays off on a backlog nobody was touching anyway. In the FlakyGuard industrial study from November 2025, the agent repaired 47.6% of reproducible flaky tests, and human developers accepted 51.8% of those repairs. That works out to roughly one merged fix for every four reproducible flakes (0.476 times 0.518 is about 0.25).

Worth knowing

• An agent will sometimes "fix" a timing flake by adding sleep(2000) or wrapping the assertion in a retry block, which just hides a real race condition. Ban sleeps and test-level retries in your prompt.

Trigger to set up: a webhook from your CI flake detector, or a weekly schedule pulling the top five flakiest tests from build analytics.

7. Mechanical migrations

The biggest payoff on the list, once you've built the validation loop.

Every few years a company has to move 2,000 files from one internal library, test runner or language pattern to another. This is the one job on the list that a human starts on purpose, once, by defining the target list of files. After that kickoff, the agent owns the per-file grind. Airbnb used this setup to migrate roughly 3,500 React test files from Enzyme to React Testing Library in six weeks, work they had estimated at 1.5 years by hand. Each file stepped through a state machine that ran the refactor, Jest, the linter and the TypeScript compiler, advancing only when every check passed.

What stands out

• The time savings at scale are huge and well documented. Airbnb's first bulk run cleared 75% of the files in about four hours, four days of prompt and harness tuning brought the total to 97%, and engineers finished the stubborn last 3% by hand in a week. At Google, three developers ran 39 migrations over twelve months where the model generated 74.45% of the code changes and cut total migration time by an estimated 50%. Spotify reports more than 1,500 merged pull requests and 60% to 90% time savings on migrations like converting Java value types to records.
• Grading is clean because the test suite before the migration and the test suite after the migration have to assert the exact same behavior.

Worth knowing

• None of those teams reached 100% automation without human cleanup at the tail end, and Airbnb, Google and Spotify all built real tooling and validation around the model. For a 20-person team, start with a 30-file migration before aiming at 3,000.

Trigger to set up: a queue or script that feeds the agent 5 to 10 files per pull request as previous batches merge.

8. Config changes

Easy to grade on syntax, and the first job on this list that can take production down.

Updating feature flag defaults, bumping rate limits in YAML, adding an allowlisted domain or rotating non-secret routing tables takes ten minutes of context switching when an engineer has to do it. Spotify's background agent handles YAML and JSON parameter updates while validating them against schemas and formatting rules, and config work sits in the highest merge band (often above 90%) in the July 2026 study.

What stands out

• Schema validation, JSON or YAML linters and dry-run plans catch malformed edits immediately.
• Non-engineers in ops or support can ask for a routine config change in Slack and get a pull request ready for an engineer's one-click review.

Worth knowing

• A config file that passes every JSON schema check can still route 100% of production traffic into a wall. Keep a human on the merge button and rely on staged rollouts or canary checks unless your deployment pipeline rolls back bad config automatically.
• Never hand an agent raw production secrets or IAM permission policies.

Trigger to set up: a tagged request in a dedicated Slack channel or a structured Linear template.

9. A first fix for a production error

The agent owns the investigation and the draft, and a person owns the merge.

When a new TypeError or unhandled null spikes in production, the first twenty minutes of on-call work are always the same: grab the stack trace, find the commit that touched that line, write a test that reproduces the crash and draft the guard clause. Sentry's Seer Autofix automates that loop when an issue hits at least 10 events within the last 14 days and scores as reasonably fixable, and Stripe's minions resolve many small issues during on-call rotations.

What stands out

• Sentry lets you choose the ceiling right in settings: Stop after Root Cause, Stop after Plan or Stop after PR Drafted.
• Requiring the agent to commit a failing reproduction test before it touches the application code gives the human reviewer real proof the fix addresses the crash.

Worth knowing

• Unlike most of this list, a bug fix changes runtime behavior. That puts you squarely in the METR study's territory, where half of test-passing pull requests still failed human maintainer review because the patch didn't solve the issue, broke other code or fell short on code quality.
• Keep the merge button with an engineer, and exclude errors in billing, authentication and data deletion paths.

Trigger to set up: an error tracker alert when a new issue crosses an event threshold after a deploy.

10. The first pass on an alert

A note in the channel is the safest thing an agent can produce, since it changes nothing.

When PagerDuty or incident.io wakes somebody up at 2 a.m., the engineer spends the first ten minutes opening five tabs: recent deploys, error logs, CPU graphs, slow queries and the runbook nobody updated since 2024. An agent triggered by the alert can pull all five, correlate timestamps against recent merges and post a single threaded summary before the on-call engineer has finished making coffee. PagerDuty's SRE Agent works on this exact boundary, taking the first pass automatically while leaving every remediation step to the human responder.

What stands out

• According to ClickHouse's report on AI SRE agents, Wix uses agents to enrich over 30,000 alerts a month with 90% root-cause accuracy, while humans still make every remediation decision.
• Because the output is a message in an incident channel, the blast radius of a mistake is zero in production.

Worth knowing

• In an August 2025 experiment, ClickHouse injected four synthetic anomalies into an OpenTelemetry demo app and found that no model reliably identified root causes on its own without follow-up human guidance. A confident wrong theory at 3 a.m. wastes precious minutes, so require the agent to link the exact log lines, commits and metric queries behind every claim.

Trigger to set up: an alert webhook from PagerDuty, incident.io or your monitoring tool posting into the incident channel.

What to keep for yourself

Knowing what stays on a human plate is what makes handing over the rest feel safe. GitHub's own documentation for its coding agent advises keeping these tasks with a person:

• Production-critical issues and active incident remediation.
• Work touching security boundaries, authentication or personally identifiable information.
• Substantial business logic, deep domain rules and ambiguous requirements.
• Tasks a developer on the team needs to do by hand to learn how the system works.

I'd add three more to that list:

• New product features. A feature has no pre-existing test suite to grade it, and the hard part is deciding what to build.
• Refactors where the grade is taste. PostHog explicitly keeps readability refactors with humans because an agent has no reliable way to grade whether the result is actually clearer to your team.
• Irreversible database migrations. Dropping a column or rewriting a hundred million rows violates the "cheap to undo" rule on sight.

Your engineers can still use Claude Code or Codex interactively on every single one of those jobs. The person in the chair just keeps ownership.

How to choose your first one

Treat this list as a starting point. Before you wire anything up, run three questions in order and pick the first job that gets three yeses:

1. Does this already happen on a schedule or from an event? If a human has to remember to ask, you haven't handed the job over yet.
2. Does a check you trust already exist? If your test suite, linter or schema validator can't tell a good run from a bad one, your reviewers will drown.
3. Would you be relaxed reverting it at 4:30 p.m. on a Friday? If the answer is no, start higher up the list.

For most engineering teams, dependency updates or red CI on a pull request is the cleanest first win because the trigger and the check are already running in GitHub today.

Once you pick the task, you have two ways to wire the trigger.

Single-purpose tools do one job well out of the box. Renovate handles dependency bumps, Sentry Seer drafts fixes for Sentry issues (on GitHub.com and GitLab.com cloud repositories), and PagerDuty's SRE Agent triages PagerDuty incidents while keeping fixes human-driven.

Merlin takes the broader route: one AI coworker across many of these jobs, driving the Claude Code and Codex already installed on your team's machines with model usage staying on each machine owner's own plan. In Merlin, an automation starts either on a schedule or when something happens across GitHub, Linear, Slack or incoming webhooks from Statsig, incident.io, Stripe, PostHog and Granola. That means a failed GitHub check suite, a new incident.io alert or a Monday 8 a.m. timer can kick off a run without anyone typing a prompt.

In Merlin, the answer to who starts it is a sentence: an event in a product, narrowed by filters, with a chosen runtime and destination.

When a job does start from a ticket, someone can delegate a Linear issue or mention @usemerlin-ai on a GitHub issue or pull request, and the agent posts its progress and the resulting pull request right back in the thread.

A delegated Linear issue keeps the work where the team tracks it, and the agent comes back with a pull request to review.

Merlin's trade-offs are worth knowing up front. Every automation run uses its creator's chosen runtime on their machine, and if that machine is offline or busy, the run is skipped and never moves to another teammate's runtime (automations docs). So a job that has to run at 3 a.m. needs an always-on machine. Each conversation gets its own working directory. That directory isn't an operating-system sandbox, so the agent runs with whatever access that machine's environment has (security docs). Merlin also has no built-in Sentry webhook among its native sources today. Workspace plans are Starter at $9 per month for up to 3 users and 1,000 requests, Team at $59 per month for up to 50 users and 5,000 requests, and Scale at $99 per month for up to 200 users and unlimited requests (pricing, seen on November 7, 2026), on top of the Claude or OpenAI plans the machine owners already use.

4 things most lists skip

• Give every job a hard stop rule. Stripe's two-round CI limit is a great model to copy. An agent with no retry cap will burn tokens all night arguing with a broken linter.
• Ban the shortcuts by name in your repo instructions. Spell out the rules in CLAUDE.md or AGENTS.md: no deleting failing tests, no .skip annotations, no @ts-ignore or eslint-disable comments, and no sleep() calls to mask a flaky test.
• Review is the new bottleneck. Every agent pull request still lands in a human engineer's review queue. Start with a weekly volume your team can review in five minutes a day, and raise it only when the diffs are boring.
• Check the merge rate per job after 30 days. If your team merges 85% of the agent's lint pull requests and 20% of its flaky test fixes, you have an honest grade on which automation to expand and which prompt to tighten or turn off.

FAQ

If you want to hand one job over this week, pick red CI on pull requests or a weekly lint pass, cap the agent at two tries, and check your merge rate in a month.