กฎภาวะผู้นำด้านวิศวกรรมที่ปรับปรุงใหม่

• สรุปกฎภาวะผู้นำด้านวิศวกรรม 5 ข้อที่นิยามใหม่หลังผ่านการพิสูจน์ในช่วงปีที่ผ่านมา ท่ามกลางสภาพแวดล้อมของ การเปลี่ยนผ่านสู่เครื่องมือ AI และการเติบโตอย่างรวดเร็ว (hypergrowth) พร้อม กรณีโครงการจริง ที่รองรับ
• ปัจจุบัน migration ไม่ได้ขับเคลื่อนโดยทีม แต่โดยบุคคลถึง 95% และทำเสร็จได้ในเวลาเพียง 10% เมื่อเทียบกับเดิม ยิ่งต้นทุนเริ่มต้นต่ำลง อิทธิพลของวิจารณญาณรายบุคคล ก็ยิ่งมากขึ้น
• โค้ดรอบแรกแทบจะฟรี แต่ต้นทุนของโค้ดที่ทำงานได้ดีขึ้นอยู่กับ development harness เช่น testing, CI/CD จึงไม่ใช่ของฟรี
• กรณีพื้นฐานของกระบวนการส่วนใหญ่สามารถ ทำให้เป็นอัตโนมัติเต็มรูปแบบด้วย agent ได้ และ first pass ของ code review ก็เร็วและมีประสิทธิภาพกว่ามนุษย์หากมี harness ที่ดี
• หากต้องการได้รับประโยชน์จาก AI จริง ๆ ต้องมี ทีมถาวรที่มี domain context และ การตัดสินใจที่รวดเร็วและหนักแน่น เป็นเงื่อนไขตั้งต้น

---

ภูมิหลัง

• ทำงานในสภาพแวดล้อม hypergrowth ตั้งแต่ต้นปี 2014 ถึงปลายปี 2020 คุณค่าที่ใหญ่ที่สุดของ hypergrowth คือ ความผิดพลาดจะปรากฏให้เห็นในเดือนถัดไป ไม่ใช่ปีถัดไป (ถ้าเคลื่อนที่เร็ว ปัญหาจะปะทุใหญ่)
• เหตุผลที่ช่วงหลังกลับมานึกถึง hypergrowth อีกครั้งคือการเติบโตทางธุรกิจที่รวดเร็วของ Imprint, การจ้างงานครั้งใหญ่เมื่อปีที่แล้ว และ การเปลี่ยนผ่านสู่เครื่องมือ AI ที่ทำให้ความเร็วในการทำงานเปลี่ยนไป
• บทความนี้สรุปทั้งกฎภาวะผู้นำที่นิยามใหม่ และโครงการรูปธรรมในช่วงปีที่ผ่านมาที่ทำให้เกิดความเชื่อเหล่านี้

กฎที่ปรับปรุงใหม่

1. Migration สามารถทำโดยบุคคล ไม่ใช่ทีม

• แม้เป็นการเปลี่ยนแปลงขนาดใหญ่และซับซ้อน บุคคลหรือทีมที่นำงานก็สามารถเป็นเจ้าของ 95% และทำเสร็จในเวลา 10% เมื่อเทียบกับเดิม
• ยิ่งต้นทุนเริ่มต้นต่ำลง รางวัล/บทลงโทษ ต่อคุณภาพของ migration แต่ละครั้งก็ยิ่งใหญ่ขึ้น
  • ข้อบกพร่องเล็ก ๆ ก็สามารถทำลาย mental model ของซอฟต์แวร์ที่เพื่อนร่วมงานต้องดูแลร่วมกันได้
• อิทธิพลของวิจารณญาณรายบุคคล ต่อบริษัทสูงกว่าที่เคยเป็นมา

2. โค้ดรอบแรกแทบจะฟรี แต่ต้นทุนของโค้ดที่ทำงานได้ขึ้นอยู่กับ development harness

• นี่เป็นยุคที่ทุกคนควรเขียนโค้ด แต่การ เขียนโค้ดที่ทำงานได้ดี โดยหลีกเลี่ยง edge case ที่ยุ่งเหยิงยังคงยากอยู่
• ความยากนั้นถูกกำหนดโดย development harness เช่น testing, CI/CD, สภาพแวดล้อมสำหรับ validation และ preview ของการเปลี่ยนแปลง
• แม้ในบริษัทที่ “ทุกคนเขียนโค้ด” ประเด็นสำคัญไม่ใช่การให้ทีม marketing ไปลดการจัดสรรเซิร์ฟเวอร์ แต่คือการมี ขอบเขต ที่ทำให้พวกเขามีส่วนร่วมได้อย่างปลอดภัยหรือไม่ (คล้ายผลิตภัณฑ์ SaaS ที่อนุญาตให้ customize ผ่านการเขียนซอฟต์แวร์)
• สิ่งที่มีคุณค่ามากที่สุดต่อการเพิ่มความเร็วของวิศวกรรมเมื่อ 2 ปีก่อน ยังคงเป็นสิ่งที่มีคุณค่ามากที่สุดในวันนี้

3. ปรับกรณีพื้นฐานของกระบวนการให้เหมาะกับ agent

• หากมี harness, การควบคุม, domain context ที่เหมาะสม และวิจารณญาณที่ดีของผู้ออกแบบ ก็สามารถ ทำให้กรณีพื้นฐานของกระบวนการส่วนใหญ่เป็นอัตโนมัติเต็มรูปแบบ ได้
• กรณีพื้นฐานของ code review โดยมนุษย์ช้ากว่าและมีประสิทธิภาพน้อยกว่า code review โดย harness ที่ดี
  • Harness ก็พลาดได้ แต่มนุษย์ก็พลาดเช่นกัน และในพื้นที่ส่วนใหญ่ การเปลี่ยนแปลงค่อนข้างปลอดภัย
  • อย่างไรก็ตาม พื้นที่เสี่ยงสูงบางส่วนเป็นข้อยกเว้น หากแยกความแตกต่างนี้ได้ถูกต้องก็จะเร็วขึ้นโดยไม่เพิ่มความเสี่ยง แต่ถ้าพลาดจะเกิดปัญหานับไม่ถ้วน
• ผลตามมาคือ กระบวนการวางแผนอย่าง sprint รายสัปดาห์หรือรายสองสัปดาห์กำลังทำงานอยู่ที่ ระดับความสูงต่ำเกินไป และการวางแผนร่วมกันของมนุษย์ควรเกิดขึ้นในระดับที่สูงกว่า

4. ทีมถาวรที่มี domain context และ ownership สูง สำคัญยิ่งขึ้น

• บทเรียนจาก Uber: ทีมที่ต่อเนื่องและแข็งแกร่ง สร้างผลลัพธ์เหมือนเวทมนตร์ได้ผ่านการสะสม domain context, การสร้างความเป็นเพื่อนร่วมทีม และความรู้สึกเป็นเจ้าของที่เข้มข้น
• แม้ในยุคที่ต้นทุนการลงมือทำถูกลง ก็ยังต้องทำ สิ่งที่ถูกต้อง และเรื่องนี้เพียงแค่ง่ายขึ้นเล็กน้อย ไม่ได้ง่ายขึ้นมาก
  • ตัวอย่าง: ข้อมูลที่จำเป็นต่อการ optimize production ไม่ได้ถูกเก็บไว้เลย ทำให้วิธีแก้ของ harness ดูสมเหตุสมผลแต่ผิด และทางออกเดียวคือการ instrument ข้อมูลที่ขาดหายไป
• ผู้เขียนไม่เห็นด้วยกับความเชื่อทั่วไปว่าบริษัทที่ให้ AI มาก่อนจะดำเนินงานด้วยวิศวกรอัจฉริยะจำนวนน้อย เพราะแม้บุคคลที่มีวิจารณญาณสูงก็จะชนข้อจำกัดจาก การขาด domain context ดังนั้นทีมถาวรจึงเป็นหน่วยพื้นฐาน

5. การตัดสินใจที่รวดเร็ว ดี และหนักแน่นคือเงื่อนไขตั้งต้นของการได้ประโยชน์จาก AI

• หากต้องการแทนที่ legal review ด้วย automation ฝ่าย Legal ต้องสามารถ commit ต่อการเปลี่ยนแปลงนั้นได้ ซึ่งขึ้นอยู่กับการออกแบบอย่างรอบคอบและความพร้อมของทีมในการร่วมมือกัน
• ประโยชน์จากความเร็วในการดำเนินงานที่เพิ่มขึ้นจะเป็นไปได้ก็ต่อเมื่อสามารถตัดสินใจได้ รวดเร็ว หนักแน่น และดี
• นี่คือเหตุผลหลักที่บทบาท CTO โดยเฉลี่ยเปลี่ยนเป็น เชิงเทคนิคมากขึ้นและเป็นราชการน้อยลง อย่างมากเมื่อเทียบกับหนึ่งปีก่อน
  • เมื่อทีมต่าง ๆ เห็นไม่ตรงกัน CTO มักเป็นคนเดียวที่สามารถตัดสินใจแบบมีผลผูกพันได้ จึงต้องตัดสินใจอย่างต่อเนื่องเพื่อรักษาความเร็ว
  • ไม่ได้อ้างว่า executive เป็นผู้ตัดสินใจที่ดีกว่า แต่ตราบใดที่ผู้บริหาร aligned กันและเคารพการตัดสินใจ การตัดสินใจของผู้บริหารที่มีผลผูกพัน ก็ทรงพลังอย่างไม่มีใครเทียบ

กรณีการนำไปใช้จริง

Migration

• เมื่อหนึ่งปีก่อน deploy แบบ manual ประมาณสัปดาห์ละ ~6 ครั้ง → ปัจจุบัน deploy 200–400 ครั้งต่อสัปดาห์ แม้จำนวนวิศวกรเพิ่มขึ้น 2 เท่า แต่เพิ่มขึ้น 20–30 เท่า YoY การปรับเปลี่ยนวิธีดำเนินงาน deploy และ migration ทั้งหมดทำโดยสมาชิกทีม infra 2 คนเป็นสัดส่วน 90% ตลอดสองเดือน
• 1 มกราคม มีประมาณ ~25% ใช้ Claude Code หรือ Cursor ทุกวัน → ปลายกุมภาพันธ์เป็น 100% โดยไม่มีคำสั่งจากบนลงล่าง แต่ลดแรงเสียดทานด้วยการปรับปรุงคุณภาพเครื่องมือและพูดคุยกับผู้ที่ยังไม่ adopt ปัจจุบัน first draft ของ PR แทบทั้งหมดทำโดย harness
• รวมวิธีตั้งค่าที่หลากหลายให้เหลือ กลไก configuration สองแบบ (สำหรับค่าคงที่ฝั่ง client/server ที่แทบไม่เปลี่ยน และสำหรับค่าตามผลิตภัณฑ์ที่เปลี่ยนบ่อย) โดยดำเนินเป็นโปรเจกต์อิสระของวิศวกรแต่ละคน
  • คนหนึ่งจัดระเบียบสถาปัตยกรรม → อีกคน implement reference architecture → หลายคนนำไปใช้กับพื้นที่อื่น ในอดีตนี่จะเป็นโปรเจกต์หลายปี แต่เสร็จในน้อยกว่าหนึ่งไตรมาส รวมถึง internal tool สำหรับให้ทีมวิศวกรและไม่ใช่วิศวกรจัดการค่าได้
• รวม frontend แบบ multi-repo เป็น สถาปัตยกรรม monorepo ในเวลาประมาณหนึ่งเดือน โดย 95% นำโดย frontend engineer 1 คน ได้ shared frontend harness และหลุดพ้นจากการ host npm package ซึ่งเคยเป็นแหล่งของ friction อย่างสิ้นเชิง
• ทำให้โค้ด frontend ที่เดิมส่วนใหญ่ไม่มี type กลายเป็น static typing เต็มรูปแบบ โดยวิศวกรหนึ่งคนใช้ token จำนวนมากตลอดหลายสัปดาห์
• เพื่อ default ด้านความปลอดภัยที่ดีขึ้นและการ deploy ที่เร็วขึ้น จึง ย้ายจาก npm ไป pnpm โดยวิศวกรหนึ่งคนทำงานวันละไม่กี่ชั่วโมงเป็นเวลาหลายวัน

ต้นทุนของโค้ดที่ทำงานได้ขึ้นอยู่กับ development harness

• วิธี “โยน” design document หรือ PR ข้ามกำแพงไปให้วิศวกรทีมอื่นไม่ได้ผล PR และ design document แบบ slop นั้นถูกก็จริง แต่กลับเป็นโทษ
  • ต้องมีการจัดระเบียบและแก้ไข และ context นั้นทำให้ LLM ปนเปื้อน จนได้ผลลัพธ์แย่กว่าการเริ่มใหม่ตั้งแต่ต้น
• ตราบใดที่ manager ตรวจสอบการเปลี่ยนแปลงด้วยตนเอง ตรวจ dashboard หลัง deploy และแก้ปัญหาที่เกิดขึ้น การ contribute โค้ดของ manager ถือว่าประสบความสำเร็จมาก แต่หากไม่เป็นเช่นนั้นก็ไม่มีผลเชิงบวก

การ optimize กรณีพื้นฐานของกระบวนการสำหรับ agent

• Triage issue ขาเข้าทั้งหมดของทีม customer operations ด้วย harness ที่รู้จักทีมและ ticket ที่เปิดอยู่ และเข้าถึง data warehouse แบบจำกัดเพื่อประเมิน impact ช่วยจัดการงานที่ซับซ้อน ต้องใช้ทักษะสูง แต่ไม่น่าสนใจ ให้เร็วขึ้น
  • Edge case ยังคงให้มนุษย์ triage และทำ automation เฉพาะบางขั้นตอนใน flow เดิมโดยไม่เปลี่ยน workflow ของมนุษย์
• First pass ของ code review ทำโดย harness เดียวกับที่ implement การเปลี่ยนแปลง โดยล้าง context ตอนเขียนออกแล้ว มนุษย์จึงโฟกัสที่ feedback ที่มีคุณค่าสูงกว่า
• ไตรมาสที่ผ่านมา rollout Claude Code และ Cowork ทั้งบริษัท โดยทีม fraud ใช้งานอย่างแข็งขันเป็นพิเศษ เพื่อแทนที่งาน manual ด้วย automation ชั้นแรก และทำ initial investigation ของการโจมตีที่อาจเกิดขึ้นโดยอัตโนมัติ (รวม attribution ที่มาจากตัวข้อมูลเอง)
• ย้ายจาก Jira ไป Linear เพื่อเสริมโครงสร้างพื้นฐาน workflow แบบ agent-first ด้วย MCP ที่ทรงพลังกว่าและ integration กับ Slack ที่ดีกว่า การ alpha test ของ internal harness ที่ดึง issue จาก Linear มาแก้โดยอัตโนมัติเกือบเสร็จแล้ว

ทีมถาวรที่มี domain context และ ownership สูง

• ตอนเข้าร่วม บริษัทมีคนเก่งที่หมุนเวียนพื้นที่รับผิดชอบตามโปรเจกต์อย่างรวดเร็วและตอบสนองไวมาก แต่ปัจจุบันวาง ทีมเล็กเฉพาะทาง ในทุกพื้นที่สำคัญเพื่อลงทุนต่อเนื่อง และทีมเหล่านี้ใช้เทคนิค AI ใหม่ ๆ ด้วยตนเอง
• หลังเปิดตัว SierraAI ทีมปรับปรุงอย่างต่อเนื่องจนพัฒนาไปสู่ระดับยอดเยี่ยมอย่างแท้จริง ซึ่งเป็นผลงานที่เป็นไปไม่ได้หากไม่มีทีมเฉพาะทางที่โฟกัสเต็มที่

การตัดสินใจที่รวดเร็ว ดี และหนักแน่น

• การเปลี่ยนวิธี configuration เป็นเรื่องที่ถกเถียงกันมาก จึงต้องอธิบายแนวทางซ้ำหลายครั้ง ผลกระทบต่อแต่ละทีมต่างกัน และประโยชน์เกิดขึ้นในระดับ ecosystem เท่านั้น (คนหนึ่งสามารถ configure ให้ทุกทีมได้) จึง ทำแบบ bottom-up ได้ยาก
• การ rework pipeline CI/CD ก็เป็นเรื่องที่ถกเถียง เพราะเปลี่ยน mental model ของ deployment และ release โดยบังคับให้ แยก deployment กับ release อย่างชัดเจนด้วย feature flagging
• การรวม web monorepo ก็เป็นการตัดสินใจที่เห็นต่างกันและถกเถียงกัน ซึ่งประโยชน์ของ การตัดสินใจที่เป็นหนึ่งเดียว มีมาก
• การนำ SierraAI มาใช้เป็นการอภิปรายที่ยากเมื่อเทียบกับคู่แข่งและทางเลือกไม่ใช้งาน และต้องมี การอนุมัติจากผู้บริหาร เพื่อจบข้อถกเถียงข้ามฟังก์ชัน

สรุป

• กรณีข้างต้นเป็นเพียงตัวอย่างสำคัญบางส่วนเท่านั้น ยังมีงานอื่นอีกจำนวนมาก และขอบเขตของสิ่งที่ทำได้ยังขยายต่อเนื่องทุกเดือน
• ปัจจัยที่ฉุดรั้งไม่ได้เปลี่ยนไปมากนัก: ความไม่ aligned ขององค์กร, การขาดความชัดเจน, สถาปัตยกรรมเทคนิคที่อ่อนแอ