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

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

สำหรับผมเอง ตอนทำงานใช้ AI อยู่หลัก ๆ 3 ส่วน คือ การเขียนเอกสารหรืออีเมล การวิเคราะห์โค้ดเดิมและประเด็นปัจจุบัน และการสร้างหรือแก้ไขโค้ดตามประเด็นนั้น
ในกรณีของเอกสารหรืออีเมล ผมก็แค่อ่านผลลัพธ์ด้วยตัวเองแล้วนำไปใช้ตามนั้น หรือไม่ก็แก้คร่าว ๆ แล้วใช้ แต่ถ้าเป็นงานที่เกี่ยวกับการสร้างหรือแก้โค้ด ผมจะใช้อย่างระมัดระวังกว่ามาก เพราะพอพูดลอย ๆ ว่า "ช่วยแก้อันนี้หน่อย" AI ก็อาจตีความคำสั่งของผมอย่างกำกวม หรือบางครั้งถึงขั้นไปแตะส่วนที่ผมไม่ได้พูดถึงเลยตามอำเภอใจ
เพราะแบบนั้น ก่อนแก้โค้ดผมจึงตั้ง global prompt ไว้เลยว่า ต้องเสนอเอกสารสเปกตาม STICC ก่อนเสมอเพื่อให้ผมอนุมัติอย่างชัดเจน จากนั้นงานแก้ไขจริงก็ให้ทำเฉพาะตามที่ระบุไว้ในสเปกเท่านั้น และหลังแก้เสร็จผมก็ตรวจ diff ทั้งหมดด้วยตัวเองทุกครั้ง ส่วนการรันคำสั่งอย่าง build ก็ต้องให้ผมอนุมัติก่อนเสมอ หรือไม่ก็ผมรันเองในเทอร์มินัลแบบแมนนวลไปเลย
ทำแบบนี้แล้วก็มีข้อเสียตรงที่เรื่องเล็ก ๆ น้อย ๆ บางอย่างผมลงมือแก้เองด้วยมือจะเร็วกว่า แต่ก็ดีกว่าให้ AI ไปแตะอะไรแปลก ๆ ตามใจตัวเองจนเกิดปัญหา เพราะสุดท้ายถ้ามันพังในสภาพแวดล้อม production คนที่ต้องรับผิดชอบก็คือผมไม่ใช่หรือครับ

ผมนึกถึงคำพูดที่มักอ้างว่าเป็นของ Peter Drucker เพื่อโต้แย้งกฎของ Goodhart
"ถ้าวัดไม่ได้ ก็จัดการไม่ได้ (If you can't measure it, you can't manage it)"
พอลองค้นต่อดู ก็พบว่าแม้แต่ Drucker Institute เองก็ระบุว่า Drucker ไม่เคยพูดแบบนั้น

กลับกัน ผมกลับเจอคำพูดที่มีความหมายตรงข้าม
การคิดว่าถ้าวัดไม่ได้ก็จัดการไม่ได้เป็นความเข้าใจที่ผิด — มันเป็นมายาคติที่มีราคาแพง (It is wrong to suppose that if you can't measure it, you can't manage it—a costly myth) - Edwards Deming

ขอบคุณสำหรับข้อมูลดี ๆ ครับ :D

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

รีบเปลี่ยนอย่างไว แต่ฝั่งภายนอกดันถูกเผยแพร่ออกไปแบบนั้นซะแล้ว ฮือ

บางครั้งผมก็ต้องไปแตะ ๆ ฟรอนต์เอนด์ที่รันอยู่บนอินทราเน็ตภายในบริษัท แล้วเคยโดนดุมาแล้วครั้งหนึ่งตอนใส่ไอคอนอย่าง ☰ ⋮ ⋯ + ไว้ในแดชบอร์ดที่ผู้บริหารใช้ดู พอท่านถามว่าฟังก์ชันนั้นฟังก์ชันนี้หายไปไหน ผมก็บอกว่ากดปุ่มนี้ได้ครับ แต่ท่านบอกว่ามองไม่เห็น ให้เขียนเป็นข้อความไปเลย สุดท้ายก็เลยต้องย้อนกลับไปใช้อินเทอร์เฟซแบบยุค 2000 ที่เคยใช้กันอยู่... จะว่าไปก็เหมือนทุกอย่างนั่นแหละ ฟรอนต์เอนด์นี่มันยากจริง ๆ

หัวข้อกลายเป็น kills ไปซะแล้ว.. 55555

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

ขอบคุณที่ช่วยทำความเข้าใจครับ

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

เมื่อไม่นานมานี้มีกรณีพบไมโครโฟนในผลิตภัณฑ์ชื่อ nanokvm ที่ออกโดยผู้ผลิตแพลตฟอร์ม embedded จากจีนอย่าง sipeed
เท่าที่ทราบ หลายคนมีความกังวลว่าผลิตภัณฑ์ embedded จากจีนอาจมีจุดอ่อนด้านความปลอดภัย หรือถึงขั้นอาจถูกใช้ในปฏิบัติการด้านความมั่นคงของรัฐก็ได้
จึงไม่แน่ใจว่ามีอคติเดิมสะท้อนอยู่ด้วยหรือไม่ แต่ช่วงหลังยังมีบทความเกี่ยวกับผลิตภัณฑ์นี้ออกมาด้วย: 중국산 NanoKVM에서 숨겨진 마이크를 발견한 과정
แต่ผมคิดว่า sipeed สามารถคลายความเข้าใจผิดจากเหตุการณ์นี้ได้ เพราะตั้งแต่ฮาร์ดแวร์ไปจนถึงการพัฒนาซอฟต์แวร์ของผลิตภัณฑ์นี้ทำแบบโอเพนซอร์ส: https://x.com/lexifdev/status/1999340940805439775

เท่าที่ทราบ ในยุคของสตอลแมน ในวาทกรรมลักษณะนี้ คนที่อยู่ในตำแหน่งนั้นแทนรัฐบาลจีนก็คือรัฐบาลสหรัฐในยุคที่ยังมีอิทธิพลของลัทธิแม็กคาร์ธี และ NSA
มีทั้งกรณีแบ็กดอร์ของ NSA ที่ตอนแรกฟังเหมือนทฤษฎีสมคบคิด แต่ภายหลังก็พิสูจน์ได้ว่ามีจริง และยังมีเรื่อง printer tracking dots (https://en.wikipedia.org/wiki/Printer_tracking_dots) ด้วย
ทุกวันนี้แทนที่จะเป็นทฤษฎีสมคบคิดที่รัฐมีส่วนเกี่ยวข้อง เรื่องที่กำลังฮอตกว่ากลับเป็นการที่บริษัทซึ่งมีรายได้หลักจากโฆษณาแอบดักฟังไมโครโฟนสมาร์ตโฟนเพื่อทำโฆษณาแบบเจาะกลุ่มเป้าหมาย

และในบริษัทเทคโนโลยีซอฟต์แวร์ ผมคิดว่าแม้ซอร์สโค้ดจะมีบทบาทสำคัญมาก แต่ความสะดวกโดยรวม ความสามารถในการให้บริการและการปฏิบัติการ และความน่าเชื่อถือ มีบทบาทมากยิ่งกว่า
ต่อให้ได้ซอร์สโค้ดของ OpenAI มาทั้งหมด ผู้ตามหลังจะสามารถจัดหาและดูแลโครงสร้างพื้นฐานที่รองรับผู้ใช้จำนวนมหาศาลได้อย่างมีเสถียรภาพ และไล่ตามความน่าเชื่อถือของแบรนด์ได้ง่าย ๆ หรือครับ
มีหลายกรณีที่เปิดผลิตภัณฑ์หลักเป็นโอเพนซอร์ส มีฟอร์กจำนวนมาก แต่ก็ยังไม่สูญเสียความเป็นผู้นำ
ถ้าจะยกตัวอย่างที่นึกออกทันที ก็อย่าง Chrome และ VS Code
แน่นอนว่าก็มีกรณีที่สูญเสียอำนาจนำ เช่น Elastic หรือ Redis จากประเด็นเรื่องไลเซนส์โอเพนซอร์สกับ AWS แต่ในทำนองเดียวกัน ผมมองว่าเรื่องนั้นเกิดขึ้นเพราะทั้งสองบริษัทตามหลัง AWS ในด้านความสะดวก ความสามารถในการให้บริการและการปฏิบัติการ และความน่าเชื่อถืออยู่พอสมควร

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

มองได้แม่นยำครับ
สตอลแมนยังยืนกรานด้วยว่าไม่ควรใช้ SaaS เช่นกัน
https://www.gnu.org/philosophy/who-does-that-server-really-serve.html

ให้ความรู้สึกเหมือนโทนเซรามิกเลยนะ

กราฟการขึ้นเงินเดือนของผมเป็น 0% มาตลอด 5 ปีแล้ว

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

ควรปฏิเสธการใช้งาน เพราะการประมวลผลบนเซิร์ฟเวอร์ของผู้อื่นเป็นวิธีที่บั่นทอนเสรีภาพในการคอมพิวติ้งของผู้ใช้

นี่ไม่ใช่การอ้างว่าควรปฏิเสธไม่ใช่แค่ LLM แต่รวมถึงบริการคลาวด์ทั้งหมดกับบริการภายนอกทั้งหมดด้วยหรอกหรือ...? หรือว่าแปลผิด?

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

จะโค้ดแบบ vibe coding ทั้งทีก็ทำด้วย C ไปเลยสิ?

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

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

ยิ่งรู้สึกอีกครั้งว่าการมอบหมายงานเป็นเรื่องยากแค่ไหน

ถ้าเป็นอย่างนั้น ก็ไม่ได้มีผู้ดูแลหลายคนถอนตัวไปแล้วหรือครับ?

มีหนังสือเกี่ยวกับเรื่องนี้ที่เป็นภาษาเกาหลีออกมาเพียงเล่มเดียว แต่ก็น่าเสียดายที่แนวทางการใช้ Rust ใน Linux kernel มีการเปลี่ยนแปลงแบบ breaking change หลายครั้ง จนไม่สามารถใช้งานร่วมกับเคอร์เนลยุคปัจจุบันได้อย่างสมบูรณ์ หากมีการช่วยกันเสริมข้อมูลผ่าน GitHub หรือช่องทางอื่น ๆ ก็คงจะดีมากครับ