A while ago, I became anti-books. As a developer, I went all in on building. I avoided anything that felt like analysis paralysis. I wanted to be smart by actually knowing how to build stuff, not by reading about building stuff.
Don't get me wrong. This is mostly the right approach. Doers and builders win. But here's the problem: you don't know what you don't know.
When your code lives in two different worlds, you need to know how to cross between them.
I get asked about this pattern all the time. Someone's staring at their codebase, looking at asyncio.to_thread() in one place and loop.run_until_complete() somewhere else. They work. But why are they different? When do you use which?
Building reliable AI applications means handling slow, expensive operations without making users wait
You've built a GenAI application. Users send requests, your code calls an LLM or generates images, and returns results. Simple enough. Until reality hits.
Your image generation model takes 35 seconds to run. Your agentic workflow makes six separate LLM calls, each taking 3-8 seconds. A user submits a request, and their browser times out waiting. Or worse, they refresh the page halfway through, and you've just burned through $2 in API credits for nothing.
This is the problem every GenAI developer hits eventually. AI operations are slow. They're expensive. They fail randomly when APIs have problems. And you can't make users sit there staring at a loading spinner for 40 seconds. You need a better way.
Everyone is obsessed with AI agents right now. Autonomous systems that plan and execute tasks. Multi-step reasoning. Tool use. The whole package.
Meanwhile, half the apps you use every day run on recommender systems. Netflix telling you what to watch. Spotify building your playlists. Amazon showing you products. YouTube deciding your next video. These systems move billions of dollars and nobody talks about them anymore.
I spent last year deep in recommender systems for my computer science degree. Built a few from scratch. Learned what works and what breaks at scale. The best part? If you've worked with RAG applications, you already understand half of it. The concepts overlap way more than you'd think.
An opinionated, scalable way to structure Python projects using hexagonal architecture, SOLID, and practical DDD.
A friend asked me: "What's the proper way to build a Python project?" Here's my take. It's what I use for clients and at my 9 to 5. I like SOLID and Domain‑Driven Design, but I don't chase perfection. I just want code that stays tidy when the app grows.