ai dev tools zoomcamp

Abstract

A free, hands-on course on using AI developer tools to build, test, deploy, extend, and audit software without losing engineering discipline. The 2026 cohort starts August 31.

The Problem

Teams adopting AI coding tools often lose engineering discipline: unclear specs, untested code, unreviewed changes, and unmanageable deployments. This course repo addresses that gap by teaching a structured, AI-native workflow where planning, implementation, review, testing, and deployment stay under human control.

What This Does

ai-dev-tools-zoomcamp is a free, hands-on course (2026 cohort starts August 31) for building, testing, deploying, extending, and auditing software with AI tools. The repository contains curriculum modules (01-ai-native-workflow/ through 05-agent-capabilities/), cohort-specific materials (cohorts/2025/, cohorts/2026/), and a research/ directory with 58 files documenting the design rationale.

The only substantive code is a Python CLI tool, weekly-feedback, in 01-ai-native-workflow/weekly-feedback/. It generates a weekly report from git history and user input. The rest is Markdown documentation, diagrams, and course content.

How It Is Wired

The wiring is not mapped for this repository yet. The repository is primarily documentation; the only executable code is the weekly_feedback package. Execution starts at 01-ai-native-workflow/weekly-feedback/src/weekly_feedback/__main__.py, which routes to cli.py. The CLI has five subcommands (report, init, log, weeks, interactive) that call functions in gitlog.py (reads git history), report.py (generates the report), and storage.py (persists data). The external effects are reading the git log and writing to local storage. There is no database, network service, or external API in this code.

The dependency file is 01-ai-native-workflow/weekly-feedback/pyproject.toml, which declares dependencies but no lockfile. Tests live in tests/ (9 test files) covering cli, gitlog, interactive, storage, and weeks.

How To Use It

Setup — The pyproject.toml implies a Python project. Install with pip or uv:

cd 01-ai-native-workflow/weekly-feedback
pip install -e .

Running it — The entry point is the weekly-feedback command, documented in the module's README.md:

weekly-feedback report

Configuration — No environment variables are documented. The tool likely reads git history from the current directory. The README in 01-ai-native-workflow/weekly-feedback/README.md is the authoritative source; verify commands there before relying on them.

Real-World Use

A developer runs weekly-feedback report at the end of each sprint. The tool inspects git log, summarizes what changed, and writes a report to local storage. This becomes the input for a weekly standup or retrospective, giving the team a consistent, auditable record of work without manual note-taking.

Code Health & Issues

Static analysis has not run for this repository yet. The structure supports these observations:

Med/SDLC — No CI/CD pipeline detected; no .github/workflows/ or CI config. There is no automated build/test gate.
Med/SDLC — No LICENSE file in the root; usage and redistribution rights are unclear despite the PRs-welcome badge.
Low/Risk — Dependencies declared in pyproject.toml without a lockfile; builds are not reproducible.

The codebase is small and focused. Tests exist for the CLI logic, which is a good sign, but the lack of CI means regressions can ship silently.

The Bottom Line

This is a course curriculum with a small, functional CLI tool, not a production application. The value is in the structured pedagogy and the documented workflow, not the code. Use it if you want to learn a disciplined AI-assisted development process or teach one; skip it if you need a reusable tool or production-grade software.

What the analyser found

Deployment readiness

3/7

Container image
CI pipeline
Lockfile committed
Test suite
README
License
No committed secrets

Composition

160 files

Markdown84
JSON16
Python13
YAML5
TOML1

Kubernetes

Module dependencies

The 10 most depended-upon modules of 13, from static import analysis. Red outline marks a module in an import cycle.

graph LR n0_k_src_weekly_feedback_models["models"] n1_src_weekly_feedback___init__["__init__"] n2__src_weekly_feedback_storage["storage"] n3_back_src_weekly_feedback_cli["cli"] n4_k_src_weekly_feedback_report["report"] n5_src_weekly_feedback___main__["__main__"] n6_k_src_weekly_feedback_gitlog["gitlog"] n7_ck_src_weekly_feedback_weeks["weeks"] n8_ekly_feedback_tests_test_cli["test_cli"] n9_y_feedback_tests_test_gitlog["test_gitlog"] n1_src_weekly_feedback___init__ --> n0_k_src_weekly_feedback_models n1_src_weekly_feedback___init__ --> n2__src_weekly_feedback_storage n5_src_weekly_feedback___main__ --> n3_back_src_weekly_feedback_cli n3_back_src_weekly_feedback_cli --> n1_src_weekly_feedback___init__ n3_back_src_weekly_feedback_cli --> n0_k_src_weekly_feedback_models n3_back_src_weekly_feedback_cli --> n2__src_weekly_feedback_storage n6_k_src_weekly_feedback_gitlog --> n1_src_weekly_feedback___init__ n4_k_src_weekly_feedback_report --> n1_src_weekly_feedback___init__ n4_k_src_weekly_feedback_report --> n0_k_src_weekly_feedback_models n4_k_src_weekly_feedback_report --> n2__src_weekly_feedback_storage n2__src_weekly_feedback_storage --> n0_k_src_weekly_feedback_models

Findings

MediumNo CI/CD pipeline detected - no automated build/test gate .github/ or CI config
MediumNo LICENSE file - unclear usage/redistribution rights root
LowDependencies declared without a lockfile - non-reproducible builds 01-ai-native-workflow/weekly-feedback/pyproject.toml

What would stop me shipping this

Ranked by severity × confidence × production reach. Reach is the honest discriminator across a collection that is mostly other people's code: the same finding matters more in something that ships.

high3

medium1

Add a LICENSE; redistribution rights are undefinedhigh

no licence file at the repository root

Fix: Add MIT or Apache-2.0 at the repository root.

Commit a lockfile beside the manifesthigh

01-ai-native-workflow/weekly-feedback/pyproject.toml

manifest with no lockfile in scope

An unlocked range means the artifact you tested and the artifact you ship can contain different transitive code, so a malicious patch release reaches production with no diff.

Fix: Run the package manager once and commit the generated lockfile.

Add a workflow that builds and tests this repositoryhigh

13 source files, no CI configuration

Every change merges with nobody having run the build once, which across this estate is 499 repositories.

Fix: Add a workflow running the project build and test command on push and pull_request.

Enable Dependabot or Renovatemedium

1 manifest(s), no update bot configured

Without a bot a published advisory sits unpatched until someone audits by hand, which across 1,322 repositories means never.

Fix: Commit .github/dependabot.yml covering the repo ecosystems plus github-actions.

Checked deterministically against the repository tree and a bounded set of its files: committed credentials, unpinned actions and base images, missing lockfiles and update bots, workflows that discard failures, published advisories against the declared dependencies, runtime configuration, licensing and notebook reproducibility. No language model is involved in this section.