Claude Features Every Engineer Should Be Using

Beyond "ask it to write a function" — the features that actually change how I work day to day: large context windows, project knowledge, artifacts, and tool use.

Large context windows change what's worth asking

The single biggest unlock isn't a feature toggle, it's the context window size. Being able to paste an entire module, a full Terraform state dump, or a multi-thousand-line log file and ask a question against all of it — rather than hand-picking the "relevant" ten lines — means the model sees connections across the file that I'd otherwise have to hold in my head. For infra debugging specifically, this matters: root causes are often scattered across a config file, a log excerpt, and a diff that's three files away from where the error surfaced.

Projects and persistent context

Claude Projects let you attach reference material — API docs, internal style guides, an architecture doc — once, and have every conversation in that project automatically draw on it. For recurring work on the same codebase or the same internal platform, this removes the "let me re-paste the context" tax from every single conversation.

Artifacts: iterating on a single output

Artifacts give you a persistent, editable side panel for a specific piece of output — a diagram, a script, a config file — that you can iterate on without it getting buried in a long chat thread. For things like a Terraform module skeleton or a Mermaid architecture diagram, this is a materially better workflow than scrolling back through chat history to find "the version from three messages ago."

Extended thinking for genuinely hard problems

For problems that benefit from working through multiple approaches before committing to one — picking an indexing strategy, debugging a subtle race condition, reasoning about a tricky distributed systems trade-off — extended/thinking modes let the model spend more computation up front rather than jumping to the first plausible answer. Reserve it for problems where you'd genuinely want a colleague to "think out loud" before answering, not for routine boilerplate.

Tool use / MCP: connecting to your actual systems

The Model Context Protocol (MCP) lets Claude call out to real tools — read a file from your repo, query your workspace, run a search — rather than operating purely on pasted text. This is the difference between "describe your error to me" and the model actually looking at your codebase, your git history, or your running terminal output to form an answer grounded in what's actually there instead of what you remembered to paste.

// Conceptually: an MCP tool call lets the assistant request real data
// rather than relying on what you manually pasted into the chat
{
  "tool": "read_file",
  "params": { "path": "terraform/modules/vpc/main.tf" }
}

Prompting patterns that actually help

• Give it the error, the relevant code, and what you already tried — not just "it's not working."
• Ask for a plan before code on anything non-trivial — reviewing the plan is cheaper than reviewing a wrong implementation.
• Paste real output (actual stack traces, actual terminal output) rather than summarising it — summaries lose the exact detail that usually matters.
• Iterate in small steps on complex refactors rather than asking for everything at once — easier to verify each step is correct.

Final thoughts

The features that move the needle aren't flashy — they're the ones that reduce the gap between "what the model can see" and "what's actually true about your system": larger context, persistent project knowledge, and real tool access. Treat it like a very fast, very well-read colleague who still needs the actual facts in front of them to be useful.