How we use Claude to write code

Claude is a tool. It helps us think faster and write code faster. But the developer is still in charge. The goal is simple: better code, clear thinking, and full responsibility.

This document explains how we use Claude at DataChef.

1. Always commit your claude.md

Every project that uses Claude must have a claude.md.

This file explains how Claude should behave in the project.

It should include things like:

• coding style
• architecture rules
• libraries we prefer
• things we never do
• how tests should look
• how commits should look

Why this matters:

Claude works best when it has context. Without context it guesses. With context it becomes consistent.

Your claude.md is the memory of the project.

Commit it to the repository so everyone works with the same rules.

2. Put your important prompts in the pull request

When Claude helps write code, the reviewer should know how that code was created.

If a prompt had a big influence on the result, include it in the pull request description.

This helps reviewers understand:

• the intent of Claude
• the reasoning of Claude
• what Claude was asked to do

It also makes it easier to reproduce or improve the result later.

Transparency builds trust.

3. Teach Claude not to sound like AI

Add a new skill for you CLaude to not sound like AI and avoid these patterns:

https://en.wikipedia.org/wiki/Wikipedia:Signs\_of\_AI\_writing

AI text often looks like:

• overly formal language
• repetitive structures
• too many bullet points
• vague explanations
• generic transitions

We want writing that sounds human and direct.

Short sentences. Clear thinking. No filler.

4. Never use dangerously skip permissions for Production

Do not start Claude with --dangerously-skip-permissions

Always review what Claude wants to do.

Read each prompt and tool request before approving it.

You should always know:

• what files Claude reads
• what files Claude changes
• what commands it runs

5. Claude writes code. You own the code.

Claude can generate code, but you are responsible for it.

Always:

• read the code
• understand the code
• question the code

If you cannot explain a change to another developer, do not merge it.

6. Ask for small steps

Do not ask Claude to build a whole system in one prompt.

Work in small steps.

Example flow:

• ask Claude to design the approach
• review the plan
• implement one part
• review again
• continue

Small steps reduce mistakes.

7. Prefer editing over generating

If a file already exists, ask Claude to improve or refactor it.

Do not ask it to rewrite everything.

Large rewrites often introduce hidden problems.

Good prompts look like:

• "simplify this function"
• "remove duplication"
• "add tests for this logic"
• "explain the edge cases"

8. Always ask for tests

If Claude writes logic, it should also suggest tests.

Tests help verify that the code does what we expect.

Good prompts include:

• "write unit tests for this function"
• "add edge cases"
• "show failure scenarios"

You can add this as part of your CLAUDE.md to make sure you never forget.

9. Ask Claude to explain its reasoning

Before accepting a change, ask Claude questions.

Examples:

• why is this approach better
• what edge cases exist
• what could break
• what are the performance risks

Claude is good at surfacing hidden issues when asked directly.

10. Keep prompts simple and direct

Claude works best with clear instructions.

Bad prompt:

"Can you improve this in a robust scalable architecture that follows best practices?"

Better prompt:

"Reduce complexity in this function. Do not change the behavior."

Clarity produces better results.

11. Use Claude as a thinking partner

Claude is not just for writing code.

It is useful for:

• debugging
• reading unfamiliar code
• designing APIs
• writing migrations
• reviewing pull requests
• explaining errors

Treat it like a second developer who thinks fast.

But remember: you are the final reviewer.

12. Leave the codebase better

Every Claude assisted change should improve the codebase.

Examples:

• clearer naming
• better structure
• fewer lines
• stronger tests
• simpler logic

Speed is helpful. Quality is the goal.

Final rule

Claude is powerful.

But good engineering still comes from:

• careful thinking
• good reviews
• clear communication
• responsibility for the code

Use Claude to move faster.

Do not use it to stop thinking.