One thing I’ve learned while working on AI projects:

Building the model is usually not the hardest part.

The difficult part is everything around it.

• The messy datasets
• The broken pipelines
• The debugging
• The deployment issues
• The random errors that appear at 2 AM for no reason 😅

Modern AI tools make it easy to build demos quickly, which is honestly incredible.

But real growth starts when you try to turn those demos into systems that actually work reliably.

Lately, I’ve been spending more time building practical tools and workflows instead of just experimenting with models.

✓ Automation systems
✓ ML workflows
✓ Developer tools
✓ Data quality utilities
✓ End-to-end AI projects

One project I’ve really enjoyed building is DatasetDoctor: https://datasetdoctor.fastapicloud.dev

Working on it made me realize how important data quality actually is in AI.

A lot of people focus only on the model, but in many cases the real problem is the dataset itself.

Bad data quietly destroys performance long before the model becomes the issue.

That’s also why I’ve been creating contents around:
✓ Data quality engineering
✓ Python and automation
✓ AI workflows
✓ Machine Learning systems
✓ Real-world development challenges
Check them out https://youtube.com/playlist?list=PL0nX4ZoMtjYHTtowSzzB2gVH2AuuoF9WW&si=EaEeZYXCkhWhUHpV

Still learning every day.
Still building.
Still breaking things and figuring them out.

That’s honestly the fun part of engineering.

#AI #Python #MachineLearning #DataEngineering #SoftwareEngineering #Automation #DataScience #AIEngineering #Tech #datasetdoctor #fastapi #fastapicloud

A Practical Python Roadmap to Become an AI Developer
Here is the start of your journey:
https://youtu.be/ldR3NdSDiyE

#Python #PythonDeveloper #LearnPython #ArtificialIntelligence #AI #AIDeveloper #MachineLearning #DeepLearning #GenerativeAI #LLM #DataScience #MLOps #FastAPI #PyTorch #ScikitLearn #SoftwareEngineering #Programming #Coding #TechCareer #BuildInPublic #OpenSource #100DaysOfCode #Developer #TechEducation #FutureOfAI

When I build an AI application, choosing the backend framework is an important decision.

There are several good options, but I usually look at 𝐅𝐚𝐬𝐭𝐀𝐏𝐈, 𝐃𝐣𝐚𝐧𝐠𝐨, and 𝐅𝐥𝐚𝐬𝐤 first.

The choice really depends on what I'm building.

✔️ 𝐅𝐚𝐬𝐭𝐀𝐏𝐈 makes a lot of sense when the application is mainly an AI/API backend. Since most AI tools I use are already in Python, I can keep the whole stack in one ecosystem, from LLMs and embeddings to document processing, RAG, databases, and the API itself.

✔️ 𝐃𝐣𝐚𝐧𝐠𝐨 is a strong choice when the AI functionality is part of a larger web application. Its built-in ORM, authentication, admin panel, and other features can save a lot of development time.

✔️ 𝐅𝐥𝐚𝐬𝐤 is still a great option when I want something simple, lightweight, and flexible, especially for smaller services or prototypes.

For an AI application, I also need to think beyond the framework:

✔️ Authentication

✔️ Database and data persistence

✔️ Document processing

✔️ Embeddings and vector search

✔️ RAG

✔️ Background tasks

✔️ Testing

✔️ Docker

✔️ Monitoring

✔️ Deployment

There isn't one framework that is "best" for every AI application. For the type of production AI backends I'm building, 𝐅𝐚𝐬𝐭𝐀𝐏𝐈 is often a practical choice because it provides a clean API layer while keeping everything close to the Python AI ecosystem.

The framework is only one piece of the puzzle.

Good architecture matters more than the framework you choose.


What do you normally use for AI applications: 𝐅𝐚𝐬𝐭𝐀𝐏𝐈, 𝐃𝐣𝐚𝐧𝐠𝐨, 𝐅𝐥𝐚𝐬𝐤, or something else?

Here is the roadmap to build an AI application with FastAPI: https://www.youtube.com/watch?v=0SLLG2Z_Htw


#FastAPI #Python #AIEngineering #GenerativeAI #RAG #BackendDevelopment #MachineLearning #Django #Flask #SoftwareArchitecture

𝐅𝐚𝐬𝐭𝐀𝐏𝐈 𝐯𝐬 𝐑𝐄𝐒𝐓 𝐀𝐏𝐈 — What’s the Difference?

One thing I see quite often when people start building APIs with Python is confusion between FastAPI and REST API.

In reality, they are not the same thing.

𝐑𝐄𝐒𝐓 𝐀𝐏𝐈 is an architectural approach for designing APIs around resources, HTTP methods, stateless communication, and standard HTTP responses.

𝐅𝐚𝐬𝐭𝐀𝐏𝐈 is a Python web framework that helps you build APIs.

For example, in an AI application, I might have:

GET /documents
𝙶𝙴𝚃 /𝚍𝚘𝚌𝚞𝚖𝚎𝚗𝚝𝚜
𝙿𝙾𝚂𝚃 /𝚍𝚘𝚌𝚞𝚖𝚎𝚗𝚝𝚜
𝙶𝙴𝚃 /𝚍𝚘𝚌𝚞𝚖𝚎𝚗𝚝𝚜/{𝚒𝚍}
𝙿𝚄𝚃 /𝚍𝚘𝚌𝚞𝚖𝚎𝚗𝚝𝚜/{𝚒𝚍}
𝙳𝙴𝙻𝙴𝚃𝙴 /𝚍𝚘𝚌𝚞𝚖𝚎𝚗𝚝𝚜/{𝚒𝚍}

These endpoints can follow 𝐑𝐄𝐒𝐓 principles.

𝐅𝐚𝐬𝐭𝐀𝐏𝐈 is the tool I use to implement them in Python.

So, a simple way to remember it:

𝐑𝐄𝐒𝐓 = how the API is designed
𝐅𝐚𝐬𝐭𝐀𝐏𝐈 = the framework used to build it

𝐅𝐚𝐬𝐭𝐀𝐏𝐈 also gives us useful features such as request validation, automatic API documentation, dependency injection, and strong support for asynchronous applications.

Understanding this distinction makes it much easier to understand 𝐅𝐚𝐬𝐭𝐀𝐏𝐈 and, more importantly, to design APIs properly.

𝐅𝐚𝐬𝐭𝐀𝐏𝐈 Fundamentals: Build Your First AI API | Python FastAPI Course (An Overview of API): https://youtu.be/vvP9GIWSews

#FastAPI #Python #RESTAPI #APIDevelopment #AI #MachineLearning #BackendDevelopment

The hardest part of building AI applications isn't writing the prompt or calling the model. In the last two weeks, I learned that keeping the backend from turning into spaghetti code once you move past the tutorial phase.

When you're wiring up an AI document pipeline in FastAPI, a few things quickly become non-negotiable:



• Payload Guardrails: If your Pydantic schemas aren't catching malformed JSON, missing nested fields, or bad Enums at the door, your AI service will fail unpredictably downstream.



• Route Isolation: Mixing your raw API endpoints with validation logic and business rules makes refactoring a nightmare by week three.



• The Persistence Gap: Transitioning from mock in-memory data structures to a real relational database and a vector store for RAG is where most clean prototypes start to break down.



If you're building production backends for AI and ML features, where do you usually draw the line between keeping things simple and over-engineering your architecture?



You can learn about FastAPI: https://www.youtube.com/playlist?list=PLQNCas8_eikM



#FastAPI #Python #BackendEngineering #SoftwareArchitecture #APIs #Pydantic #ArtificialIntelligence #MachineLearning #RAG

When building a FastAPI application, I pay close attention to how data is validated before it reaches the business logic.

That is where Pydantic becomes particularly useful.

Pydantic lets us define the structure and rules for the data our application accepts, instead of scattering validation checks throughout the codebase.

I use it to define and enforce the data contract at the application boundary.

For example:

𝑐𝑙𝑎𝑠𝑠 𝑃𝑟𝑜𝑐𝑒𝑠𝑠𝑖𝑛𝑔𝐶𝑜𝑛𝑓𝑖𝑔(𝐵𝑎𝑠𝑒𝑀𝑜𝑑𝑒𝑙):

𝑐ℎ𝑢𝑛𝑘_𝑠𝑖𝑧𝑒: 𝑖𝑛𝑡 = 𝐹𝑖𝑒𝑙𝑑(𝑔𝑡=0)

𝑜𝑣𝑒𝑟𝑙𝑎𝑝: 𝑖𝑛𝑡 = 𝐹𝑖𝑒𝑙𝑑(𝑔𝑒=0)

@𝑚𝑜𝑑𝑒𝑙_𝑣𝑎𝑙𝑖𝑑𝑎𝑡𝑜𝑟(𝑚𝑜𝑑𝑒="𝑎𝑓𝑡𝑒𝑟")

𝑑𝑒𝑓 𝑣𝑎𝑙𝑖𝑑𝑎𝑡𝑒_𝑐𝑜𝑛𝑓𝑖𝑔(𝑠𝑒𝑙𝑓):

𝑖𝑓 𝑠𝑒𝑙𝑓.𝑜𝑣𝑒𝑟𝑙𝑎𝑝 >= 𝑠𝑒𝑙𝑓.𝑐ℎ𝑢𝑛𝑘_𝑠𝑖𝑧𝑒:

𝑟𝑎𝑖𝑠𝑒 𝑉𝑎𝑙𝑢𝑒𝐸𝑟𝑟𝑜𝑟("𝑜𝑣𝑒𝑟𝑙𝑎𝑝 𝑚𝑢𝑠𝑡 𝑏𝑒 𝑠𝑚𝑎𝑙𝑙𝑒𝑟 𝑡ℎ𝑎𝑛 𝑐ℎ𝑢𝑛𝑘_𝑠𝑖𝑧𝑒")

𝑟𝑒𝑡𝑢𝑟𝑛 𝑠𝑒𝑙𝑓

Both fields can be individually valid, while their combination is not.

That is the difference between:

Field validation → Is this value valid?

Model validation → Is this combination valid?

With Pydantic, 𝙁𝙞𝙚𝙡𝙙(), 𝙛𝙞𝙚𝙡𝙙_𝙫𝙖𝙡𝙞𝙙𝙖𝙩𝙤𝙧(), 𝙖𝙣𝙙 𝙢𝙤𝙙𝙚𝙡_𝙫𝙖𝙡𝙞𝙙𝙖𝙩𝙤𝙧() let us keep these rules close to the schema.

The result is a cleaner boundary:

𝙍𝙚𝙦𝙪𝙚𝙨𝙩 → 𝙑𝙖𝙡𝙞𝙙𝙖𝙩𝙞𝙤𝙣 → 𝘽𝙪𝙨𝙞𝙣𝙚𝙨𝙨 𝙇𝙤𝙜𝙞𝙘 → 𝘿𝙖𝙩𝙖𝙗𝙖𝙨𝙚 / 𝘼𝙄

For production AI applications, this matters. Document metadata, processing parameters, search filters, and structured AI outputs all need predictable contracts.

Good schemas do more than describe data. They protect the rest of the system.


You can explore more: https://www.youtube.com/playlist?list=PLQNCas8_eikM


#Python #Pydantic #PydanticV2 #FastAPI #BackendEngineering #AIEngineering