Claude for engineering teams: beyond the obvious

Engineering teams have a complicated relationship with AI. Most engineers already know Claude. Many have strong opinions. And somehow, engineering teams are often the last in an organisation to build a consistent, configured Claude workflow — even though they're surrounded by the tools to do it.

The reason is usually this: engineers try Claude for code generation, find it useful but not transformative, and file it under "nice to have." The teams that get the most out of Claude have found a different set of use cases — ones where Claude is not replacing what they already do well, but filling the gaps where the team is genuinely slow.

What engineering teams actually use Claude for

The high-value use cases are rarely "write me a function." They are:

Incident and postmortem analysis. After an incident, someone has to write a postmortem. It involves synthesising logs, timelines, and stakeholder perspectives into a structured document. Claude is excellent at this: give it the raw Slack thread, the alert timeline, and the bullet points from the retro, and it will produce a first draft in minutes. Engineers still own the analysis — Claude handles the structure and prose.

Documentation that actually gets written. Engineering teams perpetually underdocument. Claude doesn't fix the problem of "no one wants to write docs" — but it dramatically lowers the cost. An engineer can describe a system verbally, paste in the relevant code, and ask Claude to produce an ADR (Architecture Decision Record), a README, or an API reference. The draft takes five minutes; cleaning it up takes fifteen. Before, writing it from scratch took two hours — so it didn't happen.

PR review prep. Before requesting a review, engineers can ask Claude to review their own PR: "Here is the diff. What edge cases am I missing? What would a senior reviewer likely flag?" This does not replace human review — it makes it faster and catches obvious issues before they waste a reviewer's time.

Debugging unfamiliar code. "I'm looking at this function and I don't understand why it does X. Here is the context." Claude is patient, thorough, and doesn't make you feel stupid for not knowing something. For engineers working in an unfamiliar part of the codebase, or dealing with someone else's legacy code, this is often the highest-value daily use.

Writing RFC and design doc prose. Most engineers can produce a bullet list of what a system should do. Turning that into a coherent RFC that non-engineers can read is a different skill. Claude is good at this translation — particularly when you give it the bullet points, the constraints, and an example of a past RFC you liked.

Setting up a Claude Project for engineering

The engineering Project often gets neglected because engineers assume they don't need configuration — they'll just ask ad hoc. This works poorly. A well-set-up engineering Project should include:

In the system prompt:

• Your stack (languages, frameworks, infrastructure)
• Your coding conventions and style guide principles
• What makes a good PR in your org (what reviewers actually check for)
• Your incident severity definitions
• Any acronyms or internal names Claude would otherwise guess at

Documents to upload:

• Architecture overview (one-pager or diagram description)
• Your ADR template
• Your postmortem template
• A sample RFC in your org's format
• Any public API contracts relevant to your team's work

The goal is not to give Claude your entire codebase — it's to give Claude the context it needs to produce outputs in your organisation's format, voice, and technical style. A Claude that knows you use TypeScript with strict mode, prefer functional React, and write ADRs in Notion beats a generic Claude every time.

The skeptic arc

Most engineering teams go through a predictable pattern:

1. Skepticism ("I write better code than it does")
2. Narrow adoption ("I use it for regex and SQL but nothing else")
3. Bottleneck discovery ("Wait, this postmortem would have taken me three hours")
4. Expansion ("I now use it for anything where the output is prose or structure, not logic")

The teams that get stuck at stage 2 are usually using Claude for the wrong thing: asking it to generate core application logic from scratch, which is genuinely hit or miss. Teams that move past stage 2 have found the tasks where Claude is reliably excellent: synthesis, structure, documentation, and explaining things.

It helps to share specific examples within the team. "Here's the PR description I generated in two minutes" is more convincing than any argument. Engineers are empiricists — show them evidence, not theory.

Claude Code vs Claude for engineering teams

Claude Code (the terminal tool) and Claude (the workspace) are different tools for different contexts. Claude Code is for deep, in-codebase work: multi-file edits, test generation, refactoring with full file context. Claude in the workspace is for synthesis, communication, and knowledge work around the engineering process.

Most engineering teams benefit from both. Claude Code replaces many coding tasks that previously required a human. Claude in Projects replaces many communication and documentation tasks that previously required effort no one wanted to spend.

If your engineering team is only using one, they're leaving half the value on the table.

What doesn't work

Pasting entire codebases. Claude has a large context window, but flooding it with code it doesn't need produces worse outputs, not better. Give it the relevant file, the function, and the context — not the whole repo.

Vague questions. "How do I make this faster?" produces less useful output than "This function scans 500k rows on every API call. The table has an index on user_id. Here's the query plan. What am I missing?"

Skipping review for customer-facing outputs. Claude-drafted customer communications, release notes, and external documentation should always have a human pass. The bar for "good enough to ship" is higher than "good enough as a first draft."

Further reading

• How enterprises are building AI agents in 2026 — real enterprise agent deployment patterns
• Claude and Slack — how Claude works in Slack for team collaboration