What makes a good task? A simple test: could a strong engineer who has never seen this codebase complete it from the ticket alone, given a full understanding of the repo? If yes, it's a strong fit: well-described bug fixes with repro steps, test coverage, dependency upgrades, adding an endpoint that follows an existing pattern. If it needs tribal knowledge or taste, tighten the ticket first.

Instruct Devin like you'd brief a teammate, using a simple template: Context (what you're doing and why), step-by-step expectations (sequence, constraints, what not to touch), success criteria (what 'done' looks like), and explicit references (file paths, function names, similar PRs, wiki links). The skill to hone is delegation. Invest in a strong initial prompt so you can walk away for an hour, rather than babysitting a vague one. (See the prompting cheat sheet for examples.)

Pick the model by asking how much thinking versus doing the task needs: the SWE suite of models for quick, well-specified changes and fast iteration; Ultra for deep planning and ambiguous, multi-file work.

Three ways to start a session: from an Ask Devin plan, from the session page with a prompt, or by invoking a playbook (more on those in Cloud 102). Attach anything that isn't in the repo (a design spec, a bug screenshot, a CSV) or point at a Jira or Linear ticket directly.

The lifecycle: start from a plan to scope the work, then Devin writes code, runs tests, and iterates while you watch the timeline. You can collaborate mid-session: send follow-ups to steer, make a fix in the IDE, or take over the interactive browser to get past a login. When it's done, Devin opens a PR; the next lesson covers the reviewer that checks it.

Devin's session timeline shows work starting from a delegated task