-
Notifications
You must be signed in to change notification settings - Fork 0
Home
I joined DataTalksClub's AI Dev Tools Zoomcamp 2026, a free, cohort-based course on using AI coding agents effectively — not prompt tricks, but a real workflow: turning a vague idea into a precise spec, breaking it into a backlog, building it with an agent, and testing the result before trusting it. This wiki is where I'm tracking what I actually learned, module by module, alongside the code in this repo.
- Course repo: https://github.com/DataTalksClub/ai-dev-tools-zoomcamp
- Register / course platform: https://courses.datatalks.club/register/ai-dev-tools/ · https://courses.datatalks.club/ai-dev-tools-2026/
- Launch article: https://aishippingblog.com/p/ai-dev-tools-zoomcamp-2026-starts
- Video playlist: https://www.youtube.com/playlist?list=PL3MmuxUbc_hLuyafXPyhTdbF4s_uNhc43
- Community: https://datatalks.club/slack.html
- FAQ: https://datatalks.club/faq/ai-dev-tools-zoomcamp.html
The assignment starts from one deliberately vague sentence — "a tool for managing shared household chores" — with the actual Module 1 instructions here. The point isn't Django. It's what happens before you write a line of code: turning that vague idea into something precise enough for a coding agent to build correctly, on the first try.
What I built: cohorts/2026/01-ai-native-workflow/ —
a Django app that tracks real, recurring chores for my 5 cats (nicknames only — real names stay
private): litter, feeding, bowls, water, two separate medications on their own schedules, and
regular vacuuming for the allergies all that cat hair causes. 17 tests, all passing.
A coding agent will happily build the wrong thing, correctly. The module opens with exactly that lesson: given the same vague prompt, an agent built a perfectly working command-line tool when a web app was actually needed. The code ran, the tests passed, and it solved the wrong problem entirely — nothing about the code itself would tell you that. The fix isn't a smarter model or a longer prompt; it's spending real time on the spec before the agent starts typing, because every assumption it has to make on your behalf is a bet it's making with your time.
Specifying, planning, building, and testing work best as separate steps, not one long prompt. Doing them one at a time is what makes each step cheap to get wrong and cheap to fix.
The sharper lesson, learned by actually redoing my own first draft: my first pass at this homework was a generic, buildable, entirely reasonable single-household chore list — and it never would have surfaced the one design decision that actually mattered. It took a real constraint (5 cats, two of them on their own medications, a fountain water bowl that doesn't need daily attention) to force the spec to account for recurring chores instead of one-off ones. A plausible-sounding example and a real one aren't the same exercise — the real one asks more of you, and that's exactly where the useful design decisions hide.
The full spec, backlog, and build notes live in the repo itself:
_docs/plan.md ·
backlog.md ·
module README.
The module's shape: pick a project, write the spec before any code, build a frontend against
mocked calls, define an openapi.yaml contract, implement a FastAPI backend, then swap the mock
store for a real database.
What I built: two full-stack apps for the same five cats, at
cohorts/2026/02-development/ —
Herding Cats, a Kanban board for the care routine (the graded submission), and The Cat Tax,
an expense splitter for what it costs. Both run FastAPI, SQLAlchemy 2.x, and SQLite on the
backend, React + Vite on the front, with tests against a real database rather than mocks.
Delegating is the easy way out, and it costs you something. It's tempting to hand the agent a rough idea and let it fill in the gaps. When the result doesn't match what I'd actually imagined, that's not just wrong, it's a distraction I now have to spend time correcting. There's a subtler cost too: when the agent does the thinking and the building, the result stops feeling like something I built. The practical version of the lesson is not "don't delegate" — it's don't delegate the parts you haven't decided yet, including which point of view you're even building for.
Good designs come from iterating, not from one confident pass. The discipline isn't only being willing to change a plan — it's accepting you can't have everything you originally pictured, and noticing when a design choice has painted you into a corner before you go defend the corner. The Cat Tax's money model is the clearest example: attributing every shared cost to exactly one cat would have been tidy and dishonest, so the shared pool sits on its own instead.
A green checkmark is still an interpretation, not a fact. A test meant to prove the suite hit a real database passed for the wrong reason — a module-import quirk meant the assertion checked a directory the app never wrote to. The deeper issue: a session that builds something and then tests it is checking its own homework, sharing whatever blind spot produced the bug in the first place. The durable fix is structural — independent verification, ideally from a separate session or a different model.
Correctness isn't visible by inspection. Reassigning a list of expense shares and trusting the ORM's cleanup behavior read perfectly on the page. It broke because of insert/delete ordering inside a single database flush — nothing in the diff would ever show that. Only running the tests against the actual failure condition caught it.
A lesson learned once isn't yet a reflex. A port collision cost real debugging time in this module — the same class of mistake an earlier module had already taught, with a different port number. Learning something once makes it a story about last time, not a habit, until it costs you again.
The full build notes live in the repo itself:
module README ·
kanban/ ·
expense-splitter/.