<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>AI Platform Engineering Handbook</title><link>/</link><description>Recent content on AI Platform Engineering Handbook</description><generator>Hugo</generator><language>en</language><copyright>Copyright (c) 2026 Harshhaa</copyright><lastBuildDate>Mon, 01 Jan 0001 00:00:00 +0000</lastBuildDate><atom:link href="/index.xml" rel="self" type="application/rss+xml"/><item><title>Advanced Git &amp; CI/CD Engineering</title><link>/docs/week-01/advanced-git-cicd-engineering/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>/docs/week-01/advanced-git-cicd-engineering/</guid><description>&lt;hr&gt;
&lt;h2 id="advanced-git-engineering"&gt;ADVANCED GIT ENGINEERING&lt;/h2&gt;
&lt;hr&gt;
&lt;h2 id="1-git-internals--object-model"&gt;1. Git Internals &amp;amp; Object Model&lt;/h2&gt;
&lt;p&gt;Most engineers use Git every day without understanding how it actually works internally. This is fine for basic usage, but when things go wrong — a rebase goes sideways, a reset loses commits, a merge produces unexpected results — understanding Git&amp;rsquo;s internals is the difference between recovering confidently and panicking. More importantly, once you understand the object model, everything Git does makes intuitive sense.&lt;/p&gt;</description></item><item><title>End-to-End AI Platform Architecture</title><link>/docs/week-04/end-to-end-ai-platform-architecture/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>/docs/week-04/end-to-end-ai-platform-architecture/</guid><description>&lt;hr&gt;
&lt;h2 id="1-cloud-native-ai-system-architecture"&gt;1. Cloud-Native AI System Architecture&lt;/h2&gt;
&lt;p&gt;Let&amp;rsquo;s start from the very beginning. Before cloud existed, if a company wanted to run software, they had to physically buy servers, put them in a room, hire people to maintain them, and pray nothing breaks. If traffic suddenly doubled, you were out of luck — you didn&amp;rsquo;t have extra hardware sitting around.&lt;/p&gt;</description></item><item><title>Infrastructure as Code (Terraform Advanced)</title><link>/docs/week-03/infrastructure-as-code-terraform-advanced/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>/docs/week-03/infrastructure-as-code-terraform-advanced/</guid><description>&lt;hr&gt;
&lt;h2 id="1-infrastructure-as-code-principles"&gt;1. Infrastructure as Code Principles&lt;/h2&gt;
&lt;p&gt;Let&amp;rsquo;s start from the very beginning and understand why Infrastructure as Code exists, because once you understand the problem it solves, every other concept in this section makes intuitive sense.&lt;/p&gt;</description></item><item><title>ML Lifecycle &amp; Experiment Tracking</title><link>/docs/week-02/ml-lifecycle-experiment-tracking/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>/docs/week-02/ml-lifecycle-experiment-tracking/</guid><description>&lt;hr&gt;
&lt;h2 id="1-machine-learning-lifecycle-overview"&gt;1. Machine Learning Lifecycle Overview&lt;/h2&gt;
&lt;p&gt;Before diving into individual concepts, you need a mental model of the complete journey a machine learning project takes from idea to production. Most engineers new to ML think the lifecycle is: get data, train model, done. In reality, that&amp;rsquo;s about 10% of the work. The full lifecycle is a continuous loop involving many disciplines, many failure modes, and many handoffs between people and systems.&lt;/p&gt;</description></item><item><title>Advanced Deployment Strategies</title><link>/docs/week-04/advanced-deployment-strategies/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>/docs/week-04/advanced-deployment-strategies/</guid><description>&lt;hr&gt;
&lt;h2 id="1-blue-green-deployment-strategy"&gt;1. Blue-Green Deployment Strategy&lt;/h2&gt;
&lt;p&gt;Let me start with the problem this solves. You have a model or service running in production serving real users. You&amp;rsquo;ve built a new version and want to deploy it. The naive approach: shut down the old version, deploy the new one, hope it works. The problem with this: during the switchover, users get errors. And if the new version has a bug, you&amp;rsquo;ve already killed the old one — rolling back means going through the same painful process again.&lt;/p&gt;</description></item><item><title>Docker &amp; Container Security Engineering</title><link>/docs/week-01/docker-container-security-engineering/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>/docs/week-01/docker-container-security-engineering/</guid><description>&lt;hr&gt;
&lt;h2 id="1-containerization-fundamentals"&gt;1. Containerization Fundamentals&lt;/h2&gt;
&lt;p&gt;Before containers existed, deploying software was genuinely painful in ways that are hard to appreciate if you haven&amp;rsquo;t lived through it. You&amp;rsquo;d write an application on your laptop, running Python 3.9 with specific library versions on macOS. The staging server runs Python 3.7 on Ubuntu. Production runs Python 3.8 on CentOS. Each environment has different library versions installed, different system dependencies, different file paths, different environment variables. Your application works perfectly on your laptop and mysteriously breaks in production. The phrase &amp;ldquo;it works on my machine&amp;rdquo; became a running joke in the industry because it was so universally true and so universally frustrating.&lt;/p&gt;</description></item><item><title>GitOps &amp; Continuous Delivery</title><link>/docs/week-03/gitops-continuous-delivery/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>/docs/week-03/gitops-continuous-delivery/</guid><description>&lt;hr&gt;
&lt;h2 id="1-gitops-principles"&gt;1. GitOps Principles&lt;/h2&gt;
&lt;p&gt;To understand GitOps, you first need to understand the problem it solves, because the solution only makes sense in the context of the problem.&lt;/p&gt;</description></item><item><title>Model Packaging &amp; Serving</title><link>/docs/week-02/model-packaging-serving/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>/docs/week-02/model-packaging-serving/</guid><description>&lt;hr&gt;
&lt;h2 id="1-model-serialization-techniques"&gt;1. Model Serialization Techniques&lt;/h2&gt;
&lt;p&gt;You&amp;rsquo;ve trained a model. The training process ran for hours, consumed gigabytes of GPU memory, and produced a set of learned parameters — numbers representing the patterns the model discovered in your data. When training finishes, those parameters exist only in your process&amp;rsquo;s memory. The moment that process ends, they&amp;rsquo;re gone forever unless you save them to disk. Serialization is the process of converting those in-memory parameters and model structure into a format that can be stored persistently and loaded back later.&lt;/p&gt;</description></item><item><title>CI/CD for Machine Learning</title><link>/docs/week-02/cicd-for-machine-learning/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>/docs/week-02/cicd-for-machine-learning/</guid><description>&lt;hr&gt;
&lt;h2 id="1-ml-pipeline-architecture"&gt;1. ML Pipeline Architecture&lt;/h2&gt;
&lt;p&gt;Before getting into individual concepts, you need a mental model of what an ML pipeline actually is and why it needs to be a pipeline at all rather than a collection of scripts someone runs manually.&lt;/p&gt;</description></item><item><title>Internal Developer Platform (IDP)</title><link>/docs/week-03/internal-developer-platform-idp/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>/docs/week-03/internal-developer-platform-idp/</guid><description>&lt;hr&gt;
&lt;h2 id="1-platform-engineering-fundamentals"&gt;1. Platform Engineering Fundamentals&lt;/h2&gt;
&lt;p&gt;To understand platform engineering, you first need to understand the problem that created the need for it, because the discipline emerged directly from a specific pain point that organizations hit as they scaled their engineering teams.&lt;/p&gt;</description></item></channel></rss>