---
title: "Good vs. Bad Instructions - Autohand Code"
source: https://docs.autohand.ai/guides/beginners/good-vs-bad
---

# Good vs. Bad Instructions

See real examples of effective and ineffective prompts side by side. Small changes in how you write instructions can make a big difference in results.

## The key principles

Writing good instructions for Autohand Code comes down to four habits. Once you internalize these, everything else follows naturally.

-   **Be specific, not vague.** Tell Autohand Code exactly what you need instead of leaving it to guess. The more precise you are, the less back-and-forth you need.
-   **Include context about intent, not just the change.** Explain why you want something done. This helps Autohand Code make better decisions when it runs into edge cases.
-   **Reference files and locations when you know them.** If you already know where the problem is or where the code should go, say so. It saves time and avoids changes in the wrong place.
-   **Describe the outcome you want.** Instead of dictating every step, describe what done looks like. Autohand Code can often find a better path to the result than you would prescribe.

**Rule of thumb:** If another developer on your team could not act on your instruction without asking follow-up questions, Autohand Code will struggle with it too.

## Bug fixing examples

Bug reports need symptoms, location, and expected behavior. Vague reports lead to guesswork.

#### Bad:

``` text
fix the bug
```

Too vague. Which bug? Where? What is it doing wrong?

#### Good:

``` text
The login form shows a blank screen after submitting valid credentials.
Fix the redirect logic in src/auth/login.ts
```

Specific symptom, file location, and a clear pointer to where the problem likely lives.

#### Bad:

``` text
it's broken
```

No context at all. Autohand Code has nothing to work with.

#### Good:

``` text
The API returns 500 on POST /api/orders when the items array is empty.
Add validation to return 400 with a helpful error message
```

Error code, endpoint, trigger condition, and expected fix all in two lines.

## Feature building examples

Feature requests need scope, technology choices, and references to existing patterns in your codebase.

#### Bad:

``` text
add authentication
```

Authentication is a huge topic. OAuth? JWT? Session-based? What endpoints?

#### Good:

``` text
Add JWT-based login to the Express API. Use bcrypt for password hashing,
store tokens in httpOnly cookies, and add a /me endpoint that returns
the current user
```

Specific technology choices, clear scope, and a concrete deliverable.

#### Bad:

``` text
make a dashboard
```

What kind? What data? Where does it live?

#### Good:

``` text
Create a sales dashboard page at /dashboard with three cards showing
total revenue, active orders, and new customers this month. Use the
existing Card component from src/components/ui
```

Route, data points, and a reference to existing components so Autohand Code stays consistent with your codebase.

## Refactoring examples

Refactoring instructions should name the pattern you want, the target, and any constraints on behavior.

#### Bad:

``` text
clean up the code
```

What does "clean" mean? Different developers have different opinions.

#### Good:

``` text
Refactor the UserService class to use dependency injection instead of
direct database calls. Extract the DB queries into a UserRepository
```

Clear pattern (DI), specific target (UserService), and a concrete extraction step.

#### Bad:

``` text
make it better
```

Better how? Faster? More readable? More testable?

#### Good:

``` text
Split the 400-line handleRequest function in api/router.ts into separate
handler functions, one per HTTP method. Keep the same behavior
```

Measurable change, specific file, and a safety constraint that existing behavior should not change.

## Testing examples

Test instructions should specify the function, the type of test, and the edge cases you care about.

#### Bad:

``` text
write tests
```

For what? What kind of tests? What should they cover?

#### Good:

``` text
Write unit tests for the calculateDiscount function in src/pricing.ts.
Cover edge cases: zero quantity, negative prices, expired coupons, and
percentage discounts over 100%
```

Function name, test type, file location, and four specific edge cases. Autohand Code knows exactly what to produce.

## Git and review examples

Git workflows benefit from explicit steps and safety checks. Autohand Code respects careful, staged approaches.

#### Bad:

``` text
commit this
```

No context about what changed or what the commit message should say.

#### Good:

``` text
Review my staged changes, then create a commit with a conventional
commit message
```

Clear two-step workflow: review first, then commit with a standard format.

#### Bad:

``` text
push to prod
```

Dangerous without any review step. Autohand Code will push, but you might regret it.

#### Good:

``` text
Review the diff between this branch and main. Flag any security concerns
or breaking changes before I merge
```

Safety-first approach. Get a review before taking action.

## Pipe mode examples

Pipe mode lets you send data directly to Autohand Code from other commands. Pair the piped context with a clear instruction.

#### Bad:

``` bash
echo "fix" | autohand
```

No context, no data, no direction.

#### Good:

``` bash
git diff --staged | autohand "Review these changes for potential issues and suggest improvements"
```

The staged diff provides context, and the instruction tells Autohand Code what to do with it.

#### Good:

``` bash
cat error.log | autohand -p "Analyze this error log and identify the root cause"
```

Log analysis with pipe mode. Autohand Code receives the full log and a focused task.

## Quick reference

A summary of the patterns covered in this guide.

| Pattern | Bad | Good |
|---|---|---|
| Scope | "fix it" | "Fix the null pointer in auth/session.ts line 42" |
| Context | "add a form" | "Add a contact form to the /about page using the existing Form component" |
| Outcome | "make it faster" | "Optimize the product list query to use pagination instead of loading all 10k records" |
| Safety | "change the database" | "Add a migration to rename the users.name column to users.full_name" |

## Next steps

-   [Autohand Code in your SDLC](/docs/guides/beginners/sdlc-integration.html) - Learn how Autohand Code fits into your development lifecycle
-   [Instructing Autohand Code](/docs/guides/beginners/instructing-autohand.html) - Dive deeper into writing effective prompts
-   [Plan mode](/docs/working-with-autohand-code/plan-mode.html) - Use plan mode for large, multi-step tasks