GitHub Copilot CLI and Django: A Practical Guide

GitHub Copilot CLI is a coding agent you start with copilot in the project root, as described in the GitHub Copilot CLI overview. For Django work, give it clear project instructions and small, testable tasks around models, migrations, the ORM, views, templates, and Django REST framework. This guide shows a reliable way to use it on a Django codebase without letting generic AI behavior break your Django-specific invariants.

How GitHub Copilot CLI fits Django development

Django projects have a predictable structure: apps, models files, migration directories, views, templates, and often a DRF layer. That consistency reduces the guesswork for an agent. GitHub Copilot CLI can read your repo, follow the conventions you define, run management commands, and iterate on failing tests. You can ask it to add a model field, and it can update the model, run makemigrations, create the migration, adjust serializers and tests, and tell you what changed. Because Django’s ORM and form/serializer layers are explicit, the agent’s changes are usually reviewable in a small diff. The main value is not replacing your judgement; it is taking the mechanical parts of a Django change off your hands.

Preparing a Django project for GitHub Copilot CLI

Create a file at .github/copilot-instructions.md or AGENTS.md in the repo root. GitHub Copilot CLI reads project instructions from these files before acting. The file should be short and specific. For Django, include the build, test, lint, migrate commands; your app layout; and rules that prevent common Django mistakes.

# Django project instructions for GitHub Copilot CLI

## Commands
- Install: `python -m pip install -e '.[dev]'`
- Run tests: `pytest`
- Run a single test: `pytest apps/accounts/tests/test_models.py -k test_user_email`
- Lint: `ruff check .`
- Format: `ruff format .`
- Migrate: `python manage.py migrate`
- Make migrations: `python manage.py makemigrations`

## Conventions
- Apps live in `apps/<app_name>/` and are registered in `config/settings/base.py`.
- Models are defined in each app's `models.py`; never import one app's models from another app's migrations.
- Use `settings.AUTH_USER_MODEL` instead of `django.contrib.auth.models.User`.
- DRF serializers live in `api/serializers/` and views in `api/views/`.
- Every endpoint needs permission checks.

## Rules
- Do not edit migration files by hand; always run `makemigrations`.
- Run the full test suite before declaring a change complete.
- Use `select_related` and `prefetch_related` for ORM queries that loop over related objects.
- Template changes go in `templates/<app_name>/`; keep business logic in views or services, not templates.
- Never hardcode secrets; use environment variables.

If your project is large, a codebase map for AI agents can help the agent find models and views faster, but a well-written instructions file is enough for most Django apps.

A practical workflow: plan, change, test, review

Use a plan, small step, test, review loop. Start each change with a one-sentence goal. Ask the agent to show its plan before writing code. Keep one task to one model change, one serializer, one view, or one test case. After each change, run the relevant tests and makemigrations --check --dry-run. Review the diff with git diff before accepting.

• Add a published_at datetime field to the Article model with a database index and a migration. Show the diff before applying.
• Create a DRF serializer for Article that includes the author’s full name and a computed word count, with tests for both.
• Write pytest-django tests for the article list view: anonymous access returns 401, filtering by status works, and pagination is correct.
• Refactor this view to use select_related('author') and prefetch_related('tags') and explain the query count change.
• Check the current migrations and tell me if any data backfill is needed before deploy, without editing migration files.

When a change involves multiple models or serializers, keep the loop spec-driven; see Spec-driven development with AI agents.

Django strengths and pitfalls with GitHub Copilot CLI

Tasks it handles well:

• Adding or changing model fields, including index and unique constraints, and generating migrations with makemigrations.
• Writing DRF serializers, viewsets, and permission classes from existing models.
• Creating pytest-django tests for models, views, and API endpoints.
• Refactoring ORM code to reduce N+1 queries with select_related and prefetch_related.
• Updating templates and forms based on model changes.

Watch closely:

• Migrations: the agent may hand-edit migration files or create circular dependencies between app migrations. Always instruct it to use makemigrations and review the migration graph with python manage.py showmigrations.
• User model: it may import django.contrib.auth.models.User instead of using settings.AUTH_USER_MODEL, which breaks custom user projects.
• ORM performance: it may write nested loops that trigger N+1 queries; require explicit select_related or prefetch_related before merging.
• Templates: it may put filtering, aggregation, or data formatting logic in templates. Keep business logic in views, serializers, or services.
• DRF: it may omit permission_classes, expose fields not listed in fields, or use Serializer where ModelSerializer is expected. Review serializer fields and permissions carefully.
• Tests: it may use Django’s TestCase when pytest-django is configured, or forget pytestmark = pytest.mark.django_db on tests that need the database.
• Settings and environment: it may run migrate against the wrong database if settings are ambiguous. Set DJANGO_SETTINGS_MODULE explicitly.

Verifying Django changes with tests and checks

Tell the agent to run the full test suite after every change. With pytest-django, the standard command is pytest. For a single app, use pytest apps/<app>/tests -k test_name. Before accepting a change, have the agent run the verification commands in the table below and paste the results.

For DRF endpoints, ask the agent to include API-level tests using APIClient and to test both authentication and permission behavior. If the agent says tests pass, still run git diff yourself to spot unintended changes in migrations, settings, or templates.

Running multiple agents on a Django project with AgentVera

When you need faster parallel work on a shared Django codebase, AgentVera lets you run GitHub Copilot CLI and other CLI agents in separate real terminal panels. Each agent can work in its own git worktree, which prevents concurrent changes to the same migration files or serializers from overwriting each other. Automatic code review links findings to file:line, which is especially useful for catching migration ordering bugs and missing serializer updates. Token budgets cap each agent’s work before it burns through test loops, and an approvals queue lets you gate schema changes before they run. These controls make multi-agent Django work safer.

Conclusion: making GitHub Copilot CLI work for your Django team

GitHub Copilot CLI becomes a useful Django teammate when you treat it as a junior engineer with endless stamina: clear instructions, small tasks, and a review step. Set up .github/copilot-instructions.md with your actual commands and conventions, keep changes small, run the suite, and review migrations. Use it for the mechanical parts—models, serializers, tests, and query refactors—while you keep the architectural decisions. Combined with agent orchestration when needed, this is a practical workflow for production Django projects.