Best practices · AI
Best Practices for AI Coding Assistants
Opens with creditsTool-neutral best practices for working with AI coding assistants such as Claude Code, GitHub Copilot and Cursor, checked against their official docs, the AGENTS.md convention and the OpenSSF guide to security-focused assistant instructions. It covers instruction files, writing task prompts, verification loops, reviewing generated code, security and dependencies, and managing permissions and context.
Written by Tauseef Fayyaz6 chapters, 24 practicesAbout 17 min22 quiz questionsReviewed 13 October 2026What you will learn
6 chapters · about 17 min
1Project instruction filesAssistants start every session knowing nothing about your project. A short, well-kept instruction file gives them the context they cannot infer from the code.4 practices · 3 min
2Writing task promptsThe quality of a coding session depends on the first prompt. These practices give the assistant enough to solve the right problem the first time.4 practices · 3 min
- Verification loopsAn assistant stops when the work looks done. These practices give it a real signal for done, so it can check and fix its own work.4 practices · 3 minOpens with credits
- Reviewing and owning generated codeGenerated code is your code once you merge it. These practices keep review meaningful when much of the diff came from an assistant.4 practices · 3 minOpens with credits
- Security and dependenciesAssistants repeat insecure patterns from their training data and can invent packages. These practices follow the OpenSSF guide for security-focused assistant instructions.4 practices · 3 minOpens with credits
- Permissions, sandboxing and session hygieneAgentic assistants run commands and edit files on your machine. These practices control what they can touch and keep long sessions effective.4 practices · 2 minOpens with credits
About this guide
AI coding assistants have moved from autocomplete to agents that read a repository, run commands and open pull requests. The productivity gain is real, and so is the new failure mode: plausible code that compiles, passes a quick look and is wrong in a way nobody noticed. These best practices for AI coding assistants are about keeping the speed and catching the mistakes before they ship.
The advice is tool-neutral. It draws on the official best practice guides for Claude Code and GitHub Copilot, the AGENTS.md convention that many assistants now read, and the Open Source Security Foundation's guide to security-focused instructions for code assistants. Where a feature has a tool-specific name, such as a project instruction file or plan mode, the guide describes the idea and names the common versions.
One theme runs through everything: the assistant stops when the work looks done, so you need to give it a way to know when the work is actually done. Tests, builds, type checks and linters turn an assistant from something you have to watch into something that can check itself.
The other theme is ownership. Every guide used here says the same thing in different words: you remain responsible for code you merge, whoever or whatever wrote it. The chapters on review and on security show what that looks like in practice, including the newer risk of assistants suggesting packages that do not exist.
Common questions
What is AGENTS.md?
AGENTS.md is an open, plain Markdown file with project instructions for AI coding agents, such as build and test commands, code style and gotchas. Many tools read it, including OpenAI Codex, Cursor, Gemini CLI and GitHub Copilot's coding agent. In a monorepo, agents use the nearest AGENTS.md in the directory tree.
What should go in a CLAUDE.md or copilot-instructions.md file?
Commands the assistant cannot guess, style rules that differ from defaults, testing instructions, repository conventions, project-specific architecture decisions and environment quirks. Leave out anything it can learn by reading the code, standard conventions and long tutorials. Keep it short; long files cause rules to be ignored.
Is AI-generated code safe to use?
It can be, if you treat it like any other code: understand it, review it for security and maintainability, and run tests, static analysis and dependency and secret scanning. Research summarised by OpenSSF shows generated code often carries vulnerabilities, so do not skip these checks.
What is slopsquatting?
Slopsquatting is when attackers register package names that AI assistants tend to invent, so that developers who install a suggested but non-existent package get malicious code instead. A USENIX Security 2025 study found hallucinated package rates of at least 5.2% for commercial models and 21.7% for open-source models.
How do I get better results from an AI coding assistant?
Give it a check it can run, such as tests or a build, so it can verify its own work. Write specific prompts that name files, symptoms and what done looks like, plan larger changes before coding, keep a short instruction file, and clear the context between unrelated tasks.
Sources (7)
Checked against these, last on 13 October 2026.
- Best practices for Claude Code, Claude Code docscode.claude.com/docs/en/best-practices
- Best practices for using GitHub Copilot, GitHub Docsdocs.github.com/en/copilot/get-started/best-practices
- Adding repository custom instructions for GitHub Copilot, GitHub Docsdocs.github.com/en/copilot/how-tos/configure-custom-instructions/add-repository-instructions
- AGENTS.md, Agentic AI Foundationagents.md/
- Security-Focused Guide for AI Code Assistant Instructions, OpenSSFbest.openssf.org/Security-Focused-Guide-for-AI-Code-Assistant-Instructions
- We Have a Package for You! A Comprehensive Analysis of Package Hallucinations by Code Generating LLMs, USENIX Security 2025www.usenix.org/conference/usenixsecurity25/presentation/spracklen
- Prompting best practices, Anthropic docsplatform.claude.com/docs/en/build-with-claude/prompt-engineering/claude-prompting-best-practices
Related on Sefism
Picked from the other libraries by shared topics.
Roadmaps
See allCheat sheets
See allBest practices
See all- Best Practices for Building LLM AppsHow to build LLM apps and agents that hold up in production: prompts, evals, prompt injection, tool permissions, cost, logging and privacy.
- Prompt Engineering Best PracticesHow to write prompts that work the same way on the hundredth input as on the first: clear instructions, structure, examples, reasoning, output control and testing.
- Best Practices for Building AI AgentsHow to design AI agents that finish real tasks: when to use one, tool design, context and memory, control loops, MCP and agent security, and evaluating agent runs.
Checklists
See all- RAG Production ChecklistA RAG production checklist: chunking, embeddings, hybrid search, reranking, per-user permissions, citations, evals, re-indexing and cost, with how to verify each check.
- LLM Evaluation ChecklistAn LLM evaluation checklist: success criteria, eval datasets, code and model graders, judge calibration, agent evals, safety tests and production monitoring, with how to verify each check.
- AI Feature Launch ChecklistAn AI feature launch checklist: use case fit, evals, UX for errors, disclosure, human override, abuse filters, rate limits, cost caps, prompt privacy, monitoring and rollback.
Project structures
See all- GenAI RAG app (FastAPI) project structureFor developers turning a "chat with your documents" demo into an app people can rely on. A FastAPI backend where every layer has a home: ingestion workers, retrieval, prompts as versioned files, model clients with fallbacks and cost caps, guards, evals that gate CI, and tracing, so a wrong answer can be traced to the step that caused it.
- AI agent with an MCP server project structureFor developers who want to give AI assistants safe access to their own data or API. A TypeScript MCP server built on the official SDK, organised by feature (tasks, projects) with each feature owning its tools, resources and prompts, served over stdio for local hosts and Streamable HTTP with OAuth for remote ones, plus a small agent and the evals that prove a model can use it.
- Python AI agent with LangGraph project structureFor Python developers moving from "call a model in a loop" to an agent that can pause, resume and be debugged. It starts from the official LangGraph template (langgraph.json, a src/agent package, unit and integration tests) and grows into a customer support agent with typed state, one file per node and tool, human approval before refunds, evals that score whole trajectories, tracing, auth and a deployable server image.
Career questions
See all- Which AI tools do employers expect junior developers to know in 2026?Employers rarely require a specific brand. They expect you to use an AI coding assistant well (in the editor and in the terminal), to review and test what it produces, to call an LLM API in a small feature, and to explain when you would not use AI. Pick one assistant, learn it properly, and show judgement in your projects.
- How do I start learning AI agents as a software engineer?Start with one LLM API and plain code: a loop that calls the model, lets it pick a tool, runs the tool and feeds the result back. Build one small agent that does a real task end to end, add evaluation and guardrails, and only then reach for a framework. Agents are software engineering first.
- Should I learn LangGraph, CrewAI or the OpenAI Agents SDK first, or build AI agents without a framework?Build one small agent without a framework first: the tool-calling loop is about fifty lines and every framework wraps it. Then learn one framework deeply, chosen by what your project needs: LangGraph for explicit state and approvals, the OpenAI Agents SDK for quick assistants with handoffs, the Claude Agent SDK for agents that work on files.
Stuck on something specific?
Writing only gets you so far. If you want an answer to your situation rather than the general case, book a session and we will work through it together. Sessions are free for approved Sefism members, and a few slots open each week.
- 1:1 Mentorship
- Fresh Graduate Mentorship
- Career Guidance
Brand deals, promos and partnerships: tauseeffayyaz@gmail.com