Writing tasks Devin can actually finish

When an agent session fails, the instinct is to blame the model. Usually the task was wrong. Cognition’s own documentation is unusually direct about this, and the guidance is worth taking literally.

Structure the instruction

The documented recommendation is a three-part shape:

1. Describe the task.
2. Describe the do’s and don’ts.
3. Describe the expected results and behaviours to test for completion.

The instruction is to “be as specific as possible” — write the detailed spec you would give a coworker, not the one-line version you would type into a search box.

That third part carries the most weight. “Add rate limiting to the API” is a wish. “Add rate limiting to POST /api/subscribe, 5 requests per minute per IP, returning 429 with a Retry-After header, and add a test that asserts the sixth request in a minute is rejected” is a task with a finish line.

Wide and shallow beats tall and deep

Cognition frames task shape as a tradeoff:

• Tall and deep — complex, net-new features. Documented as having lower reliability at scale.
• Wide and shallow — simple, well-defined tasks. Documented as highly reliable and effective.

The practical consequence is counterintuitive but consistent: slicing a project into simpler pieces makes the whole project more reliable, not just each piece. If you have a large change, the win comes from cutting it up rather than from writing a longer prompt.

The three-hour rule of thumb

The docs offer a concrete heuristic: tasks that would take three hours or less are a great fit.

This is a useful filter precisely because it is about the work, not the agent. If you cannot estimate the task in hours, you do not understand it well enough to delegate it yet — to Devin or to a person.

What makes a task suitable

Per the documentation, look for:

• Clear success criteria — test suites, CI checks, verifiable outcomes
• Appropriate scope — well-defined boundaries and clear existing patterns to follow
• Repetitive elements — the same change applied in many places

That last one is where agents genuinely outclass humans: mechanical, wide changes across many files, where a person’s error rate climbs with tedium.

Two habits that pay off

Scope with Ask Devin first. Use Ask mode to settle the approach before any code is written. It is cheaper to discover a bad plan in planning than in review.

Stop repeating yourself in prompts. If you find yourself pasting the same conventions into every task, that content belongs in Knowledge, not in the prompt. The next guide covers how Knowledge, Playbooks, and Skills divide that job.

In Devin Desktop

For local prompting, the documented components of a high-quality prompt are: a clear objective or outcome, all relevant context (via @-Mentions), and the necessary constraints — frameworks, libraries, complexity limits, security requirements.

References

1. Instructing Devin effectively — docs.devin.ai
2. When to use Devin — docs.devin.ai
3. Best practices — docs.devin.ai
4. Prompting — docs.devin.ai
5. Prompt engineering (Desktop) — docs.devin.ai

From Devin Central — subscribe for Devin news, features & tutorials. Devin is a trademark of Cognition.