FDE: ขอบเขตใหม่ของบทบาทวิศวกรรมที่ขับเคลื่อนด้วยปัญญาประดิษฐ์

ในเดือนที่ผ่านมา ผู้เขียนได้พบเพื่อนสี่คนที่กำลังวางแผนเปลี่ยนสายอาชีพ—นักพัฒนาฟรอนต์เอนด์ ผู้ออกแบบสถาปัตยกรรมโซลูชัน ผู้จัดการผลิตภัณฑ์ และวิศวกรอัลกอริธึมแบบดั้งเดิม ซึ่งมีพื้นหลัง อายุ และเมืองที่ต่างกัน แต่ต่างก็ถามคำถามเดียวกันว่า: FDE [2] คุ้มค่าที่จะไปไหม

FDE ย่อมาจาก Forward Deployed Engineer [2] เมื่อสองปีก่อนยังเป็นศัพท์เฉพาะในวงการ Palantir แต่วันนี้มันได้กลายเป็นประโยคเปิดตัวของนักจัดหางาน ตำแหน่งที่พบบ่อยในประกาศรับสมัครงาน และหนึ่งในคำตอบที่ถูกเสนอว่าเป็นตำแหน่งที่มีมูลค่าสูงสุดในยุค AI บนโซเชียลมีเดีย OpenAI ได้ก่อตั้ง Deployment Company [3] ด้วยชื่อนี้โดยตรงในเดือนพฤษภาคม 2026 โดยมีการลงทุนเริ่มต้น 4 พันล้านดอลลาร์สหรัฐ และระบุชัดเจนว่าจะส่งวิศวกรไปทำงานในสถานที่จริงของลูกค้า เพื่อผสานเข้ากับกระบวนการทำงานของลูกค้า ในขณะเดียวกันทีม Applied AI ของ Anthropic ก็กำลังรับสมัคร FDE พร้อมกันในสี่เขตเวลา ปรากฏการณ์นี้ใช้เวลาเพียงกว่าหนึ่งปีในการเปลี่ยนจากศัพท์เฉพาะในวงการให้กลายเป็นคำที่เปิดเผยและแพร่หลาย

บทความก่อนหน้าของผู้เขียน เรื่อง “ถึงบุคคลพิเศษ” [4] ได้พูดถึง “เครื่องยนต์ของมนุษย์” — ความอยากรู้อยากเห็น การเรียนรู้ด้วยตนเอง แรงจูงใจในตัวเอง และทักษะการลงมือทำ — ว่าจะกระตุ้นให้เกิดขึ้นได้อย่างไรภายใน Closed-loop ที่สมบูรณ์ แต่มนุษย์ไม่ได้ลอยอยู่ในอากาศ มนุษย์ต้องถูกจับต้องโดยระบบพิกัดตำแหน่งงานที่ชัดเจน หากบุคคลพิเศษเป็น “วัตถุดิบ” ของความสัมพันธ์การผลิตในยุค AI แล้ว FDE ก็คือรูปแบบตำแหน่งงานที่เด่นชัดที่สุดที่ตลาดได้พัฒนาขึ้นในปีนี้

ในมุมมองของผู้เขียน FDE ไม่ได้อยู่ในกล่องที่ปรึกษา หรือกล่องนอกสถานที่ มันใกล้เคียงกับบุคคลอัจฉริยะมากที่สุด ความแตกต่างเพียงอย่างเดียวคือ FDE เป็นบุคคลอัจฉริยะที่ถูกจัดระเบียบอยู่ในช่องว่างระหว่าง “บริษัทโมเดล × ลูกค้า”

คุณรู้ไหม—คำว่า Forward Deployed มาจากไหน? มันเดิมทีเป็นศัพท์ทางทหารของสหรัฐฯ คือ Forward Deployed Forces ซึ่งหมายถึงกองกำลังที่ถูกส่งไปประจำการต่างประเทศหรือแนวหน้า เพื่อตอบสนองได้อย่างใกล้ชิด โดยเปรียบเทียบกับกองกำลังที่ยังคงอยู่ในฐานหลักบนดินแดนต้นทาง ในช่วงปลายทศวรรษ 2000 Palantir ได้นำคำนี้มาใช้ในอุตสาหกรรมซอฟต์แวร์ เพื่ออธิบายรูปแบบการทำงานที่ “ส่งวิศวกรออกจากสำนักงานใหญ่ไปอยู่ที่ไซต์ลูกค้า” แม้แต่ทีมภายในก็ถูกตั้งชื่อตามรหัสเสียงทางทหารว่า Delta และ Echo ครั้งนี้ OpenAI และ Anthropic ได้รับกลับมาอีกครั้ง ไม่ใช่เรื่องบังเอิญ—การส่งวิศวกรไปแนวหน้า แก่นแท้ของเรื่องนี้ยังคงไม่เปลี่ยนแปลง

บทความนี้จะตอบคำถามสามข้อเฉพาะที่ผู้เขียนถูกเพื่อนทั้งสี่คนถามเมื่อเร็วๆ นี้:

FDE คือบริษัทที่ปรึกษาที่สวมรอยด้วยปัญญาประดิษฐ์หรือไม่? ขอบเขตของมันกับที่ปรึกษาแบบดั้งเดิมอยู่ที่ไหน?

FDE คือการรับจ้างพัฒนาซอฟต์แวร์ระดับสูงกว่าไหม? มันต่างจากงานที่ฉันทำในฐานะผู้รับจ้างอย่างไร?

ฉันเหมาะกับงาน FDE ไหม? ประเภทคนใดที่ตำแหน่งนี้จะทำให้เด่นชัด และประเภทคนใดที่จะถูกบดขยี้?

ทัศนคติของผู้เขียนคือระมัดระวังแต่เป็นบวก: FDE กำลังเติบโตอย่างแท้จริง แต่มันยังห่างไกลจากทางออกสำหรับทุกคน การอธิบายมันให้ชัดเจนสำคัญกว่าการทำให้มันดูน่าตื่นเต้น

หากต้องเลือกเพียงเหตุการณ์เดียวเพื่อระบุจุดเริ่มต้นของการกลับมาโดดเด่นอีกครั้งของ FDE ผู้เขียนจะเลือกวันที่ 11 พฤษภาคม 2026—วันที่ OpenAI ประกาศก่อตั้ง Deployment Company [5] โดย Brad Lightcap หัวหน้าฝ่ายปฏิบัติการ ได้ย้ายจากสายธุรกิจเดิมไปรับตำแหน่ง special projects และรายงานตัวโดยตรงต่อ Sam Altman เพื่อดูแลเรื่องนี้อย่างเต็มเวลา ในสัปดาห์เดียวกันนั้น OpenAI ได้ซื้อกิจการบริษัทที่ปรึกษา AI ของอังกฤษชื่อ Tomoro ซึ่งทำให้สามารถรวมพนักงาน Forward Deployed Engineer และ Deployment Specialist จำนวน 150 คนเข้าสู่บริษัทใหม่ทันที

น่าสังเกตว่าหน้าการรับสมัครงานของ OpenAI กำลังประกาศตำแหน่ง FDE มากกว่าสิบตำแหน่งพร้อมกัน: ซานฟรานซิสโก นิวยอร์ก วอชิงตัน รวมถึงแนวตั้งตามอุตสาหกรรม เช่น Life Sciences, Semiconductor, Gov และแม้แต่ตำแหน่งผู้รับสมัคร FDE [6] ก็อยู่ในระหว่างการรับสมัครเช่นกัน นักวิเคราะห์ประเมินว่าทีมนี้จะขยายตัวเป็น 2,000–4,000 คนภายในสามปี นี่ไม่ใช่ขนาดของทีมวิจัย แต่เป็นกองทัพที่เป็นทางการ

ที่ Anthropic นั้นแทบจะเป็นการกระทำที่สะท้อนกันอย่างสมบูรณ์แบบ ตำแหน่ง Forward Deployed Engineer ภายใต้ทีม Applied AI [7] ได้เปิดรับสมัครพร้อมกันในหกเมือง ได้แก่ บอสตัน นิวยอร์ก เซแอตเทิล ซานฟรานซิสโก วอชิงตัน และลอนดอน โดยมีข้อกำหนดให้เดินทางไปยังสถานที่ลูกค้า 25%–50% ตัวอย่างที่ถูกอ้างอิงบ่อยครั้งคือบริษัทฟินเทค FIS — ซึ่งในประกาศของพวกเขามีการระบุโดยตรงว่า “ทีม Applied AI และ forward-deployed engineers ของ Anthropic ได้ถูกผนวกเข้ากับ FIS เพื่อร่วมกันออกแบบ Financial Crimes AI Agent และถ่ายทอดความรู้ให้กับ FIS เพื่อให้สามารถขยาย agent เพิ่มเติมได้ด้วยตนเองในอนาคต”

ข้อความนี้เปิดเผยภาพจริงของงาน FDE ไม่ใช่สถาปนิกก่อนการขาย ไม่ใช่ SDR และไม่ใช่ผู้เผยแพร่ที่มาฝึกอบรมลูกค้า มันคือวิศวกรที่นำโมเดลมาอยู่ร่วมกับรหัสของลูกค้า Brad Lightcap กล่าวอย่างตรงไปตรงมาว่า: “ลูกค้าของเราบอกเราว่าพวกเขาต้องการความสามารถในการย้ายจาก pilot ไปสู่ production Deployment Company คือการส่งวิศวกรของเราเข้าไปอยู่ในทีมของพวกเขา และจัดสรรทรัพยากรเพียงพอเพื่อให้สามารถส่งมอบได้”

วาดเรื่องนี้เป็นภาพ จะทำให้ความสัมพันธ์ของสามฝ่ายชัดเจนมากขึ้น:

โปรดสังเกตเส้นสองเส้นที่มีข้อมูลมากที่สุดในรูปนี้ คือข้อมูลย้อนกลับที่ FDE ส่งไปยังทั้งสองทิศทาง ไปทางลูกค้า FDE ไม่ได้ขายโมเดลเป็น SaaS แต่รวมข้อมูล สิทธิ์ การปฏิบัติตามกฎระเบียบ และระบบภายในของลูกค้าให้เป็นท่อเดียวที่สามารถรันโมเดลได้ ไปทางบริษัทโมเดล FDE นำปัญหาจริงและตัวอย่างความล้มเหลวของลูกค้ากลับไปยังผลิตภัณฑ์และการวิจัย เพื่อส่งผลต่อเส้นทางการพัฒนา—รูปแบบการเรียกเครื่องมือที่ผิดพลาดซ้ำๆ อาจกลายเป็นการดูดซับแบบฝังตัวถัดไปของ SDK

นี่คือเหตุผลที่ FDE ถูกบริษัทโมเดลชั้นนำสองแห่งเปิดใช้งานอีกครั้งในรอบนี้ ซึ่งไม่ได้หมายความเพียงว่า “เราเองก็ต้องเรียนรู้จาก Palantir ในการให้คำปรึกษา” มันคืออุปกรณ์รับสัญญาณของบริษัทโมเดล—ปัญหาของลูกค้าที่หนาแน่นที่สุดบนแนวหน้า ต้องมีคนของตัวเองอยู่ตรงนั้นจึงจะจับได้ ความต้องการที่ถูกแปลผ่านพันธมิตรมักจะขาดความลึกซึ้งไปหนึ่งชั้น Anthropic เดินทางแบบผสมผสาน: ทั้งดำเนินการ FDE เองและร่วมสร้างเครือข่ายการติดตั้งกับบริษัทให้คำปรึกษาและผู้เล่นรายใหญ่ด้าน PE หนึ่งฝ่ายเน้นการดำเนินการเอง อีกฝ่ายเน้นระบบนิเวศ แต่แก่นแท้ของทั้งสองคือเหมือนกัน: บริษัทโมเดลไม่ได้เป็นเพียงผู้ให้บริการ API อีกต่อไป แต่จะส่งวิศวกรเข้าไปในผลิตภัณฑ์ของลูกค้าโดยตรง

คำถามถัดไปที่จะตอบคือ ข้อแตกต่างระหว่าง FDE กับการให้คำปรึกษาแบบดั้งเดิม (เช่น แมคคินซีย์ เอเชนเนอร์) อยู่ที่ไหน? มันเหมือนหรือต่างจากงานรับจ้างพัฒนาซอฟต์แวร์ที่เราคุ้นเคยหรือไม่?

หลายคนเมื่อได้ยินคำอธิบายงานของ FDE เป็นครั้งแรก มักตอบกลับว่า: “นี่ไม่ใช่แมคคินซีย์หรืออีเกนซ์เวอร์รุ่นใหม่หรือ?”

ผู้เขียนเข้าใจการเชื่อมโยงนี้ การใส่สูท ไปเยี่ยมลูกค้าที่ไซต์งาน นั่งในห้องประชุมลูกค้าและวาดรูปบนไวท์บอร์ด ร่วมประสานงานกับผู้บริหารระดับซี—จากภาพรวมแล้ว FDE และที่ปรึกษาดูเหมือนกันมาก แต่เพียงแค่ลึกขึ้นอีกขั้นหนึ่ง ลักษณะงานของทั้งสองอย่างจะต่างกันโดยสิ้นเชิง ที่ปรึกษาขายขอบเขตของกระบวนการ ในขณะที่ FDE ขายขอบเขตของโมเดล

วางทั้งสองอย่างไว้ข้างๆ กันในตารางเดียวกัน ความแตกต่างจะปรากฏทันที

รายการที่ควรหยุดพิจารณาเป็นพิเศษในตารางนี้คือ “การเสื่อมค่าของสินทรัพย์”

ตรรกะที่ทำกำไรได้มากที่สุดของการให้คำปรึกษาแบบดั้งเดิมคือการใช้ทรัพย์สินซ้ำ — แผนสำหรับธนาคารแห่งหนึ่งสามารถปรับเล็กน้อยแล้วขายอีกครั้งให้กับธนาคารถัดไป; คู่มือดิจิทัลสำหรับอุตสาหกรรมค้าปลีกสามารถนำไปใช้ซ้ำกับลูกค้าสามสิบรายได้ นี่คือแบบจำลองทางเศรษฐกิจพื้นฐานที่ทำให้ Accenture, Deloitte และ McKinsey Digital เติบโตมาตลอดสามทศวรรษที่ผ่านมา

FDE ไม่มีสินทรัพย์ประเภทนี้ ความสามารถของโมเดลยังคงเปลี่ยนแปลงอย่างรวดเร็ว—วันนี้ยังต้องการการสร้าง Prompt ที่ออกแบบอย่างรอบคอบ แต่รุ่นถัดไปอาจทำได้ด้วยเพียงประโยคเดียว การ “สะสมวิธีการ” ในการปรึกษาจะสูญเสียมูลค่าอย่างรวดเร็วเมื่อเทียบกับความเร็วนี้ ดังนั้น FDE จึงไม่สามารถใช้รูปแบบการใช้ซ้ำสินทรัพย์ได้ แต่ต้องรันวงจรปิดใหม่ทุกครั้ง—ประเมินขอบเขตของโมเดลใหม่ เลือกชุดเครื่องมือใหม่ และประกอบรูปแบบผลิตภัณฑ์ใหม่ ดูเหมือนไม่มีประสิทธิภาพ แต่จริงๆ แล้วเป็นวิธีเดียวที่จะตามทันความเร็วของโมเดล

คุณรู้ไหม—Product Overhang คืออะไร? ผู้เขียนได้อธิบายคำนี้ไว้ในบทความก่อนหน้า “ถึงบุคคลเหนือชั้น” [4]: ความสามารถของโมเดลเกินกว่ารูปแบบผลิตภัณฑ์ที่มีอยู่ แต่ยังขาดช่องทางการเข้าถึง สิทธิ์ และบริบทเพื่อแปลงมันให้เป็นรูปธรรม บทบาทของ FDE มีคุณค่าโดยพื้นฐานคือการแปลง Overhang ที่ลอยอยู่ในสถานการณ์ของลูกค้าให้กลายเป็นผลิตภัณฑ์ที่สามารถดำเนินการได้จริง ลูกค้าไม่ได้ซื้อปริมาณการเรียกใช้ API ของโมเดล แต่ซื้อความสามารถในการ “มีคนนำ Overhang ทั้งหมดนี้ไปประยุกต์ใช้จริงในธุรกิจของฉัน”

สิ่งนี้ยังอธิบายความแตกต่างในแถว “โครงสร้างโครงการ” โครงสร้างมาตรฐานของโครงการที่ปรึกษาคือ SOW (Statement of Work) + WBS (Work Breakdown Structure) + การรับรองตามระยะ: ระบุอย่างชัดเจนในสัญญาถึงสิ่งที่ต้องส่งมอบ เวลาที่ต้องส่งมอบ และเกณฑ์การรับรอง โครงสร้างนี้ตั้งอยู่บนสมมติฐานว่าเป้าหมายได้ถูกกำหนดไว้แล้วก่อนที่จะลงนามในสัญญา

โครงการของ FDE ไม่ได้ใช้วิธีนี้ ลูกค้ามักพูดว่า: “ฉันรู้ว่า AI ควรช่วยฉันทำบางอย่างได้ แต่ฉันไม่รู้ว่าควรทำอะไร” เป้าหมายนั้นเป็นส่วนหนึ่งของโครงการเอง ดังนั้น FDE จึงไม่รับ SOW แต่รับ mission—ทิศทางที่ค่อนข้างคลุมเครือ—แล้วใช้การวนซ้ำแต่ละรอบเพื่อทำให้ทิศทางชัดเจนขึ้น ในที่สุดในรอบใดรอบหนึ่ง โมเดลที่สะสมไว้จะถูกแปลงเป็นรูปแบบผลิตภัณฑ์

แถว “สิ่งที่ส่งมอบ” ก็ควรขยายความเช่นกัน หลังจาก FDE ลาออก แล้วที่เหลืออยู่ในระบบลูกค้าคือฟังก์ชันที่ใช้งานได้—อาจเล็ก อาจดูไม่สวย หรืออาจไม่มีอินเทอร์เฟซผู้ใช้มากมาย แต่มันถูกเรียกใช้งาน ถูกปรับปรุง และถูกวิพากษ์วิจารณ์ทุกวัน สิ่งที่ส่งมอบของที่ปรึกษาคือ PPT และรายงานการจัดการการเปลี่ยนแปลง แม้ว่าในโครงการจะเขียนโค้ดหรือตั้งค่า ERP มาก่อน แต่สิ่งสุดท้ายที่ผู้บริหารลูกค้าได้รับยังคงเป็นเอกสารวิธีการ

แถว “รั้วป้องกัน” เป็นสิ่งที่ละเอียดอ่อนที่สุด รั้วป้องกันของ FDE คือความรู้สึกแบบเรียลไทม์เกี่ยวกับขอบเขตของความสามารถของโมเดล—คุณได้ดำเนินการสถานการณ์ลูกค้าจริงกี่กรณีในเดือนนี้ คุณก็จะรู้ดีกว่าคนอื่นว่า Claude 4.7 ทำอะไรได้บ้าง และอะไรต้องรอจนถึง Claude 5 ความรู้สึกนี้ไม่สามารถเขียนลงใน PPT หรือใส่ลงในฐานความรู้ได้ มันเติบโตอยู่ในสมองของวิศวกรที่เคยลงมือทำในช่วง 90 วันที่ผ่านมาเท่านั้น

ดังนั้น ครั้งหน้าหากมีใครพูดว่า “FDE ไม่ก็แค่เวอร์ชันใหม่ของ Accenture” คุณสามารถตอบได้ว่า: วิศวกรของ Accenture ไปออกแบบกระบวนการของลูกค้าใหม่ ขณะที่ FDE ไปค้นหาขอบเขตของโมเดลอีกครั้ง ทรัพย์สินของฝั่งแรกสามารถสะสมได้นานสิบปี แต่ทรัพย์สินของฝั่งหลังต้องเติบโตใหม่ทุก 90 วัน

หากการตีความว่า “FDE คือ Accenture เวอร์ชันใหม่” เป็นการเข้าใจผิดระดับที่หนึ่ง การตีความว่า “FDE คือการจ้างภายนอกซอฟต์แวร์ราคาแพง” ก็เป็นการเข้าใจผิดระดับที่สอง การตีความระดับนี้มีความคลาดเคลื่อนมากกว่า เพราะหลักฐานภายนอกดูเหมือนจะชัดเจนมาก: FDE จริงๆ แล้วไปเขียนโค้ดที่ไซต์ลูกค้า จริงๆ แล้วปรับแต่งฟังก์ชันตามธุรกิจของลูกค้า และจริงๆ แล้วถูกเรียกใช้งานตามช่วงเวลาทำงานของลูกค้า ดูเหมือนจะไม่ต่างจากวิศวกรรับจ้างภายนอกเลย

แต่เพียงแค่ดูที่วงจรป้อนกลับ ความแตกต่างก็ซ่อนไม่ได้

ความแตกต่างที่สำคัญที่สุดในภาพนี้ ไม่ได้อยู่ที่ส่วนบนของภาพเรียบง่ายเพียงใด แต่อยู่ที่ส่วนล่างของภาพมีสายการตอบกลับที่ยืดออกไปยังบริษัทโมเดล สายการนี้ไม่ใช่แค่การตกแต่ง มันคือเหตุผลที่แท้จริงที่ตำแหน่ง FDE มีอยู่ เมื่อแยกความแตกต่างนี้ออก จะมีการเปรียบเทียบอย่างน้อยสี่ชุด

สิ่งที่รับมาต่างกัน การจ้างภายนอกรับ SOW—รายการความต้องการที่ถูกกำหนดไว้ล่วงหน้าก่อนลงนามสัญญา: ต้องทำฟีเจอร์อะไร ใช้เทคโนโลยีอะไร ตรวจสอบตามมาตรฐานใด และหากผิดสัญญาจะชดเชยอย่างไร ส่วน FDE รับ mission—ลูกค้าเองก็ยังไม่ชัดเจนว่าต้องการอะไร แต่รู้แค่ว่า “AI น่าจะช่วยทำบางอย่างให้ฉันได้” SOW มีพื้นฐานอยู่บนความแน่นอน ส่วน mission มีพื้นฐานอยู่บนการค้นหา ทั้งสองแบบมีท่าทีในการเริ่มโครงการที่ต่างกันโดยสิ้นเชิง

ขอบเขตที่ทำต่างกัน งานรับจ้างทำเฉพาะการส่งมอบบางส่วน—เช่น โมดูลหนึ่ง หนึ่งเว็บไซต์ หรือหนึ่ง data pipeline เมื่อเสร็จก็แพ็กเกจและจากไปเพื่อไปทำที่อื่น ส่วน FDE ทำแบบครบวงจร—เริ่มจากปัญหาทางธุรกิจ ไปจนถึงการเลือกโมเดล การออกแบบรูปแบบผลิตภัณฑ์ และการดูแลการรักษาผู้ใช้จริงและการเลิกใช้งานหลังเปิดตัว

วิธีการคิดค่าบริการต่างกัน จุดนี้ตรงข้ามกับความเข้าใจทั่วไปที่สุด บริษัทโมเดลหนึ่งส่ง FDE เข้าไปที่ลูกค้า ซึ่งสิ่งที่พวกเขาสนใจไม่ใช่แค่ค่าที่ปรึกษาจากโครงการนี้เท่านั้น แต่ยังรวมถึง: ลูกค้ารายนี้จะใช้ token ไปเท่าไหร่ในอนาคต? จะกลายเป็นลูกค้าที่คงอยู่หรือไม่? จะขยายไปยังสายธุรกิจอื่นๆ เพิ่มเติมหรือไม่? KPI ที่แท้จริงของ FDE คือเส้นโค้งการใช้ token ของโมเดลในระยะยาว ไม่ใช่ตัวเลขบนใบรับรองการยอมรับโครงการ

ทิศทางของข้อเสนอแนะต่างกัน นี่คือกลุ่มที่ลึกที่สุดในสี่กลุ่ม ในโครงการจ้างภายนอก ข้อเสนอแนะจากลูกค้าจะหยุดเพียงแค่ที่บริษัทจ้างภายนอก และไม่มีผลต่อผลิตภัณฑ์ที่บริษัทจ้างภายนอกจะขายให้ผู้อื่นในอนาคต แต่ข้อเสนอแนะจาก FDE จะไหลย้อนกลับไปยังเส้นทางการพัฒนาของบริษัทโมเดล—ปัญหาทุกข้อ ความล้มเหลวของ Prompt ทุกครั้ง และบั๊กในการเรียกใช้เครื่องมือที่ลูกค้าพบในสถานการณ์จริง ล้วนกลายเป็นข้อมูลป้อนสำหรับชุดข้อมูลการฝึกอบรมรุ่นถัดไป การออกแบบเครื่องมือรุ่นถัดไป และฟีเจอร์ผลิตภัณฑ์รุ่นถัดไป กล่าวอีกนัยหนึ่ง ลูกค้าแต่ละรายที่ติดตั้ง FDE สำหรับบริษัทโมเดล ถือเป็นพันธมิตรด้านการออกแบบโดยธรรมชาติ

นี่คือเหตุผลที่แท้จริงที่บริษัทโมเดลยินดีจ่ายเงินเดือนสูงเพื่อจ้าง FDE พวกเขาไม่ได้แค่ขายบริการ แต่พวกเขากำลังรวบรวมสัญญาณรูปแบบผลิตภัณฑ์ในโลกจริงจากสถานที่ของลูกค้า สัญญาณเหล่านี้ไม่สามารถซื้อได้ จับได้ หรือค้นพบผ่านการสำรวจแบบสอบถาม—มันสามารถรับมาได้เฉพาะโดยวิศวกรที่เฉพาะเจาะจง ผ่านการทดลองในกระบวนการทำงานของลูกค้าจริง หลังจากชนกำแพงมาหลายครั้ง

คุณรู้ไหม—ค่าจ้างรวมของ FDE สำหรับ OpenAI และ Anthropic สูงถึงเท่าใด? จากข้อมูลสาธารณะบน Levels.fyi สำหรับวิศวกรซอฟต์แวร์ของ Anthropic [8] ค่าจ้างรวมกลางของ SDE ระดับอาวุโสได้ถึง 710,000 ดอลลาร์สหรัฐแล้ว ตำแหน่ง FDE มีความเสี่ยงสูงกว่า—ต้องรับมือกับความไม่แน่นอนของความสามารถของโมเดล ความไม่แน่นอนของธุรกิจลูกค้า และความไม่แน่นอนของรูปแบบผลิตภัณฑ์ ดังนั้นตามการรวบรวมข้อมูลอุตสาหกรรม [9] ค่าจ้างรวมของ FDE ระดับกลางถึงสูงในห้องปฏิบัติการ AI ชั้นนำมักอยู่ระหว่าง 350,000–550,000 ดอลลาร์สหรัฐ ในขณะที่ระดับ Staff ขึ้นไปสามารถพุ่งถึง 630,000 ดอลลาร์สหรัฐขึ้นไป ราคาดังกล่าวไม่ได้จ่ายให้กับ “ชั่วโมงงานรับจ้าง” แต่จ่ายให้กับผู้รับผิดชอบต่อการรวมกันของความเสี่ยงสามประการ: “ผลิตภัณฑ์ + ลูกค้า + โมเดล” > ย้อนกลับไปปี 2006 เมื่อผู้เขียนเพิ่งเริ่มงานที่บริษัทรัฐวิสาหกิจแห่งหนึ่ง ซึ่งกำลังดำเนินการเปลี่ยนผ่านสู่ระบบสารสนเทศ ในยุคนั้น บริษัทของเราจ้างที่ปรึกษาจาก Accenture มาประจำที่สำนักงาน และต้องจ่ายค่าที่ปรึกษาให้ Accenture วันละ 3,500 หยวน เป็นเวลาหลายปี ซึ่งสื่อในยุคนั้นเรียกว่า “กลุ่มผู้บริหารระดับสูง” ต่อมาผู้เขียนย้ายไปทำงานที่บริษัท SAP ของเยอรมนี โดย SAP ได้กำหนดชื่อใหม่สำหรับอุตสาหกรรมที่ปรึกษา และที่ปรึกษา SAP กลายเป็นสัญลักษณ์ของ “กลุ่มผู้บริหารระดับสูง” เห็นได้ชัดว่า เงินเดือนของ FDE จะยังคงเพิ่มขึ้นอย่างต่อเนื่องภายในระยะเวลา 24–36 เดือน และความต้องการก็ยังคงเพิ่มขึ้นอย่างมั่นคง

การจ้างภายนอกคือการแสวงหาผลประโยชน์จากแรงงาน ในขณะที่ FDE คือเซนเซอร์ด้านหน้า การสับสนระหว่างสองสิ่งนี้จะทำให้ฝ่ายว่าจ้างเข้าใจผิดว่าสามารถรับ FDE เข้ามาด้วยวิธี SOW และทำให้ผู้สมัครปฏิบัติตัวเหมือนพนักงานจ้างภายนอกเมื่อทำหน้าที่ FDE ทั้งสองฝ่ายจะชนกำแพงอย่างรวดเร็ว

หลายคนเข้าใจผิดว่าคำว่า FDE เป็นสิ่งที่ OpenAI คิดขึ้น แต่จริงๆ แล้วไม่ใช่ มันมีรากฐานสองเส้นทาง เส้นหนึ่งมาจาก Palantir อีกเส้นหนึ่งมาจากบริษัทโมเดลรุ่นใหม่หลังปี 2023 การวางรากฐานทั้งสองเส้นทางไว้ข้างๆ กัน จะช่วยให้เข้าใจได้ชัดเจนยิ่งขึ้นว่าตำแหน่ง FDE ทำหน้าที่อะไรจริงๆ

ดูเส้นเวลาแรก

รากแรกคือ Palantir.

Palantir ก่อตั้งขึ้นในปี 2003 โดย Peter Thiel, Alex Karp, Joe Lonsdale และผู้อื่น โดยลูกค้ารายแรกคือหน่วยงานข่าวกรองของสหรัฐฯ Karp ไม่มีพื้นฐานด้านวิทยาการคอมพิวเตอร์—he ศึกษาปริญญาเอกกับนักปรัชญา Jürgen Habermas ที่แฟรงก์เฟิร์ต และกลับมาสหรัฐฯ จึงถูก Thiel ดึงเข้ามารับตำแหน่งซีอีโอ ตำแหน่ง FDE เกิดขึ้นจากโครงสร้าง “ซีอีโอที่ไม่ธรรมดา + ลูกค้าที่มีความลับสูง” ของ Karp: บทความทบทวนของ 36Kr [10] เขียนอย่างตรงไปตรงมาว่า Palantir ในช่วงแรกถูกหน่วยงานข่าวกรองวิจารณ์อย่างหนัก เพราะวิศวกรไม่สามารถเข้าถึงสถานการณ์ทางธุรกิจจริง และความต้องการถูกแปลงผ่านหลายชั้นจนเบี่ยงเบนไปจากต้นฉบับ ต่อมา Palantir บรรลุข้อตกลงหนึ่งประการ—ให้วิศวกรของตนเองเข้าไปทำงานร่วมกับนักวิเคราะห์ข่าวกรองในสถานที่ของลูกค้า รูปแบบนี้ต่อมาถูก Shyam Sankar ระบบ化 และกลายเป็นรูปแบบเริ่มต้นของ FDE

ถึงปี 2009 FDE ได้ขยายตัวเข้าสู่ภาคธุรกิจ เมื่อ JPMorgan ใช้งานแพลตฟอร์ม Metropolis ของ Palantir นักวิเคราะห์ FDE จำนวน 120 คนได้เข้าไปประจำภายในองค์กรเพื่อดำเนินการตรวจสอบภัยคุกคามจากภายใน ตั้งแต่นั้นมา FDE ไม่ได้เป็นเพียง “การส่งวิศวกรไปประจำที่ลูกค้า” อีกต่อไป แต่กลายเป็นกลยุทธ์การฝังตัวกับลูกค้าอย่างเป็นระบบ: การนำ Foundry / Gotham ไปผสานเข้ากับกระบวนการดำเนินงานของลูกค้าอย่างแท้จริง ไม่ใช่แค่ส่งใบอนุญาตแล้วจากไป

การรับสมัคร FDE ของ Palantir มีเกณฑ์ที่ขัดกับสัญชาตญาณ—ไม่ต้องการใบปริญญาด้านวิทยาการคอมพิวเตอร์ ข้อมูลนี้สามารถใส่ไว้ใน “คุณรู้ไหม”

คุณรู้ไหม—Palantir FDE ไม่ต้องการใบปริญญาด้านวิทยาการคอมพิวเตอร์? จากมาตรฐานการรับสมัครของ Palantir ที่จัดทำโดย SkillScouter [11] และหน้า careers อย่างเป็นทางการของ Palantir [12] Palantir ยินดีรับผู้สมัครที่ไม่ได้เรียนด้านวิทยาการคอมพิวเตอร์ โดยผู้ที่ได้รับการคัดเลือกในช่วงไม่กี่เดือนที่ผ่านมา มาจากสาขาวิศวกรรมเครื่องกล เศรษฐศาสตร์ ปรัชญา เป็นต้น สิ่งที่พวกเขาจริงจังกับจริงๆ มีสองอย่างคือ: สามารถดำเนินการได้แม้ในสภาวะข้อมูลไม่สมบูรณ์ และสามารถพูดคุยโดยตรงกับลูกค้าระดับซีอีโอ ปริญญาด้านวิทยาการคอมพิวเตอร์เป็นข้อได้เปรียบ ไม่ใช่เงื่อนไขเบื้องต้น Karp เองก็เป็นตัวอย่างแรกของมาตรฐานนี้—ซีอีโอที่เรียนปรัชญา และนำทีม FDE ที่เรียนฟิสิกส์ คณิตศาสตร์ และปรัชญา

บริษัทโมเดลรุ่นใหม่หลังปี 2023

หลังจากที่ ChatGPT เปิดตัวปลายปี 2022 OpenAI รีบตระหนักถึงสิ่งหนึ่ง: การติดตั้ง API ของโมเดลไว้บนเอกสารและให้ลูกค้าเชื่อมต่อเองนั้นไม่สามารถทำได้จริง ลูกค้าไม่ได้ไม่อยากใช้ แต่ไม่รู้ว่าจะใช้อย่างไร—พวกเขามีปัญหาทางธุรกิจ แต่ไม่มีรูปแบบผลิตภัณฑ์ ดังนั้นบริษัทต่างๆ เช่น OpenAI, Anthropic, Cohere, Scale, Glean, Sierra, Hebbia และ Decagon จึงเริ่มรับพนักงาน FDE จำนวนมาก

ช่วงนี้ FDE เรียนรู้จาก playbook ของ Palantir — ส่งวิศวกรไปที่ไซต์ลูกค้า เพื่อดำเนินกระบวนการทั้งหมดตั้งแต่ต้นจนจบ แต่ตัวกลางผลิตภัณฑ์ได้เปลี่ยนไปแล้ว: ในยุค Palantir FDE ทำหน้าที่รวมข้อมูลและปรับแต่งอินเทอร์เฟซผู้ใช้ ขณะที่ FDE รุ่นใหม่ทำหน้าที่ออกแบบ Prompt การจัดการ Agent การเรียกใช้เครื่องมือ และการฝังกระบวนการ

ในบทความของ Pragmatic Engineer เกี่ยวกับ FDE [13] ได้เรียกเวอร์ชันใหม่นี้ว่า “embedded with enterprises to make Claude solve real, specific, high-value problems” — การระบุนี้ใกล้เคียงกับสิ่งที่ Palantir เคยใช้ในอดีต เพียงแต่เปลี่ยนคำว่า “ข้อมูล” เป็น “โมเดล”

เมื่อดูรากทั้งสอง这条ร่วมกัน คุณจะเห็นจุดร่วมและจุดแตกต่างที่ชัดเจนชุดหนึ่ง

จุดร่วม: ลูกค้าไม่ได้ซื้อซอฟต์แวร์ ลูกค้าซื้อ “วิศวกรที่สามารถแก้ปัญหาของฉันได้ พร้อมชุดเครื่องมือ” สิ่งนี้เป็นเรื่องผิดปกติในประวัติศาสตร์ซอฟต์แวร์องค์กรตลอดสามทศวรรษที่ผ่านมา SAP, Oracle, Salesforce ขายซอฟต์แวร์เอง—วิศวกรเป็นทรัพยากรสนับสนุนที่มีอยู่เพื่อ “ทำให้ลูกค้าสามารถใช้ซอฟต์แวร์นี้ได้” Palantir กลับกัน: เครื่องมือมีอยู่เพื่อเป็นแรงผลักดันให้ FDE สามารถแก้ปัญหาให้ลูกค้าได้ บริษัทรุ่นใหม่เหล่านี้สืบทอดความสัมพันธ์ที่กลับด้านนี้—OpenAI ไม่ได้ขายใบอนุญาต GPT-4 แต่ขาย “FDE ของเราที่สามารถใช้ GPT-4 ช่วยให้คุณดำเนินการอัตโนมัติบริการลูกค้าได้”

ความแตกต่าง: ยุค Palantir เน้นการผสานรวมด้าน OPS — จุดสำคัญอยู่ที่การผสานรวมข้อมูล การสร้างแบบจำลองออนโทโลยี และการจัดการสิทธิ์ รุ่นใหม่เน้นการประยุกต์ใช้ความสามารถของโมเดล — จุดสำคัญอยู่ที่การออกแบบ Prompt การจัดเรียง Agent และการเพิ่มประสิทธิภาพการรักษาผู้ใช้ ยุคแรกเหมือนเวอร์ชันที่พัฒนาขึ้นของผู้ให้บริการผสานรวมระบบ ส่วนยุคหลังเหมือนการขยายบทบาทของวิศวกรผลิตภัณฑ์

ข้อเท็จจริงที่น่าสนใจอีกข้อหนึ่งคือ: ผู้ที่เคยเป็น FDE ของ Palantir ในช่วงแรกๆ จำนวนมากได้กลายเป็นผู้ประกอบการ หรือเข้าร่วมบริษัทโมเดลรุ่นใหม่โดยตรง ทีมงานต้นกำเนิดของ Anthropic, OpenAI, Sierra และ Hebbia ล้วนมีชื่อของอดีตพนักงาน Palantir อยู่เป็นจำนวนมาก นี่ไม่ใช่เรื่องบังเอิญ—ตำแหน่ง FDE นั้นบังคับให้บุคคลหนึ่งรับผิดชอบต่อความเสี่ยงด้านผลิตภัณฑ์ ความเสี่ยงด้านลูกค้า และความเสี่ยงด้านวิศวกรรม แทบจะเหมือนเป็นหลักสูตรฝึกอบรมผู้ประกอบการ ผู้เขียนขอมอง Palantir ว่าเป็นค่ายฝึกอบรมผู้ประกอบการที่ซ่อนเร้น: มันไม่ได้ผลิตเพียงวิศวกรเท่านั้น แต่ยังผลิตกลุ่มคนที่รู้วิธีขับเคลื่อนสิ่งใดสิ่งหนึ่งจากศูนย์เป็นหนึ่งในสภาวะข้อมูลที่ไม่สมบูรณ์ รากสองเส้นสุดท้ายก็มาบรรจบกันหลังปี 2023

การรวมตัวของสองรากหลักเกิดขึ้นส่วนใหญ่ในต่างประเทศ ในประเทศจีน คำว่า FDE ยังไม่ได้รับการใช้งานมานาน แต่เนื้องานที่มันสื่อถึงไม่ได้เกิดขึ้นมาอย่างไร้พื้นฐาน การเข้าใจ FDE ในประเทศจีน ต้องเริ่มจากการมองให้ชัดเจนถึงรากฐานสองประการในท้องถิ่นของมัน ก่อนจะพิจารณาความแตกต่างสามประการระหว่าง FDE ของจีนกับ FDE ของสหรัฐฯ

สองต้นกำเนิดท้องถิ่น

ต้นกำเนิดแรกคือสถาปนิกโซลูชันของผู้ให้บริการคลาวด์ แอร์คลาวด์ ทencent Cloud และ Huawei Cloud ได้พัฒนาทีมสถาปนิกโซลูชัน (SA) ที่สมบูรณ์แบบตลอดสิบปีที่ผ่านมา โดยทำงานกับลูกค้าเพื่ออธิบายสถาปัตยกรรม เขียน POC จัดทำแผนการย้ายระบบ และร่วมมือในการส่งมอบจนถึงการเปิดใช้งาน ในภายใน Huawei ยังมีลำดับตำแหน่ง “วิศวกรส่งมอบ” ที่รับผิดชอบเฉพาะในการดำเนินโครงการให้เสร็จสิ้นในศูนย์ข้อมูลของลูกค้า ระบบดังกล่าวได้ดำเนินงานประมาณ 80% ของงาน FDE แต่จุดเน้นยังคงอยู่ที่ระยะก่อนขายและการติดตั้ง—ความรับผิดชอบในการพัฒนาผลิตภัณฑ์แบบครบวงจรไม่อยู่ในมือของ SA หากมีการเปลี่ยนความต้องการ ต้องผ่านขั้นตอนการเปลี่ยนแปลง หากเปลี่ยนโมเดลต้องรอตารางเวลาจากสำนักงานใหญ่

ต้นกำเนิดที่สองคือตำแหน่งใหม่ที่เกิดขึ้นในบริษัทสตาร์ทอัพด้าน AI MiniMax ลงประกาศตำแหน่ง “ผู้เชี่ยวชาญด้านโซลูชันก่อนการขายด้าน AI” บน BOSS Zhipin บริษัทโมเดลต่างๆ เช่น Moonshot, Zhipu, Tongyi และ Hunyuan ก็ลงประกาศตำแหน่งคล้ายกัน ชื่อตำแหน่งอาจแตกต่างกันเล็กน้อย แต่เนื้อหา JD มีความคล้ายคลึงกันอย่างมาก: เข้าใจบริบทของลูกค้า ทำ demo ปรับ Prompt รัน RAG เขียนแผนการจัดส่ง และประสานงานกับทีมวิศวกรรมของลูกค้าจนถึงการเปิดใช้งาน ตำแหน่งเหล่านี้คือ “FDE ในประเทศ” อย่างแท้จริง

สามความแตกต่างของดินและน้ำ

การปรับใช้งานแบบเฉพาะตัวและการปฏิบัติตามกฎระเบียบข้อมูลทำให้รูปแบบการเรียกใช้โมเดลเพียงอย่างเดียวล้มเหลว ลูกค้าภาคธุรกิจในประเทศจีนมีข้อกำหนดที่สูงกว่าตลาดสหรัฐอเมริกาอย่างมากในเรื่องข้อมูลไม่ออกนอกเขต น้ำหนักของโมเดลสามารถควบคุมได้ และสามารถตรวจสอบการตรวจสอบได้ ในโครงการ FDE หน้าที่การเรียก API และรัน Prompt อาจใช้เพียงสามสิบเปอร์เซ็นต์ของงานทั้งหมด ส่วนอีกเจ็ดสิบเปอร์เซ็นต์คือการย้ายโมเดลไปยังศูนย์ข้อมูลของลูกค้า การเชื่อมต่อระบบยืนยันตัวตน การเชื่อมต่อกับแพลตฟอร์มข้อมูล และการจัดทำเอกสารการปฏิบัติตามกฎระเบียบ

ความสามารถของโมเดลยังคงตามรอย SOTA ทำให้พื้นที่ในการพัฒนาถูกบีบให้เหลือแค่ระดับวิศวกรรม บริษัทของสหรัฐฯ เช่น OpenAI และ Anthropic สามารถดึงดูดลูกค้าด้วยความสามารถของโมเดลเอง แต่ในประเทศจีน โมเดลของ Tongyi, DouBao, Kimi, GLM และ DeepSeek มีความแตกต่างกันไม่มากนัก ดังนั้นการตัดสินใจของลูกค้าจึงมุ่งเน้นไปที่ความสามารถทางวิศวกรรม เช่น การจัดเรียง Agent คุณภาพการค้นหา RAG การผสานรวมเครื่องมือ และการออกแบบ Workflow สำหรับ FDE ในประเทศจีน สิ่งที่แข่งขันกันไม่ใช่ “โมเดลของฉันเก่งแค่ไหน” แต่คือ “ฉันสามารถดำเนินธุรกิจนี้ให้สำเร็จได้จริงหรือไม่”

ความตั้งใจในการจ่ายเงินและการกำหนดราคาของฝั่ง B ไม่สอดคล้องกับสหรัฐอเมริกา รูปแบบของ Palantir ที่ “ส่ง FDE เข้าไปก่อน แล้วค่อยเรียกเก็บค่าสมัครรายเดือนในราคาสูง” ยากที่จะคัดลอกโดยตรง งบประมาณของลูกค้าในประเทศตามวงจรการจัดซื้อประจำปี และมีแนวโน้มจ่ายตามโครงการ FDE มักใช้รูปแบบธุรกิจผสมผสานระหว่างการสมัครสมาชิก การอนุญาตให้ใช้งานแบบเฉพาะตัว และการจัดส่งโครงการ

ตำแหน่งที่โดดเด่น: FDE ภายใน

ทีม AI ภายในบริษัทขนาดใหญ่หลายแห่งเริ่มใช้รูปแบบ FDE เพื่อให้บริการแก่ "ลูกค้าภายใน" อาลีคลาวด์ PAI ส่งวิศวกรไปประจำที่ Taobao ขณะที่เทนเซนต์ฮุนหยวนก็มีกลไกคล้ายกันในการเชื่อมต่อกับเว่ยซินและทีมโฆษณา บน JD ระบุตำแหน่งว่า "วิศวกรการประยุกต์ใช้งานในอุตสาหกรรม" "วิศวกรการประยุกต์ใช้ AI" และ "ผู้เชี่ยวชาญด้านธุรกิจอัจฉริยะ" ซึ่งโดย本质คือ FDE ภายใน—การนำความสามารถของทีมโมเดลไปใช้งานแบบครบวงจรบนฝั่งธุรกิจ สิ่งนี้เปิดมุมมองใหม่ให้กับผู้บริหารของบริษัทขนาดใหญ่: แค่มี FDE ภายในไม่กี่คนไปประจำอยู่บนฝั่งธุรกิจ สร้าง demo แรกให้สำเร็จ และส่งข้อมูล ROI ให้กับผู้บริหารฝั่งธุรกิจ กำแพงระหว่างแผนกจะหายไปเร็วกว่าการจัดประชุมประสานงานสิบครั้ง

ผู้เขียนได้กล่าวถึงห้าเครื่องยนต์ของบุคคลพิเศษในบทความก่อนหน้า “ถึงบุคคลพิเศษ” [4] ได้แก่ ความอยากรู้อยากเห็นสูง จิตวิญญาณในการสำรวจและนวัตกรรมสูง ความสามารถในการเรียนรู้ด้วยตนเองสูง แรงจูงใจในตัวเองสูง และทักษะในการลงมือทำสูง ห้าสิ่งเหล่านี้เป็นบัตรเข้าสู่ตำแหน่ง FDE แต่ไม่ใช่ทั้งหมด ตำแหน่ง FDE ยังต้องการคุณลักษณะเพิ่มเติมที่เฉพาะเจาะจงอีกชุดหนึ่ง และมีบุคลิกภาพบางประเภทที่ไม่เหมาะกับตำแหน่งนี้อย่างชัดเจน ผู้เขียนเคยเห็นวิศวกรที่ยอดเยี่ยมจำนวนมากเปลี่ยนมาเป็น FDE แล้วปรับตัวไม่ได้ ปัญหาส่วนใหญ่ไม่ได้อยู่ที่ความสามารถ แต่อยู่ที่บุคลิกภาพและรสนิยมในการทำงาน

คุณลักษณะห้าประการที่เหมาะกับ FDE

ไม่กลัวการขายและการสื่อสาร งานประจำวันของ FDE ไม่ใช่การปิดประตูเขียนโค้ด แต่เป็นการติดต่อโดยตรงกับ CTO ผู้บริหารธุรกิจ ผู้จัดซื้อ ผู้เชี่ยวชาญด้านการปฏิบัติตามกฎหมาย และทีม IT ของลูกค้า จังหวะทั่วไป: CTO ของลูกค้าขัดจังหวะระหว่างการสาธิต FDE ต้องไม่ตอบว่า “ฉันจะกลับไปแก้เวอร์ชันใหม่แล้วมาใหม่สัปดาห์หน้า” แต่ต้องเปิด IDE ทันที เพื่อแก้ Prompt และรันใหม่ให้ดูทันที “ลูกค้าอยู่ตรงนี้ ฉันกำลังแก้ไข” เป็นเรื่องปกติของ FDE

สนุกกับพื้นที่ที่ไม่ชัดเจน FDE ไม่ได้รับ PRD ที่ชัดเจน แต่ได้รับเพียงประโยคเดียวว่า “เราอยากใช้ AI ทำบางอย่าง” ลูกค้าเองก็ยังไม่สามารถอธิบายได้ว่าต้องการอะไร จึงต้องการให้ FDE ช่วยพัฒนาความคาดหวังที่คลุมเครือให้กลายเป็นรูปธรรม หากคุณรอจนกว่าจะมีความต้องการที่ชัดเจนถึงจะเริ่มทำงาน ทุกวัน FDE จะทำให้คุณรู้สึกกังวล

มีพื้นฐานด้านวิศวกรรมที่มั่นคง แต่ไม่จำเป็นต้องถึงระดับ 10x FDE ไม่ได้ต้องการให้คุณเป็นคนเขียนโค้ดสะอาดที่สุดหรือมีความลึกทางอัลกอริทึมที่สุดในบริษัท แต่ต้องการให้คุณสามารถทำงานแบบครบวงจรได้: ฝั่งฟรอนต์เอนด์สามารถสร้างหน้าเว็บที่คลิกได้ ฝั่งแบ็กเอนด์สามารถตั้งค่าบริการที่ทำงานได้ และโมเดลสามารถเชื่อมต่อกับแหล่งข้อมูลธุรกิจได้ ในโลกของ FDE “พอใช้ก็เพียงพอ” ไม่ใช่ข้อเสีย แต่เป็นคุณธรรม

ชอบให้ข้อเสนอแนะช่วยปรับปรุง ในงานของ FDE มีช่วงเวลาจำนวนมากที่ต้องถูกลูกค้าตำหนิและให้กลับไปทำใหม่: demo วันนี้ พรุ่งนี้ฝ่ายธุรกิจบอกว่า “นี่ไม่ใช่สิ่งที่ฉันต้องการ”; แผนที่เคยตกลงกันเมื่อสัปดาห์ที่แล้ว สัปดาห์นี้ลูกค้าเปลี่ยนผู้บริหารและต้องทำใหม่ทั้งหมด คนที่เหมาะกับงาน FDE จะมองข้อเสนอแนะเหล่านี้เป็นเชื้อเพลิง รับผิดชอบเต็มขั้นตอนจากต้นจนจบ และไม่โยนความผิดให้กับ “ฝ่ายขอความต้องการพูดไม่ชัด”

ไวต่อขอบเขตของโมเดล นี่คือข้อที่มีความเทคนิคสูงที่สุดและซ่อนเร้นที่สุด FDE ต้องสามารถตัดสินได้ว่าภารกิจใดเหมาะกับ LLM และภารกิจใดไม่เหมาะ รวมถึงควรใช้กลยุทธ์สำรองอย่างไร—ความไวต่อขอบเขตแบบนี้ไม่สามารถเรียนรู้ได้จากบทความวิจัย แต่ต้องเกิดจากการล้มเหลวซ้ำๆ เมื่อตัวอย่างการล้มเหลวสะสมเพียงพอ FDE จะพัฒนาความจำเชิงกล้ามเนื้อเกี่ยวกับขอบเขตของโมเดล: สถานการณ์ใดควรใช้ RAG สถานการณ์ใดควรใช้กฎ และสถานการณ์ใดต้องมีช่องทางสำรองให้ผู้ใช้เป็นมนุษย์

ผู้ที่ไม่เหมาะสำหรับ FDE

ผู้ที่ชอบซ่อนตัวอยู่ในโค้ด ฟีดีใช้เวลาประมาณ 50% ไปกับการประชุมลูกค้า การประสานงานภายใน การอภิปรายผลิตภัณฑ์ และการผลักดันสัญญา ไม่ใช่การเขียนโค้ด หากความสุขของคุณมาจากการเขียนโค้ดโดยไม่มีใครรบกวนต่อเนื่องสี่ชั่วโมง ฟีดีจะทำให้คุณเผชิญกับภาวะหมดไฟในระยะยาว

คนที่ต้องมี OKR ถึงจะเคลื่อนไหวได้ เป้าหมายของ FDE อยู่ที่ลูกค้า ไม่ได้อยู่บนตารางผลการปฏิบัติงานของคุณ ความคืบหน้าในการทำงานถูกกำหนดโดยจุดสำคัญของโครงการลูกค้า การเปลี่ยนแปลงของความสามารถของโมเดล และการตัดสินใจของคุณเกี่ยวกับบริบท ผู้ที่เคยชินกับการ “ต้องมี OKR ก่อนถึงจะรู้ว่าต้องทำอะไร” จะไม่สามารถหาจุดยึดได้

ผู้ที่ให้ความสำคัญกับการเลื่อนตำแหน่งมากกว่าผลงาน FDE ไม่ได้ได้เปรียบในระบบการเลื่อนตำแหน่งของบริษัทใหญ่ — ตัวชี้วัดเช่น ความพึงพอใจของลูกค้า การได้รับคำสั่งซื้อโครงการ และอัตราการนำกลับมาใช้ใหม่ ไม่มีน้ำหนักเท่ากับจำนวนโค้ดหรือความถี่ในการเปิดใช้งานในการประเมินระดับตำแหน่ง หากแรงจูงใจหลักของคุณคือการเลื่อนตำแหน่ง FDE ไม่ใช่ตัวเลือกที่ดี

ผู้ที่ต่อต้านบริบททางธุรกิจ FDE ต้องเข้าใจ P&L ของลูกค้า ROI กระบวนการจัดซื้อ และข้อกำหนดด้านการปฏิบัติตามกฎหมาย หากคุณรู้สึกไม่ชอบการพูดถึงเงิน ข้อตกลง หรือตรรกะทางธุรกิจอยู่แล้ว งานของ FDE จะทำให้คุณรู้สึกเหมือนกำลังขายอุดมการณ์ทางเทคโนโลยีของตัวเอง

รายการตรวจสอบตนเอง

คำถาม 7 ข้อ แต่ละข้อสอดคล้องกับสถานการณ์การทำงานจริงของ FDE ถ้าตอบ “ใช่” มากกว่า 5 ข้อ สามารถพิจารณา FDE อย่างจริงจัง หากตอบ “ใช่” น้อยกว่า 3 ข้อ แนะนำให้พิจารณาอย่างรอบคอบ

คุณยินดีที่จะย้ายเวลา 50% ของแต่ละวันจากโค้ดไปยังการประชุมลูกค้า การตอบข้อความ และการโทรหรือไม่?

2. เมื่อลูกค้าบอกคุณว่า “อันนี้ใช้ไม่ได้ แต่ฉันก็อธิบายไม่ถูกว่าทำไม” ปฏิกิริยาแรกของคุณคือความอยากรู้อยากเห็น หรือความหงุดหงิด?

3. ไม่มีใครเขียน PRD ให้คุณ คุณสามารถทำงานร่วมกับ Claude Code เพื่อสร้างต้นแบบที่สามารถแสดงให้ลูกค้าดูได้ภายในหนึ่งสัปดาห์ไหม?

4. สำหรับงานส่งมอบเดียวกัน ลูกค้าให้คุณแก้ไข 8 เวอร์ชัน คุณยังสามารถรักษาความสามารถในการตัดสินใจของคุณ แทนที่จะดำเนินการตามคำสั่งอย่างเครื่องจักร?

5. เมื่อโมเดลให้คำตอบผิด ปฏิกิริยาแรกของคุณคือการออกแบบระบบสำรอง หรือบ่นว่าโมเดลไม่ดี?

6. คุณยินดีลงนามในสัญญา เขียนรายงาน ดำเนินการรับรองจากลูกค้า และปรึกษากับฝ่ายกฎหมายเกี่ยวกับข้อกำหนดการปฏิบัติตามกฎหมายไหม?

7. คุณสามารถยอมรับการสร้างต้นแบบอย่างรวดเร็วและการล้มเหลวอย่างรวดเร็วได้ไหม?

คุณสมบัติห้าประการ ภาพจำลองย้อนกลับสี่ประเภท และคำถามทดสอบตนเองเจ็ดข้อ สุดท้ายแล้วล้วนชี้ไปที่คำถามเดียวกัน: คุณยินดีที่จะให้ความรู้สึกเชิงผลิตภัณฑ์ ความสามารถด้านวิศวกรรม และการตัดสินใจทางธุรกิจของคุณถูกพัฒนาพร้อมกันในกระบวนการทำงานเดียวกันหรือไม่

บทความก่อนหน้านี้ผู้เขียนได้พูดถึง “เครื่องยนต์ของมนุษย์”: ความอยากรู้อยากเห็น จิตวิญญาณของการค้นคว้า ความสามารถในการเรียนรู้ด้วยตนเอง แรงจูงใจภายใน และทักษะการลงมือทำ ว่าจะกระตุ้นให้เกิดวงจรปิดอย่างสมบูรณ์ภายในบริษัทขนาดใหญ่ได้อย่างไร บทความนี้จะพูดถึงอีกเรื่องหนึ่ง—รูปแบบของตำแหน่งงาน FDE เป็นรูปแบบตำแหน่งงานใหม่แรกที่มีชื่อ มีช่วงเงินเดือน มีคำอธิบายตำแหน่งในการรับสมัคร และมีการยืนยันจากลูกค้าที่จ่ายเงินในยุคปฏิวัติอินทรีย์ปัญญาประดิษฐ์ มันไม่ใช่คำพ้องความหมายของแนวคิด “บุคคลเหนือชั้น” แต่เป็นจุดอ้างอิงแรกที่เปลี่ยนจากสิ่งที่เป็นนามธรรมไปสู่ความเป็นจริงในคลื่นการเปลี่ยนแปลงครั้งนี้

FDE ไม่ใช่จุดสิ้นสุด ผู้เขียนเชื่อว่า FDE เป็นรูปแบบแรกที่ได้รับชื่อในโครงสร้างการแบ่งงานใหม่ ต่อไปจะมี Forward Deployed PM, Forward Deployed Designer, Forward Deployed Researcher—งานทั้งหมดที่เชื่อมโยงอย่างใกล้ชิดกับบริบทของลูกค้าและต้องสร้างผลิตภัณฑ์ขึ้นในพื้นที่ที่ไม่ชัดเจน จะมีเวอร์ชัน “การติดตั้งล่วงหน้า” ของตนเอง ชื่อตำแหน่งอาจเปลี่ยนไป แต่ตรรกะพื้นฐานยังเหมือนเดิม: ความสามารถของโมเดลวิ่งนำหน้า รูปแบบผลิตภัณฑ์ตามทัน และโครงสร้างตำแหน่งถูกแบ่งใหม่ตามกระบวนการทำงาน

ให้แต่ละกลุ่มผู้อ่านสามกลุ่มหนึ่งประโยค

สำหรับนักเทคนิค: FDE ไม่ได้ต้องการให้คุณเป็นคนเขียนโค้ดเก่งที่สุดในบริษัท แต่ต้องการให้คุณยินดีถ่ายโอนเวลาครึ่งหนึ่งจากโค้ดไปยังลูกค้า หากคำตอบของคุณคือ “ยินดี” ช่องตลาดเพิ่งเปิดขึ้น การรับสมัครจากบริษัทโมเดลชั้นนำในประเทศ ผู้ให้บริการคลาวด์ และทีม AI ภายในบริษัทใหญ่กำลังเร่งขึ้น หากคำตอบคือ “ไม่ยินดี” ก็ไม่มีปัญหาอะไร เพราะในโครงสร้างงานใหม่จะมีตำแหน่งอื่นๆ ที่เหมาะกับคุณเกิดขึ้นอีก

สำหรับฝ่ายทรัพยากรบุคคลและพัฒนาองค์กร: ระวัง “ความไม่สอดคล้องระหว่างชื่อและหน้าที่” บริษัทของคุณอาจมี FDE อยู่แล้วจำนวนมาก แต่ถูกจัดรหัสตำแหน่งว่า “ผู้เชี่ยวชาญด้านโซลูชัน” “สถาปนิกอุตสาหกรรม” หรือ “วิศวกรแอปพลิเคชัน AI” ให้ระบุพวกเขา จัดหมวดหมู่ใหม่ และสร้างเส้นทางการเติบโตที่สอดคล้องกับเนื้องานของพวกเขา ซึ่งมีประสิทธิภาพมากกว่าการรับพนักงานใหม่จากศูนย์

สำหรับผู้จัดการ: โหมด FDE ไม่ได้ใช้ได้แค่ภายนอก แต่ยังสามารถใช้ภายในได้เช่นกัน การตั้งจุด FDE ภายในบริษัทบางจุดเพื่ออยู่ร่วมกับทีมธุรกิจ และนำความสามารถของทีมโมเดลไปใช้งานแบบครบวงจรในกระบวนการธุรกิจ อาจมีประสิทธิภาพมากกว่าการสร้างแผนก AI ใหม่และจัดการประชุมประสานงานข้ามทีมอีกสิบครั้ง กำแพงแผนกไม่ได้ถูกลบเลือนโดยการออกแบบองค์กร แต่ถูกลบเลือนโดยการสาธิตที่ทำงานได้จริง

การเปลี่ยนแปลงอาชีพในยุคปัญญาประดิษฐ์ได้เริ่มต้นขึ้นแล้ว FDE เป็นสัญญาณแรกที่บอกเราว่า ความเร็วในการเปลี่ยนแปลงของความสามารถของโมเดลเร็วจนกระทั่งต้องสร้างตำแหน่งงานใหม่ขึ้นมา ผู้เขียนอยากให้ผู้อ่านคิดถึงคำถามที่ชัดเจนหนึ่งข้อ—ถ้าสามปีข้างหน้า แผนผังโครงสร้างองค์กรของบริษัทคุณมีตำแหน่งใหม่เพิ่มขึ้นสามตำแหน่ง คุณเดาได้ไหมว่าจะเป็นตำแหน่งอะไรสามตำแหน่ง? การคิดให้ชัดเจนเกี่ยวกับคำถามนี้ มีประโยชน์มากกว่าการอ่านบทความนี้จบ

👦🏻 ผู้เขียน: เฮนรี (ทีม DeerFlow) [1]