Using Claude as Your Coding Assistant

Why does the same developer get wildly different results from Claude on different days — sharp, accurate code one afternoon and confidently wrong suggestions the next? Usually it's not Claude that changed. It's the amount of context in the prompt, and that's the whole story behind using claude as coding assistant well or poorly.

Before: The Weak Prompt

Add pagination to this endpoint.

Why It Fails

This is missing the framework, the existing pagination pattern used elsewhere in the codebase (if any), the database being queried, and whether this needs to support cursor-based or offset-based pagination. Claude will pick reasonable defaults — and reasonable defaults that don't match your actual stack create more work than they save.

⚠️ Common mistake: Assuming Claude remembers your codebase's conventions from a previous, unrelated conversation. Each new chat starts fresh unless you explicitly provide context again — treat every request like you're briefing a contractor who's never seen your code before, because functionally, that's accurate.

After: The Improved Prompt

Framework: [e.g. Express.js with Prisma ORM, Postgres]

Here's the existing endpoint: [paste code]

Here's how pagination is implemented elsewhere in this codebase,
for consistency: [paste example from another endpoint, or state
"no existing pattern — recommend one and explain why"]

Add pagination to this endpoint. Requirements:
- [cursor-based / offset-based], because [reason, e.g. "this table
  grows quickly and offset pagination degrades at scale"]
- Default page size: [number], max: [number]
- Preserve existing error handling pattern shown above

What this does: Providing an existing pagination example (or explicitly saying there isn't one) is the difference between Claude inventing a new pattern that clashes with the rest of your API and Claude extending a pattern that's already consistent. The explicit reasoning for cursor vs. offset also helps Claude flag if your stated reasoning doesn't actually match the choice — a useful sanity check.

Breaking Down Each Element

The framework and ORM line matters more than it looks — Prisma, SQLAlchemy, and raw SQL all handle pagination with completely different idioms, and generic "add pagination" code often defaults to a naive LIMIT/OFFSET pattern regardless of what's actually best for your database.

Pasting the actual endpoint code, not a description of it, lets Claude match your naming conventions, your existing middleware usage, and your error response shape — all things a description would flatten into something generic.

The default and max page size numbers seem like a small detail, but leaving them unspecified means Claude picks arbitrary values that may not match your API's existing conventions or your frontend's expectations.

Variations for Different Contexts

For code review instead of code generation:

Review this pull request diff for [specific concern — security,
performance, or readability, pick one focus per review pass]:
[paste diff]. Flag issues specific to that concern only. For each
issue, cite the line and explain the risk in one sentence.

For architecture decisions:

I'm deciding between [option A] and [option B] for [specific problem].
Constraints: [team size, expected scale, existing stack]. Don't just
list generic pros and cons — reason about which fits these specific
constraints better and say so directly.

Scenario: Solo founder building an MVP with an unfamiliar framework A solo technical founder building his first Rails app used the framework-context pattern heavily, pasting existing controller code every time he asked for a new feature, specifically to keep Claude's suggestions consistent with Rails conventions he was still learning himself.

Scenario: Tech lead reviewing a contractor's pull request A tech lead used the single-focus code review prompt — running it three times with three different focus areas (security, then performance, then readability) rather than one vague "review this" pass — and found the focused passes caught issues a general review had missed on a previous contractor's PR.

Scenario: Engineering manager evaluating a database migration An engineering manager used the architecture-decision prompt to reason through a NoSQL vs. relational database choice for a new service, feeding Claude the team's actual scale numbers and existing operational experience rather than accepting a generic "it depends" answer.

Save and Reuse This

The real fix for inconsistent results when using claude as coding assistant is always the same: more specific context, every time, even when it feels repetitive. Once you've built a solid context template for your stack — framework, conventions, and an example to match — save it in PromptABCD so you're pasting a proven skeleton into every new coding session instead of re-explaining your codebase from scratch.