Don't want to set this up manually? Paste a link to this page into a Devin session and ask it to set everything up for you. A developer asked Devin to add pagination to an API endpoint. The prompt was short and reasonable-sounding: ```txt Original prompt (vague) theme={null} Add pagination to GET /api/users. Run the tests when done. ``` The session finished successfully — tests passed, the PR looked good. But it consumed **42 ACUs** for what should have been a **\~12 ACU** task. Three-and-a-half times the expected cost, on a feature that already had a working pattern elsewhere in the codebase. Here's how to find out what went wrong and make sure it doesn't happen again. Every completed session can have a free [Session Insights](/product-guides/session-insights) analysis. Click the **lightbulb icon** in the top bar of any finished session and then click **Generate Analysis** to trigger it — no Advanced session required. For this pagination session, Session Insights flagged: * **Issue Timeline** — Red marks at the 14-minute and 28-minute marks where Devin changed approaches entirely. * **Issues Detected** — "Incorrect codebase assumption: built pagination from scratch when `src/utils/paginate.ts` already existed" and "Wrong implementation type: used cursor-based pagination, but tests expect offset-based." * **Improved Prompt** — A rewritten version with the missing context filled in, ready to copy. * **ACU Usage** — 42 ACUs, flagged as disproportionate for the task scope. For many sessions, this is enough. Copy the improved prompt, start a new session, and compare. But if you want the full phase-by-phase cost breakdown, go deeper. Click **Investigate with Devin** in the Session Insights panel to launch a Devin session pre-loaded with the original session's full history. Or start a new session manually and describe what you want analyzed: ```txt Analyze the pagination session theme={null} This session used 42 ACUs to add pagination to GET /api/users. I expected ~12. Break down: 1. Where did Devin spend an abnormally long time? 2. What dead ends or wrong approaches did it try? 3. What could it have done more efficiently? 4. What context was missing from my prompt? 5. Give me a revised, structured prompt that would avoid these issues. ``` Devin reviews every action from the original session and identifies where time was spent inefficiently: ``` Session analysis | Task: Add pagination to GET /api/users Actual: 42 ACUs | Expected: ~12 ACUs Inefficiencies identified: 1. Unnecessary exploration — investigation phase took abnormally long Devin explored 23 files looking for a pagination helper. It built pagination from scratch, then discovered src/utils/paginate.ts and had to refactor everything. Fix: Mention existing utilities in the prompt. 2. Wrong approach — entire implementation had to be rewritten Devin implemented cursor-based pagination. Tests failed because the API uses offset-based. It rewrote the entire implementation from scratch. Fix: Specify "offset-based" in the prompt. 3. Environment issue — repeated failed installs npm install failed twice due to a missing .npmrc config for the private registry. Devin retried with workarounds. Fix: Add registry config to repo setup. ``` Three root causes, all preventable with a better prompt or repo configuration. You can ask Devin to start a new session with the improved prompt directly — no need to copy-paste. The analysis produces a structured prompt that includes exactly the context that was missing: ```txt Optimized prompt (structured) theme={null} Add offset-based pagination to GET /api/users. ## Context - Use our existing pagination utility at src/utils/paginate.ts - Follow the same pattern as GET /api/projects (already paginated) - Query params: page (default 1), limit (default 20, max 100) - Response shape: { data: User[], meta: { page, limit, total, totalPages } } ## Implementation 1. Add page and limit query params with Zod validation 2. Use paginate() from src/utils/paginate.ts to wrap the Prisma query 3. Return the paginated response matching the shape above ## Testing - Run existing tests with npm test - Verify pagination works with 0 results, 1 page, and multiple pages - Verify invalid page/limit params return 400 Do not open a PR until all tests pass. ``` Compare the two prompts side by side: | | Original | Optimized | | --------------------- | --------------- | --------------------------- | | **Pagination type** | Not specified | "offset-based" | | **Existing utility** | Not mentioned | `src/utils/paginate.ts` | | **Reference pattern** | None | "same as GET /api/projects" | | **Response shape** | Not specified | Explicit schema | | **Testing criteria** | "Run the tests" | Specific edge cases | | **ACU result** | 42 ACUs | \~12 ACUs | The optimized prompt eliminates all three root causes. Devin skips the 23-file exploration, picks the right pagination type on the first try, and follows a proven pattern. A single prompt rewrite saves ACUs on one session. Turning the findings into permanent configuration saves ACUs on every future session. **Add recurring context to [Knowledge](/product-guides/knowledge).** The pagination analysis revealed two facts Devin needs repeatedly — the pagination type and the utility location. Add them as Knowledge entries so every session starts with that context automatically: * *"All API endpoints use offset-based pagination. The shared utility is at `src/utils/paginate.ts`. See GET /api/projects for the reference implementation."* * *"Run tests with `npm test`. Run type checks with `npm run typecheck`."* **Fix workspace issues in [environment configuration](/onboard-devin/environment).** The 3 ACUs wasted on `npm install` failures were caused by a missing `.npmrc` config for the private registry. Adding registry configuration to your environment prevents every future session from hitting that error. **Batch-analyze to find team-wide patterns.** If multiple developers are seeing high-ACU sessions, analyze several at once to find shared root causes: ```txt Batch-analyze recent sessions theme={null} Here are 5 sessions from this week: [paste session links] Find common patterns of ACU waste across all of them. What knowledge entries should I add to prevent these issues in every future session? ```

{title}