A C# enterprise dev learns Python by building AI agents, one module at a time, from a couch, with a busted leg.
I've been a .NET developer since 2010, building enterprise apps in C#. In March 2026, I moved to a team that builds AI agents at high throughput. Cool opportunity except most of the code is in Python.
So I needed to learn Python. Then I hurt my leg and couldn't really go anywhere.
Honestly? Best forced study break I've had in years.
This repo is my structured path from C# to Python, ending with a real AI agent pipeline. If you're a .NET developer making the same transition or coming from any other typed, object-oriented language and want to see how all these pieces fit together feel free to follow along. C# analogies appear throughout as optional context, the core explanations stand on their own.
Five modules, each one building on the last:
| Module | What you build | Key tech |
|---|---|---|
| 1 | Weather REST API | FastAPI, Pydantic, pytest |
| 2 | Containerize it | Docker, Docker Compose |
| 3 | Wrap it as an MCP server | Model Context Protocol |
| 4 | Wire up an AI agent | Strands Agents, Ollama, Langfuse |
| 5 | Evaluate the agent | LLM-as-judge eval suite |
By the end: a working AI agent that answers weather questions, backed by your own API, observable via Langfuse, and testable against a golden dataset.
- .NET / C# developers moving into AI or Python work
- Engineers who learn by building things, not just reading docs
- Anyone who wants a realistic, end-to-end Python AI stack, not a toy notebook
No prior Python experience needed. C# or enterprise dev background helps, but isn't required.
Not a C# developer? You'll still get full value from this repo. Throughout the modules you'll see C# analogy tables and comparisons, these are optional context for people coming from .NET. If you don't know C# skip those sections and focus on the Python explanations. Everything you need to build the project is there regardless of your background.
python-agent-foundations/
├── README.md
├── docs/ # start here
│ ├── LEARNING_PLAN.md # module overview and topics
│ ├── MODULE_1_instructions.md
│ └── ...
└── solution/ # complete reference implementation
├── pyproject.toml
├── uv.lock
├── .env.example
├── Makefile
├── api/
├── mcp_server/
├── agent/
├── evals/
├── tests/
├── Dockerfile.api
└── docker-compose.yml
The root is intentionally bare, just docs and a reference implementation. The idea is that you build everything in solution/ yourself by following the module instructions. Delete the folder before you start, it'll always be on GitHub if you need it.
Prerequisites: Python 3.13+, uv, Docker (Module 2 onwards)
# clone the repo
git clone https://github.com/SampathBhashyam/python-agent-foundations.git
cd python-agent-foundations
# delete the reference implementation and start fresh
rm -rf solution/
# open the learning plan and follow Module 1Then open docs/LEARNING_PLAN.md and start at Module 1. The instructions will walk you through creating every file from scratch.
If you're using Claude Code CLI, three custom skills are included to support your learning. Run them from inside a claude terminal session at the project root.
Note: these skills work in the Claude Code CLI only (
claudein your terminal), not in the VS Code extension or Claude.ai chat.
After each module — get a review:
/review-module 1Compares your code against the module instructions and writes feedback to solution/reviews/MODULE_1_REVIEW_NOTES.md. Change the number for each module.
Understand a piece of code:
/explain-code solution/api/main.pyWalks through a file (or snippet) explaining what it does, why it's written that way, and what Python patterns are in play framed for developers coming from other languages.
Add teaching comments to a file:
/add-comments solution/api/config.pyAdds inline comments to an existing Python file explaining non-obvious patterns and gotchas, without changing any logic.
- Module 1 — complete
- Module 2 — complete
- Module 3 — complete
- Module 4 - complete
- Module 5 - complete
- Bonus Module 6 - in progress
The module instructions were drafted with GitHub Copilot's free plan (Claude Haiku 4.5) and then reviewed and corrected with Claude Code (Claude Opus 4.7). Opus caught cross-module inconsistencies, broken code examples, and missing edge cases that the first pass didn't flag.
Why two models? It's a cost-smart split, not a token saver: both passes consume tokens, but Haiku is roughly 15× cheaper per token than Opus, so pushing the bulk of the drafting to Haiku and reserving Opus for review keeps the total cost a fraction of pure-Opus authoring.
MIT — use it, fork it, learn from it.