How to Delegate Coding Tasks to AI

February 22, 2026

Delegation is a skill. Most developers haven’t had to practice it because they’ve always been the ones doing the work. Now you have something that can do the work for you — and your instinct is to either hand it everything or hand it nothing.

Both are wrong. Here’s the framework I use.

The delegation spectrum

Not every task is a binary “delegate or don’t.” I think about it as a spectrum.

Fully delegate: Write the spec, hand it off, review the output. You don’t touch the code during implementation.

Partially delegate: Hand off the initial implementation, then iterate together. You review mid-task, adjust direction, maybe write a critical section yourself.

Do yourself: The task requires judgment you can’t articulate in a spec, or the cost of getting it wrong is too high to risk.

Most tasks fall in the first two categories. The mistake solo devs make is putting too many tasks in category three because “it’s faster if I just do it.” It’s not. It’s faster for the next 20 minutes. It’s slower for the next 20 days.

What makes a task delegatable

I’ve delegated hundreds of tasks at this point. The ones that go well share four properties.

Clear inputs. The agent knows what it’s working with. “Add a rate limiter to the API” is missing inputs. “Add a rate limiter to src/middleware/ that limits each authenticated user to 100 requests per minute using the existing Redis connection in src/lib/redis.ts” has clear inputs.

Clear outputs. The agent knows what done looks like. “Improve the onboarding” is an outcome, not an output. “Replace the three onboarding screens in src/screens/Onboarding/ with the copy in this spec, keeping the existing layout and animation” is a clear output.

Existing patterns to follow. If your codebase already has 10 API routes and you’re adding an 11th, the agent can follow the pattern. If you’re creating the first API route, you should probably write it yourself — then delegate the next 10.

Testable result. You can verify the output by reading the diff, running the app, or running tests. If the only way to verify the output is “it feels right,” the task needs more definition.

When a task has all four, I hand it off with confidence. When it’s missing one, I either fix the gap in the spec or move the task to “partially delegate.”

What you should never delegate

Some tasks don’t belong in the agent’s hands. Not because the agent can’t write the code — it probably can. Because the decisions embedded in the task are too consequential.

Architecture decisions. Where the service boundaries are. Which database to use. How services communicate. The agent will make these decisions if you let it, and they’ll be reasonable decisions. But “reasonable” isn’t the same as “right for your specific constraints.” I learned this on Scouter when an agent picked a message queue architecture for a feature that didn’t need one. The code was clean. The architecture was wrong.

Security-critical logic. Authentication flows. Payment processing. Data access controls. Not because AI writes insecure code by default — it doesn’t. Because security bugs are expensive and subtle, and you need to understand every line of the implementation. If you delegated it, you’re reviewing code you didn’t think through. That’s backwards.

First implementations of a new pattern. When I added background job processing to Scouter, I wrote the first job handler myself. Then I delegated the next six. The first implementation sets the pattern. The agent replicates the pattern. If you delegate the pattern-setting task, you get the agent’s preferred pattern, which may not match your codebase’s conventions.

Ambiguous product decisions. If you don’t know what the feature should do, the agent definitely doesn’t. “Figure out what the settings page should include” is a product decision, not a coding task. Make the decisions first, then delegate the implementation.

The handoff format

The spec is the handoff document. It’s the only thing standing between “I know what I want” and “the agent knows what I want.”

A good handoff spec looks like this:

## Task: Add CSV export to Scouter dashboard

### What
Add a "Download CSV" button to the prospects table in the dashboard.
Export all visible rows (respecting current filters) as a CSV file.

### Where
- Button: `src/components/Dashboard/ProspectsTable.tsx`, toolbar area
- Export logic: new file `src/features/export/csv.ts`
- Use the existing `useProspects()` hook for data access

### Behavior
- Button label: "Export CSV"
- Filename: `scouter-prospects-{date}.csv`
- Include columns: name, email, company, score, status, created date
- Respect current filter/search state
- Client-side generation (no API call needed, data is already loaded)

### Constraints
- No new dependencies. Use native Blob/URL APIs
- Match existing button style in the toolbar
- No loading state needed (data is already in memory)

That’s 20 lines. Takes about 2 minutes to write. Saves 20 minutes of back-and-forth. I go deeper on spec writing in the spec that makes AI agents work independently.

The review contract

This is the part people skip. Don’t.

The contract is simple: you always review. No exceptions.

Not “review if it looks complicated.” Not “review the important stuff.” Review everything. Every diff. Every file. Every time.

Here’s why. The agent writes correct code most of the time. When it doesn’t, the bugs are subtle — an off-by-one in a filter, a missing null check on an edge case, a slight misunderstanding of your data model. These aren’t the kind of bugs you catch by running the app and clicking around. You catch them by reading the diff.

My review process:

  1. Read the full diff in git. Every line.
  2. Check that the changes match the spec. Not approximately — exactly.
  3. Look for things the spec didn’t mention. Unexpected file changes. Unnecessary refactors. Added dependencies.
  4. Run the specific feature if possible.
  5. Run existing tests to check for regressions.

This takes 5–15 minutes per task. It’s the most important 5–15 minutes of the workflow. The trust-but-verify approach covers this in more detail.

Real examples: good and bad delegation

Good delegation — Triumfit workout timer. I needed a rest timer between sets. Clear input (current set data), clear output (countdown timer UI), existing patterns (the app already had timer components), testable (you can see if a timer works). I wrote a 12-line spec. The agent built it in one pass. I reviewed it in 4 minutes. Shipped.

Bad delegation — Lucid journal architecture. I asked the agent to “design the data model for journal entries with tags, templates, and cross-references.” That’s an architecture decision disguised as an implementation task. The agent built a normalized relational schema with a junction table for tags and a template inheritance system. It was well-engineered. It was wrong for a local-first iOS app where I needed a flat document model with embedded metadata. I threw away the output and designed the data model myself. Then I delegated the implementation.

Good delegation — Scouter API endpoint. Scouter already had 14 API endpoints following the same pattern. I needed a 15th. The spec was 6 lines: the route, the method, the input params, the response shape, and which existing endpoint to use as a reference. Done in one pass.

Bad delegation — Octopus Coder initial design. I tried delegating “build the landing page” for this site without specifying the layout, sections, or content. What I got back was a generic SaaS landing page with a hero, features grid, and pricing table. It looked fine. It wasn’t the site I wanted. The task wasn’t delegatable yet because I hadn’t made the product decisions.

The pattern is consistent. When the decisions are made and the spec is tight, delegation works. When decisions are still open, delegation produces reasonable but wrong output. Scoping tasks properly is the skill that makes the whole thing work.

Building the delegation muscle

If you’re new to this, start small. Pick tasks you already know the exact output for. A bug fix you’ve diagnosed. A copy change you’ve already written. A new route that follows an existing pattern.

Delegate those. Review the output. Build trust in the process.

Then gradually expand. Larger features. More complex specs. Multiple tasks in parallel. Within a few weeks you’ll have a feel for what delegates well and what doesn’t. That instinct is the most valuable thing you’ll develop.