Building Python Projects With AI Agents:
You Are the Bottleneck, Not the Agent
Building Python Projects With AI Agents: You Are the Bottleneck, Not the Agent
Building a Project With Agents • 8 Hours • 4 Live Sessions
Eight hours, one real project, and nobody in the room types the code that ships. What you practice instead is saying what you want precisely enough to get it.
Hosted By
Core Team member at Real Python and the author of Object-Oriented Programming in Python. He teaches Real Python's Intermediate Python Deep Dive cohort and brings the same hands-on approach to this course.
The agent builds what you asked for. That’s the problem.
You gave it a sentence. It gave you a few hundred lines that run. You read them, felt vaguely uneasy, couldn’t say precisely why, and shipped it anyway.
“It works. I think.”
“I’d have written this differently, but I can’t explain what’s actually wrong with it.”
“I asked for one change and it rewrote half the project.”
Here’s the uncomfortable part. When the output is disappointing, the instinct is to blame the model, try a different tool, or write a longer prompt.
It’s usually none of those.
The agent did exactly what you said. You just didn’t say very much.
Meanwhile the thing you’re now doing most days — reading code somebody else wrote, quickly, and deciding whether it’s good enough — is a skill nobody trained you for. Teams are shipping agent-written Python right now and the review is happening on instinct.
Both of those come down to the same two abilities: saying what you want precisely, and recognizing whether you got it.
That’s what eight hours here is for.
What Makes This Course Different
You Won’t Type the Code. You’ll Decide Whether It’s Good Enough.
Over four sessions we take one real project — a gym class booking system — from an empty directory to something deployed and working at a URL.
An agent writes every line that ships. Nobody in the room types implementation code, and neither does the instructor.
What you write instead is the part that turns out to be harder:
- the domain vocabulary, agreed in words before anyone writes a specification
- what “done” means, in a form something other than the agent can check
- the corrections, phrased so the agent fixes one thing instead of rewriting everything
- the review checklist you’ll take to every agent-written diff after this
And here’s the part that makes this course different from anything else we run.
Nothing is rehearsed.
We hand the agent a real specification, live, and read whatever comes back. The instructor hasn’t seen it. There’s a list of what to look for, but no script for what will be there.
That’s deliberate, and it’s the whole point. If the critique were rehearsed, the judging would have happened offstage and you’d be watching a performance of an opinion rather than the forming of one. The skill being taught is exactly the thing a rehearsal removes: reading unfamiliar code, under time pressure, and deciding what actually matters.
Sometimes the agent does a good job. That’s a legitimate outcome and a useful one — knowing when not to intervene is part of the judgment, and most developers are worse at it than they think.
Then, halfway through, the requirements change. Because they always do.
There’s a Second Thread Running Through All of It
This is a course about working with AI agents. It’s also, deliberately, a course about Python.
You cannot judge agent-written code without a standard to judge it against. So the standard is the other half of what we do here — and it arrives the way it should, attached to code in front of you rather than to a slide.
- a class that has quietly become four, and the principle that names why that hurts
- business rules living in the same function as the database call, and what it costs the moment you want to test them
- a design that reads beautifully and then takes eleven files to change when the product moves
- a test that’s awkward to write, and what that awkwardness is telling you about the design
- error paths, validation and the race nobody thought about, which agents skip unless asked
Design principles only get named here when the code in front of us has already broken one. Nothing on the SOLID list gets taught for completeness — if the agent didn’t violate it, we say so and move on.
So you leave better at two things, not one. Better at directing an agent, and better at the Python judgment that tells you whether anybody’s code — the agent’s, a colleague’s, your own from last year — is actually any good.
Course Curriculum
Four live 2-hour sessions on Zoom. You work through every step in real time, and questions are taken as they come rather than held to the end.
Session 1: Saying What You Want
By the end of this session, you'll have written a specification precise enough to hand to an agent — and handed it over.
What you'll write: The domain vocabulary, the rules, and acceptance criteria for the first slice of the project.
What you'll learn:
- Why one vague sentence produces confidently wrong code, and how to see it in what comes back
- How to build the vocabulary of a domain before writing a single requirement
- How to write "done" so that something other than the agent can check it
- Which loose words in a brief cause arguments later, and how to catch them early
- Why the specification, not the prompt, is the artifact worth your time
Session 2: Reading and Judging
By the end of this session, you'll have read a few hundred lines of unfamiliar agent-written Python and said precisely what's wrong with them.
What you'll write: Corrections — the kind that fix one thing instead of triggering a rewrite.
What you'll learn:
- A method for taking in an unfamiliar codebase in ten minutes: entry points, data, decisions, edges
- What to look for in agent output: the class that quietly became four, decisions buried in conditionals, domain rules sitting next to database calls, invented requirements, and rules that went silently missing
- Design principles introduced only where the code in front of you actually broke them — and named after you've described the problem in your own words
- How to phrase a correction so an agent changes one thing
- How to tell when a correction is really a specification change
Session 3: Tests, and the Requirement That Changes
By the end of this session, you'll have watched a design meet a requirement nobody planned for.
What you'll write: Predictions — how many files have to change — and then you find out.
What you'll learn:
- Why an awkward test is usually the design telling you something
- Which cases are worth testing in a domain with real rules, and how high coverage can still check nothing interesting
- What happens to a tidy-looking design when the product changes mid-project
- How to judge a design by the change most likely to arrive in six months, rather than by how it reads today
Session 4: Making It Real
By the end of this session, the project is deployed and working, and you have the checklist you came for.
What you'll write: The review checklist, built from two sessions of argument, and the one-page summary of what changes on your own projects.
What you'll learn:
- The unglamorous things agents skip unless asked: validation, error paths, two people booking the last place at once
- How to turn a day of judgment calls into a checklist you can reuse on any agent-written diff
- A deliberately small deployment slice — one container, one host, one URL — so the project is real
- Open clinic: your projects, your specifications, your agents
Next cohort: dates to be announced
Join the Waitlist →Be First in Line When Dates Are Announced.
Real Python Satisfaction Guarantee
This course is backed by Real Python's guarantee. You can receive a full refund within 14 days after the course ends, provided you meet the completion criteria in our refund policy.What You’ll Be Able to Do
- Write a specification precise enough that an agent produces something close to what you meant the first time
- Read unfamiliar agent-written code quickly and say what's wrong with it in words the agent can act on
- Tell the difference between code that needs a correction and a design that needs changing
- Apply Python design and testing principles where they actually earn their keep, rather than reciting them
What You’ll Receive
- 4 live 2-hour sessions via Zoom
- Cohort forum with the instructor and your peers, before and after the sessions
- The complete project repository, with every specification, every agent run and every correction in the git history, so the whole decision trail is readable afterward
- The specification template: domain vocabulary, rules, acceptance criteria and definition of done, in the form the course used
- The review checklist built live in session 4, plus the one-page method for reading unfamiliar code fast
- Lifetime access to the recordings and materials
Who This Course Is For
#1
Quietly Uneasy Builders who have built things with an agent, felt something was off about the result, and couldn't say precisely what
#2
Reluctant Reviewers whose teams have started shipping agent-written code, and who will be reviewing it whether they feel ready or not
#3
Brief Writers who write specifications, tickets or briefs that other people — or other agents — have to work from
Who Should Not Take This Course?
This isn’t a course about how agents work inside. We never open the loop. If that’s what you want, take AI Agents for Python Developers instead.
It isn’t a deployment course either. Session 4 puts the project somewhere, and that’s all — one container, one host, one URL. Deployment done properly is a different course.
And it isn’t for beginners. Judging code requires having written some. You should be comfortable in Python, able to read a traceback, and willing to have opinions about code and defend them out loud. You need no prior agent experience at all — session 1 doubles as the orientation.
Meet Your Instructor
Core Team member at Real Python and acclaimed Python educator who combines years of teaching expertise and storytelling techniques to make complex programming concepts clear, engaging, and unforgettable.
Stephen Gruppetta is a seasoned Python educator and author known for his engaging narrative approach to explaining complex concepts, drawing on his PhD in physics and years as a lecturer and technical writer.
With experience ranging from corporate training to creating accessible resources like The Python Coding Book, he’s dedicated to helping learners master Python with clarity and creativity.
Why Learn With Real Python?
Real Python started as a Kickstarter project in 2012. Today, over 1 million developers, data scientists, and ML engineers read it every month.
Our content goes through what very few Python resources match:
- Expert technical review for accuracy
- Teaching specialist evaluation for learning effectiveness
- Professional editing for clarity
Our live courses bring that same review process to an interactive, instructor-led format. You get the questions, the live discussion, and a community that’s been learning Python with us since 2012.
What Learners Say About
Stephen’s Courses
“I felt like I was a really well-studied Python beginner… But I couldn’t quite get out of there to the next level. And [Stephen's course] is helping because it’s all about that deeper understanding.”
“I can look at modules, I can look at other people’s code and I understand why they’re doing what they’re doing. And it’s not just taking things for granted anymore… I can go on and start exploring more complex things without immediately getting lost.”
— Jerry Wilson, Technical Lead at AIM EMS Software
“Ever since we’ve been taking the course, I’ve really changed a lot of the way that I’m programming.”
“It’s definitely given me more confidence to go deep dive into things I just took for granted… But after this course I feel much stronger in being able to understand the fundamentals of why things work in Python that it’s given me more confidence to go deeper.”
— Matt Thacker, Sr. Solutions Engineer at Eptura
Why This Course Works
Judgment can’t be taught from a slide, because a slide already knows the answer.
You can read every article ever written about clean design and still freeze in front of four hundred lines of unfamiliar Python with a meeting in ten minutes. Recognizing good code when someone points at it is easy. Finding what’s wrong yourself, quickly, and saying it in a way that gets it fixed — that only comes from doing it.
So we do it. Repeatedly, on code that doesn’t exist yet, in front of you.
The rhythm repeats four times across the course: specify, run, read, judge, say it back. By the fourth time around, the room is running it and the instructor is mostly listening.
It’s live and unscripted, but never chaotic. If an agent run goes badly, we pick up from the last working version and keep going, so your time goes on judging code, not waiting for it.
This course couldn’t be a video series. Its value is live judgment on code that doesn’t exist yet. A recording of it would be a recording of someone else’s opinions — useful, but not the same thing as forming your own.
How This Differs From Our Other AI Courses
We run several courses on working with AI, and they overlap enough that it’s worth being straight about where the lines are.
Claude Code for Python Developers and Codex for Python Developers — both have run, several times.
These teach you to get good output from a specific tool: how to drive it, where it fits in your workflow, and how to build a whole project with it inside your codebase.
This course assumes the output already exists and asks a different question: is it any good, and how would you know? It’s tool-agnostic, and it’s about your judgment rather than the tool’s capabilities.
AI Agents for Python Developers
That one takes the lid off: you build an agent by hand and learn what a loop, a message list and a tool call actually are. It’s about how the machine works. This one never opens the lid — the agent is a given, and the work is upstream of it.
AI Agent Teams for Python Developers
The closest neighbor, and the one to read carefully before choosing. That course is about several agents working together: what each one is allowed to know, and how to keep them from tripping over each other. Writing specifications shows up there as a means to that end.
Here, the specification is the subject, there’s only ever one agent, and the whole second half is about reading and judging what it produced.
One more difference, and it’s the one people tell us they care about. This course also spends real time on Python itself — design, structure, testing, the things that make code hold up when it changes. You can’t judge what an agent wrote without a standard to judge it by, so the standard gets taught alongside. If you want to come out of an AI course a better Python developer rather than just a faster one, this is the one that’s built for it.
Short version: if you want to run more agents, that’s the other one. If you want to trust what one agent gives you — and sharpen your own Python judgment while you’re at it — it’s this one.
Frequently Asked Questions
You should be comfortable with Python and able to form an opinion about code you didn’t write. Specifically:
- Writing and calling functions, and working with classes
- Reading an unfamiliar module and following what it does
- Using modules, packages, and virtual environments
You need no prior agent experience. The opening segment doubles as orientation for anyone who has never watched an agent work.
Those courses teach you to get good output from a specific tool, building a whole project with it inside your codebase. Both have run several times.
This course starts after that. The output exists — is it any good? It’s tool-agnostic, and it’s about your judgment rather than the tool’s capabilities. There’s a fuller comparison further up this page, including how it relates to our other agent courses.
Both, on purpose.
Judging agent-written code requires a standard to judge it against, so Python design and testing run as a second thread through the whole course: structure, responsibilities, where rules belong, what makes a test worth having, and how a design behaves when requirements change.
Principles get named only when the code in front of us has already broken one. Nothing gets taught for completeness. The result is that you leave better at directing an agent and better at reading any Python, whoever or whatever wrote it.
Not implementation code, and neither does the instructor. The agent writes everything that ships.
You write the specification, the acceptance criteria, the corrections and the review checklist — which is more writing than it sounds, and harder than typing the implementation would have been.
The instructor may drop into an editor to show something, then delete it and put it into the specification instead. We never fix code by hand. The moment we did, this would quietly become a different course.
A gym class booking system. The domain costs nothing to explain — everyone has booked a class or missed one — and the rules are genuinely intricate without being technical: capacity, waitlists, cancellation windows, no-shows, membership tiers.
It’s chosen because it produces design decisions worth arguing about, and because it has a natural mid-course requirement change that tests whether the design holds.
That happens, and it’s a useful session rather than a wasted one. “This is good, here’s how we know, and here’s why we’re leaving it alone” is a genuinely valuable thing to watch. Knowing when not to intervene is part of the judgment.
There’s also a harder test built into session 3: the requirements change halfway through. Very few designs survive an unforeseen change cleanly, however tidy they look.
You read along with the instructor’s output, and the discussion is the work. That’s deliberate: if everyone’s agent produced different code, there’d be no shared thing to point at and the review would fragment into twenty separate conversations.
You’ll have the same vetted specification, so you can run it against your own agent between sessions and compare. The closing clinic is for your projects and your agents.
Python 3.12 or newer, your editor of choice, and Zoom.
If you want to run the specification against your own agent between sessions, you’ll need access to an AI coding tool and a model API. We’ll confirm the exact setup and run a supported setup week beforehand.
We name it before the course so you know what you’re watching, and the method is deliberately tool-agnostic. Nothing in the specification, the reading method or the review checklist depends on which agent produced the code — that’s rather the point, since you’ll be reviewing output from whatever your team happens to use.
Yes. You’ll keep:
- The complete project repository, with every specification, agent run and correction in the git history
- The specification template and the review checklist
- The reading method, as a one-page procedure
- Session recordings
Dates and times haven’t been announced yet. Join the waitlist and you’ll be the first to hear when they are, before the course is opened up more widely.
Each session is recorded and posted shortly afterward, so you can catch up on your own schedule. We recommend attending live when you can — this course in particular is built around the discussion, and the discussion only happens once.
Every cohort gets a dedicated forum that runs from before the first session through to after the last. Stephen is based in UTC+1 and monitors the forum throughout his working day, so you can ask questions, share what you’re building, and get unstuck without waiting for the next live session.
Yes. Select the number of seats you need on the booking page when the cohort opens. Each team member will receive their own access to the course materials and recordings.
This course is backed by Real Python’s satisfaction guarantee. You can receive a full refund within 14 days after the course ends, provided you meet the completion criteria in our refund policy.
Have another question? Email us at info@realpython.com