Role, Engineering

Claude for
engineering

Reading code, writing code, reviewing pull requests, debugging stack traces, generating tests, and building the little tools that make the repetitive bits go away.

I'm not an engineer but I work with a lot of them, and the gap between engineers who get value from Claude and those who don't is usually about mental model, not technical knowledge. The ones who get value treat it like a senior pair programmer with no sense of stopping. They ask for a plan before code, they iterate on a tight loop, and they never let it touch production without a review. This page is the short version of what that looks like.

Three places to start

Three workflows where Claude earns its keep on engineering work without needing any special infrastructure.

1. First-pass PR review

Paste the diff, paste the context (what the PR is trying to do, any relevant ticket or design doc), and ask Claude for a first-pass review focused on correctness, edge cases, and security. It's not a substitute for a human review. It's a way to focus your human review on the things that actually matter. The thirty-second output will catch half the issues before you've finished your coffee.

PR review prompt, annotated

Four elements, aimed specifically at making the review useful rather than noisy.

YouHere is a pull request adding retry logic to our job runner. The ticket is about jobs occasionally silently failing after a transient network error. Diff pasted below. 1 Here is our internal code review checklist, pasted below, as a reference for what kinds of issues matter to us. 2 Do a first-pass review focused on correctness, edge cases, and any obvious security or performance concerns. Rank your comments by how likely they are to actually bite us. 3 Do not comment on style or naming. If a section of code is fine, say nothing. Only flag things where I genuinely need to decide whether to change them. 4
1
Context. What the PR does and why. Without this every review is generic.
2
Example. Your team's review checklist is the voice reference.
3
The ask. Focus areas and a ranking. "Most likely to bite us first" is the single best filter.
4
Escape hatch. "Say nothing" is an underused instruction. It's what stops the review being 40 comments long.

Where this falls over

Claude will nitpick style and naming if you don't explicitly tell it not to. Say "do not comment on style" up front and stick to substance.

2. Debugging a stack trace

Paste the trace, paste the relevant code, paste what you were trying to do. Ask Claude to walk you through the three most likely causes in order of likelihood, and for each, one thing you could check to confirm or rule it out. This is the pattern that replaces the "I'll just Google this error" reflex, and it's usually faster and more targeted.

Debugging the hard way vs the fast way

Same stack trace. Different amount of context. Dramatically different output.

Youwhat's wrong with my code, i'm getting this error TypeError: Cannot read properties of undefined (reading 'id') at processItem (worker.js:42) at ...
What Claude sends back

Asks five general questions about your code, framework, and environment. Suggests "make sure the item exists before accessing it". Technically correct, practically useless.

YouStack trace pasted below. Relevant code from worker.js pasted below. What I was doing when it happened: running the overnight batch job that processes Monday's ticket backlog. It ran fine yesterday on the same data shape. The only thing that changed overnight was a dependency upgrade to the "ticketlib" package from 2.3 to 2.4. Walk me through the three most likely causes in order of likelihood. For each, give me one thing I could check or log to confirm or rule it out.
What Claude sends back

Three ranked causes, each with a specific check:

  1. Most likely: ticketlib 2.4 changed the shape of a response. The 2.4 release notes mention a breaking change to the pagination response. Check if item is now nested under item.data instead of being returned directly. One-line check: log the response shape just before line 42.
  2. Possible: a malformed row in Monday's data. The error would happen on one row and then crash the whole batch. Wrap line 42 in a try/catch that logs the row ID and skips it, and see if only some rows fail.
  3. Less likely: race condition between workers. Would normally show up as intermittent, not consistent. Check if this is reproducible with a single worker.

Where this falls over

If you paste the trace without the code, Claude will guess wildly. If you paste both without the context of what you were doing, it will still guess but slightly less wildly. Always include all three.

3. Scaffolding a new feature with Claude Code

For any greenfield feature, the best workflow is: describe what you want in a few sentences, ask for the plan before the code, review the plan, then let Claude Code execute step by step. The tight loop (plan, step, verify, step, verify) is the thing that stops it going off the rails. The faster you see something running, the earlier you catch problems.

Scaffolding a small tool, as a conversation

A rough reconstruction. Notice that nothing gets written until the plan is approved.

YouI need a small CLI tool that watches a folder for new CSV files, validates each row against a schema, and alerts me when anything fails. Python, standard library only if possible.
ClaudeGot it. Before I write any code, here's the plan: (1) main.py using watchdog to monitor the folder, (2) schema.py with the validation rules as a dataclass, (3) a simple stdout alerter, (4) a test that runs against a sample CSV with two deliberately broken rows. Any of that off, or want me to go ahead?
YouLooks right. Skip the test file for now, we'll add tests once the basic loop is working.
ClaudeDone. Writing main.py first so you can see the skeleton before I fill in the schema. I'll stop after that and you can run it against an empty folder to confirm the file-watching works, then I'll build schema.py.
YouGo.
ClaudeHere's main.py. It uses the `watchdog` library (not standard library, worth the dependency). Run it now, drop a test CSV into the folder, and you should see a "new file detected" line in stdout. If that works, tell me and I'll build schema.py next.

Where this falls over

Letting Claude Code run without a plan is how you get an hour of work you can't use. The three most useful words in this workflow are "show me first".

Worked examples

Before and after, on tasks from engineering work.

Prompts to steal

Copy any of these, fill in the square brackets, run.

Try this week

Pick one. All of these are under an hour.

A lot of the engineering work across Abingdon is going to end up touching Claude in one form or another. The thing that separates the people who ship something useful from the people who build a demo and move on is the habit of evaluation. Even twenty test cases is better than zero.

If you want to go broader, the Beginner guide covers the habits that apply everywhere. The prompt library has the full set of role-tagged prompts in one place.