One task, one session

The single highest-leverage efficiency habit: one clearly scoped task per session. Not because Devin can't handle more, but because focused sessions finish faster, cost less, and are easier to review.

How sessions are sized

Devin classifies every session with a T-shirt size, XS through XL. Size is a composite of two signals: how much Agent Compute Unit usage the session consumed and how many messages you sent. Whichever of the two is larger sets the size. Sessions that land at L or XL are flagged as unhealthy: either Devin hit significant trouble, or the task was too broad for one session. The exact thresholds live in the Devin docs; what matters is the signal, not the number.

Treat L and XL as a smell, the same way you'd treat a thousand-line PR. Aim for XS, S, and M.

Split, don't stretch

When a task feels big, the instinct is to keep one session going and feed it piece after piece. Resist it. Split the work into independent sub-tasks and run a session per piece, in parallel where the pieces don't depend on each other. There are no limits on concurrent sessions, and a fanned-out split usually finishes faster in wall-clock time too: three focused sessions running at once beat one long session doing three things in sequence.

Splitting also contains failure. If one sub-task goes sideways, you relaunch one small session instead of untangling a large one.

Cheap before expensive

Before spending on a session at all, scope in the cheap tier: ask DeepWiki or Ask Devin how the code works, or plan the approach in Ask mode and let it construct the prompt. You learned these tools in Cloud 101; the efficiency framing is that exploration there costs a fraction of exploration inside a running session. Spend pennies on scoping so the session spends its budget on the actual work.

Kill or steer?

Mid-session, when Devin heads the wrong way, you have two moves:

• Steer when Devin misunderstood one specific thing and a single message fixes it: wrong file, wrong flag, missed constraint.
• Kill and relaunch when your correction amounts to re-scoping the ticket. Take what you learned, write a better brief, and start fresh.

The math favors killing earlier than most people do. Each corrective message extends the session, and a session steered five times usually costs more than a clean relaunch with a brief that needed no steering.

Frontload, don't drip-feed

Everything the session will need belongs in the first message: context, constraints, success criteria, references. Drip-feeding requirements one correction at a time is the most common way small tasks become L sessions. You already know how to write that brief from Cloud 102's How to prompt lesson; this course just adds the price tag to the habit.