What to delegate to a coding agent: 12 tasks and ready-to-use briefs

Most teams try it once. You open a fresh thread, type "improve the codebase" and come back to a large diff nobody wants to review.

The agent had to decide what improvement means, where to start and when to stop. You then have to review those decisions as well as the code.

Start with work whose result you can inspect. Hoplite's delegation guide recommends giving a Hoplite cloud agent one coherent change per thread, with a definition of done the agent can check in its sandbox.

The briefs below are examples to adapt to your repository. Replace the illustrative paths and commands with the ones your project actually uses. They're task templates, not results from twelve completed runs.

Fix behavior you can reproduce

1. A repeatable bug

Fix the filter reset when returning to the orders page. Reproduce it by selecting a status, opening an order and navigating back. Preserve the chosen status for that navigation. Add a regression test and verify the sequence in a browser. Stop if the expected persistence behavior conflicts with existing product requirements.

2. A missing boundary case

Add coverage for an empty result in the invoice-summary function. Preserve its current public interface. Run the existing summary tests first, add the empty-input case and fix the implementation only if the result violates the documented behavior.

3. A small accessibility repair

Make the search dialog operable with the keyboard using the project's existing dialog pattern. Verify opening, focus movement, dismissal and focus restoration. Keep the visual design unchanged and report any remaining behavior you couldn't verify.

4. A failing CI job

Investigate the failed unit-test job on this PR. Identify the first relevant failure and reproduce it if the environment permits. Report whether it comes from the change, setup or a nondeterministic test. Don't edit code until the cause is supported by evidence.

Investigation is a complete task. Hoplite can inspect GitHub Actions jobs and logs, so a useful result may be an explanation with a source location instead of a patch.

Reduce maintenance work in small batches

5. A dependency update

Update the named dependency within the approved version range. Read its release notes, inspect breaking behavior relevant to this repository and run the affected checks. Keep other dependency versions unchanged. Stop if the update requires a product or architecture decision.

6. A duplicated implementation

Consolidate the duplicated date-formatting logic in the two report modules. Preserve their current output, including empty values and timezone behavior. Add coverage for differences before extracting shared code. Keep the diff within reporting.

7. A stale setup guide

Follow the development setup guide in a fresh sandbox. Fix instructions that are demonstrably wrong, then rerun the changed commands. Record any step blocked by unavailable credentials. Don't claim an unexecuted step works.

8. An obsolete flag

Investigate the named feature flag and identify its references, fallback behavior and remaining consumers. Produce a removal plan first. Implement only if repository evidence establishes the chosen permanent behavior and the task's removal conditions are met.

The flag brief deliberately begins with investigation. A constant that appears unused in one package may still affect a separate service or an older client.

Add features with an agreed shape

9. An existing component variant

Add a compact variant to the existing status component using its current styling system. Keep the default appearance unchanged. Cover the supported status values and inspect the compact variant at the required narrow width. Don't introduce another component library.

10. A bounded API extension

Add the agreed optional field to the account response. Preserve the response for existing consumers. Update the schema and affected tests, verify authorization for the new field and report any consumer that needs a separate change.

11. A small migration batch

Migrate the selected reporting module to the agreed replacement API using the established example. Preserve output and error handling. Run its checks before and after. Stop if the replacement has different semantics that the migration plan doesn't address.

12. A review-feedback pass

Address the attached PR comments. For each requested change, update the relevant test or explain why it isn't needed. Summarize what changed and what remains unresolved. Rerun affected checks and leave the PR open for review.

Hoplite's PR rail can attach comments to the originating thread, keeping the feedback beside the work it describes.

Choose the first task by verification cost

Pick a task with a known environment and a result you can check in a few minutes. If the acceptance criteria still require a long discussion, make that discussion or investigation the first task.

Put recurring conventions in project instructions, as described in the prompting guide. Keep each brief focused on what changes, what must stay true and the evidence you want back. Then review the first result before handing over the rest of the queue.