ความเชี่ยวชาญเฉพาะโดเมนคือคูเมืองที่แท้จริงมาโดยตลอด

• ความยากของซอฟต์แวร์ไม่เคยอยู่ที่การพิมพ์โค้ด แต่คือการทำความเข้าใจกฎในโลกจริงอย่างเงินเดือน การเดินทาง ฯลฯ แล้วสร้างเป็น domain model ขึ้นมา และโค้ดก็เป็นผลลัพธ์ของความเข้าใจนั้น
• Agentic AI ทำให้สามารถผลิตซอฟต์แวร์ได้แม้ไม่มีความเข้าใจโดเมน และย้ายคอขวดจาก “สร้างได้หรือไม่” ไปเป็น “ตัดสินได้หรือไม่ว่าถูกต้อง”
• ผู้เชี่ยวชาญโดเมน อย่างผู้จัดตารางขนส่ง, clinical coder หรือ actuary อาจไม่รู้โค้ด แต่สามารถตัดสินได้ว่าผลลัพธ์สอดคล้องกับกฎหมาย กฎการเบิกจ่าย และกฎการปฏิบัติงานหรือไม่
• วิศวกรทั่วไปอาจตรวจสอบสถาปัตยกรรมและความน่าเชื่อถือได้ แต่ในงานอย่าง clinical coding ซึ่งคำตอบที่ถูกต้องผูกกับความรู้โดเมน ก็อาจพลาดข้อผิดพลาดที่ดูสมเหตุสมผลได้
• ความสามารถที่มีค่าที่สุดคือ วิจารณญาณ ในการตรวจสอบทั้งความสมบูรณ์ของโค้ดที่ถูกสร้างขึ้นและความจริงแท้ของผลลัพธ์ ทำให้การลงทุนกับความเชี่ยวชาญโดเมนยิ่งสำคัญขึ้นสำหรับวิศวกรที่มีประสบการณ์

---

คอขวดของซอฟต์แวร์กำลังย้ายจากการลงมือสร้างไปสู่การตรวจสอบ

• ส่วนที่ยากของการเขียนซอฟต์แวร์ไม่ใช่การพิมพ์โค้ดเอง แต่คือการสร้าง domain model ขึ้นมาในหัวก่อน
  • ระบบเงินเดือนต้องรองรับการอายัด, การหักก่อนภาษี, และการจัดการช่วงจ่ายเงินเดือนเมื่อทับกับช่วงเวลาที่มีการเปลี่ยนอัตราค่าจ้าง
  • แอปขนส่งต้องสะท้อน GTFS feed, ความต่างระหว่าง trip กับ route, และเหตุผลที่รถบัสซึ่ง “ตรงเวลา” ก็ยังอาจผิดได้
  • โค้ดเป็นเพียงผลจากการถ่ายทอดความเข้าใจนี้ และงานที่แท้จริงคือการได้มาซึ่งความเข้าใจนั้น
• Agentic AI ทำให้ความเชื่อมโยงระหว่างความเข้าใจโดเมนกับการผลิตซอฟต์แวร์อ่อนลง
  • ตอนนี้สามารถผลิตซอฟต์แวร์ได้โดยไม่ต้องสร้าง domain model ด้วยตนเองโดยตรง
  • สมมติฐานที่งานสายซอฟต์แวร์ทั้งอาชีพพึ่งพามาเริ่มสั่นคลอน
• เหมือน มุมมองเมื่อปีที่แล้ว ที่อธิบายว่าเครื่องมือแบบนี้ช่วยขยายศักยภาพของนักพัฒนาอาวุโสที่มีวิจารณญาณ ซึ่งก็จริง แต่ยังไม่พอ
  • การเปลี่ยนแปลงที่ชัดกว่านั้นคือคอขวดได้ย้ายจาก “สร้างได้หรือไม่” ไปเป็น “ตัดสินได้หรือไม่ว่าถูกต้อง”

คนที่ใช้เครื่องมือแบบ agentic ได้เก่ง

• ผู้เชี่ยวชาญโดเมนสามารถตัดสินคำตอบที่ถูกต้องได้แม้ไม่รู้โค้ด

  • คนอย่างผู้จัดตารางขนส่ง, clinical coder หรือ actuary อาจอ่าน stack trace ไม่ออก และอาจอธิบายความต่างระหว่าง hash map กับ list ไม่ได้
  • แต่เมื่อเห็นตารางงานที่เอเจนต์สร้างขึ้น พวกเขาจะรู้ได้ทันทีว่าคนขับคนไหนไม่สามารถทำกะนั้นได้ตามกฎหมาย
  • พวกเขายังดูออกได้ด้วยว่าการเบิกประกันด้วยชุดรหัสบางแบบจะไม่ผ่านการจ่ายเงิน
  • คนกลุ่มนี้อยู่กับอินพุตและเอาต์พุตมาเป็นสิบปี จึงรู้ว่าผลลัพธ์ที่ถูกต้องสำหรับอินพุตหนึ่ง ๆ ควรเป็นอย่างไร
  • สิ่งที่เอเจนต์มอบให้คือความสามารถในการผลิตโค้ดที่พวกเขาขาด และสิ่งที่พวกเขามีให้เอเจนต์คือ เกณฑ์ความจริงของคำตอบ (ground truth) ที่เอเจนต์ไม่มี

• วิศวกรทั่วไปอาจแยกไม่ออกระหว่างซอฟต์แวร์ที่สร้างมาดีกับซอฟต์แวร์ที่ถูกต้องจริง

  • วิศวกรทั่วไปที่เก่งรู้เรื่องสถาปัตยกรรม ความน่าเชื่อถือ การทดสอบ และวิธีทำให้ระบบไม่พังตอนตีสอง
  • แต่ในโดเมนอย่าง clinical coding พวกเขาอาจแยกไม่ออกระหว่างคำตอบที่ดูน่าเชื่อแต่ผิด กับคำตอบที่ถูกต้อง
  • เอเจนต์อาจสร้างสิ่งที่คอมไพล์ได้ และผ่านการทดสอบที่วิศวกรคิดขึ้นมา แต่ยังสร้างข้อผิดพลาดเรื่องกฎการเบิกจ่ายที่ละเอียดอ่อนและมีต้นทุนสูงได้
  • วิศวกรอาจตรวจสอบได้ว่าซอฟต์แวร์ถูกสร้างมาดีหรือไม่ แต่เมื่อความถูกต้องถูกนิยามโดยโดเมนที่ไม่มีอยู่ในหัวของพวกเขาเลย ก็ยากที่จะตรวจสอบ ความแม่นยำ

• ก่อนยุคเอเจนต์ เคยมีเส้นทางการเรียนรู้ที่เอื้อกับวิศวกรมากกว่า

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

• เครื่องมือแบบ agentic ทำลายเส้นทางนี้ไปเพียงด้านเดียว

  • ความได้เปรียบของวิศวกรในการแปล domain model ให้กลายเป็นโค้ดที่ทำงานได้ กลายเป็นสิ่งที่ต้นทุนต่ำลง
  • แต่ความได้เปรียบของผู้เชี่ยวชาญโดเมนในการรู้ว่าอะไรถูกต้อง ไม่ได้ถูกทำให้ราคาถูกลง
  • ความสามารถนี้ไม่ได้มาเพียงเพราะมี prompt และก็ไม่มี skill file ที่บรรจุความรู้ฝังลึกจากการทำเงินเดือนให้ถูกต้องมาหลายพันครั้ง

• คนที่มีค่าที่สุดคือคนที่ตรวจสอบได้ทั้งสองชั้น

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

[GN⁺]

ความคิดเห็นจาก Hacker News

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

  • ผมยิ่งคิดชัดขึ้นเรื่อย ๆ ว่า เครื่องมือ AI ทำให้การพัฒนาซอฟต์แวร์ยากขึ้น
    มันยากขึ้นเพราะเกณฑ์ของสิ่งที่ทำได้ถูกยกระดับขึ้นมาก นักพัฒนาคนเดียวสามารถรับโปรเจ็กต์ที่ยากกว่ามากได้ และสุดท้ายข้อจำกัดก็เป็นเรื่องเวลามาโดยตลอด ส่วน AI ก็ช่วยให้เราทำงานได้มากขึ้นภายในเวลาที่มี
    แต่สิ่งที่ทำได้ภายในเวลานั้นเองกลับยากขึ้นมาก เราต้องเข้าใจเรื่องต่าง ๆ มากขึ้น และต้องก้าวออกจากพื้นที่ปลอดภัยที่คุ้นเคยจากยุคก่อน AI ไปไกลมาก
    เมื่อก่อนการใช้เวลาหลายวันเพื่อรีแฟกเตอร์โค้ดเบสหรือเตรียมปล่อยฟีเจอร์เล็ก ๆ เพราะเป็นส่วนของระบบที่ไม่คุ้นเคยหรือต้องเรียนรู้ไลบรารีใหม่ ยังถือว่าเป็นเรื่องที่ยอมรับได้
    ด้วย coding agent เราอาจไต่เส้นโค้งการเรียนรู้นั้นได้เร็วขึ้นมาก แต่ก็ยังต้องไต่เองอยู่ดี และปริมาณข้อมูลที่ไหลเข้ามาก็มากขึ้นมาก
    ถ้าคุณกังวลว่าจะถูกคนทำ vibe coding ที่ไม่ใช่สายเทคนิคแย่งงาน วิธีรับมือที่ถูกต้องคือสร้างซอฟต์แวร์ให้ดีกว่าพวกเขามาก ๆ ซึ่งก็ต้องใช้ทักษะมากขึ้น ความทะเยอทะยานมากขึ้น และประสบการณ์มากขึ้น และมันไม่ง่าย
  • LLM ก็เป็นแค่ เครื่องมือ ที่เพิ่มเข้ามาในคลังอาวุธเท่านั้น ไม่ได้ทรงอำนาจไปเสียทุกอย่าง และต้องใช้อย่างระมัดระวังเหมือนเครื่องมือชนิดอื่น
    อุปมาที่ผมรู้สึกว่าเหมาะที่สุดตอนนี้คือการเปรียบเทียบสว่านไขควงไฟฟ้าสมัยใหม่กับไขควงหรือสว่านมือแบบเก่า
    เมื่อเทียบกับอุปกรณ์แบบเก่า มันให้ผลลัพธ์น่าทึ่งได้ในเวลาสั้นมาก
    เช่นเรื่องเล่าทำนองว่า “งานยึดพื้นทั้งวันที่ควรใช้เวลาทั้งวัน ผมทำเสร็จในหนึ่งชั่วโมง แถมยังออกไปสูบบุหรี่ได้หลายรอบระหว่างนั้น” ถ้าใช้ปืนยิงตะปูก็คงเสร็จในครึ่งเวลา แต่ภายหลังก็อาจยกพื้นนั้นขึ้นมาได้ยาก และต้นทุนก็อาจสูงขึ้นประมาณสองเท่า
    ผมก็ใช้ on-premises LLM หลายตัวและเข้าถึงโมเดลอื่น ๆ ได้ด้วย เลยคิดว่าสักวันอาจขยายอุปมานี้ไปถึงความต่างระดับแบรนด์ได้
    แต่ผมไม่คิดว่ามันจะออกไปหางานใหม่แทนได้ สว่านไขควงไฟฟ้าไม่ใช่ช่างไม้หรือคนงานหน้างาน และถ้าไม่มีคน มันก็ไม่มีประโยชน์
  • จำ กระแสโอ้อวดเรื่อง object-oriented เมื่อ 20 ปีก่อนได้ไหม? ทุกคนเปิดอ่านหนังสือ GoF แบบผ่าน ๆ แล้วก็ยัด pattern กันมั่วทั้งที่ไม่รู้ด้วยซ้ำว่าทำไปทำไม และเรายังต้องตามเก็บกวาดโค้ดแบบนั้นออกจากโค้ดเบสอยู่จนถึงทุกวันนี้
    ผมคิดว่าอีก 20 ปีข้างหน้า เราก็คงยังต้องตามเก็บขยะที่ร่วมเขียนกับ Claude อยู่เหมือนกัน
    https://mastodon.gamedev.place/@JeremiahFieldhaven/116654345...
  • ต่อให้ก่อนยุค AI ก็มีกรณีที่การเป็น ผู้เชี่ยวชาญโดเมน มีค่ามากกว่าการเป็นนักพัฒนาซอฟต์แวร์ที่เก่งอยู่แล้ว
    ในปี 2018 ผมเห็นคนที่ไม่มีประสบการณ์เขียนโค้ดเลยสร้างเครื่องมือที่ทำเงินได้ดีพอสมควรจากการเขียนโค้ดแค่เดือนเดียว เพราะเขารู้จักตลาดเฉพาะทางตลาดหนึ่งดีมาก
    เขาให้ดูโค้ดบางส่วน ซึ่งเละพอ ๆ กับโปรแกรมแรกของผมเลย แต่สิ่งนั้นแก้ปัญหาจริงได้
  • มันให้ความรู้สึกคล้ายกับวิธีที่คนดูหรือคนทั่วไปประเมิน กีฬาอาชีพ
    ยกตัวอย่างเช่น พวกเขาบอกว่า “ถ้าอยากเก่งกีฬา ต้องมีความสมมาตรสมบูรณ์แบบ ซึ่งสัมพันธ์อย่างมากกับความมั่นคงของพัฒนาการตั้งแต่ช่วงทารกในครรภ์ ยิ่งสมมาตรมาก ก็ยิ่งพัฒนาได้สมบูรณ์แบบ”
    จากนั้นไม่กี่ปีต่อมาก็มีข่าวว่า Bruce Lee มีขาข้างหนึ่งสั้นกว่าอีกข้างค่อนข้างมาก และ Usain Bolt ก็มีความไม่สมมาตรของพัฒนาการในลักษณะคล้ายกัน
    จากนั้นพวกเขาก็กลับลำ เอาข้อยกเว้นเหล่านี้มาอธิบายกลบเกลื่อนว่าไม่ได้กระทบกฎทั่วไปแต่แรก
    แค่สร้างสิ่งที่น่าสนใจก็พอ แล้วมันอาจเวิร์กก็ได้

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

  • ทิศทางที่ผมกำลังมุ่งไปสุดท้ายดูจะใกล้กับ platform engineer มากกว่า
    คือการสร้างราวกันตก การตรวจสอบ ไลบรารีพรอมป์ต์ รวมถึง agent และการรีวิวด้วยมือ เพื่อปกป้องให้ผู้เชี่ยวชาญโดเมนใช้ coding agent ได้อย่างปลอดภัย
    มันคล้ายกับงานซัพพอร์ตลูกค้าภายในระดับ T2/T3 หรือซัพพอร์ตเอนจิเนียร์อยู่บ้าง คือไม่ได้แก้ปัญหาทั่วไปทุกอย่างด้วยตัวเอง 100% แต่มีหน้าที่คอยจับจุดเสี่ยง เคสขอบเขตแปลก ๆ และตรวจให้แน่ใจว่าการตั้งค่าทั้งหมดถูกต้อง
    แน่นอนว่าเลยต้องแตะเรื่องข้ามสายงานอยู่มากด้วย
  • ประสบการณ์ของผมก็คล้ายกัน LLM ทำให้การสำรวจโดเมนอื่นง่ายขึ้น แต่ไม่ได้ทำให้คุณกลายเป็นปรมาจารย์ของโดเมนนั้น คุณยังต้องมี ความรู้โดเมนเฉพาะทาง อยู่ดี
    แต่ในฐานะเครื่องมือสำหรับลองไอเดียใหม่ ๆ อย่างรวดเร็วและขุดลึกลงไป มันยอดเยี่ยมมาก ถ้าคุณมีความอยากรู้อยากเห็น มันก็อาจเป็นตัวเร่งการเรียนรู้ชั้นยอดได้
  • ผมไม่ค่อยเข้าใจตรงที่บอกว่า “แค่เดือนที่แล้วใช้ไปหลายพันล้านโทเค็น”
    ผมใช้ Claude Code (Opus 4.6, ตั้งค่า effort สูงสุด) ทั้งวันทุกวัน แต่ก็ยังนึกไม่ออกว่ามันจะเป็นไปได้อย่างไร และก็สงสัยด้วยว่าปริมาณการใช้งานขนาดนั้นให้ผลตอบแทนคุ้มจริงไหม
    อาจเป็นเพราะผมยังไม่เข้าใจดีพอ แต่ผมไม่รู้จริง ๆ ว่ามันไปถึงจุดนั้นได้อย่างไร
  • ถ้า ความเชี่ยวชาญโดเมน มาควบคู่กับกรอบคิดด้าน QA ที่สม่ำเสมอ มันอาจแทนที่วิศวกรซอฟต์แวร์ได้ แต่กรอบคิดด้าน QA ที่สม่ำเสมอนั้นหาได้ยาก

• มีตัวอย่างที่ดีมากจากประสบการณ์ล่าสุด
  ตอนนั้นกำลังไปทริปตกปลา และผมก็ถามกัปตันว่าอยากลองดูไหมว่าแอปฟรีที่ผมทำอยู่ (https://oceanconnect.ca) จะช่วยงานเขาได้หรือเปล่า
  ผมไม่ค่อยรู้เลยว่าคนในทะเลใช้ ข้อมูลทางทะเล กันอย่างไร พวกเขาอยากรู้อะไร และทำไมถึงอยากรู้ พอคำถามและข้อมูลเกี่ยวกับวิธีที่คนใช้ข้อมูล รวมถึงสิ่งที่เราทำกับข้อมูลได้ ถาโถมเข้ามา ผมก็ไม่พร้อมเลย แต่การได้มุมมองแบบนั้นมันทั้งเจ๋งและน่าสนใจมาก
  มันทำให้นึกขึ้นมาอีกครั้งว่าโมเดลไม่ใช่สิ่งเดียวกับระบบที่มันใช้ทำ abstraction และความรู้ที่ใช้พัฒนาโมเดลก็แทบไม่เกี่ยวกับความรู้ที่ใช้มันเลย
  คนคนนี้มีความรู้มหาศาลเกี่ยวกับการใช้ ข้อมูลสภาพอากาศ บนผืนน้ำ ในแง่หนึ่งเขารู้จักข้อมูลมากกว่าผมเสียอีก และถึงแม้เขาอาจไม่ตระหนักถึงเรื่องนั้น หรือไม่เข้าใจการแทนข้อมูลในรูปแบบดิจิทัล ถ้าเขาเขียนโปรแกรมได้ เขาก็น่าจะสร้างแอปที่มีประโยชน์สำหรับคนแบบเขาได้ดีกว่ามาก
  ผมคิดว่าถ้าคนแบบนี้มี LLM อยู่ตรงหน้าแล้วสามารถถ่ายทอดไอเดียลงสู่หน้าจอได้ ก็น่าจะสร้างอะไรที่ยอดเยี่ยมได้จริง ๆ ถ้าวันหนึ่งมีเงินทุน ผมอยากสัมภาษณ์คนที่ออกทะเลทุกวันเพื่อขัดเกลาผลิตภัณฑ์ ความรู้เฉพาะทางนั้นมีลักษณะเฉพาะมาก และคนที่อยู่ในโดเมนซับซ้อนมาหลายสิบปีรู้เรื่องที่เราไม่มีทางคาดคิดจริง ๆ

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

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

• บางทีข่าวดีคือ ต่อให้เป็น นักบัญชีสายสเปรดชีตขั้นเทพ ที่เก่งที่สุดฝั่งตะวันตก สุดท้ายถ้าจะตรวจสอบความถูกต้องก็ยังต้องมีประสบการณ์การเขียนโปรแกรมอยู่บ้าง
  คุณอาจถาม LLM ได้ว่า “โค้ดนี้ทำอะไร และเมื่อเป็น Y แล้วจะได้ X เสมอหรือไม่” แต่ก็เท่ากับแค่ซ้อนปัญหาการตรวจสอบเข้าไปในปัญหาการตรวจสอบอีกชั้นหนึ่ง

• แก่นสำคัญไม่เคยเป็นเรื่องโค้ดตั้งแต่แรก
  ตลอด 5 ปีที่ผ่านมา ผมสร้างซอฟต์แวร์สำหรับ venture capital และ private equity แล้วรู้สึกอินกับบทความนี้มาก การเขียนโค้ดเป็นส่วนที่ง่ายที่สุดในงานของผมแบบทิ้งห่าง ส่วนที่ยากคือ วิศวกรรมการเงินและบริบทอันละเอียดอ่อน ที่ต้องใช้เพื่อเข้าใจว่าลูกค้าบริษัทต้องการอะไรกันแน่
  เราชอบล้อกันว่าถ้าเป็นไปได้ก็อยากจ้างนักบัญชีกองทุนระดับซีเนียร์แล้วสอนให้เขียนโปรแกรม ปัญหาคือแทบไม่มีคนแบบนั้นอยู่เลย และการทำให้วิศวกรเข้าใจรายละเอียดของการบัญชีกองทุนมากพอจะเอาไปสร้างเป็นซอฟต์แวร์ก็ยากเหมือนกัน

  • ถ้ามีแต่ความเชี่ยวชาญโดเมนแต่ไม่มีทักษะทางเทคนิค พอถึงจุดหนึ่งอย่างมากที่สุดมันก็นำไปสู่ หนี้ทางเทคนิค ก้อนมหึมา
    จริง ๆ แล้วประมาณครึ่งหนึ่งของอาชีพผมคือการตามเก็บงานที่ “มีความรู้โดเมนพอจะปิด ticket หรือ epic ได้ แต่สุดท้ายก็ทิ้งหนี้ทางเทคนิคไว้เพียบ”
    ตัวอย่างเช่น ต่อให้มีความรู้โดเมน คนก็ยังพลาดได้ ไม่รู้ว่าวิธีที่ดีกว่าคืออะไร ไม่เอาฟีดแบ็กไปปรับใช้ หรือแย่กว่านั้นคือไม่ตรวจทานสิ่งที่ coding agent เขียนไว้ ดังนั้นผมเลยต้องรีวิว PR อย่างละเอียดมาก
    ผมยังต้องรีแฟกเตอร์อะไรที่ “ในทางเทคนิคถือว่าถูก แต่เขียนได้แย่มากจน timeout หรือทำให้ผู้จัดการ/DBA โวยวาย” อยู่บ่อย ๆ
    วิศวกรซอฟต์แวร์ที่ดีจริง ๆ มีทั้งความสามารถและความตั้งใจที่จะเรียนรู้โดเมน แต่ก็ต้องมีวิธีให้เขาเรียนรู้ด้วย บางบริษัท บางทีม หรือบางเพื่อนร่วมงานช่วยให้เรื่องนั้นเกิดขึ้นได้ แต่บางที่ก็พูดอย่างเดียวว่ามันสำคัญ ทั้งที่ในความเป็นจริงคุณต้องเดาเอาจาก JIRA กับเศษเสี้ยวคำพูดที่หลุดออกมาจากคนฝ่าย non-IT ตอนประชุม
    สำหรับผม การเปลี่ยนกระบวนทัศน์ครั้งใหญ่ในช่วง 5 ปีหลังคือบริษัทส่วนใหญ่คาดหวังให้คนทำงานจนสุดขีด แต่กลับปิดกั้นเวลาสำหรับบทสนทนาสำคัญ ๆ ซึ่งให้ผลตรงกันข้าม
    วัฒนธรรมองค์กรเป็นตัวแปรใหญ่ บางที่อย่างน้อยก็ยังคุยสั้น ๆ ข้างโต๊ะกันได้หรือเรียกประชุมได้ง่าย แต่บางที่ถ้าจะขอเวลามาคุยกันจริงจังเหมือนต้องไปตั้งคำร้องใน change.org เลย
    ถึงอย่างนั้นประเด็นหลักก็ยังถูกต้องอยู่ดี สุดท้ายแล้ว requirements สำคัญกว่าโค้ด แม้ว่าความต้องการทั้งหมดจะครบ ทีมก็อนุมัติการตัดสินใจด้านการออกแบบแล้ว แต่ก็ยังมีที่ที่คนซึ่งหายไประหว่างการพัฒนาทั้งหมดกลับมา แล้วทำให้ฟีเจอร์ล่าช้าเพียงเพราะไม่ชอบวิธีที่เขียน
    แล้วไม่นานคุณก็จะพบว่า “batch process” กำลังทำการ insert จำนวน %numberOfRecord%*10 ครั้ง มี query เพิ่มเพราะโมเดลข้อมูลออกแบบผิด และทำ SQL upsert ด้วยวิธีที่ผิดที่สุดเท่าที่จะเป็นไปได้ นั่นคือไปดึงจาก DB ก่อน แล้วถ้าไม่มีก็ค่อยเพิ่มเรคคอร์ดที่จะ insert แทนที่จะกลับไปคิดรูปแบบ query ของ data layer ใหม่ ก็ค่อย ๆ ทำเรื่องชวนพิรุธมากขึ้นเรื่อย ๆ ในนามของ “การปรับปรุงประสิทธิภาพ” ผมเห็นแบบนี้มาเกินหนึ่งครั้งในอาชีพแล้ว

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

• ผมเคยมองว่า moat ที่แท้จริงของซอฟต์แวร์อยู่ตรงที่แทบไม่จำเป็นต้องใช้ความรู้หรือประสบการณ์ที่กว้างขวางทั้งในระดับระบบและในระดับโดเมน
  การลอกเลียนแบบ รสนิยมและ network effects นั้นยากกว่ามาก ในความเป็นจริง แม้ก่อนยุค vibe coding สตาร์ทอัพที่ได้ทุนร่วมลงทุนและมีทั้งคนเก่งกับทรัพยากรพร้อมก็มักไม่ค่อยยืนระยะในตลาดได้
  นั่นจึงเป็นเหตุผลว่าทำไมคนวัย 20 กว่ายังแข่งขันกับผู้เชี่ยวชาญจากหลายสาขาได้ และผมคิดว่ากระแสต้านในตอนนี้เกิดจากการกำเนิดของคนประเภท “ทำงานในวงการมา X ปี” ซึ่งเป็นสิ่งที่เห็นกันทั่วไปในอุตสาหกรรมที่โตเต็มที่อื่น ๆ

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

  • กลุ่มของเรากำลังค่อย ๆ แทนที่ Tableau ด้วยเครื่องมือที่สร้างเอง และ ประสิทธิภาพที่ดีขึ้น นั้นมหาศาล
    ผมคิดว่าบริษัท BI พวกนี้จะเจอปัญหาใหญ่ โดยเฉพาะบริษัทอย่าง Tableau ที่ทำให้แม้แต่การวาดอะไรพื้นฐานอย่าง histogram ก็แทบเป็นไปไม่ได้

• เพื่อนของฉันเป็นวิศวกรไฟฟ้า และเพิ่งมี FIDE chess rating 2000 เกินมาไม่นาน เขาเล่นหมากรุกมา 30 ปี และตอนมัธยมก็ยังก่อตั้งชมรมหมากรุกด้วย ตอนเรียนมหาวิทยาลัยเขาเคยทำงานกับไมโครคอนโทรลเลอร์เลยได้เรียนรู้การเขียนโปรแกรมมาบ้างเล็กน้อย
  ส่วนฉันมีวุฒิด้านวิทยาการคอมพิวเตอร์ แต่ใกล้เคียงกับงานสาย infrastructure/management แบบจับฉ่ายมากกว่า และเขียนโปรแกรมเป็นงานอดิเรกมา 30 ปี เรตติ้ง Lichess ของฉันต่อให้วันฟอร์มดีก็แค่ 1000
  เราเคยแข่งกันทำบอตหมากรุก เป็นการแข่งขันแบบเปิดตำรา ใช้ AI ช่วยเขียนโปรแกรมก็ได้ และจะเอา opening book หรือ endgame table อะไรมาใช้ก็ได้อย่างอิสระ ฉันชนะเขาแบบขาดลอย แต่ถ้าเป็นหมากรุกบนกระดานจริง ตลอด 20 ปีฉันชนะเขาได้แค่สองครั้ง
  ในโลกความเป็นจริง เขาน่าจะชนะผู้เล่นสุ่มได้ 99% ส่วนฉันคงชนะได้แค่ราว 20%
  ฉันเองก็ไม่แน่ใจว่ากำลังจะสื่ออะไรพอดี แต่ตอนนี้รู้สึกว่าความรู้เชิงโดเมนอาจไม่ใช่ทั้งหมดอีกต่อไปแล้ว หรือไม่ก็ตัวโดเมนเองอาจเปลี่ยนไปแล้วก็ได้

  • ถ้ามองจากมุมของ AI การทำความเข้าใจแบบกลางๆ น่าจะเป็นว่า บางโดเมน ตื้น เช่น หมากรุก ขณะที่บางโดเมนลึกกว่า
  • ฉันไม่แน่ใจจริงๆ ว่าความสามารถในการเล่นหมากรุกจริงเกี่ยวข้องอะไรกับการเขียน อัลกอริทึมค้นหา game tree ที่มีประสิทธิภาพ มากไปกว่าหลักการง่ายๆ ไม่กี่ข้อ
    เท่ากับว่าคุณท้าเขาแข่งเขียนโปรแกรม และคุณซึ่งเป็นโปรแกรมเมอร์ที่มีประสบการณ์กว่ามากก็เป็นฝ่ายชนะ ถึงจะใช้ AI ได้ก็ตาม แต่ในกรณีนี้ผมมองว่าความรู้เชิงโดเมนของคุณต่างหากที่เป็นตัวตัดสิน