All course materials are in the GitHub repo. Each module has its own folder (e.g. 01-overview, 03-mcp), and cohort-specific homework is under the cohorts/ folder.

For the 2026 cohort, the week-by-week folders are:

• Week 1: 01-ai-native-workflow
• Week 2: 02-development
• Week 3: 03-deployment
• Week 4: 04-devops

Start from the folder for your current week — it gathers everything for that week in one place.

Lectures are pre-recorded and available in the YouTube playlist. New workshops or updated videos are announced on Slack and Telegram. If you don't see an announcement, assume everything you need is already there.

Each homework has a strict deadline listed on the schedule; after the deadline the form closes. Submissions appear on the leaderboard. You can earn extra points by sharing your learning publicly with the hashtag #aidevtools and tagging Alexey Grigorev or DataTalksClub.

Lectures are pre-recorded and available in the YouTube playlist. New workshops or updated videos are announced on Slack and Telegram.

Live sessions are primarily for Q&A and are announced separately - there is no regular schedule for them. When a live session takes place, the recording is posted on YouTube.

Instructions and the submission form are on GitHub. You can update your submission until the deadline.

Homework grade = points for the questions + 1 point for the FAQ + up to 7 points for learning in public.

• Learning in public: up to 7 points, depending on how many platforms you shared your post on (e.g. LinkedIn, X, blog) and the quality of the post.
• FAQ: 1 point. To get it, contribute to the FAQ repo and add the link to your PR in your homework submission.

Optional questions are scored too - read the submission form carefully. The homework is for practice and does not affect your certificate. If you think you weren't graded, log in to check your results or search for your name on the leaderboard.

You'll create a repo on GitHub, connect your local folder to it, push your code, and submit the repo link. You need Git installed and a GitHub account.

1. Create a folder (e.g. ai-dev-tools-zoomcamp) and put your homework files inside.

2. On github.com, create a new public repo (skip README/license for now) and click "Create repository".

3. In a terminal, move into your folder and run:

   git init
   git remote add origin https://github.com/USERNAME/ai-dev-tools-zoomcamp.git
   git remote -v
   

4. Add and commit your files:

   git add .
   git commit -m "Add homework for module 1"
   

5. Push and set tracking:

   git push -u origin main
   

   Future updates are just git add . / git commit -m "..." / git push.

6. Open your repo page on GitHub, copy the URL, and paste it into the homework submission form.

You don't need any previous experience with AI tools. A basic ability to program (Python, JavaScript, or similar) is enough to follow the materials and complete the projects.

No. You're only late for submitting the first couple of homeworks, and they aren't required for the certificate. To earn the certificate you need to pass a project and evaluate 3 of your peers' projects, and that part starts later in the course.

You can complete the course on free or low-cost tools:

• Module 1: free tools like Groq or Gemini.
• Module 2: Cursor or GitHub Copilot (pro free trial possible).
• Module 4: a small API deposit (~$5) for OpenAI/Anthropic.
• Other free alternatives are shared on Slack (e.g. Qoder, Kilo Code, Antigravity).

Besides the tools listed above, free models (free API) exist, although sometimes temporarily, which could still be suitable for the duration of a course:

• OpenRouter free models
• Kilo free models
• Nous Portal models (free models listed on top)

For example, at time of writing, Hy3 and Minimax M3 are free, albeit rate-limited.

No. This course is about using AI dev tools to be a more productive developer, not about building LLM applications. LangChain/LangGraph, vector databases, retrieval, and reranking are AI engineering topics - those are covered in the free LLM Zoomcamp. The only overlap is Module 4, where you build a coding agent to understand how these tools work under the hood.

Yes, you still need to understand the code. With AI tools your job shifts from writing code to reading, reviewing, and improving it - and you're the one who will maintain it, so you need to follow what's happening. The way to keep your skills sharp is to stick to core engineering practices: write tests, commit to git regularly, keep documentation, and ask the assistant to explain code you don't follow. Vibe coding (just accepting whatever works) is fine up to a point, but it breaks down once the codebase grows or something stops working.

Yes. Use GitHub Codespaces - you only need a modern browser (or VS Code) and an internet connection, and you can install whatever you need inside the Codespace. GitHub Copilot and OpenAI Codex both work in Codespaces. The free tier is usually generous enough for the course.

There's no dedicated module for either, but you'll pick them up in practice. AI-generated code isn't guaranteed to work, so you learn to debug it as you go - and the course's engineering practices (writing tests, committing to git) surface broken or hallucinated code for you. For example, when a model invents a method that doesn't exist, a failing test makes it fix it. You can also ask the assistant to debug a specific error, or paste in the correct docs when it uses an outdated API. Deep prompt engineering is more of an LLM Zoomcamp topic.

Not much, and no GPU or cloud compute. You need an editor (VS Code, or Cursor which is VS Code-based), Python (the course uses uv, which can also install Python for you on Windows), and Node.js (install it via nvm for the JavaScript parts). You do not need Android Studio or any mobile tooling unless your own project targets mobile. Installing the tools for your operating system is up to you - the course shows how to use them, not how to install them.

Yes. The course works with many coding assistants, so use what you're comfortable with. Codex has similar functionality to Copilot and Cursor, and people use it alongside them. Gemini CLI is a good free alternative - it works fine for the Django homework in Unit 1, and you can use it in Unit 2 instead of a paid Cursor/Copilot subscription. Antigravity is another free option.

For building things, use agent mode - it can plan and make changes across multiple files. Use edit mode when you only want to change a single file. Ask mode (just chatting without editing) is rarely needed for coding. Inline autocomplete is also handy, though sometimes noisy.

There's no truly unlimited option - free tiers (Antigravity, Gemini CLI) hit quota limits and you may have to wait hours or switch models. To manage it:

• Track usage (/stats in CLIs, quota-tracker extensions in Antigravity).
• Use Cursor's "auto mode" so you don't burn a specific model's limit.
• Toggle between tools (Cursor, Antigravity, Claude Code).
• Pay as you go with a small budget for Claude or GPT, or use Codex if you have a ChatGPT subscription.
• At work, ask for a Cursor or Claude Code license.

Use uv by default. When you specifically need pip, use uv pip.

You don't have to over-engineer it. With a capable model, it can plan and execute in one go. Tools like Cursor let you explicitly plan first, review the plan, then execute - but that's often redundant for everyday edits. For models, use a stronger one for big tasks and a faster/auto mode for follow-ups (Cursor's "auto mode" also avoids burning a specific model's usage limit). Switching models mid-task can cause context loss, so try to keep one model per task.

AGENTS.md gives coding agents durable, project-specific context and instructions, so you don't repeat the same instructions in every prompt. Put the file at the repo root (see agents.md) and document stable project information there:

• Project structure and conventions
• Commands for running the application and tests
• Coding standards and constraints
• Important architectural decisions
• Testing and validation requirements

For example, a line like "commit code to git regularly" makes the agent commit on its own. Most assistants read AGENTS.md automatically (Antigravity is a notable exception). Cursor also has Commands for repetitive instructions.

Keep long-lasting rules in AGENTS.md; task-specific requirements belong in the spec or backlog rather than in AGENTS.md.

To keep prompt history, save the agent's plan files (e.g. PLAN.md / todo.md) or export your chat - handy when you switch models or revert code. See the Unit 1 lesson for how specs, backlogs, and AGENTS.md fit into the AI-native workflow.

Rules in Antigravity are Markdown files with standards, conventions, and constraints that guide the agent. You can manage them through the UI or by creating the files directly — see the official Rules docs.

To use the UI: open the Customizations panel via the "…" dropdown at the top of the agent panel, go to the Rules panel, and click + Global or + Workspace.

Workspace rules

Workspace rules live in the .agents/rules folder of your workspace or git root. Create a .md file there (e.g. coding-standards.md) with your constraints in plain Markdown. (The older .agent/rules path still works, but .agents/rules is the current default.)

Global rules

Global rules apply across all workspaces and live in ~/.gemini/GEMINI.md.

At the rule level you can set how a rule activates: Manual (via @ mention in the agent input), Always On, Model Decision (the model decides from your description), or Glob (applies to files matching a pattern like src/**/*.ts).

If authentication keeps failing - even in Chrome and after clearing the cache - the most reliable workaround is to create a temporary new Google account just for Antigravity. This often works when nothing else does.

Claude Code's OAuth login opens a browser tab pointing at http://localhost:PORT/callback. In GitHub Codespaces, that callback URL can fail to load because the browser reaches it through Codespaces' port-forwarding proxy instead of talking directly to the listener.

Workaround:

1. Run claude and let it open the login link in your browser.
2. When the page fails to load, copy the full callback URL from the address bar (for example http://localhost:35251/oauth/callback?code=...).
3. In a second terminal tab inside the same Codespace, run:

curl "http://localhost:35251/oauth/callback?code=..."

4. Your original claude terminal should log in immediately.

Why this works: the curl runs inside the Codespace on the same machine as the listener, so it bypasses the forwarding proxy.

If this still doesn't resolve it, check Anthropic's Troubleshoot installation and login docs for other known causes.

On macOS, use the built-in recorder with cmd+shift+5. On Windows 11, use win+shift+S. Loom is also popular for quick, shareable recordings.

Do this step-by-step from your terminal:

1. Create a local folder (or use your existing project folder).

2. Create an empty repository on GitHub:

   • Go to GitHub → New repository.
   • Choose public/private.
   • Create it without adding a README (so it stays “empty”).

3. Clone the empty repo to your machine:

   • Copy the repo URL from GitHub (HTTPS).
   • Run:

   git clone https://github.com/USERNAME/REPO.git
   cd REPO
   

   (If your code is already in another folder, you can instead git init there, but cloning is the simplest for a truly empty repo.)

4. Copy (or move) your files into the cloned folder (the REPO/ directory).

5. Stage files:

   git add .
   

6. Commit:

   git commit -m "Add project files"
   

7. Push to GitHub (replace main if your branch name differs):

   git push -u origin main
   

If you hit an authentication prompt on push, use the credentials method recommended by GitHub (now typically a GitHub token instead of a password).

When tests live in tests/ but import a package under src/ (e.g. from weekly_feedback.cli import main), plain pytest fails with ModuleNotFoundError because pytest adds the test file's directory to sys.path, not the project root — so the src/ package is invisible.

Point pytest at src — the directory containing the importable package, not the repo root. In pyproject.toml (as in the Unit 1 weekly-feedback project):

[tool.pytest.ini_options]
testpaths = ["tests"]
pythonpath = ["src"]

Or in a pytest.ini at the repo root:

[pytest]
testpaths = tests
pythonpath = src

The pythonpath option needs pytest 7+. Alternatively, pip install -e . makes the package importable everywhere without pytest config.

When Codex CLI prompts for approval, it’s because the command pattern matches a rule that requires user confirmation.

• If you trust the command, choose the prompt option like “Yes, and don’t ask again for commands that start with …”. Codex will save an execution rule for that command prefix, so future matching gh ... commands run without asking again.

• For example, instead of approving gh issue view 1 --json number,title,body,state,labels,url,comments every time, select “Yes, and don’t ask again” and Codex will allow that matching gh issue view ... prefix for future runs.

• If you want Codex to manage approval prompting more interactively, start it with codex --ask-for-approval on-request so approval is controlled on demand rather than being fully disabled.

Note: "trusted project"/sandbox trust and "ask-for-approval" are separate—trusting a project doesn't automatically disable all command-approval prompts. Avoid using codex --ask-for-approval never unless you understand the security implications.

See the Codex CLI reference (--ask-for-approval, --sandbox) and the sandbox and approvals guide.

Yes, implement in dependency order—but fix the backlog first and don’t work around a cycle.

Why it happens: the grooming/PM agent typically looks at one issue at a time, so Issue A’s acceptance criteria can assume an endpoint that Issue B will introduce, while Issue B’s constraints assume A already exists. With the “linked follow-up” rule, both issues can end up assuming the other, creating a grooming bug.

What to do:

1. Identify which issue “owns” the shared piece (usually the model or the endpoint).
2. Move that shared work into the owning issue, delete it from the other issue, and use a one-way dependency link (e.g., “blocked by #…”) instead of mutual/blocking links.
3. If they can’t be separated because they’re truly one vertical slice, merge them into a single issue and close the other as a duplicate.
4. After grooming (before implementing anything), run a quick dependency check: ask the assistant to list dependencies between all open issues and flag any cycles. Catching cycles early prevents engineers from writing code against a spec that can’t hold.

Then implement in dependency order once the cycle is removed. "One issue at a time" is about keeping each unit of work small enough to review, not about the issue count.

This error happens when you add created_at = models.DateTimeField(auto_now_add=True) to a Django model that already has rows in the database. Django can't invent timestamps for the existing rows, so it stops and asks for a default.

It's easy to miss because the prompt is interactive. If your coding agent runs makemigrations non-interactively, it crashes with EOFError: EOF when reading a line instead of showing the question — which looks like an unrelated bug.

Three common fixes:

1. Answer the interactive prompt Run uv run python manage.py makemigrations yourself and choose the option that sets the default (often Django suggests timezone.now).

2. Recreate the database (if it's disposable) For early homework/dev scenarios where the DB can be thrown away (the sqlite file should be in .gitignore anyway):

rm -f db.sqlite3
rm -f chores/migrations/0*.py     # only if those migrations are also throwaway
uv run python manage.py makemigrations
uv run python manage.py migrate

3. Avoid auto_now_add and use a default instead If you want a timestamp without hitting the prompt, use a default value:

from django.utils import timezone

created_at = models.DateTimeField(default=timezone.now)

Note: auto_now_add=True sets the value only on insert and is effectively read-only on updates. If you need to override timestamps in a seed script or tests, prefer default=timezone.now.

Tip for AI agents: if your agent evolves the models multiple times in one session, run makemigrations after each meaningful model change—small migrations are easier to interpret and revert.

No. Homework 1 is beginner-friendly, and the AI assistants guide you through each step.

Django 5.2.9 needs Python 3.10 or above; on older versions (3.9 or less) the server won't start.

Check your system Python version (macOS):

/usr/bin/python3 --version 2>&1

To fix it, create and use a virtual environment with Python 3.10+:

/usr/local/bin/python3.10 -m venv .venv --clear
source .venv/bin/activate

Then restart the Django server.

This is the "CORS trap" with a monolith setup: if your backend disables CORS whenever it detects a frontend/dist folder (assuming production = same origin), a local build will fool it into blocking your localhost dev server. Don't rely on folder checks - use an explicit environment variable (e.g. APP_ENV) to decide prod vs dev, and configure the frontend to use relative paths (/api) so the production build respects the same-origin policy.

They aren't documented in the repo. You can extract them yourself - paste a screenshot into ChatGPT, or run the video transcripts through a tool like NotebookLM to pull out the instructions. If you compile a list, a PR to the course repo is very welcome.

Both work. A monolith (bundling the frontend build inside the backend container) is simpler to deploy, but on a free tier like Render the whole app sleeps. A split setup (static site + web service) keeps the frontend fast while the backend wakes up, but runs two instances and uses more hours. For the course either is fine - pick the monolith for simplicity unless free-tier cold starts bother you.

Instead of relying on railway.toml, ask an AI assistant to create an entrypoint script that runs the app with uvicorn (rather than fastapi run). Example entrypoint:

exec uv run uvicorn main:app --host 0.0.0.0 --port ${PORT:-8000}

Quickest path:

1. Push your image to Docker Hub:

   docker push <your-username>/<image>:latest
   

2. In Render, create a new Web Service → "Deploy an existing image from a registry" → paste the Docker Hub URL.
3. Set the start command (e.g. uvicorn app:app --host 0.0.0.0 --port $PORT). Render injects $PORT at runtime — listen on it, don't hardcode.
4. Free tier sleeps after ~15 min idle, so the first request after that takes ~30s to wake up.

Render is a popular free-tier choice for project deployment because it doesn't require a credit card. Other options: Fly.io, Google Cloud Run (both require a card), Railway, PythonAnywhere.

Don't post Docker Hub itself as your "deployment" — it's a registry, not a runtime.

Don't get stuck on theory. Treat MCP simply as a plugin that gives the LLM access to external tools and knowledge it didn't have. The fastest path is to just try using it and ask your AI assistant to help you set it up. The official intro at modelcontextprotocol.io is a good short read if you want background.

Yes, you can skip MCP Inspector. As long as your editor (VS Code, Cursor, Antigravity, etc.) can connect to your MCP server, you're fine. For practice you can also write your own MCP client - see the example in toyaikit.

Antigravity's MCP config lives at ~/.gemini/antigravity/mcp_config.json. Either open the container as a dev-container, or put a docker run ... command in the MCP config. If you use stdio, make sure your launcher (e.g. a .bat file) passes input on stdin and writes to stdout. Many people find it easier to run inside a WSL VM and use "Connect to WSL" remote development in VS Code/Antigravity.

Yes. Skills turn repetitive tasks into reusable workflows and are great for code review, docs generation, and testing patterns. Check out awesome-claude-skills for ready-made options.

Yes, but you need to connect the agent to an online documentation service such as Context7, which provides up-to-date docs and examples. Without it, the agent may generate code based on older or outdated versions. This helps your agents produce current code and avoid hallucinations from outdated libraries.

Tips:

• Use /compact regularly to avoid losing context in long conversations.
• Use /clear to start fresh while keeping project context.
• Check conversation size with /status.
• Put project rules in a CLAUDE.md file at the repo root.
• Use the --verbose flag for debugging.

Common issues and fixes:

• "Command not found: claude" - Claude isn't in PATH. Use npx @anthropic-ai/claude-code or fix your PATH.
• Context loss / Claude becomes less capable - use /compact before the context gets too long.
• Claude ignores CLAUDE.md - check the file exists (ls -la CLAUDE.md) and that you're in the right directory.
• Claude writes failing tests - work TDD: have it write tests first, review them, then implement.
• Claude forgets how to compile - keep build commands in CLAUDE.md and remind it explicitly.

Your AI coding front-end has to support OpenAI's Responses API. Non-codex models work over the older API, but the codex models need the Responses API - if the client doesn't speak it, you get timeouts. This is the same integration Alexey covers in the "Building a Lovable Clone" material.

Not a full production agent. Unit 5 has you extend a coding agent (MCP, skills, custom loops) so you get intuition for how tools like Cursor and Lovable work under the hood - it's deliberately not a deep, multi-agent framework course. If you want to go deeper into building agents, see the LLM Zoomcamp.

For production and evaluation simplicity. Serving the frontend build as static files from the backend keeps requests same-origin, avoids CORS issues, and allows true end-to-end testing with a single container. During development you can still run the frontend and backend separately for faster iteration.

Any stack is fine - use whatever you're comfortable with. One tip from the instructors: picking a stack you're less comfortable with is actually a great way to get value out of AI-assisted development.

Yes. Combining an ML component (for example an image classifier) with a frontend and backend is a perfectly good project.

YouTube blocks data-center IPs, so free/data-center proxies are unreliable; residential proxies generally work but cost a little (students used webshare, oxylabs, and decodo - which has a short free trial - around $3-4/month). Since you're downloading text, not video, traffic is small and cheap. Watch out for a second source of blocks: yt-dlp may also need cookies. Most of the time goes into deploying behind a proxy in the cloud, so plan for it.

Start simple: plain text/keyword search is a strong baseline. Hybrid (semantic + keyword) usually gives the best quality but is more complex. If answers depend on understanding a whole conversation, agentic search can beat classic RAG - at the cost of more complexity. Begin with text search and add complexity only if you need it.