Write a task Devin can finish

When an agent session fails, it is tempting to blame the model. More often the task was too big, too vague, or had no finish line. Cognition’s docs give concrete guidance on all three.

Read the steps as text

1. Context. The repository and the purpose of the work.
2. Steps. The work broken into logical parts.
3. Success criteria. What “done” means: passing tests, green CI, a matching pattern.
4. References. Existing code, patterns or docs to follow.

1. Context. The repository and the purpose of the work.
2. Steps. The work broken into logical parts.
3. Success criteria. What “done” means: passing tests, green CI, a matching pattern.
4. References. Existing code, patterns or docs to follow.

Size: the three-hour rule

The docs give a simple test: “if a task would take you three hours or less, Devin can most likely do it.” For longer work, break it into smaller sessions.

This rule is useful because it is about the work, not the agent. If you cannot estimate a task in hours, you do not yet understand it well enough to hand it to anyone.

Detail: decide things for Devin

The docs say to be “as specific as possible” and to “make important decisions and judgment calls for Devin.” Their own examples show the difference:

Poor	Good
Improve our database’s performance.	Optimize the getOrderDetails query in orderService.js by adding a composite index.
Make the app look better.	Use authTemplate.rs as a reference to keep error handling consistent.
Make sure it works.	Run npm test after each iteration.

A good instruction has four parts: the context, the steps, the success criteria, and references to existing code or docs.

Finish line: something Devin can check

Ask yourself the docs’ question: “Can I describe clear success criteria?” Tasks with test suites, CI checks or other verifiable outcomes give the best results. A task with a clear start and end can be finished. A wish cannot.

Big projects: slice them

For large work such as migrations, refactors and technical debt, the best-practice guide says to break the project into isolated, repetitive subtasks. For each slice:

• it should take under 90 minutes of manual engineering work
• it needs its own pass or fail check, such as tests, a build or CI
• it must be independent and backwards-compatible, so slices can run in parallel
• it should get human review before it is merged

The guide sums it up: “The simpler the slice, the more reliable the overall project.”

Two habits that help

• Scope with Ask first. For complex tasks, the docs suggest using Ask Devin to scope the work before starting a session. Lesson 2.2 showed how.
• Stop pasting the same instructions. If the same conventions go into every prompt, they belong in a skill. That is the next lesson.