Concepts used in this article
You do not need to know them in advance. Open an explanation when a term is unfamiliar.
Python
The programming language used to build Django and most Django projects.
Read the explanation →Web application
A program people use through a browser or an HTTP API.
Read the explanation →Django in plain language
A web application is a program that people use through a browser or a programmatic web interface. An online shop, an editorial site, and an internal dashboard can all be web applications. Building them repeatedly requires similar parts: handling addresses, working with data, processing forms, managing accounts, and checking access.
Django is a free and open-source web framework for building these programs with Python. A framework provides reusable components and shared conventions, so a team does not have to rebuild the entire technical foundation. It does not decide the product for developers or remove the need to understand their own code.
Developers in companies, organisations, and governments use Django. According to the official overview, people have used it for content management systems, social networks, and scientific computing platforms, among other products. It is a general foundation for a web application, not one finished page.
Think of a workshop. Python is the language you use to describe how the program should behave. Django is a workshop equipped with reusable tools and conventions for combining them. Your web application is the particular thing you build there.
Concepts you need first
This article does not assume one universal level of reader knowledge. If Python and web development are new to you, these definitions are enough to begin:
- Python is the programming language used to build Django and usually to write a Django project’s code. The code lives in files and contains instructions, functions, and objects.
- A web application is a program that receives a web request and returns a response. A browser may display that response as a page, while another program may process it as data.
- HTTP is a set of rules for exchanging web requests and responses. Here, it is enough to know that a request contains an address and other data, while a response contains a result and information about it.
- HTML is text markup that a browser uses to construct a page.
Canonical learning pages for Python and web applications are not available in this learning system yet. These are explicit gaps, not assumptions about what the reader knows. The minimum needed here is explained above.
How one web request moves through Django
When a person opens an address, the browser sends an HTTP request to a program on a server. For a first encounter, the path inside Django can be described like this:
- Django receives a request for an address such as
/articles/. - A route maps the address path to a view—Python code that prepares the response.
- The view runs the application logic. When needed, it uses a model to work with a database.
- The view may pass data to an HTML template or produce another response type, such as JSON.
- Django returns the response, and the browser displays the result.
A model, database, and template are not required for every response. The simplest view can return a short piece of text directly. Real projects may also add intermediate processing, but this model shows the main roles without incorrectly requiring every component.
A project and an app are not the same thing
In Django, a project is the whole website or service with shared settings. It defines enabled components, top-level routes, and environment configuration, including database configuration when a database is needed.
An app is a distinct functional area inside the project. An article catalogue, user accounts, and comments can be separate apps. An app is not necessarily a standalone website; it is a way to group code with a clear responsibility.
When an AI agent proposes a new app, ask it to state the app’s responsibility in one sentence. If that boundary cannot be explained, a separate app may be premature.
What Django provides
- Routes and views connect web addresses to Python code.
- An ORM lets developers describe data with Python classes and perform many common operations without hand-writing most SQL queries.
- Migrations describe database-structure changes in files that are applied in a defined order. They are powerful, but the first exercise does not need them.
- Templates and forms help produce HTML, receive input, and report validation errors.
- Authentication and permissions provide a foundation for user sign-in and access checks.
- The admin site creates an internal interface for managing models. It does not replace a deliberately designed product interface.
Django also provides mechanisms that help developers avoid common web risks, including SQL injection, CSRF, and cross-site scripting. This is not a security guarantee. The official documentation stresses layered security, proper handling of untrusted data, and an understanding of each mechanism’s limits.
What Django and an AI agent do not solve automatically
Django cannot decide by itself which data is private, who should receive access, what correct business behaviour means, or how a system should recover from a failed deployment. A real project still requires knowledge of Python, HTTP, data, testing, security, and operations.
An AI agent can explain unfamiliar code, map a project, prepare a small change, and help with a test. It can also guess the repository structure incorrectly, recommend an incompatible version, or confidently expand the task without permission.
Give the agent only the context it needs, state allowed and prohibited actions separately, and stop at the first unexplained change. Verification means code read by a person, a reproduced test, checked documentation, and observed file state. The sentence “everything works” from an agent replaces none of these.
Six stages of safe work with an agent
The learning path in the frontmatter has two branches because a new empty folder and an existing project have different risks. Both follow the same sequence: understand the goal, inspect the boundaries, make a plan, perform only the approved action, verify the result independently, and explain it in your own words.
In a new disposable folder, the agent may create an isolated environment and a minimal local example. The initial installation of an approved Django version is allowed only inside that environment. Existing-package upgrades, migrations, an external database, secrets, production, and public deployment are unnecessary and prohibited.
In an existing project, the agent first reads only approved files in a separate working copy. After a map and written plan, the owner may separately approve one test, a database-free local page, or a documentation change. That approval does not extend to dependencies, migrations, data, secrets, production, or publication.
What the first result should be
For a first encounter, one local page with one route, one view, and one test is enough. User registration, Docker, an external database, and cloud deployment only add more unfamiliar parts. A smaller example is easier to read, verify, and remove.
The result is not complete when the agent reports success. You must independently connect the address to the route and view, explain the test condition, repeat the check, and confirm the boundaries of the changed files.
From there, sensible next topics include Python, HTTP, models and databases, templates, forms, testing, security, and deployment. Each topic should add one understandable capability rather than turning the first exercise into an unverified production service.
Sources
Move from explanation to a verified result with an AI agent
Choose the branch that matches your situation. Each branch moves through understand, inspect, plan, act, verify, and explain. The agent may act only within approved local boundaries, and its own claim never counts as verification.
Completed steps:0 / 0
I do not have a Django project yetBuild the learning example only in a new disposable folder that you can safely remove by hand afterwards.
Understand the path of one request
Explain how an address in a browser becomes a Django response before running any command.
Boundaries, checks, and agent brief
Understand first
- A route selects a view, and the view prepares a response.
- A model and a template are not required for every response.
Safe context for the agent
- The 'How one web request moves through Django' section of this article.
- Your one-sentence explanation of the flow.
Allowed
- Explain terms, ask checking questions, and show pseudocode that does not run commands or change files.
Not allowed
- Run commands, create files, request device access, or treat the agent's answer as proof of understanding.
Stop when
- You cannot explain the difference between a route and a view in your own words.
- The explanation incorrectly claims that every response requires a database or template.
How to verify
- Close the agent's answer and walk through the diagram from left to right yourself.
- Compare the roles of the route and view with this article.
Goal: Explain how an address in a browser becomes a Django response before running any command. Safe context for the agent: - The 'How one web request moves through Django' section of this article. - Your one-sentence explanation of the flow. Allowed: - Explain terms, ask checking questions, and show pseudocode that does not run commands or change files. Not allowed: - Run commands, create files, request device access, or treat the agent's answer as proof of understanding. Stop when: - You cannot explain the difference between a route and a view in your own words. - The explanation incorrectly claims that every response requires a database or template. Expected artifact: Your browser → route → view → response diagram, with model and template marked as optional. How to verify: - Close the agent's answer and walk through the diagram from left to right yourself. - Compare the roles of the route and view with this article.
Inspect the future learning workspace
Confirm that the work will happen in a new empty folder and will not touch existing projects.
Boundaries, checks, and agent brief
Understand first
- The folder path defines the boundary of the agent's file operations.
- An initial Django installation in a new virtual environment must not alter the system Python installation.
Safe context for the agent
- The operating system, available Python version, and absolute path to a folder created specifically for this exercise.
Allowed
- Show the Python version, list the approved folder only, and explain which local files a virtual environment may create.
Not allowed
- Read other folders, the home directory, repositories, .env files, or credential stores; install packages, change files, use administrator privileges, or connect to production, cloud services, or real databases.
Stop when
- The folder is not empty, its path is ambiguous, it is inside an existing repository, or inspection requires elevated privileges.
How to verify
- Independently confirm the absolute path and list the folder again.
Goal: Confirm that the work will happen in a new empty folder and will not touch existing projects. Safe context for the agent: - The operating system, available Python version, and absolute path to a folder created specifically for this exercise. Allowed: - Show the Python version, list the approved folder only, and explain which local files a virtual environment may create. Not allowed: - Read other folders, the home directory, repositories, .env files, or credential stores; install packages, change files, use administrator privileges, or connect to production, cloud services, or real databases. Stop when: - The folder is not empty, its path is ambiguous, it is inside an existing repository, or inspection requires elevated privileges. Expected artifact: A note with the exact path, Python version, and confirmation that the learning folder is empty. How to verify: - Independently confirm the absolute path and list the folder again.
Plan the minimal local example
Agree on the action sequence and first-project boundaries before any command runs.
Boundaries, checks, and agent brief
Understand first
- A virtual environment isolates learning packages from the system installation.
- The first example does not need an external database, migrations, credentials, or deployment.
Safe context for the agent
- The verified folder and Python note, the official Django tutorial for a compatible version, and the agreed local-page text.
Allowed
- Propose commands to create a virtual environment, initially install a compatible Django version, and create a minimal project; name expected files, network access, and verification for each command.
Not allowed
- Upgrade existing packages or system Python; plan migrations, database changes, optional packages, destructive commands, production access, or public deployment.
Stop when
- Python and Django compatibility has not been confirmed in official documentation, or a command leaves the folder, requires elevated privileges, or has an unclear side effect.
How to verify
- Independently match the version to official documentation and confirm that the plan changes nothing outside the learning folder.
Goal: Agree on the action sequence and first-project boundaries before any command runs. Safe context for the agent: - The verified folder and Python note, the official Django tutorial for a compatible version, and the agreed local-page text. Allowed: - Propose commands to create a virtual environment, initially install a compatible Django version, and create a minimal project; name expected files, network access, and verification for each command. Not allowed: - Upgrade existing packages or system Python; plan migrations, database changes, optional packages, destructive commands, production access, or public deployment. Stop when: - Python and Django compatibility has not been confirmed in official documentation, or a command leaves the folder, requires elevated privileges, or has an unclear side effect. Expected artifact: A reviewable command plan with versions, boundaries, expected files, and a separate check for every result. How to verify: - Independently match the version to official documentation and confirm that the plan changes nothing outside the learning folder.
Build one page under supervision
Create a minimal local Django project with one route, one view, and one test.
Boundaries, checks, and agent brief
Understand first
- Every change must correspond to the approved plan, and you must read the diff.
Safe context for the agent
- The written approved plan, the absolute path to the empty learning folder, and the local-page text.
Allowed
- Create a virtual environment only in the learning folder; download the approved Django version from an approved source; create a minimal project, route, view, and local test; show the file list and diff after each action group.
Not allowed
- Upgrade existing packages, create or apply migrations, change databases, read secrets, connect external services or production, use real credentials, run destructive commands, change other paths, publish the application, or expose the server beyond the local device.
Stop when
- A command differs from the plan, touches another path, proposes an upgrade, a test fails, a change cannot be explained, or a password, token, external database, or elevated privilege is requested.
How to verify
- Independently inspect the file list, read the route, view, and test, and compare them with the plan.
Goal: Create a minimal local Django project with one route, one view, and one test. Safe context for the agent: - The written approved plan, the absolute path to the empty learning folder, and the local-page text. Allowed: - Create a virtual environment only in the learning folder; download the approved Django version from an approved source; create a minimal project, route, view, and local test; show the file list and diff after each action group. Not allowed: - Upgrade existing packages, create or apply migrations, change databases, read secrets, connect external services or production, use real credentials, run destructive commands, change other paths, publish the application, or expose the server beyond the local device. Stop when: - A command differs from the plan, touches another path, proposes an upgrade, a test fails, a change cannot be explained, or a password, token, external database, or elevated privilege is requested. Expected artifact: A local page, one automated test, and a diff of all created files that you have read. How to verify: - Independently inspect the file list, read the route, view, and test, and compare them with the plan.
Independently verify the page and change boundaries
Establish the result through observable checks rather than the agent's claim.
Boundaries, checks, and agent brief
Understand first
- A passing test verifies only its encoded condition; the page and file boundaries require separate checks.
Safe context for the agent
- The created files, agreed page text, single-test command, and initial path note.
Allowed
- Run the approved test in the learning environment, run the server locally for a short manual check, and show the exit status and file list.
Not allowed
- Change code, weaken the test, add network access, or contact external services, production, or real data.
Stop when
- The test fails, the page has different text, the server is reachable beyond the local device, or an unexplained file or process appears.
How to verify
- Run the test yourself again, open the local address, compare the text, and confirm that the server has stopped.
Goal: Establish the result through observable checks rather than the agent's claim. Safe context for the agent: - The created files, agreed page text, single-test command, and initial path note. Allowed: - Run the approved test in the learning environment, run the server locally for a short manual check, and show the exit status and file list. Not allowed: - Change code, weaken the test, add network access, or contact external services, production, or real data. Stop when: - The test fails, the page has different text, the server is reachable beyond the local device, or an unexplained file or process appears. Expected artifact: A record of the actual test result, local page check, and folder-boundary check. How to verify: - Run the test yourself again, open the local address, compare the text, and confirm that the server has stopped.
Explain the result without the agent's prompt
Keep the knowledge, not only the generated code.
Boundaries, checks, and agent brief
Understand first
- The address, route, view, response, and test have distinct roles.
Safe context for the agent
- The route, view, test, and independent verification results.
Allowed
- After your answer, ask the agent to identify one possible inaccuracy with a file or official-documentation reference.
Not allowed
- Let the agent write the explanation for you, create another project, or treat its agreement as proof of correctness.
Stop when
- You cannot connect the address to the response function or explain the limits of the test.
How to verify
- Change only the response text by hand, predict the test result, repeat the check, restore the agreed state, and compare your explanation with code.
Goal: Keep the knowledge, not only the generated code. Safe context for the agent: - The route, view, test, and independent verification results. Allowed: - After your answer, ask the agent to identify one possible inaccuracy with a file or official-documentation reference. Not allowed: - Let the agent write the explanation for you, create another project, or treat its agreement as proof of correctness. Stop when: - You cannot connect the address to the response function or explain the limits of the test. Expected artifact: Your concise explanation of the files, test, and completed checks. How to verify: - Change only the response text by hand, predict the test result, repeat the check, restore the agreed state, and compare your explanation with code.
I already have a Django projectStart with a read-only map of a separate working copy. A change is allowed only after a plan and separate approval, and it may not touch dependencies, migrations, data, secrets, or production.
State the learning question
Define exactly what you want to understand before granting access to files.
Boundaries, checks, and agent brief
Understand first
- A project defines shared configuration, while apps group distinct product capabilities.
- Explaining one address path is safer and more testable than analysing the whole project.
Safe context for the agent
- This article's sections about requests, projects, and apps; one address, capability, or test.
Allowed
- Help narrow the question, name needed evidence, and explain general terms without repository access.
Not allowed
- Request an archive of the whole project, secrets, a database dump, production access, or assume repository structure without inspection.
Stop when
- The question has no boundary or requires real user data.
How to verify
- State the question and sufficiency condition in one sentence and confirm that the list contains no secrets or production data.
Goal: Define exactly what you want to understand before granting access to files. Safe context for the agent: - This article's sections about requests, projects, and apps; one address, capability, or test. Allowed: - Help narrow the question, name needed evidence, and explain general terms without repository access. Not allowed: - Request an archive of the whole project, secrets, a database dump, production access, or assume repository structure without inspection. Stop when: - The question has no boundary or requires real user data. Expected artifact: One bounded learning question and a list of file types that may answer it. How to verify: - State the question and sufficiency condition in one sentence and confirm that the list contains no secrets or production data.
Map the project without changing it
Find confirmed links between an address, route, view, data or template, and test.
Boundaries, checks, and agent brief
Understand first
- A filename or a confident agent assumption does not prove that code participates in the request.
Safe context for the agent
- The path to a separate local working copy, a confirmed clean version-control baseline, and only approved dependency, configuration, route, view, and test files.
Allowed
- Read approved tracked files, show the relevant tree, inspect version-control state and declared dependency versions without installation or execution, and label assumptions separately from facts with file and line references.
Not allowed
- Read .env files, keys, tokens, credential stores, dumps, or production data; run the application, tests, migrations, installations, or commands that may contact external systems; change code, dependencies, databases, configuration, or repository state.
Stop when
- There are unexplained local changes, values resembling secrets, or continuing requires code execution, network access, or an unapproved file.
How to verify
- Open every cited file and line yourself and confirm that the local-change report and diff remain empty.
Goal: Find confirmed links between an address, route, view, data or template, and test. Safe context for the agent: - The path to a separate local working copy, a confirmed clean version-control baseline, and only approved dependency, configuration, route, view, and test files. Allowed: - Read approved tracked files, show the relevant tree, inspect version-control state and declared dependency versions without installation or execution, and label assumptions separately from facts with file and line references. Not allowed: - Read .env files, keys, tokens, credential stores, dumps, or production data; run the application, tests, migrations, installations, or commands that may contact external systems; change code, dependencies, databases, configuration, or repository state. Stop when: - There are unexplained local changes, values resembling secrets, or continuing requires code execution, network access, or an unapproved file. Expected artifact: An address → route → view → data/template → test map with exact references and explicit gaps. How to verify: - Open every cited file and line yourself and confirm that the local-change report and diff remain empty.
Plan one small change
Prepare a testable plan without executing it automatically.
Boundaries, checks, and agent brief
Understand first
- Every planned file must connect to the learning question and a completion criterion.
Safe context for the agent
- The verified project map, one learning goal, and a documented local test environment without production or external data.
Allowed
- Propose, on a separate local branch, one test, one database-free local page, or a documentation clarification; name files, risks, checks, and a manual way to restore only planned lines.
Not allowed
- Plan package upgrades, migrations, database or production-configuration changes, access to secrets, external services, real data, public deployment, or execution without separate owner approval.
Stop when
- A safe local environment is not confirmed, or there is no exact expected result, test, or restoration method.
How to verify
- Review the plan before changing files, reject unnecessary files, and compare the test command with repository documentation.
Goal: Prepare a testable plan without executing it automatically. Safe context for the agent: - The verified project map, one learning goal, and a documented local test environment without production or external data. Allowed: - Propose, on a separate local branch, one test, one database-free local page, or a documentation clarification; name files, risks, checks, and a manual way to restore only planned lines. Not allowed: - Plan package upgrades, migrations, database or production-configuration changes, access to secrets, external services, real data, public deployment, or execution without separate owner approval. Stop when: - A safe local environment is not confirmed, or there is no exact expected result, test, or restoration method. Expected artifact: A one-change plan with files, criteria, a test, boundaries, and a restoration method. How to verify: - Review the plan before changing files, reject unnecessary files, and compare the test command with repository documentation.
Perform only the approved small change
Implement one local learning step without expanding the scope.
Boundaries, checks, and agent brief
Understand first
- Separate plan approval does not allow related modernisation work.
Safe context for the agent
- The written approved plan, permitted files, a clean local branch, and a documented local test command without production dependencies.
Allowed
- Change only listed files for one test, database-free local page, or documentation; show a diff after every file; run only the approved local test.
Not allowed
- Change dependencies, create or apply migrations, touch databases, secrets, production, external services, or real user data; run destructive commands, rewrite history, publish, or deploy changes.
Stop when
- An unapproved file, command, or access level is needed; the test contacts an external system, fails, creates unexplained files, or the diff leaves the permitted list.
How to verify
- Read every changed line yourself, map it to the plan, and inspect repository status for unplanned files.
Goal: Implement one local learning step without expanding the scope. Safe context for the agent: - The written approved plan, permitted files, a clean local branch, and a documented local test command without production dependencies. Allowed: - Change only listed files for one test, database-free local page, or documentation; show a diff after every file; run only the approved local test. Not allowed: - Change dependencies, create or apply migrations, touch databases, secrets, production, external services, or real user data; run destructive commands, rewrite history, publish, or deploy changes. Stop when: - An unapproved file, command, or access level is needed; the test contacts an external system, fails, creates unexplained files, or the diff leaves the permitted list. Expected artifact: A small local diff in approved files and the actual result of one targeted test. How to verify: - Read every changed line yourself, map it to the plan, and inspect repository status for unplanned files.
Independently verify the change
Determine whether the local change matches the plan and respects approved boundaries.
Boundaries, checks, and agent brief
Understand first
- A green test does not justify an extra diff, and the agent's explanation does not replace command output.
Safe context for the agent
- The baseline, approved plan, current diff, documented test command, and official Django documentation when needed.
Allowed
- Run the approved test again in the isolated local environment, compare the diff with the plan, and check relevant claims against official documentation.
Not allowed
- Fix new issues, expand scope, weaken tests, or use production, secrets, external data, or unapproved commands.
Stop when
- The independent run does not reproduce the result, the diff has an unexplained change, or correctness depends only on the agent's claim.
How to verify
- Run the test yourself, record its exit status, and compare every changed line with the plan and documentation.
Goal: Determine whether the local change matches the plan and respects approved boundaries. Safe context for the agent: - The baseline, approved plan, current diff, documented test command, and official Django documentation when needed. Allowed: - Run the approved test again in the isolated local environment, compare the diff with the plan, and check relevant claims against official documentation. Not allowed: - Fix new issues, expand scope, weaken tests, or use production, secrets, external data, or unapproved commands. Stop when: - The independent run does not reproduce the result, the diff has an unexplained change, or correctness depends only on the agent's claim. Expected artifact: An 'accept locally' or 'reject' decision with the test result, diff check, and cited evidence. How to verify: - Run the test yourself, record its exit status, and compare every changed line with the plan and documentation.
Explain the connection from address to test
Show that you understand the project and the boundary of the completed change.
Boundaries, checks, and agent brief
Understand first
- The explanation must distinguish confirmed facts, assumptions, and matters that remain unverified.
Safe context for the agent
- The verified map, final diff, test result, and previous decision.
Allowed
- After your explanation, ask the agent to pose follow-up questions or identify a contradiction with a specific file or official documentation.
Not allowed
- Let the agent replace your explanation with a generated report, declare the change safe without evidence, publish, merge, or deploy it.
Stop when
- You cannot explain the purpose of a changed line or the limits of the test.
How to verify
- Check every claim against a file, test result, or official documentation; another person should be able to reproduce the explanation without trusting the agent.
Goal: Show that you understand the project and the boundary of the completed change. Safe context for the agent: - The verified map, final diff, test result, and previous decision. Allowed: - After your explanation, ask the agent to pose follow-up questions or identify a contradiction with a specific file or official documentation. Not allowed: - Let the agent replace your explanation with a generated report, declare the change safe without evidence, publish, merge, or deploy it. Stop when: - You cannot explain the purpose of a changed line or the limits of the test. Expected artifact: Your explanation of the request path, the change's role, the evidence, and what was not verified. How to verify: - Check every claim against a file, test result, or official documentation; another person should be able to reproduce the explanation without trusting the agent.