<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Week 17 - Forward Deployed Engineering on AI Platform Engineering Handbook</title><link>/docs/week-17/</link><description>Recent content in Week 17 - Forward Deployed Engineering on AI Platform Engineering Handbook</description><generator>Hugo</generator><language>en</language><copyright>Copyright (c) 2026 Harshhaa</copyright><atom:link href="/docs/week-17/index.xml" rel="self" type="application/rss+xml"/><item><title>Customer Problem Discovery &amp; Technical Scoping</title><link>/docs/week-17/customer-problem-discovery-technical-scoping/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>/docs/week-17/customer-problem-discovery-technical-scoping/</guid><description>&lt;hr&gt;
&lt;h1 id="customer-problem-discovery--technical-scoping"&gt;Customer Problem Discovery &amp;amp; Technical Scoping&lt;/h1&gt;
&lt;h2 id="the-big-picture-first"&gt;The Big Picture First&lt;/h2&gt;
&lt;p&gt;This whole course has spent sixteen weeks building up genuinely deep technical skill — how models work, how to build RAG systems and agents, how to secure and scale and fine-tune AI systems. This final week shifts to something genuinely different, and honestly, something a lot of technically skilled engineers underestimate: the actual work of figuring out what to build in the first place, for a real customer, with real constraints, real existing systems, and real business needs that don&amp;rsquo;t always look anything like a clean, well-defined technical spec. Forward deployed engineering is a genuinely distinctive role that&amp;rsquo;s emerged specifically around AI products, precisely because AI systems are so deeply shaped by the specific data, specific workflows, and specific constraints of whoever&amp;rsquo;s actually going to use them — meaning a huge amount of the real work happens before any code gets written at all. Let&amp;rsquo;s build up an understanding of what this actually involves.&lt;/p&gt;</description></item><item><title>Rapid Prototyping &amp; AI Solution Development</title><link>/docs/week-17/rapid-prototyping-ai-solution-development/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>/docs/week-17/rapid-prototyping-ai-solution-development/</guid><description>&lt;hr&gt;
&lt;h1 id="rapid-prototyping--ai-solution-development"&gt;Rapid Prototyping &amp;amp; AI Solution Development&lt;/h1&gt;
&lt;h2 id="the-big-picture-first"&gt;The Big Picture First&lt;/h2&gt;
&lt;p&gt;The previous explanation covered how a forward deployed engineer figures out what actually needs to be built. This explanation covers what happens next — actually, genuinely building it, but in a genuinely distinctive way compared to how a lot of traditional software gets built. Here&amp;rsquo;s the core mindset shift worth understanding upfront: in a customer-facing AI engineering context, the goal usually isn&amp;rsquo;t to disappear for months and come back with a perfectly polished, fully complete system. It&amp;rsquo;s to get something genuinely real, genuinely working, and genuinely testable in front of the customer as quickly as possible, and then to keep refining it together with them, in tight, iterative cycles. This whole explanation is about the practical skills and habits that make this particular way of working actually succeed.&lt;/p&gt;</description></item><item><title>Production Deployment &amp; Customer Integration</title><link>/docs/week-17/production-deployment-customer-integration/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>/docs/week-17/production-deployment-customer-integration/</guid><description>&lt;hr&gt;
&lt;h1 id="production-deployment--customer-integration"&gt;Production Deployment &amp;amp; Customer Integration&lt;/h1&gt;
&lt;h2 id="the-big-picture-first"&gt;The Big Picture First&lt;/h2&gt;
&lt;p&gt;The previous explanation covered rapid prototyping — actually getting something real and working in front of a customer quickly. This final explanation covers what happens after a prototype has genuinely proven itself: actually turning it into something that lives permanently inside a customer&amp;rsquo;s real, live production environment, handling real business traffic, day after day, reliably. This is genuinely a different kind of challenge than prototyping. A prototype only needs to work well enough to prove a point, in a controlled setting, for a limited time. A production deployment needs to keep working well, indefinitely, inside a customer&amp;rsquo;s own particular real infrastructure, under their own particular real constraints, while a forward deployed engineer is often no longer sitting right there, watching over it constantly. Let&amp;rsquo;s build up an understanding of everything involved in making that genuine transition successfully.&lt;/p&gt;</description></item><item><title>Customer Engineering &amp; Communication</title><link>/docs/week-17/customer-engineering-communication/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>/docs/week-17/customer-engineering-communication/</guid><description>&lt;hr&gt;
&lt;h1 id="customer-engineering--communication"&gt;Customer Engineering &amp;amp; Communication&lt;/h1&gt;
&lt;h2 id="the-big-picture-first"&gt;The Big Picture First&lt;/h2&gt;
&lt;p&gt;This is genuinely the final piece of the entire whole course, and it&amp;rsquo;s worth pausing on why it comes last. Everything covered throughout the previous sixteen and a half weeks — the technical depth, the discovery process, the rapid prototyping, the production deployment — genuinely, actually only delivers real value if it can actually be understood, trusted, and properly sustained by the real, actual humans involved on the customer&amp;rsquo;s own particular side. A forward deployed engineer who builds a genuinely brilliant technical solution, but who can&amp;rsquo;t actually explain it clearly, can&amp;rsquo;t actually document it well, and can&amp;rsquo;t actually build real trust with the people who&amp;rsquo;ll be relying on it, genuinely risks that brilliant work never actually being properly understood, properly adopted, or properly maintained once they&amp;rsquo;re no longer directly there. This final explanation is about that essential, often underestimated other half of the job.&lt;/p&gt;</description></item></channel></rss>