Machikoba no Techo

มีเพียงคนที่เขียนเองได้เท่านั้น ที่มองเห็นอันตราย

กันยายนแล้วครับ ฤดูตกหมึกกล้วย (Kensaki) ในยามค่ำคืน ซึ่งเป็นสัญญาณหนึ่งของฤดูร้อนที่นี่ กำลังจะปิดฉากลง บรรดาผู้ที่ออกเรือกันตอนกลางคืนก็ค่อย ๆ ย้ายเป้าหมายไปยังหมึกที่เราเรียกกันว่า budouika หรือ “หมึกองุ่น” อย่างเงียบ ๆ ขอขอบพระคุณทุกท่านที่ให้การสนับสนุนเราเสมอมาครับ

และกันยายนยังมีอีกเรื่องหนึ่ง นั่นคือเป็นฤดูที่หมึกหอม (หมึก Aori) มารวมตัวกัน เมื่ออุณหภูมิน้ำค่อย ๆ ลดลงจากจุดสูงสุดของฤดูร้อน ปลาเหยื่อก็คึกคักขึ้นมาพร้อมกันทีเดียว หมึกเปลี่ยนไปตามนั้น และฝูงหมึกตัวเล็กก็เคลื่อนเข้ามาในเขตน้ำตื้น คันเบ็ดโค้งงอตามแนวเขื่อนกันคลื่นในช่วงสั้น ๆ ของรุ่งสางและพลบค่ำ นี่อาจเป็นช่วงที่น่าตื่นเต้นที่สุดของทั้งปี และสำหรับใครที่คิดจะเริ่มการตกหมึกด้วยอีจิ นี่ก็เป็นฤดูที่ให้อภัยมือใหม่มากที่สุดเช่นกัน

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

■ แค่บอกว่า “อยากได้อะไรทำนองนี้” มันก็ใช้งานได้

vibe coding คือการข้ามการเขียนสเปกอย่างละเอียด คุณอธิบายสิ่งที่ต้องการด้วยภาษาพูดธรรมดา ให้ AI เขียนให้ แล้วรับสิ่งที่รันได้กลับมา ตลอดหนึ่งปีที่ผ่านมา เราสร้างเครื่องมือเล็ก ๆ สำหรับหน้างานขึ้นมาหลายตัวด้วยวิธีนี้ทั้งนั้น หรือจะพูดให้ถูกคือ เราผลิตเครื่องมือกันราวกับหายใจ

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

■ “รันได้” กับ “ถูกต้อง” เป็นคนละเรื่องกัน

แต่สิ่งที่น่ากลัวที่สุดในปีนี้ ก็คือการที่มัน รันได้ นี่แหละ สิ่งที่ออกมามักจะใช้งานได้ หน้าจอดูสะอาดตา ตัวเลขก็ขึ้นครบ และเพราะมันรันได้ คุณจึงมองจากภายนอกไม่ออกว่ามันปลอดภัยหรืออันตราย

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

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

■ ในโรงงานเล็ก ๆ ไม่มีชิ้นงานในอุดมคติ

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

ในกรณีของผม ผมทำสิ่งที่ค่อนข้างแปลกอยู่เป็นประจำ นั่นคือผมสร้าง NC ซึ่งเป็นภาษาของเครื่องจักร ขึ้นมาด้วย vibe coding เวลาเขียนโค้ดที่พ่นผลลัพธ์ออกมาเป็น NC ระบบมักเลือก Python ให้โดยอัตโนมัติ แต่ส่วนใหญ่ผมจะเปลี่ยนไปใช้ Ruby แทน นั่นคือสไตล์ของผม

เครื่องมือกลระบบ NC สมัยนี้แม่นยำอย่างเหลือเชื่อ ถ้าให้วัสดุในอุดมคติ รูปทรงในอุดมคติ และขนาดในอุดมคติ มันจะกัดออกมาได้ผิวงานที่ทำให้คุณทึ่ง แต่ในโรงงานของเรา อุดมคติเหล่านั้นแทบไม่เคยพร้อมเลย คุณต้องทำงานให้เสร็จด้วยสิ่งที่มีอยู่ตรงหน้า วัสดุไม่สม่ำเสมอ รูปทรงและขนาดต่างกันทุกครั้ง ข้อสมมติที่ว่า “ตรงตามแบบ” ไม่ได้อยู่ตรงหน้าเราเลย

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

■ เหมาะที่สุดกับการปรับตามชิ้นงานจริง และกับการทำ reverse engineering

และวิธีทำงานแบบนี้ คือการปรับตามชิ้นงานจริง คล้ายกับ vibe coding อย่างน่าประหลาดใจ ไม่มีสเปกที่สมบูรณ์แบบมาก่อน คุณค่อย ๆ เข้าใกล้วัตถุที่อยู่ตรงหน้า กัดแล้วลองทาบ ทาบแล้วกลับไปกัดอีก ให้มันสร้างของที่รันได้ออกมา ชี้ว่าตรงไหนผิด ให้แก้ แล้วลองใหม่ เพราะคุณขยับมือได้ก่อนที่สเปกจะนิ่ง มันจึงเข้ากับหน้างานแบบ “ทำให้เสร็จด้วยสิ่งที่มี” ได้ดีอย่างน่าทึ่ง

เหนือสิ่งอื่นใด vibe coding เป็นตัวเสริมที่ดีสำหรับส่วนที่ยากที่สุด นั่นคือ การยกระดับความเป็นนามธรรม ลองให้มันดูเวอร์ชันที่ฝังตัวเลขตายตัวไว้สักชุดหนึ่ง แล้วขอให้เขียนใหม่ให้ยังทำงานได้เมื่อขนาดเปลี่ยน มันจะคัดออกมาได้เองว่าอะไรควรกลายเป็นตัวแปร ส่วนของการทำให้เป็นกรณีทั่วไปที่เคยกินเวลาคนหลายวัน คือการหามุมเข้าทำ ถูกเคลียร์ไปในพริบตา และนั่นคือความสามารถที่หน้างานแบบ “ทำให้เสร็จด้วยสิ่งที่มี” ของเราขาดอยู่พอดี

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

เรื่องใกล้ตัว โปรแกรม NC ที่ผู้ผลิตเครื่องจักรพ่นออกมาเอง พูดตรง ๆ ผมไม่ค่อยชอบเท่าไร ไม่มีการย่อหน้า คอมเมนต์ก็ไม่ช่วยอะไร อ่านไม่ออกว่ากำลังทำอะไรอยู่ โปรแกรมที่อ่านไม่ออก คือโปรแกรมที่หยุดตรวจสอบไม่ได้ AI เข้ามาเติมช่องว่างตรงนี้ ขอให้มันเติมย่อหน้าและคอมเมนต์เพราะโค้ดอ่านยาก มันก็ส่งกลับมาแบบนั้นเป๊ะ บอกว่าระดับนามธรรมต่ำเกินไป ขอให้แยกออกเป็นซับรูทีน มันก็แบ่งโค้ดออกเป็นบล็อกที่มีความหมาย พฤติกรรมเหมือนเดิม แต่จัดเรียงให้อยู่ในรูปที่คนอ่านได้ นี่อาจเป็นการใช้งานที่เราหยิบมาใช้บ่อยที่สุดในตอนนี้

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

ขอยกตัวอย่างที่เป็นรูปธรรมสักเรื่อง เราให้ AI ช่วยเรียบเรียงโปรแกรม NC ของเครื่อง wire EDM อยู่บ่อย ๆ สะดวกจนแทบเลือดกำเดาไหล ในโลกของ NC ถึงทุกคนจะเรียกมันว่า “G-code” เหมือนกัน แต่ผู้ผลิตแต่ละรายก็มีนิสัยการเขียนของตัวเอง จะเรียกว่าเป็นภาษาถิ่นก็ได้ รุ่นนี้เขียนแบบนี้ อีกรุ่นต้องใช้คำสั่งนี้ สำหรับคนก็คือต้องเทียบคู่มือและเรียนรู้เอาจากหน้างาน

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

แต่เราไม่เคยส่งโปรแกรมที่ได้มาแบบนั้นเข้าเครื่องตรง ๆ เราดีบัก มันต้องขึ้นเครื่องจริงเสมอ เดินทีละบรรทัด ตรวจค่าตัวแปรและการเคลื่อนที่ของเส้นลวดด้วยตาเปล่า ตรงนี้แหละที่ M01 (optional stop) ซึ่งผมเขียนถึงเมื่อเดือนที่แล้ว ได้แสดงคุณค่าของมัน ต่อให้งานที่ออกมาดูดีแค่ไหน ถ้าคุณไม่มีความสามารถที่จะดีบักมันบนเครื่องจริง คุณก็ใช้เครื่องมือนี้ไม่ได้ หรือจะพูดให้ถูกคือ ผมเชื่อว่าคุณไม่ควรใช้ ถ้าใช้เป็นเครื่องมือผลิตคำตอบที่ถูกต้อง มันอันตราย แต่ถ้าใช้เป็นเครื่องมือหามุมเข้าทำ มันน่าเกรงขาม แต่การยืนยันว่ามุมนั้นถูกต้อง เป็นฝั่งของมนุษย์เสมอ

■ ควรปล่อยให้เป็นกล่องดำหรือไม่

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

ส่วนที่น่าอึดอัดคือ กล่องดำไม่ได้มีแค่ส่วนที่ AI เขียน ซอฟต์แวร์ทุกวันนี้ถูกสร้างขึ้นด้วยการเรียกใช้ชิ้นส่วนจำนวนมหาศาล คือไลบรารีที่ใครสักคน ที่ไหนสักแห่ง เผยแพร่ไว้บน GitHub และที่อื่น ๆ เพิ่งมีเหตุการณ์ใหญ่ในโลกของ JavaScript ไปหมาด ๆ (อันที่จริง ข่าว backdoor แทบจะโผล่มาทุกวัน) ไลบรารีที่ซอฟต์แวร์จำนวนมากตั้งอยู่บนนั้น ถูกยึดครองและถูกฝังกลไกที่ทำงานตอนติดตั้ง แล้วแพร่ตัวเองต่อไปยังแพ็กเกจถัดไป ดูเหมือนว่ามีแพ็กเกจหลายร้อยตัวถูกปนเปื้อนภายในไม่กี่ชั่วโมง ก่อนหน้านั้นไม่นานก็มีกรณีการดักระหว่างทางเพื่อสลับปลายทางการชำระเงิน นั่นคือการแก้ไขส่วนที่จัดการเรื่องเงินโดยตรง

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

คำถามที่ว่าจะเชื่อกล่องของคนอื่นได้หรือไม่ ไม่ใช่เรื่องใหม่ ในช่วงกลางทศวรรษ 1990 D. J. Bernstein ผู้เขียนโปรแกรมรับส่งเมล qmail (ซึ่งเราเองก็เคยใช้อยู่เมื่อกว่าสิบปีก่อน) ไม่ไว้ใจแม้แต่ไลบรารีมาตรฐานของภาษา C ซึ่งเป็นชิ้นส่วนที่มากับตัวภาษา และทุกคนใช้กันโดยไม่ตั้งคำถาม เขาระบุไว้ในบันทึกการออกแบบว่า เขาแทบจะเลิกใช้ไลบรารีมาตรฐาน และแทนที่ส่วนที่เกิดอุบัติเหตุได้ง่ายที่สุด เช่น การจัดการสตริงและการจัดการหน่วยความจำ ด้วยชิ้นส่วนเล็ก ๆ ของเขาเองที่พัฒนามาหลายปี เขาไม่ได้ไปไกลถึงขั้นสร้างระบบปฏิบัติการขึ้นใหม่ แต่มีอยู่ข้อหนึ่งที่เขาทำอย่างถึงที่สุด นั่นคือ เอาส่วนที่อันตรายมาไว้ในการควบคุมของตัวเอง

สิ่งที่แล่นอยู่ตลอดทั้ง qmail คือแนวคิดของ การลดสิ่งที่คุณจำเป็นต้องเชื่อใจให้เหลือน้อยที่สุด นอกจากจะเขียนชิ้นส่วนของตัวเองแล้ว เขายังแบ่งภายในโปรแกรมออกเป็นส่วนเล็ก ๆ ตามหน้าที่ และสร้างขึ้นในแบบที่แม้แต่ชิ้นส่วนของเขาเองก็ไม่เชื่อใจกันและกัน ถ้าชิ้นใดชิ้นหนึ่งถูกยึด มันก็ไปต่อไม่ได้ มีคนคิดเรื่องนี้จนตกผลึกตั้งแต่สามสิบปีก่อน แน่นอนว่าเราเลียนแบบการเขียนไลบรารีเองทั้งหมดไม่ได้ แต่แนวคิดที่ว่า ให้ขีดเส้นแบ่งโดยตั้งสมมติฐานไว้ก่อนว่าจะมีของที่เชื่อใจไม่ได้ปนเข้ามา นั้น ใช้ได้กับวันนี้โดยตรง

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

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

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

■ มากกว่าการเขียนโค้ด คือวิศวกรรมระบบ

เมื่อมองย้อนกลับไปตลอดทั้งปี นี่คือจุดที่ความรู้สึกของผมเปลี่ยนไปมากที่สุด สิ่งที่จะขาดไม่ได้จริง ๆ นับจากนี้ ไม่ใช่การเขียนโค้ดเอง แต่คือ วิศวกรรมระบบ

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

เมื่อเวลาที่ใช้เขียนโค้ดลดลง เราก็เริ่มใช้เวลาไปกับการออกแบบ กับการใช้งานจริง และกับการตัดสินว่าเมื่อไรควรหยุด น่าขันตรงที่ การหายไปของแรงที่ใช้เขียน กลับทำให้น้ำหนักของงานที่มาก่อนการเขียน มองเห็นได้ชัดขึ้นมาก

■ ทุกกระบวนการทำเองในโรงงาน ที่ Arita

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

เรื่องนี้เหมือนกับการทำอีจิทุกประการ ต้นแบบประกอบขึ้นมาได้เร็วกว่าเมื่อก่อนมาก แต่ขั้นตอนการยืนยันผลในทะเลนั้น ย่นให้สั้นลงไม่ได้ด้วยวิธีใดเลย สิ่งที่ตัดสินว่าดีหรือไม่ดีในบั้นปลาย คือทะเลเสมอ ยิ่งเราสร้างได้เร็วเท่าไร เราก็ยิ่งทุ่มเวลาไปกับการยืนยันมากขึ้นเท่านั้น นั่นคือวิธีใช้ที่เราเลือกแล้ว

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

■ ออกทะเลในเดือนนี้

เดือนกันยายนนี้มีสีใหม่และสินค้าใหม่ตามมาหลายรายการ Akazamurai Meteor Glow Orange เป็นสีส้มที่เปลี่ยนอารมณ์ไปมาระหว่างการเรืองแสงกับการส่องด้วยไฟ UV มีกำหนดวางจำหน่ายในเดือนนี้ JetChaser Purple Edition ซึ่งเล็งไปที่ tip-run จากฝั่ง ก็อยู่ในเดือนนี้เช่นกัน นอกจากนี้ JetChaser size 3.0 และ size 3.1 จะวางจำหน่ายทั่วไป โดยมีกำหนดจัดส่งช่วงปลายเดือนกันยายน

ปีนี้ยังเป็นปีที่สิบห้านับจากที่สี “Akazamurai” ของ EgiSharp ถือกำเนิดขึ้น เมื่อปลายเดือนที่แล้วเราได้เผยแพร่ภาพของสีที่ทำขึ้นเพื่อฉลองครบรอบสิบห้าปี การที่มันยังคงถูกเลือกใช้มาตลอดสิบห้าปี ไม่ใช่ความมั่นใจของเราเอง แต่เป็นคำตอบที่ผู้ใช้งานมอบให้

ไม่ว่าเครื่องมือจะฉลาดขึ้นเพียงใด คนที่ตัดสินในตอนท้ายก็คือมนุษย์ และสิ่งที่ชี้ขาดว่าดีหรือไม่ดีคือทะเล เราจะจดจำสิ่งนี้ไว้ และเดินหน้าสร้างสิ่งของต่อไปทีละก้าว ขอขอบพระคุณสำหรับการสนับสนุนในเดือนนี้อีกครั้งครับ

กันยายน 2026
KeyStone Corporation
Nobuhide Kanagawa, ประธานบริษัท