วิศวกรรมในยุค LLM

• บทความสรุปการขบคิดตลอด 1 ปีครึ่งที่ Reindeer ว่าจะสร้างผลิตภัณฑ์และองค์กรพัฒนาอย่างไรในยุค LLM โดยทุกข้อสังเกตเริ่มต้นจากการตระหนักว่า human context คือทรัพยากรที่หายากที่สุด
• ปริมาณการผลิตคอนเทนต์เพิ่มขึ้นแบบระเบิด แต่ความเร็วในการบริโภคของมนุษย์ยังเท่าเดิม และช่องว่างนี้กลายเป็นคอขวดใหม่ — ต้องหยุดวงจรอุบาทว์ที่ slop feeds slop
• การตัดสินใจเชิงโครงสร้าง อย่างการทำ modeling และการออกแบบ API ยังเป็นพื้นที่ของมนุษย์ และต้องมีคนที่กล้าพูดว่า "no" กับผลลัพธ์ที่ LLM สร้างขึ้น
• เอาชนะ LLM ด้วย code review อย่างเดียวไม่ได้ จึงต้องสร้างชั้นป้องกันแบบอัตโนมัติและอิงวินัย เช่น linters, LLM judges, PR ขนาดเล็ก
• ทักษะหลักของนักพัฒนาไม่ใช่ความรู้เชิงเทคนิคลึก ๆ แต่คือ การสลับ context และขนาด context window ของตัวเอง ผู้ที่ปรับตัวได้จะกลายเป็นคนที่มีผลิตภาพสูงมาก ส่วนผู้ที่ปรับตัวไม่ได้จะกลายเป็น net negative ต่อทีม

---

Human context คือทรัพยากรที่หายาก

• ความจริงที่ไม่เปลี่ยนตลอด 25 ปีในอุตสาหกรรม — ทรัพยากรที่แพงที่สุดคือ human context และมนุษย์เองก็มี context window และ attention mask ที่จำกัดเหมือน LLM
• สิ่งที่เปลี่ยนไปตอนนี้คือ LLM slop กำลังทะลักมาจากทุกทิศ — อัตราส่วน ระหว่างความเร็วในการผลิตกับความเร็วในการบริโภคของมนุษย์กลายเป็นคอขวดใหม่
• ปัญหาคือ slop feeds slop
  • คอมเมนต์โค้ดที่ LLM พองให้ยาวเกินจริง, คำอธิบาย PR ที่เยิ่นเย้อ, เอกสารที่เล่าประวัติแทนที่จะสรุปผลลัพธ์
  • LLM ตัวถัดไปอ่านสิ่งเหล่านี้ แล้ว context ก็เต็มไปด้วย noise ก่อนจะทำแบบเดิมต่อไป
• คอนเทนต์ข้อความภายในองค์กรควร กระชับแบบบีบอัด และมีเฉพาะสิ่งที่ไม่ชัดเจนอยู่แล้วจากโค้ดและพฤติกรรมของมัน

พื้นที่ที่แทนมนุษย์ไม่ได้

• Modeling เป็นงานของมนุษย์
  • งานอย่างการแปลง CUJ (Critical User Journey) ให้เป็น flow ของ API และตัดสินใจว่าอะไรคือ component แต่ละตัว แต่ละส่วนมี concern อะไร และเส้นแบ่งอยู่ตรงไหน
  • เพราะ LLM เขียนโค้ดออกมาได้เร็ว modeling ที่แย่ก็แพร่กระจายได้เร็ว เช่นกัน และสร้าง dependency ที่บิดเบี้ยวซึ่งแก้ทีหลังไม่ได้
  • ยิ่งต้นทุนการลงมือทำถูกลงเท่าไร สัดส่วนของ การตัดสินใจเชิงโครงสร้างโดยมนุษย์ ในมูลค่าปลายทางก็ยิ่งสูงขึ้น
  • Modeling คือความจริงขององค์กรจริง ๆ และต้องมีชีวิตอยู่ในที่ที่ทุกคนเข้าถึงได้
• การนิยาม API ต้องมีวินัยแบบมนุษย์ที่เข้มงวด
  • LLM มีแนวโน้มจะเพิ่ม field ที่สะดวกกับ task เฉพาะหน้าตลอด และแต่ละ field แบบนั้นจะทำให้ API สกปรกอย่างถาวร
  • API คือ public contract ไม่ใช่ scratch pad — ต้องมีมนุษย์ที่พูดว่า "no" ได้

การป้องกัน slop ในระดับใหญ่

• เอาชนะ LLM ด้วย human code review ไม่ได้ — มันขยายไม่ออก และสุดท้ายจะลงเอยด้วยสภาพที่ ทุกคนหลับตา approve
• Reindeer จึงมุ่งไปสู่ ชั้นบังคับใช้อัตโนมัติ
  • Linters: กฎตรรกะแบบเด็ดขาด เช่น dependency ที่ห้ามมีระหว่าง service หรือขอบเขตทางสถาปัตยกรรม
  • LLM judges: สิ่งที่เขียนเป็นโค้ดยาก แต่ให้โมเดลตรวจได้ เช่น implicit contract
• แต่เมื่อมีการแตะ API หรือเกิดการเปลี่ยนแปลงด้าน modeling ต้องมี human review จริง เสมอ
• กฎระดับชีวิตประจำวันคือ "อย่าโยน slop ให้กันและกัน"
  • PR เล็ก ๆ และถ้าจำเป็นก็ใช้ stacked PR
  • ต้องต้านทั้งความยั่วยวนที่จะโยน PR แบบ slop ยาว 2,000 บรรทัด และความเป็นไปได้ที่ reviewer จะหลับตา approve
  • PR คือ หน่วยพื้นฐานของความสนใจ (attention) — ถ้าเกิน context window ของคน มันอาจได้ approve แต่จะไม่ถูกอ่าน

Padded rooms — พื้นที่สำหรับปล่อย LLM ให้ทำงานอิสระ

• เมื่อมีโครงสร้างข้างต้น ก็จะระบุพื้นที่ที่ LLM วิ่งได้อย่างอิสระ หรือ "padded rooms" ได้
  • เป็นพื้นที่ที่ไม่กระทบ modeling และไม่มี dependency ระยะยาว
  • ต่อให้เกิด slop ก็แทนที่ได้ง่าย และไม่แพร่ไปทั้ง codebase
  • อาจเป็นโค้ดส่วนใหญ่ของบริษัท แต่ไม่ใช่ส่วนที่ load bearing
• นี่คือ คำตอบของการทำ customer customization ด้วย
  • การ customize ต้องอยู่ใน padded rooms 100%
  • ทันทีที่มันรั่วเข้าสู่แกนหลัก core ก็จะเริ่มแตกร้าว และเกิดความเสี่ยงใหม่ทุกครั้งที่มีลูกค้าใหม่
  • padded rooms คือโครงสร้างพื้นฐานที่ทำให้ตอบลูกค้าได้เร็วว่า "yes" โดยไม่ต้องจ่ายราคาในเชิงสถาปัตยกรรม

การกลับด้านทางเศรษฐศาสตร์ของ technical debt

• การแยกระหว่างพื้นที่รับน้ำหนักกับ padded rooms เปลี่ยน ความสัมพันธ์กับ technical debt ไปด้วย
• อดีต: ถ้าระหว่างพัฒนาพบปัญหา modeling ก็มักเลื่อนไปให้ตัวเองในอนาคต เพราะต้นทุนการเขียนใหม่สูง จึงยอมกลืนหนี้ระหว่างงานใหญ่
• ปัจจุบัน: ต้นทุนการเขียนใหม่เกือบเข้าใกล้ศูนย์
  • การลงทุนที่แท้จริงไม่ใช่การพิมพ์ แต่คือ modeling
  • ทิ้งของเดิม แก้ modeling แล้วเขียนใหม่ เป็นเรื่องราคาถูก
  • แต่การผัดวันกลับแพงมาก — LLM ทุกตัวที่ต้องผ่านโค้ดผิด ๆ จะนำมันไปใช้ต่อ, slop feeds slop, และความผิดพลาดด้าน modeling ที่ไม่รีบแก้จะกลายเป็นหนี้ที่ซับซ้อนขึ้นหลายเท่าในเวลาไม่นาน

PM ในยุคนี้

• บทบาทของ PM เปลี่ยนไป — ต้อง ทำงานใกล้ชิดกับผู้ทำ modeling เพื่อให้แน่ใจว่า CUJ จะไม่เสียหายระหว่างถูกแปลงเป็น API และ component
• ถ้า PM กับ modeler ไม่ sync กัน
  • ก็จะได้ผลิตภัณฑ์ที่ technically ใช้งานได้แต่ไม่ตอบโจทย์ CUJ หรือ
  • ได้ CUJ ที่สวยงามแต่สร้างจริงอย่างสมเหตุสมผลไม่ได้
• ที่ Reindeer, PM จะ สร้าง MVP ด้วยตัวเองใน repo แยก
  • โดยมีสมมติฐานว่าโค้ดนี้จะไม่มีวันแตะ production
  • ทำให้เคลื่อนไหวเร็วกับ LLM และมีอิสระพอจะโชว์ลูกค้าได้
  • สิ่งที่จะสำเร็จจริงหรือได้เจอลูกค้าจริง ต้องผ่านกระบวนการ modeling/พัฒนาอย่างเป็นทางการ
  • จึงตั้งเดโมและตรวจสอบกับลูกค้าได้รวดเร็วก่อนลงทุนกับ core — เป็นสมดุลระหว่าง ความเร็วในการทดสอบไอเดีย กับ ความเข้มงวดระดับศัลยกรรมต่อสิ่งที่จะเข้าไปอยู่ในผลิตภัณฑ์

โครงสร้างพื้นฐานที่ทำให้หลุดพ้นจาก loop

• ความต่างระหว่างการคอยจับมือ agent ทีละขั้น กับการปล่อยให้มันทำหลาย task แบบขนานแล้วเราไปนอน คือการมี reward function ที่ดี
  • ถ้าไม่มี LLM จะออกเดินทางแบบกลับไม่ถึงบ้าน
  • ถ้ามี มันจะประเมินเองได้ว่าเมื่อไรเข้าใกล้เป้าหมายและเมื่อไรออกห่าง
• ในงานพัฒนา reward function ที่ดีแปลออกมาเป็น การทดสอบที่ดี
  • รวมถึง E2E tests สำหรับแพลตฟอร์ม
  • ช่วยดึง LLM ออกจาก นิสัยแย่ ๆ ที่พึ่งพา mock ซึ่งไม่ได้ทดสอบอะไรจริง
  • มี Evals สำหรับผลลัพธ์ที่สร้างด้วย LLM
  • มี LLM judges ที่ใช้ context สะอาด ทำ loop การรีวิวอัตโนมัติ — เพื่อไม่ให้ judge ตกอยู่ในอาการหลอนแบบเดียวกับ agent ที่เขียนโค้ด
• ในระดับองค์กร โครงสร้างพื้นฐานนี้ต้อง แชร์ร่วมกัน
  • Reindeer มี repo ส่วนกลางสำหรับ skill marketplace ที่แยกเป็นหมวดหมู่และรวมสกิลภายในทั้งหมด
  • รองรับอัตโนมัติในทุก harness ทั้ง Claude Code, Codex และรองรับ pi.dev สำหรับคนที่ unhinged ลึกระดับเจ้าตัว
  • นักพัฒนาใหม่จะได้สกิลทั้งหมดขององค์กรทันที (รวมถึงสกิลสำหรับ onboarding และ setup)

นักพัฒนาแห่งอนาคต

• ความสามารถชี้ขาดของนักพัฒนาในยุคนี้ไม่ใช่ ความรู้เชิงลึก แต่คือ การสลับ context และขนาด context window/attention mask ของตัวเอง
  • คนที่รักษา context ขนาดใหญ่ไว้ได้ ไม่เสียโฟกัสขณะสลับ task และจัดการหลาย agent แบบขนานได้ จะเป็นผู้ชนะ
  • ความลึกทางเทคนิคเฉพาะทางสำคัญน้อยลง เพราะ LLM เติมเต็มให้ได้
• ความสามารถเสริมคือ ทักษะ modeling, ความเข้าใจที่ดีต่อ system architecture และสัญชาตญาณว่าควรระวังอะไรในขั้นออกแบบ
• เหตุผลที่โลกใหม่จะแบ่งนักพัฒนาออกเป็นสองกลุ่ม
  • คนที่ปรับตัวได้จะกลายเป็น super-productive
  • คนที่ปรับตัวไม่ได้จะไม่ใช่แค่กลาง ๆ แต่จะเป็น net negative ต่อทีม
  • LLM คือ multiplier — สำหรับคนที่ใช้เป็น มันคูณผลิตภาพ; สำหรับคนที่ใช้ไม่เป็น มันเร่งความเสียหาย
  • ในด้านผลตอบแทน เงินเดือนของนักพัฒนากลุ่มที่สองจะกลายเป็น 0 — เพราะจะไม่มีงานให้ทำ
• แม้จะทำงานได้มากขึ้นมากด้วยคนน้อยลงมาก แต่ การเติบโตจะยากมาก และต้องเลือกคนอย่างเข้มงวด

เรื่องต้นทุนโทเค็น

• คำถามที่ถูกถามซ้ำ ๆ: ถ้าต้นทุนโทเค็นพุ่งขึ้น 5–10 เท่าจะเกิดอะไรขึ้น
• เมื่อเวลาผ่านไป ความกังวลนี้ดูไม่สมจริง
  • AI มี กฎของมัวร์แบบเร่งความเร็ว และคุณภาพต่อดอลลาร์ยังเพิ่มขึ้นเรื่อย ๆ
  • มี open models มากพอจนไม่สามารถตั้ง cartel ได้
• เหตุผลที่โทเค็นยังถูก — ถ้า Claudex แพงขึ้นอย่างไร้เหตุผล ทุกคนก็จะย้ายไปใช้ Qwen บน neocloud ใดสักแห่งทันที