ความเชี่ยวชาญเชิงโดเมนคือคูเมืองที่แท้จริงมาโดยตลอด
(brethorsting.com)- ความยากของซอฟต์แวร์ไม่ได้อยู่ที่การพิมพ์โค้ด แต่คือการเข้าใจกฎในโลกจริงอย่างเงินเดือนหรือการคมนาคมเพื่อสร้าง domain model และโค้ดก็เป็นผลลัพธ์ของความเข้าใจนั้น
- Agentic AI ทำให้การผลิตซอฟต์แวร์เป็นไปได้แม้ไม่มีความเข้าใจโดเมน และย้ายคอขวดจาก “สร้างได้หรือไม่” ไปเป็น “ตัดสินได้หรือไม่ว่าถูกต้อง”
- ผู้เชี่ยวชาญโดเมน อย่างผู้จัดตารางงานขนส่ง, clinical coder, หรือ actuary สามารถตัดสินได้ว่าเอาต์พุตสอดคล้องกับกฎหมาย กฎการเบิกจ่าย หรือกฎการปฏิบัติงานหรือไม่ แม้ไม่รู้โค้ดก็ตาม
- วิศวกร generalist สามารถตรวจสอบสถาปัตยกรรมและความน่าเชื่อถือได้ แต่ในงานอย่าง clinical coding ที่คำตอบที่ถูกต้องผูกกับความรู้โดเมน อาจพลาดความผิดพลาดที่ดูสมเหตุสมผลได้
- ความสามารถที่มีค่าที่สุดคือ การตัดสิน ที่ตรวจสอบได้ทั้งความสมบูรณ์ของโค้ดที่ถูกสร้างและความจริงแท้ของเอาต์พุต ทำให้การลงทุนในความเชี่ยวชาญโดเมนสำคัญขึ้นสำหรับวิศวกรที่มีประสบการณ์
แก่นแท้คือความเข้าใจโดเมน ไม่ใช่การเขียนโค้ด
- ในการพัฒนาซอฟต์แวร์ ส่วนที่ยากไม่ใช่การเขียนโค้ด แต่คือการสร้าง แบบจำลองการทำงานของโดเมน ขึ้นมาในหัวก่อน
- โค้ดเป็นเพียง การถอดความ (transcription) ของความเข้าใจนั้น และกระบวนการได้มาซึ่งความเข้าใจต่างหากคืองานที่แท้จริง
-
ตัวอย่างที่เป็นรูปธรรม
- ก่อนเปิดตัวระบบเงินเดือน ต้องเข้าใจ การหักเงินตามคำสั่งศาล (garnishment), การหักก่อนหักภาษี, และวิธีจัดการเมื่อรอบจ่ายเงินคร่อมช่วงเวลาที่อัตราค่าจ้างมีการเปลี่ยนแปลง
- ก่อนเปิดตัวแอปขนส่งสาธารณะ ต้องเรียนรู้ว่า GTFS feed คืออะไร, ทำไม trip กับ route จึงต่างกัน, และทำไมรถบัสที่ “มาตรงเวลา” จึงยังอาจผิดได้
Agentic AI ตัดสายสัมพันธ์นี้ออกไป
- Agentic AI ตัดความเชื่อมโยงระหว่างการสร้างแบบจำลองกับการผลิตซอฟต์แวร์ ทำให้สามารถสร้างซอฟต์แวร์ได้โดยไม่ต้องมีแบบจำลอง
- สิ่งนี้ทำลายสมมติฐานที่ทั้งอาชีพเคยยึดเป็นฐาน
- มุมมองเมื่อปีที่แล้ว มองว่าเครื่องมือนี้ช่วย ขยายศักยภาพของนักพัฒนาระดับซีเนียร์ ที่มีวิจารณญาณ ซึ่งก็จริงแต่ยังไม่ครบถ้วน
- การเปลี่ยนแปลงที่สังเกตได้จริงคือ ข้อจำกัดหลักได้ย้ายจาก “สร้างได้หรือไม่” ไปเป็น “ตัดสินได้หรือไม่ว่าถูกต้อง”
เปรียบเทียบบุคคลสองประเภท
-
ผู้เชี่ยวชาญโดเมน (ไม่มีพื้นฐานซอฟต์แวร์)
- เช่น ผู้จัดตารางงานขนส่ง, clinical coder, actuary ที่อ่าน stack trace ไม่ออก และอธิบายความต่างระหว่าง hashmap กับ list ไม่ได้
- แต่เมื่อดูตารางงานที่เอเจนต์สร้างขึ้น ก็จะรู้ได้ทันทีว่า ไม่มีพนักงานขับรถคนใดทำกะนี้ได้อย่างถูกกฎหมาย หรือรู้ได้ทันทีว่าการเบิกจ่ายตามโค้ดนั้นไม่มีทางได้รับเงิน
- เพราะอยู่กับอินพุตและเอาต์พุตเหล่านี้มานาน 10 ปี จึงรู้ว่า เอาต์พุตที่ถูกต้อง สำหรับอินพุตที่กำหนดควรเป็นอย่างไร และเอเจนต์ก็เข้ามาเติมเต็มความสามารถในการผลิตโค้ดที่พวกเขาขาดได้อย่างแม่นยำ
- สิ่งที่พวกเขานำมาคือ ground truth ที่เอเจนต์ให้ไม่ได้
-
วิศวกร generalist ที่เก่งมากแต่ไม่มีประสบการณ์โดเมน
- ออกแบบอะไรก็ได้ และรู้เรื่องความน่าเชื่อถือ การทดสอบ และวิธีทำให้ระบบไม่ล่มตอนตี 2
- แต่ถ้าถูกส่งไปทำ clinical coding ก็จะ แยกไม่ออกระหว่างคำตอบผิดที่ดูเหมือนถูกกับคำตอบที่ถูกจริง
- เอเจนต์สร้าง กฎการเบิกจ่าย (billing rule) ที่ผิดแบบละเอียดอ่อนแต่มีต้นทุนสูง ซึ่งคอมไพล์ผ่านและผ่านการทดสอบที่มันเขียนเอง
- วิศวกรไม่มี oracle จึงตรวจได้เพียงว่าซอฟต์แวร์ถูกสร้างมาดีหรือไม่ แต่ตรวจไม่ได้ว่ามันถูกต้องหรือไม่ — เพราะความถูกต้องถูกนิยามโดยโดเมนที่เขาไม่มีอยู่ในหัว
ความไม่สมมาตรที่มีเพียงเส้นทางเดียวพังทลาย
- ก่อนมีเอเจนต์ วิศวกรมีเส้นทางที่ผู้จัดตารางงานไม่มี — สามารถค่อย ๆ ซึมซับแบบจำลองโดเมน ได้จากการตามผู้เชี่ยวชาญ อ่านสเปก และเจอความผิดพลาดในสภาพแวดล้อมการปฏิบัติงานจริง
- ในหลายสาขา เส้นทางนี้คือ career ladder เอง แต่ผู้เชี่ยวชาญโดเมนกลับไม่มีเส้นทางเทียบเท่าที่ต้องใช้เวลาหลายปีเพื่อเรียนรู้การสร้างซอฟต์แวร์ที่เชื่อถือได้
- เครื่องมือแบบ Agentic ทำลายเพียงหนึ่งในสองเส้นทางนี้
- จุดแข็งของวิศวกรในการแปลงแบบจำลองโดเมนเป็นโค้ดตอนนี้กลายเป็นสิ่งที่ ราคาถูก (cheap)
- แต่จุดแข็งของผู้เชี่ยวชาญโดเมนที่รู้ว่าอะไรถูกต้องนั้นไม่ได้เป็นเช่นนั้น และไม่สามารถไปถึงได้ด้วยการพรอมป์ต
- ไม่มีไฟล์สกิลที่บรรจุ ความรู้ฝังลึก (tacit knowledge) ของคนที่เคยประมวลผลเงินเดือนมาหลายพันครั้ง
บุคลากรที่ตรวจสอบได้ทั้งสองชั้น
- ในโลกใหม่นี้ คนที่มีค่าที่สุดคือคนที่มีทักษะทั้งสองด้านและสามารถ ตรวจสอบได้ทั้งสองชั้น
- รู้ว่าโค้ดที่ถูกสร้างขึ้นมีความแข็งแรง และขณะเดียวกันก็รู้ว่าคำตอบที่โค้ดนั้นให้มานั้นเป็นความจริง
- เพราะรู้กฎ จึงเขียนการทดสอบที่เข้ารหัสว่า “คนขับรถทำงานเกิน 11 ชั่วโมงไม่ได้” ได้ และเพราะรู้ว่ากำลังทดสอบอะไร จึงตัดสินได้ว่าการทดสอบนั้นมีความหมายจริง
- เอเจนต์ทำหน้าที่ถอดความ ส่วนมนุษย์ทำหน้าที่ ตัดสินสองครั้ง (judging, twice)
การเดิมพันสำหรับวิศวกรที่มีประสบการณ์
- สำหรับวิศวกรที่มีประสบการณ์ซึ่งกำลังคิดว่าจะลงทุนกับอะไรในอีกไม่กี่ปีข้างหน้า นี่คือทิศทางของการเดิมพัน
- ทักษะเชิงกลไก (mechanical skill) ในการแปลงไอเดียที่ชัดเจนให้เป็นโค้ดที่สะอาด จะมีมูลค่าลดลงอย่างมาก
- สิ่งที่ยังหายากคือ แบบจำลองที่ลึกและผ่านการพิสูจน์แล้ว ของโดเมนจริงบางอย่าง และต้องไปให้ถึงสิ่งนั้น
- เลือกสักอย่างระหว่างอุตสาหกรรม ผลิตภัณฑ์การเงิน ระบบกำกับดูแล หรือกระบวนการทางกายภาพ แล้ว เรียนรู้โดเมนนั้น เหมือนที่เคยเรียนภาษาโปรแกรมหรือเฟรมเวิร์กในอดีต
- นั่นคือส่วนที่เอเจนต์ทำแทนให้ไม่ได้ และตอนนี้คือส่วนที่มีมูลค่าสูงที่สุด
7 ความคิดเห็น
แต่ผมก็คิดว่านี่เป็นการมองข้ามคุณค่าของโค้ดมากเกินไปเหมือนกัน
การพัฒนาซอฟต์แวร์เองก็เป็นโดเมนหนึ่ง และการทำสิ่งนั้นได้ดีเองก็เป็นทักษะความเชี่ยวชาญเฉพาะทาง
เหมือนกับที่ซอฟต์แวร์ที่ AI สร้างขึ้นอาจแก้ปัญหาได้ในเชิงฟังก์ชัน แต่ยังทำให้มันสมบูรณ์ไม่ได้ และยังต้องมีคนมาคอยเติมเต็มส่วนนั้น
ผมมีความเห็นแย้งกับความคิดของ xguru เล็กน้อย
ขอยก Excel มาเป็นตัวอย่างนะครับ โดยทั่วไปแล้วในการทำงานบริษัทจะมีระดับที่จำเป็นต้องใช้ และเมื่อเกินกว่านั้นไป คนส่วนใหญ่ก็มักไม่ได้อยากเรียนรู้เพิ่มอีกนัก แม้จะมีคนที่ใช้ Excel ได้เก่งแบบสุด ๆ อยู่บ้าง แต่นั่นก็เป็นกรณีที่พิเศษมากจริง ๆ
ในกรณีของโค้ดก็เช่นกัน — ตอนนี้ยังไม่เป็นแบบนั้นก็ตาม — ผมเคยคิดว่าอาจจะแยกออกเป็นสองทางแบบนั้นได้ คือคนส่วนน้อยที่สร้างผลิตภัณฑ์ซับซ้อนมากจริง ๆ กับคนส่วนใหญ่ที่ใช้งานมันเหมือนการขี่จักรยาน
หืม? คนที่ใช้ Excel เก่งก็ไม่ได้ถูกดูแคลนนี่ครับ
แต่การบอกว่าคุณค่าของการเขียนโค้ดนั้นลดลงไปเอง มันให้ความรู้สึกเหมือนกำลังมองข้ามกันอยู่นะครับ
ผมคิดว่า ต่อให้บอกว่าใช้งานได้เหมือนปั่นจักรยาน ก็ไม่ควรไปพูดกับคนที่สร้างผลิตภัณฑ์ซับซ้อนว่า คุณค่าของคุณก็ไม่ได้มีอะไรมากหรอก
ผมเห็นด้วยกับประเด็นที่คุณกล่าวมา
ประเด็นคือเทคโนโลยีและโค้ดที่พอจะเรียกได้ว่าเป็นซอฟต์แวร์ที่ซับซ้อนจะลดลง หากสิ่งที่ AI สามารถเขียนแบบเบา ๆ ได้มีมากขึ้น
หากยืมสำนวนจากบทสรุปของ GeekNews: ดูเหมือนว่าโค้ดที่เอเจนต์ไม่สามารถทำแทนได้จะค่อย ๆ ลดลงทุกวัน
เหมือนกับความเห็นนี้ที่อยู่ในความคิดเห็นบน Hacker News
เลยครับ
ในประเด็นนั้น สถานการณ์เหมือนกับว่าความรู้โดยนัยแทบจะหายไปแล้ว และเมื่อผู้เชี่ยวชาญโดเมนระดับแนวหน้ามาออกแบบเอเจนต์แล้วฝังเข้าไปในโมเดล,,, ตอนนี้แม้จะมีการเน้นย้ำความสำคัญของความรู้โดเมนอยู่ แต่ก็ไม่แน่ใจว่าอีก 1 ปีข้างหน้าจะยังพูดแบบเดิมกันหรือเปล่า เพราะท้ายที่สุดความรู้โดยนัยก็กำลังค่อย ๆ ถูกถ่ายทอดไปเป็นพรอมต์ และโมเดลต่าง ๆ ก็จะคัดเลือกความรู้โดยนัยที่ผู้ใช้เพิ่มไว้ในพรอมต์ แล้วฉีดกลับเข้าไปในโมเดลอีกที เอเจนต์โมเดลที่ฝังความรู้โดยนัยไว้ย่อมมีคุณค่า แต่ผมมองว่าแม้แต่สิ่งนี้ก็น่าจะถูกซื้อขายกันในตลาดได้ เอเจนต์ที่มีความรู้โดเมนลึกกว่ามากในสาขานั้นๆ
อีก 1 ปีข้างหน้า ผมคาดว่าเกณฑ์การประเมินอาจจะก้าวข้ามเรื่อง orchestration ไปสู่การบริหารจัดการเอเจนต์ (เหมือนบริษัท) แทนก็เป็นได้
ความคิดเห็นจาก Hacker News
ไม่รู้เลยว่าต้องฟังคำอธิบายยืดยาวอีกแค่ไหนกว่าคนจะยอมรับว่า ไม่มีใครรู้จริง ๆ ว่าควรใช้ AI อย่างไร ในระดับปัจเจก
ตอนแรกบอกว่าแค่เป็นนักพัฒนาที่เก่งแล้วเรียนรู้วิธีใช้ AI ก็พอ จากนั้นก็บอกว่าความสามารถด้านการออกแบบสถาปัตยกรรมสำคัญ ต่อมาก็บอกว่า รสนิยม ต่างหากที่ตัดสินทุกอย่าง แล้วตอนนี้ก็มาบอกว่ามีแต่ผู้เชี่ยวชาญโดเมนเท่านั้นที่สำคัญ
ตราบใดที่การพัฒนา หรือการชะงักตัวของ AI ยังไม่อยู่ในภาวะที่เสถียรและคาดเดาได้ การตีความแบบนี้ก็จะยังไร้ความหมายและมีแนวโน้มจะผิดเป็นส่วนใหญ่
มันยากขึ้นเพราะเกณฑ์ของสิ่งที่ทำได้ถูกยกระดับขึ้นมาก นักพัฒนาคนเดียวสามารถรับโปรเจ็กต์ที่ยากกว่ามากได้ และสุดท้ายข้อจำกัดก็เป็นเรื่องเวลามาโดยตลอด ส่วน AI ก็ช่วยให้เราทำงานได้มากขึ้นภายในเวลาที่มี
แต่สิ่งที่ทำได้ภายในเวลานั้นเองกลับยากขึ้นมาก เราต้องเข้าใจเรื่องต่าง ๆ มากขึ้น และต้องก้าวออกจากพื้นที่ปลอดภัยที่คุ้นเคยจากยุคก่อน AI ไปไกลมาก
เมื่อก่อนการใช้เวลาหลายวันเพื่อรีแฟกเตอร์โค้ดเบสหรือเตรียมปล่อยฟีเจอร์เล็ก ๆ เพราะเป็นส่วนของระบบที่ไม่คุ้นเคยหรือต้องเรียนรู้ไลบรารีใหม่ ยังถือว่าเป็นเรื่องที่ยอมรับได้
ด้วย coding agent เราอาจไต่เส้นโค้งการเรียนรู้นั้นได้เร็วขึ้นมาก แต่ก็ยังต้องไต่เองอยู่ดี และปริมาณข้อมูลที่ไหลเข้ามาก็มากขึ้นมาก
ถ้าคุณกังวลว่าจะถูกคนทำ vibe coding ที่ไม่ใช่สายเทคนิคแย่งงาน วิธีรับมือที่ถูกต้องคือสร้างซอฟต์แวร์ให้ดีกว่าพวกเขามาก ๆ ซึ่งก็ต้องใช้ทักษะมากขึ้น ความทะเยอทะยานมากขึ้น และประสบการณ์มากขึ้น และมันไม่ง่าย
อุปมาที่ผมรู้สึกว่าเหมาะที่สุดตอนนี้คือการเปรียบเทียบสว่านไขควงไฟฟ้าสมัยใหม่กับไขควงหรือสว่านมือแบบเก่า
เมื่อเทียบกับอุปกรณ์แบบเก่า มันให้ผลลัพธ์น่าทึ่งได้ในเวลาสั้นมาก
เช่นเรื่องเล่าทำนองว่า “งานยึดพื้นทั้งวันที่ควรใช้เวลาทั้งวัน ผมทำเสร็จในหนึ่งชั่วโมง แถมยังออกไปสูบบุหรี่ได้หลายรอบระหว่างนั้น” ถ้าใช้ปืนยิงตะปูก็คงเสร็จในครึ่งเวลา แต่ภายหลังก็อาจยกพื้นนั้นขึ้นมาได้ยาก และต้นทุนก็อาจสูงขึ้นประมาณสองเท่า
ผมก็ใช้ on-premises LLM หลายตัวและเข้าถึงโมเดลอื่น ๆ ได้ด้วย เลยคิดว่าสักวันอาจขยายอุปมานี้ไปถึงความต่างระดับแบรนด์ได้
แต่ผมไม่คิดว่ามันจะออกไปหางานใหม่แทนได้ สว่านไขควงไฟฟ้าไม่ใช่ช่างไม้หรือคนงานหน้างาน และถ้าไม่มีคน มันก็ไม่มีประโยชน์
ผมคิดว่าอีก 20 ปีข้างหน้า เราก็คงยังต้องตามเก็บขยะที่ร่วมเขียนกับ Claude อยู่เหมือนกัน
https://mastodon.gamedev.place/@JeremiahFieldhaven/116654345...
ในปี 2018 ผมเห็นคนที่ไม่มีประสบการณ์เขียนโค้ดเลยสร้างเครื่องมือที่ทำเงินได้ดีพอสมควรจากการเขียนโค้ดแค่เดือนเดียว เพราะเขารู้จักตลาดเฉพาะทางตลาดหนึ่งดีมาก
เขาให้ดูโค้ดบางส่วน ซึ่งเละพอ ๆ กับโปรแกรมแรกของผมเลย แต่สิ่งนั้นแก้ปัญหาจริงได้
ยกตัวอย่างเช่น พวกเขาบอกว่า “ถ้าอยากเก่งกีฬา ต้องมีความสมมาตรสมบูรณ์แบบ ซึ่งสัมพันธ์อย่างมากกับความมั่นคงของพัฒนาการตั้งแต่ช่วงทารกในครรภ์ ยิ่งสมมาตรมาก ก็ยิ่งพัฒนาได้สมบูรณ์แบบ”
จากนั้นไม่กี่ปีต่อมาก็มีข่าวว่า Bruce Lee มีขาข้างหนึ่งสั้นกว่าอีกข้างค่อนข้างมาก และ Usain Bolt ก็มีความไม่สมมาตรของพัฒนาการในลักษณะคล้ายกัน
จากนั้นพวกเขาก็กลับลำ เอาข้อยกเว้นเหล่านี้มาอธิบายกลบเกลื่อนว่าไม่ได้กระทบกฎทั่วไปแต่แรก
แค่สร้างสิ่งที่น่าสนใจก็พอ แล้วมันอาจเวิร์กก็ได้
ไม่นานมานี้ผมตรวจแอปที่ทำด้วย vibe coding จนเกือบเสร็จแล้ว เจ้าของบอกว่าแทบพร้อมปล่อยแล้วและแค่ต้องการเช็กเร็ว ๆ
พอเปิดดูพบว่าการออกแบบฐานข้อมูลเละมาก บางฟีเจอร์ทำงาน บางฟีเจอร์ไม่ทำงาน ผมอธิบายว่าขาดอะไรไปและมันพังเพราะอะไร คนคนนั้นก็เป็นผู้เชี่ยวชาญโดเมนเหมือนในบทความต้นฉบับ
แค่เดือนที่แล้วเขาใช้ไปหลายพันล้านโทเค็น และเครื่องมือก็กำลังพัฒนาขึ้นเร็วมาก แต่การให้ AI กับผู้เชี่ยวชาญโดเมนไม่ได้แปลว่าไม่ต้องมีวิศวกรซอฟต์แวร์อีกต่อไป
ผู้เชี่ยวชาญโดเมนใช้ AI เพื่อสร้างซอฟต์แวร์ได้ และวิศวกรซอฟต์แวร์ก็ใช้ AI เพื่อเรียนรู้โดเมนได้ ทั้งสองฝ่ายนำความเชี่ยวชาญคนละแบบเข้ามา
คือการสร้างราวกันตก การตรวจสอบ ไลบรารีพรอมป์ต์ รวมถึง agent และการรีวิวด้วยมือ เพื่อปกป้องให้ผู้เชี่ยวชาญโดเมนใช้ coding agent ได้อย่างปลอดภัย
มันคล้ายกับงานซัพพอร์ตลูกค้าภายในระดับ T2/T3 หรือซัพพอร์ตเอนจิเนียร์อยู่บ้าง คือไม่ได้แก้ปัญหาทั่วไปทุกอย่างด้วยตัวเอง 100% แต่มีหน้าที่คอยจับจุดเสี่ยง เคสขอบเขตแปลก ๆ และตรวจให้แน่ใจว่าการตั้งค่าทั้งหมดถูกต้อง
แน่นอนว่าเลยต้องแตะเรื่องข้ามสายงานอยู่มากด้วย
แต่ในฐานะเครื่องมือสำหรับลองไอเดียใหม่ ๆ อย่างรวดเร็วและขุดลึกลงไป มันยอดเยี่ยมมาก ถ้าคุณมีความอยากรู้อยากเห็น มันก็อาจเป็นตัวเร่งการเรียนรู้ชั้นยอดได้
ผมใช้ Claude Code (Opus 4.6, ตั้งค่า effort สูงสุด) ทั้งวันทุกวัน แต่ก็ยังนึกไม่ออกว่ามันจะเป็นไปได้อย่างไร และก็สงสัยด้วยว่าปริมาณการใช้งานขนาดนั้นให้ผลตอบแทนคุ้มจริงไหม
อาจเป็นเพราะผมยังไม่เข้าใจดีพอ แต่ผมไม่รู้จริง ๆ ว่ามันไปถึงจุดนั้นได้อย่างไร
มีตัวอย่างที่ดีมากจากประสบการณ์ล่าสุด
ตอนนั้นกำลังไปทริปตกปลา และผมก็ถามกัปตันว่าอยากลองดูไหมว่าแอปฟรีที่ผมทำอยู่ (https://oceanconnect.ca) จะช่วยงานเขาได้หรือเปล่า
ผมไม่ค่อยรู้เลยว่าคนในทะเลใช้ ข้อมูลทางทะเล กันอย่างไร พวกเขาอยากรู้อะไร และทำไมถึงอยากรู้ พอคำถามและข้อมูลเกี่ยวกับวิธีที่คนใช้ข้อมูล รวมถึงสิ่งที่เราทำกับข้อมูลได้ ถาโถมเข้ามา ผมก็ไม่พร้อมเลย แต่การได้มุมมองแบบนั้นมันทั้งเจ๋งและน่าสนใจมาก
มันทำให้นึกขึ้นมาอีกครั้งว่าโมเดลไม่ใช่สิ่งเดียวกับระบบที่มันใช้ทำ abstraction และความรู้ที่ใช้พัฒนาโมเดลก็แทบไม่เกี่ยวกับความรู้ที่ใช้มันเลย
คนคนนี้มีความรู้มหาศาลเกี่ยวกับการใช้ ข้อมูลสภาพอากาศ บนผืนน้ำ ในแง่หนึ่งเขารู้จักข้อมูลมากกว่าผมเสียอีก และถึงแม้เขาอาจไม่ตระหนักถึงเรื่องนั้น หรือไม่เข้าใจการแทนข้อมูลในรูปแบบดิจิทัล ถ้าเขาเขียนโปรแกรมได้ เขาก็น่าจะสร้างแอปที่มีประโยชน์สำหรับคนแบบเขาได้ดีกว่ามาก
ผมคิดว่าถ้าคนแบบนี้มี LLM อยู่ตรงหน้าแล้วสามารถถ่ายทอดไอเดียลงสู่หน้าจอได้ ก็น่าจะสร้างอะไรที่ยอดเยี่ยมได้จริง ๆ ถ้าวันหนึ่งมีเงินทุน ผมอยากสัมภาษณ์คนที่ออกทะเลทุกวันเพื่อขัดเกลาผลิตภัณฑ์ ความรู้เฉพาะทางนั้นมีลักษณะเฉพาะมาก และคนที่อยู่ในโดเมนซับซ้อนมาหลายสิบปีรู้เรื่องที่เราไม่มีทางคาดคิดจริง ๆ
ซอฟต์แวร์เจเนอรัลลิสต์ ที่บทความนี้อธิบายก็มีความเชี่ยวชาญเฉพาะทางเหมือนกัน โดเมนนั้นก็คือซอฟต์แวร์
ถ้าตอนนี้คุณเป็นวิศวกรซอฟต์แวร์สายเจเนอรัลลิสต์ที่เก่ง คุณก็คงไม่หนี 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 ไปเป็นแอปที่ยืดหยุ่นกว่า
ผมคิดว่าบริษัท BI พวกนี้จะเจอปัญหาใหญ่ โดยเฉพาะบริษัทอย่าง Tableau ที่ทำให้แม้แต่การวาดอะไรพื้นฐานอย่าง histogram ก็แทบเป็นไปไม่ได้
เพื่อนของฉันเป็นวิศวกรไฟฟ้า และเพิ่งมี FIDE chess rating 2000 เกินมาไม่นาน เขาเล่นหมากรุกมา 30 ปี และตอนมัธยมก็ยังก่อตั้งชมรมหมากรุกด้วย ตอนเรียนมหาวิทยาลัยเขาเคยทำงานกับไมโครคอนโทรลเลอร์เลยได้เรียนรู้การเขียนโปรแกรมมาบ้างเล็กน้อย
ส่วนฉันมีวุฒิด้านวิทยาการคอมพิวเตอร์ แต่ใกล้เคียงกับงานสาย infrastructure/management แบบจับฉ่ายมากกว่า และเขียนโปรแกรมเป็นงานอดิเรกมา 30 ปี เรตติ้ง Lichess ของฉันต่อให้วันฟอร์มดีก็แค่ 1000
เราเคยแข่งกันทำบอตหมากรุก เป็นการแข่งขันแบบเปิดตำรา ใช้ AI ช่วยเขียนโปรแกรมก็ได้ และจะเอา opening book หรือ endgame table อะไรมาใช้ก็ได้อย่างอิสระ ฉันชนะเขาแบบขาดลอย แต่ถ้าเป็นหมากรุกบนกระดานจริง ตลอด 20 ปีฉันชนะเขาได้แค่สองครั้ง
ในโลกความเป็นจริง เขาน่าจะชนะผู้เล่นสุ่มได้ 99% ส่วนฉันคงชนะได้แค่ราว 20%
ฉันเองก็ไม่แน่ใจว่ากำลังจะสื่ออะไรพอดี แต่ตอนนี้รู้สึกว่าความรู้เชิงโดเมนอาจไม่ใช่ทั้งหมดอีกต่อไปแล้ว หรือไม่ก็ตัวโดเมนเองอาจเปลี่ยนไปแล้วก็ได้
เท่ากับว่าคุณท้าเขาแข่งเขียนโปรแกรม และคุณซึ่งเป็นโปรแกรมเมอร์ที่มีประสบการณ์กว่ามากก็เป็นฝ่ายชนะ ถึงจะใช้ AI ได้ก็ตาม แต่ในกรณีนี้ผมมองว่าความรู้เชิงโดเมนของคุณต่างหากที่เป็นตัวตัดสิน