- ตรงกันข้ามกับความเชื่อที่ว่า AI จะเปลี่ยนนักพัฒนาให้กลายเป็น “ผู้จัดการ” หรือ “บรรณาธิการ” ผู้เขียนเสนอแนวทาง “เขียนโค้ดแบบศัลยแพทย์” และเน้นการโฟกัสกับงานแกนหลัก
- เช่นเดียวกับที่ศัลยแพทย์อาศัยทีมสนับสนุนเพื่อช่วยให้โฟกัสเฉพาะส่วนสำคัญของการผ่าตัด นักพัฒนาก็สามารถ มอบหมายงานประกอบให้เครื่องมือ AI และทุ่มเทกับการแก้ปัญหาที่เป็นสาระสำคัญ
- งานหลักบางอย่าง (เช่น การทำ UI prototyping) ยังต้องให้คนลงมือทำเอง แต่ งานซ้ำๆ อย่างการเขียนเอกสาร การแก้บั๊ก และการสำรวจโค้ด สามารถให้ AI agent จัดการได้
- การมอบหมายงานซ้ำๆ ให้ AI ช่วยให้ มอบงานจุกจิกได้โดยไม่ติดปัญหาเรื่องลำดับชั้นสถานะ และด้วยความพร้อมใช้งานตลอด 24 ชั่วโมง จึงสามารถสั่งงานได้แม้ในช่วงดึกหรือช่วงพักกลางวัน
- แนวทางนี้เชื่อมโยงกับ แนวคิด ‘autonomy slider’ ของ Andrej Karpathy ซึ่งชี้ว่า กลยุทธ์การใช้ AI ควรแตกต่างกันตามระดับความเป็นอิสระของงาน
เขียนโค้ดแบบศัลยแพทย์: แนวคิดหลัก
- คัดค้านการคาดการณ์ทั่วไปที่ว่า AI จะทำให้นักพัฒนากลายเป็นผู้จัดการหรือบรรณาธิการ และเสนอวิธีทำงานแบบ ศัลยแพทย์ (Surgeon)
- ศัลยแพทย์เป็นผู้ลงมือผ่าตัดเอง แต่ อาศัยทีมสนับสนุนจัดการงานเตรียมการและงานรอง เพื่อให้โฟกัสเฉพาะ งานหลัก ที่ต้องใช้ความเชี่ยวชาญเฉพาะตัว
- นักพัฒนาก็สามารถใช้ AI เสมือนเป็นผู้ช่วย เพื่อ โฟกัสกับงานสร้างสรรค์ที่เป็นแกนหลัก ได้เช่นกัน
- ผู้เขียนซึ่งทำงานด้าน UI prototyping ตั้งเป้าหมายที่จะใช้เครื่องมือ AI เพื่อ ทุ่มเวลา 100% ให้กับงานที่มีความหมาย
- มอบหมายงานประกอบที่ AI ทำได้ เพื่อเพิ่มผลิตภาพให้สูงสุด
งานประกอบที่สามารถมอบหมายให้ AI ได้
- รายการ งานช่วยเหลือ ที่ AI สามารถทำได้ดีพอ
- เขียนไกด์เกี่ยวกับโค้ดเบสก่อนการเปลี่ยนแปลงขนาดใหญ่
- สร้างโค้ดร่างแบบ ‘spike’ สำหรับการลองเปลี่ยนแปลงครั้งใหญ่
- แก้ข้อผิดพลาด TypeScript หรือบั๊ก ที่มีสเปกระบุชัดเจน
- เขียนเอกสาร สำหรับฟีเจอร์ที่กำลังพัฒนาอยู่
- งานเหล่านี้สามารถ รันแบบ asynchronous อยู่เบื้องหลัง ได้
- AI ทำงานต่อได้ในช่วงพักกลางวันหรือเวลากลางคืน และสามารถกลับมาตรวจทานได้ทันทีในวันถัดไป
- สิ่งนี้ช่วยให้ทำงานได้เหมือน “ศัลยแพทย์ที่เดินเข้าห้องผ่าตัดซึ่งเตรียมพร้อมแล้ว” คือ โฟกัสกับการเขียนโค้ดส่วนสำคัญได้เมื่อทุกอย่างพร้อมครบ
Autonomy slider (Mind the autonomy slider)
- วิธีใช้ AI นั้น แตกต่างกันมากระหว่างงานหลักกับงานประกอบ
- งานออกแบบและ prototyping ที่เป็นแกนหลักยังต้องให้คนทำเอง โดย วงจร feedback ที่รวดเร็วและการมองเห็นภาพรวมที่ชัดเจน เป็นสิ่งสำคัญ
- ในทางกลับกัน งานประกอบนั้น ให้ AI ทำงานอย่างอิสระเป็นเวลานาน จะมีประสิทธิภาพกว่า
- สำหรับเซสชันยาวๆ ที่ไม่มีการกำกับ ผู้เขียนชอบ Claude Code และช่วงหลังชอบ Codex CLI
- ความแตกต่างนี้คล้ายกับ แนวคิด ‘autonomy slider’ ของ Andrej Karpathy
- เครื่องมือและวิธีคิดที่ต้องใช้จะต่างกันไปตามระดับความเป็นอิสระ และการสับสนระหว่างสองแบบนี้เป็นเรื่องอันตราย
AI กับแนวคิด ‘ทีมศัลยแพทย์ซอฟต์แวร์’
- แนวคิด "ศัลยแพทย์ซอฟต์แวร์" เป็นไอเดียเก่าที่ Harlan Mills เสนอไว้ในปี 1975 ผ่านหนังสือ "『The Mythical Man-Month』" ของ Fred Brooks
- เป็นโครงสร้างที่มี ‘chief programmer’ เป็นศูนย์กลาง โดยมี ‘copilot’ และบุคลากรสายบริหาร คอยสนับสนุน
- ในอดีตบทบาทผู้ช่วยเหล่านี้เป็นหน้าที่ของ มนุษย์ แต่ตอนนี้ AI เข้ามาแทนในรูปแบบที่คุ้มค่าทางเศรษฐกิจ
- ผู้เขียนชี้ว่าการเปลี่ยนแปลงนี้มีความหมายมากกว่าแค่การลดต้นทุน
- ช่วยบรรเทาปัญหา ลำดับชั้นสถานะ (status hierarchy)
- การมอบหมาย ‘grunt work’ ที่ซ้ำซากและน่าเบื่อให้ AI ช่วย ลดปัญหาการกระจายงานที่ไม่สมดุลภายในทีม
- AI พร้อมใช้งานตลอด 24 ชั่วโมง จึงสามารถทำ งานค้นคว้ายามดึกหรือการวิเคราะห์โค้ดในเวลากลางคืน ที่จะให้เด็กฝึกงานมนุษย์ทำไม่ได้
Notion และการขยายแนวคิด ‘ทำงานแบบศัลยแพทย์’
- ผู้เขียนอธิบายว่าแนวทางนี้ถูกนำมาใช้จริงแล้วใน Notion ที่ตนทำงานอยู่
- ในระดับบริษัท มีการ สนับสนุนการใช้เครื่องมือ AI สำหรับเขียนโค้ดอย่างจริงจัง และออกแบบโค้ดเบสให้สอดรับกับแนวทางนี้
- โดยเฉพาะสำหรับนักพัฒนาที่เพิ่งเข้ามาร่วมงานกับโค้ดเบสขนาดใหญ่ จะเห็น ผลด้านการเพิ่มผลิตภาพ ชัดเจน
- ในมุมผลิตภัณฑ์ Notion ยังต้องการ ขยายแนวทาง ‘ทำงานแบบศัลยแพทย์’ จากโปรแกรมเมอร์ไปสู่แรงงานความรู้ทุกประเภท
- เป้าหมายหลักไม่ใช่ การมอบหมายงานแกนหลัก แต่คือการ ระบุและมอบหมายงานประกอบที่ไม่สำคัญและซ้ำๆ เพื่อช่วยให้ โฟกัสกับสิ่งที่สำคัญที่สุด
7 ความคิดเห็น
ดูเหมือนว่าจะหมายถึงให้โฟกัสกับงานในส่วนแกนหลัก และมอบงานส่วนรอบนอกให้ AI จัดการ ซึ่งผมค่อนข้างเห็นด้วยกับเรื่องนี้ และงานที่ไม่ใช่โดเมนหลักบางอย่างซึ่งถูกแทนที่ด้วย SaaS ได้อยู่แล้ว หรือพวกงานแอดมิน ก็ดูเหมือนว่าจะสามารถแทนที่ด้วย AI ได้ ยิ่งประเด็นที่น่าถกเถียงกว่านั้นน่าจะเป็นว่า งานในส่วนแกนหลักสามารถถูกแทนที่ด้วย AI ได้หรือไม่ สุดท้ายแล้วกระแสน่าจะไหลไปทางฝั่งที่ให้ผลลัพธ์ดีกว่าอยู่ดี พอดูจากการแก้โจทย์ IOI หรือ LeetCode ก็มีให้เห็นว่า AI แสดงความสามารถด้านการเขียนโค้ดได้ดีกว่ามนุษย์มาก การคาดการณ์แบบรีบด่วนคงเกินความสามารถของผมไปหน่อย ดังนั้นคงต้องรอดูกันต่อไปครับ
อุปมานี้เป็นการเปรียบเทียบที่ผิดโดยสิ้นเชิง เพราะจับประเด็นสำคัญไม่ได้
การผ่าตัดเป็นงานที่ย้อนกลับไม่ได้ แต่การเขียนโปรแกรมเป็นงานที่ย้อนกลับได้ (หรือที่เรียกกันว่าเซฟแอนด์โหลดได้)
ถ้าการผ่าตัดก็ย้อนกลับได้เหมือนกัน ศัลยแพทย์ก็คงสั่งให้ลูกน้องที่ผ่าตัดเป็นทำแทน แล้วตัวเองไปออกแบบหรือรีวิวและบริหารจากข้างหลังจะมีประสิทธิภาพมากกว่า ถ้าพลาดก็แค่ย้อนกลับก็จบ
เห็นด้วยครับ ผมคิดว่าในทำนองเดียวกันก็มักมีคนเข้าใจผิดว่า software engineering เหมือนกับ engineering ในอุตสาหกรรมก่อสร้าง
ถ้าอยากเขียนโค้ดให้เหมือน "ศัลยแพทย์" ของจริง งั้นก็ควรทำให้มีแค่คนที่จบวิทยาการคอมพิวเตอร์เท่านั้นที่เขียนโค้ดได้ไม่ใช่เหรอ ถ้าเพิ่มที่นั่งเรียนสายคอม พวกโปรแกรมเมอร์ก็น่าจะรวมตัวกันประท้วงหยุดงานกันบ้างด้วย......
ทำไมไม่มีผู้ช่วยเขียนโค้ดบ้างล่ะ!?
555555555555555555555555555555555
ความคิดเห็นจาก Hacker News
ถ้าศัลยแพทย์มือใหม่เริ่มผ่าตัดโดยเชื่อว่าพยาบาลหรือวิสัญญีแพทย์จะคอยกันความผิดพลาดให้ คนไข้อาจตายได้ในเวลาไม่นาน
การที่ต้องมีทีมผ่าตัด ไม่ได้แปลว่า การฝึกฝนของศัลยแพทย์อาวุโส เป็นสิ่งไม่จำเป็น
ปัญหาคือศัลยแพทย์ที่ไร้ประสบการณ์คิดว่า “ไม่จำเป็นต้องเรียนหรอก เพราะพยาบาลส่งมีดผ่าตัดให้ได้อยู่แล้ว”
ถ้าต้องเรียนรู้โดยแลกด้วยการเสียสละคนไข้ก็อาจต้องทำ แต่ถ้าไม่อยากเป็นแบบนั้น ก็ควรไปเรียนแพทย์ให้เรียบร้อยก่อน
เลยทำให้ทั้งบทความมีกลิ่นของ ผล Dunning-Kruger (อคติทางการรับรู้ที่คนซึ่งความสามารถยังไม่พอ กลับประเมินความสามารถตัวเองสูงกว่าความเป็นจริงมาก)
ผมพูดมานานแล้วว่าวิศวกรซอฟต์แวร์ควรอ่าน The Mythical Man-Month
ช่วง 25 ปีที่ผ่านมา วิธีพัฒนาซอฟต์แวร์เปลี่ยนไปมาก เช่น การเปลี่ยนจาก waterfall ไปเป็น agile
แต่พอทำงานพัฒนาแบบอิง LLM (เช่น Codex, Claude Code) กลับรู้สึกเหมือนย้อนกลับไปสู่แพตเทิร์นการพัฒนาแบบยุค 70~80
ตอนนี้เราสามารถคิดเชิงสถาปัตยกรรมได้เหมือน การออกแบบมหาวิหาร และมอบหมายรายละเอียดการลงมือทำต่อได้
การผ่าตัดมีคนลงมือได้ทีละคน แต่ซอฟต์แวร์มีหลายคนแตะพร้อมกันได้
จริง ๆ แล้วมันใกล้กับ ทีมกีฬา มากกว่า และที่ใช้เวลานานก็เพราะเราซ้อมและโค้ชกันไม่พอจนกว่างานจะลงตัว
ทำให้โฟกัสที่การออกแบบได้มากกว่าการเขียนโค้ด
เพราะถ้าจะสร้างตึกสูงจริง ๆ ก็ต้องใส่ใจ คุณภาพของเหล็กและที่มาของสลักเกลียว ด้วย
ถ้ามองข้ามเรื่องพวกนั้นก็อันตราย
อุปมานี้ผิดทั้งตามตัวอักษรและในเชิงนามธรรม
ศัลยแพทย์ไม่ใช่แค่แรงงาน แต่เป็นผู้จัดการที่ ดูแลการผ่าตัดทั้งหมด และในความเป็นจริงวิสัญญีแพทย์ต่างหากที่สำคัญที่สุด
อีกทั้งแนวคิดเรื่อง “งานใช้แรงแบบพื้น ๆ (grunt work)” เองก็เป็นมุมมองที่ผิด
ท่าทีที่มองตัวเองเป็นศัลยแพทย์และมองคนอื่นเป็นแรงสนับสนุน คือ มุมมองที่เอาตัวเองเป็นศูนย์กลาง
เหมือนแนวคิด “Chief Programmer” ของ Brooks ที่หัวหน้านักพัฒนาทำงานได้เพราะมีทีมคอยสนับสนุน
ผู้เขียนมองจูเนียร์ไม่ใช่แรงงานชั้นล่าง แต่เป็น เมนที
แม้จะไม่ใช่อุปมาที่สมบูรณ์แบบ แต่สารที่สื่อเกี่ยวกับเครื่องมือเขียนโค้ด AI ก็ยังมีคุณค่าให้รับฟัง
และยกตัวอย่างทางประวัติศาสตร์ว่าการผ่าตัดเคยทำได้แม้ไม่มีการดมยาสลบ
เช่นคำอธิบาย framework ที่ชอบเปรียบโปรแกรมเมอร์เป็น ช่างไม้ ทั้งที่ช่างฝีมือจริงไม่ได้ขัดแต่งทุกส่วนให้เนี้ยบสมบูรณ์แบบเสมอไป
ผมชอบอุปมานี้ เลยคิดว่าจะหยิบไปใช้ต่อ
อีกอุปมาหนึ่งที่นึกถึงคือ สตูดิโอของจิตรกรคลาสสิก
Rembrandt หรือ Rubens ให้ลูกศิษย์เตรียมผ้าใบและลงสีบางส่วน ส่วนอาจารย์จะวาดเองเฉพาะจุดสำคัญ
ตรงกันข้าม หลังยุคโรแมนติกได้เกิดอุดมคติที่ศิลปินต้องทำทุกอย่างเสร็จสมบูรณ์ด้วยตัวคนเดียว
โปรแกรมเมอร์บางคนอยาก สร้างงานคนเดียวแบบ Turner แต่ผมอยากเป็นแบบ Rembrandt คือวาดภาพใหญ่แล้วให้ AI หรือจูเนียร์ช่วยทำรายละเอียด
คุณภาพของโค้ดต้องดีพอเพื่อให้ตอบสนองต่อฟีดแบ็กจากผู้ใช้ได้รวดเร็ว
มันไม่ใช่แค่ “เขียนโค้ดให้เร็วแล้วจบ” แต่ต้องมี โครงสร้างที่ลดต้นทุนการเปลี่ยนแปลง
ถ้าแนวทางแบบ Rembrandt นำไปสู่โค้ดที่ดีได้ก็โอเค แต่ตอนนี้ยังมีหลักฐานสนับสนุนไม่มากพอ
ผมเองก็ใช้ Claude มาหลายเดือนแล้ว แต่รู้สึกว่าเขียนโค้ดเองยังมีประสิทธิภาพกว่า
แต่ครั้งนี้ตอนอัปเกรดฐานข้อมูลขนาดใหญ่จาก MySQL 8→9 ผมให้ Claude ช่วยหา คิวรีที่อาจมีปัญหา ปรากฏว่ามันทายถูกเป็นส่วนใหญ่จนน่าทึ่ง
มันไม่สมบูรณ์แบบ แต่ช่วยลด เวลาในการดีบัก ได้มาก
เลยรู้สึกว่าแทนที่ LLM จะเขียนโค้ดเอง บทบาทแบบ ช่วยหาจุดเสี่ยง กลับมีค่ามากกว่าเยอะ
ถ้าเอา stack trace จาก codebase เก่า ๆ ไปให้ LLM มันช่วยชี้ ทิศทางการดีบักเบื้องต้น ได้
ตอนแก้ปัญหาประสิทธิภาพก็ให้มันช่วยตรวจได้ว่า code path ต่าง ๆ ยังให้ผลลัพธ์เดียวกันหรือไม่
ตอนนี้การเขียนโค้ดยังอยู่แค่ระดับ autocomplete แต่ประสิทธิภาพการทำงานดีขึ้นชัดเจน
ทำให้นึกถึงงานบรรยาย Software Faster ของ Dan North
ประโยคที่ว่า “ซอฟต์แวร์ก็เหมือนการผ่าตัด ทำเท่าที่จำเป็นขั้นต่ำเพื่อแก้ปัญหา” น่าประทับใจมาก
แต่บทความนี้กลับห่างจากปรัชญานั้นพอสมควร
เลยทำให้ตอนนี้ผมรู้สึกเหมือนเป็นศัลยแพทย์ที่ต้องทำ การตัดทิ้ง อยู่บ่อย ๆ
โครงสร้างแบบ Chief Programmer Team ดูเหมือนกำลังกลับมาอีกครั้ง
รอบนี้มาในรูปแบบที่มี AI agent อยู่ในทีมแทนมนุษย์บางส่วน
ไอเดียของ Fred Brooks กำลังถูกหยิบมาสนใจอีกครั้ง
ถ้าเอาทีมเก่ง ๆ ไปประกบ นักพัฒนาประสิทธิภาพ 10 เท่า (10x-er) ก็จะลดเวลาที่เสียไปกับประชุมหรือจัดการ Jira ได้
ในเมื่อจ่ายเงินเดือนแพง ก็ควรใช้เวลาของพวกเขาให้คุ้มค่าที่สุด
การเข้าใจ สเปกตรัมของความอิสระ หรือ สเปกตรัมของการมอบหมายงาน คือหัวใจของการใช้เครื่องมือ AI สำหรับเขียนโค้ดให้เก่ง
วิศวกรมักไม่คุ้นกับการมอบหมายงาน แต่ผู้ก่อตั้งบริษัทมักซึมซับเรื่องนี้ได้เร็วกว่า
มีคนชี้ว่า คำพูดอย่าง “ศัลยแพทย์โฟกัสกับงานสำคัญ” นั้น ในโลกจริงงานสนับสนุนทุกอย่าง สำคัญเท่าเทียมกัน
ควรถ่อมตัว เคารพการสนับสนุนจากคนรอบข้าง และ support พวกเขากลับอย่างเท่าเทียม