How to Write Prompts That Actually Work for Devin AI

The difference between a Devin session that nails it and one that burns through compute units going in circles? Ninety percent of the time, it’s the prompt.

You’ve probably heard that AI agents like Devin are powerful. And they are — but power without direction is just noise. If you’ve ever handed a task to Devin and watched it spin off in the wrong direction, or return something technically correct but completely off from what you needed, this post is for you.

Today is Day 6 of my 45-day Devin AI challenge. Yesterday we covered signing up and running a first session. Now let’s talk about the skill that will determine whether Devin becomes a genuine force multiplier for you or just an expensive experiment: writing effective prompts.

Why Prompting Devin Is Different from Prompting ChatGPT

When you prompt a conversational AI like ChatGPT, a slightly vague question often gets you a decent answer. The model can ask clarifying questions, or just make reasonable assumptions and explain them. You’re in a dialogue.

Devin is different. It’s an autonomous agent. When you give Devin a task, it goes off and executes — often for 10–30 minutes — before surfacing results. It’s running shell commands, browsing docs, editing files, and testing code. If your prompt was ambiguous, you won’t find out until after all that compute has been spent. And if Devin goes off in the wrong direction, the cost isn’t just the ACUs (Agent Compute Units) burned — it’s also the time you spend reviewing and correcting a misaligned result.

Think of it less like chatting with a smart assistant and more like delegating to a capable junior engineer you can’t interrupt mid-task. What would you put in the Jira ticket?

The Three Pillars of a Good Devin Prompt

1. Specificity — Tell Devin Exactly What to Touch

Vague prompts produce vague results. This sounds obvious, but it’s easy to underestimate just how specific you need to be.

Bad: Make the dashboard faster.

Good: The /api/reports endpoint is taking 4–6 seconds on large date ranges. Profile the query in src/db/reports.js and add an index on the (user_id, created_at) column. Verify the improvement with EXPLAIN ANALYZE before and after. Target: response time under 500ms for a 90-day date range with 10k+ rows.

The difference isn’t just detail — it’s that the good prompt tells Devin where to look, what to do, and how to know when it’s done. Without those three things, Devin has to guess, and every guess is a potential divergence from what you actually wanted.

File paths are gold. If you know the relevant file, mention it. src/components/UserTable.tsx is infinitely better than "the user table component." It saves Devin from searching through the codebase and reduces the chance it edits the wrong file.

Name the function, not just the feature. Instead of “fix the login bug,” try: “The authenticateUser() function in src/auth/service.ts returns 500 instead of 401 when the password is wrong. Fix it so it returns 401 with a JSON body of { error: 'Invalid credentials' }."

2. Success Criteria — Define “Done” Explicitly

One of the most underused levers in Devin prompting is the success criterion. This is the line (or lines) that tell Devin — and you — what a completed task looks like.

Without a success criterion, Devin may stop when it thinks it’s done. With one, it can verify its own work and confirm the result matches your expectation.

Here’s a real example from Devin’s own documentation guidance:

Add Jest tests for the AuthService methods: login and logout.
- Coverage for these two functions should be at least 80%
- Use UserService.test.js as a reference for style and structure
- After implementation, run: npm test -- --coverage
- Verify the report shows >80% for both methods
- Tests must pass for both valid and invalid credentials
- Confirm logout clears session data

Notice how that prompt specifies the metric (80% coverage), the reference file to follow (UserService.test.js), the exact command to run (npm test — — coverage), and the specific cases to cover (valid, invalid, session clearing). Devin doesn’t have to wonder if it’s done — the success criteria make it unambiguous.

A practical template for your success criteria section:

After completing the task:
- Run [specific command] and confirm [expected output]
- Check [specific file or endpoint] and verify [expected state]
- Ensure [edge case] is handled by [behavior]

3. Validation Steps — Tell Devin How to Test Its Own Work

Devin has a full desktop environment — shell, browser, and IDE — available to it. That means it can test its own work, but only if you tell it what testing looks like. This is the difference between getting a pull request you still have to validate manually and getting one that’s already been tested.

Bad: Add input validation to the sign-up form.

Good:

Add input validation to the sign-up form in src/pages/SignUp.tsx.

Validation rules:
- Email: must be a valid email format
- Password: minimum 8 characters, at least one number
- Username: 3–20 characters, alphanumeric only

After implementing:
1. Run the dev server with `npm run dev`
2. Open the sign-up form in the browser
3. Test with invalid inputs and confirm the correct error messages appear
4. Test with valid inputs and confirm the form submits successfully
5. Run `npm test` and confirm all existing tests still pass

You’ve now given Devin a QA checklist, not just a feature request. The result should be code that’s already been validated — not just written.

Common Prompt Anti-Patterns to Avoid

The Open-Ended Design Task. Prompts like “Redesign the onboarding flow” or “Refactor the authentication module” are red flags. These involve architectural decisions that require your judgment — not Devin’s. If you want Devin’s help on something like this, break it down first. Identify one discrete, well-scoped sub-task and start there.

No Reference Files. If you’re asking Devin to follow a particular pattern (your team’s test style, a specific component structure), give it an example. “Write tests like we do in UserService.test.js” is far better than “write tests.” Without a reference, Devin will invent its own style — which may or may not match what your team does.

Missing the “Why.” Sometimes a sentence of context makes a huge difference. If Devin knows why a change is needed, it can make better judgment calls in edge cases. “We’re migrating to Postgres because MySQL is being deprecated — update all raw SQL queries in the data layer” is cleaner than just “switch our queries to Postgres syntax.”

Assuming Devin Knows Your Stack. It doesn’t — not automatically. If your app uses a non-obvious pattern, a custom ORM wrapper, or a proprietary API client, mention it. Even better: add it to Devin’s Knowledge Base (a feature that lets you save standing context about your codebase). Knowledge items are auto-recalled when relevant, so you only have to teach Devin your conventions once.

A Prompt Template to Start With

Here’s a starting structure you can adapt for most tasks:

## Task
[One clear sentence describing the goal]

## Context
- Relevant file(s): [path/to/file.ext]
- Related function/component: [name]
- Background: [why this change is needed, if non-obvious]

## Requirements
1. [Specific requirement]
2. [Specific requirement]
3. [Edge case to handle]

## Success Criteria
- Run [command] and verify [expected result]
- Check [file or URL] and confirm [expected state]
- Ensure [specific behavior] works as expected

## Notes
- Follow the pattern in [reference file]
- Do NOT modify [file] — that's handled separately

You won’t always need every section, but having this structure in mind prevents the most common prompt mistakes.

How Prompting Gets Easier Over Time

The good news: you don’t have to write a perfect prompt every time to build a high-functioning workflow with Devin.

Devin has Playbooks — reusable prompt templates for repeated tasks. Once you’ve nailed the prompt for, say, “add unit tests to a new service,” you save it as a Playbook and trigger it with a macro for future tasks. The upfront investment in a great prompt pays dividends across many sessions.

Similarly, the Knowledge Base lets you document your codebase conventions once — your folder structure, your test style, your API patterns — and Devin recalls them automatically. Over time, your prompts can get shorter because Devin already knows the standing context.

We’ll cover both Playbooks and the Knowledge Base in later days of this challenge. For now, the main takeaway is this: start with specificity, define what “done” looks like, and give Devin a way to verify its own work.

Key Takeaways

Prompting Devin well is a skill, not a magic trick. The framework is simple:

Be specific about what to touch. File paths, function names, and expected behavior reduce ambiguity dramatically.

Define success explicitly. Give Devin measurable criteria — coverage targets, expected outputs, or specific behaviors to verify.

Build in validation. Tell Devin how to test its own work. It has a full dev environment; use it.

Avoid open-ended tasks. Break large, ambiguous work into discrete, well-scoped tasks. Devin thrives on the kind of work a junior engineer could knock out in half a day with clear specs.

The engineers who get the most out of Devin aren’t the ones with the fanciest prompts — they’re the ones who treat Devin like a capable collaborator who deserves a clear brief. Write the brief you’d want if you were the one executing the task.

Day 7 of the #45DayDevinChallenge covers real examples of prompts that work vs. prompts that waste ACUs — with side-by-side comparisons and what to watch for.

Sources consulted: Instructing Devin Effectively · Good vs. Bad Instructions · Coding Agents 101