Which Tasks Should You Give an AI Coding Agent?

Which Software Tasks Should You Give an AI Coding Agent?

Give an AI coding agent a task when the outcome is clear, the work is reversible, feedback is fast, permissions can stay narrow, the data is appropriate, and a qualified reviewer can validate the result. Hold the task when authority or consequence exceeds the available evidence and oversight.

The fact that an agent can produce code is not the deciding factor.

flowchart TD
    A["Define the software task"] --> B["Score clarity and testability"]
    B --> C["Score reversibility and observability"]
    C --> D["Score authority, sensitivity, and blast radius"]
    D --> E["Confirm qualified reviewer"]
    E --> F{"Choose autonomy"}
    F --> G["Research or propose only"]
    F --> H["Supervised local execution"]
    F --> I["Delegated bounded execution"]
    F --> J["Hold for stronger controls or authority"]

Evaluate the task, not the tool demo

A documentation typo and an identity migration are both software tasks. They should not receive the same permissions, review, or autonomy.

Describe the task as an outcome with exclusions. Identify the affected repository, interfaces, users, data, environments, and external systems. Write the evidence that would demonstrate success.

If the description is "clean up the codebase," the task is not ready. If it is "rename this internal function, update its three call sites, preserve behavior, and pass the focused test suite," the scope is more observable.

Score eight dimensions

Do not average away a critical risk. A task with excellent tests but direct production deletion authority is not medium risk.

Match the autonomy level

Research or explanation is appropriate when the agent can inspect approved material without changing state. The output is a summary, plan, question list, or proposed test.

Propose-only work can produce a patch or plan for review while execution remains blocked. This is useful when the task is clear but mutations need explicit approval.

Supervised local execution fits bounded changes in a sandbox or feature branch. Commands and edits remain visible, tests are fast, and the reviewer can stop the work immediately.

Delegated execution requires strong isolation, narrow permissions, reliable tests, logging, limits, and rollback. It is not merely supervised execution with fewer interruptions.

Hold is the right decision when the task needs a product judgment, security authority, legal interpretation, production credential, destructive migration, regulated-data decision, or qualified reviewer that is not available.

Good starting tasks

Low-risk starting work usually has a small diff and a clear oracle.

These are not automatically safe. A documentation file can expose a secret. A rename can change a public API. A test can encode the wrong behavior.

Tasks that need tighter control

Authentication, authorization, cryptography, payments, personal data, regulated workflows, dependency upgrades, CI/CD, infrastructure, migrations, public APIs, safety-critical behavior, and incident response deserve specialist review and stronger permissions.

An agent can still assist with research, inventory, plans, test cases, or a proposed diff. The autonomy level should reflect the consequence.

NIST SP 800-218 supports integrating secure development practices into the lifecycle. The OWASP Top 10 for Large Language Model Applications adds risks such as prompt injection, sensitive-information disclosure, insecure output handling, and excessive agency.

Those sources do not classify one organization's task. They help teams ask better questions.

Set permissions from the task record

Start with no more authority than the task needs.

A local documentation task may need read access to the repository and write access to one documentation folder. It should not inherit access to environment files, cloud credentials, databases, email, production commands, or external deployment tools.

Cursor's May 2026 Auto-review changelog describes current product behavior around allowlists, sandboxing, classifiers, and approval for some tool calls. That is a vendor feature at a point in time, not a replacement for the organization's own access model.

Permissions should be enforced by the environment whenever possible. A prompt asking an agent not to touch a file is weaker than a sandbox that prevents the write.

Define stop conditions

The agent should stop when it discovers a material scope change.

An autonomy decision expires when the task changes.

Require a review record

The task record should preserve the outcome, exclusions, risk dimensions, autonomy level, allowed files and tools, blocked authority, acceptance checks, stop conditions, reviewer, commands, diff, test results, and final decision.

Cursor's current agent best-practices guide emphasizes plans, focused context, tests, and careful review. Those practices become more reliable when they are attached to a task classification instead of applied as general optimism about the tool.

Reassess after the pilot

Track the defects caught in review, rejected scope, test failures, interruptions, incidents, and recovery attempts. Do not measure only completion time.

A task type may earn more autonomy after repeated success under stable conditions. It may lose autonomy after a near miss, system change, new data class, or weaker reviewer coverage.

The correct question is not "Can the agent do this?" It is "Can this task be executed with bounded authority and accepted through evidence we trust?"

This guide was developed with AI assistance from the immutable E037 transcript, NIST SSDF, OWASP material, current Cursor first-party guidance and changelog records, and the linked autonomy matrix. Dalton Anderson remains the author. Technical, security, current-source, and founder review are mandatory before publication. Publication is not authorized.