- เมื่อ 'slop' ซึ่งเป็นคอนเทนต์คุณภาพต่ำที่สร้างโดย AI แพร่กระจายไปทั่วอินเทอร์เน็ต ก็เริ่มเห็นปรากฏการณ์คล้ายกันในโลกซอฟต์แวร์ ไม่ใช่แค่ในเพลง วิดีโอ หรือข้อความ
- การผลิตคอนเทนต์ถูกทำให้เหมาะที่สุดโดยมีเป้าหมายเพียง การเพิ่มการมีส่วนร่วมและรายได้ให้สูงสุด จน จิตวิญญาณแห่งงานช่างและความคิดสร้างสรรค์ค่อย ๆ หายไป
- คุณภาพที่ตกต่ำและความเสื่อมถอยทางเทคนิค ของบริษัทยักษ์ใหญ่ด้านเทคโนโลยีเริ่มมาตั้งแต่ก่อนการมาถึงของ AI แล้ว และ การแบ่งงานเป็นส่วนย่อยแคบ ๆ ก็ทำให้ทักษะและความสามารถในการคิดของวิศวกรอ่อนแอลง
- AI agent มีประโยชน์กับงานทำซ้ำที่นิยามไว้อย่างชัดเจน แต่ก็มี ข้อจำกัดพื้นฐาน คือชอบแต่งเรื่อง ไม่เข้าใจโค้ดอย่างแท้จริง และสร้างโค้ดที่แย่
- เช่นเดียวกับขบวนการ Arts and Crafts ในศตวรรษที่ 19 นี่อาจเป็นเวลาที่ซอฟต์แวร์ควรฟื้นแนวคิดจากยุคคอมพิวเตอร์ตอนต้นและปลุกจิตวิญญาณแห่งงานช่างที่ยึดมนุษย์เป็นศูนย์กลางกลับมาอีกครั้ง
การแพร่กระจายของ AI slop และแนวคิดเรื่อง technique
- หลังการเปิดตัวโมเดล AI คอนเทนต์ AI คุณภาพต่ำที่ถูกเรียกว่า ‘slop’ ก็เพิ่มขึ้นอย่างรวดเร็วทั้งในเสียง วิดีโอ และข้อความ
- คอนเทนต์ขยะมีอยู่เสมอ แต่ AI ทำให้แรงงานที่ใช้ในการผลิต ลดลงหลายสิบเท่า
- ในงานที่ ขาดการพินิจพิจารณา หรือไม่จำเป็นต้องพินิจพิจารณามากนัก AI ไปถึงระดับที่ แทนแรงงานมนุษย์ได้เพียงพอ แล้ว
- แนวคิด 'technique' ของ Jacques Ellul: วิธีคิดที่ลดทอนกิจกรรมให้เป็น ชุดของวิธีการที่มีประสิทธิภาพ เพื่อมุ่งสู่เป้าหมายที่วัดผลและนิยามได้
- Instagram Reels, วิดีโอ YouTube และบล็อกโพสต์ ถูกมองว่าเป็นผลงานที่ “ดี” หาก ดึง engagement ได้มากที่สุดด้วยความพยายามน้อยที่สุด
- ความหมกมุ่นกับตัวชี้วัดและผลลัพธ์ได้กัดกิน คุณค่าที่จับต้องไม่ได้ อย่างความเป็นงานช่าง ความงาม และความเพลิดเพลิน
เปรียบเทียบแพลตฟอร์มเพลง: Bandcamp vs Spotify
- Bandcamp: เน้นอัลบั้มเต็มและการคัดสรรโดยบุคคล
- ช่วยหนุนกระแสดนตรีอินดี้ในช่วงทศวรรษ 2010~2020 และผลักดันศิลปินอย่าง Car Seat Headrest, Mitski, Alex G, Phoebe Bridgers
- ในฐานะแพลตฟอร์มที่ให้ดนตรีเป็นเป้าหมายหลัก จึง ห้าม เพลงที่สร้างโดย AI
- Spotify: โมเดลที่ตั้งอยู่บนเพลย์ลิสต์และการแนะนำโดยอัลกอริทึม
- โฟกัสที่ การปรับให้เหมาะกับตัวชี้วัด มากกว่าตัวดนตรีเอง
- การแพร่กระจายของ muzak ที่จืดชืดและถูกปรับให้เข้ากับอัลกอริทึม
- ในสภาพแวดล้อมที่ไม่ให้ความสำคัญกับจิตวิญญาณแห่งงานช่าง AI สามารถผลิตคอนเทนต์จำนวนมหาศาลที่ ได้เปรียบกว่าดนตรีที่มนุษย์สร้างในแง่ 'การเพิ่มรายได้สูงสุด'
ปรากฏการณ์คุณภาพถดถอยในอุตสาหกรรมซอฟต์แวร์
- ก่อน AI จะมาถึง ซอฟต์แวร์จำนวนมากก็อยู่ในสภาพ คุณภาพต่ำโดยรวม อยู่แล้ว
- วิศวกรรมซอฟต์แวร์ในบริษัทยักษ์ใหญ่ด้านเทคโนโลยีถูกบิดเบือนจนคล้าย ‘งานเดินท่อ (plumbing)’
- เหลือเพียงบทบาทเชื่อมหลายระบบเข้าด้วยกันเพื่อให้ข้อมูลไหลผ่าน
- แนวคิดเรื่อง ‘งานยิ่งใหญ่’ ของ Richard Hamming หรือการสร้างของขวัญให้มวลมนุษยชาติ กลับถูกมองว่าอุดมคติเกินไปในอุตสาหกรรมเทคโนโลยีปัจจุบัน
- ระบบซอฟต์แวร์ขนาดใหญ่จำนวนมากอยู่ในสภาพ เทอะทะ ออกแบบหยาบ และเอกสารไม่เพียงพอ
- ผู้ใช้ต้องอยู่ในภาวะตั้งรับตลอดเวลาเพื่อไม่ให้ถูกเอาเปรียบในกระบวนการ ‘enshittification (การทำให้คุณภาพเสื่อมลง)’ ของแพลตฟอร์มที่แย่ลงเรื่อย ๆ
- ผู้เขียนเห็นพ้องกับมุมมองจากบรรยายของ Jonathan Blow เรื่อง การป้องกันการล่มสลายของอารยธรรมซอฟต์แวร์
- วิศวกรมืออาชีพและบริษัทซอฟต์แวร์ขนาดใหญ่ ลืมวิธีทำงานให้ถูกต้องไปแล้ว
- ด้วยโครงสร้างแบบ การผูกขาดที่ไม่ต้องแข่งขัน จึงได้รับการปกป้องจากแรงกดดันของตลาด
- แนวปฏิบัติด้านซอฟต์แวร์จึงหย่อนยานลง
- องค์กรก็อืดใหญ่ขึ้น
- และคุณภาพโดยรวมก็ตกต่ำลงอย่างมาก
- วิศวกรในบิ๊กเทคทำหน้าที่เพียง บทบาทที่จำกัดอย่างยิ่ง ภายในองค์กรขนาดมหึมา
- ความสามารถด้านวิศวกรรมที่กว้างขวางและจิตวิญญาณแห่งงานช่างจึง เสื่อมถอยลงตามธรรมชาติ
ปัญหาของทุนมนุษย์และการแบ่งงาน
- สิ่งที่บริษัทหรือสังคมจะทำได้ด้วยคอมพิวเตอร์ขึ้นอยู่กับ ทุนมนุษย์ หรือก็คือจะสามารถบ่มเพาะวิศวกรที่มีทักษะกว้างรอบด้านได้มากเพียงใด
- โครงสร้างการแบ่งงานสุดโต่งของบริษัทเทคโนโลยีขนาดใหญ่
- สร้างแรงงานเทคนิคที่มี ทักษะแคบเฉพาะทาง จำนวนมาก
- และทำให้พวกเขากลายเป็นบุคลากรที่ทำงานได้เฉพาะภายในโครงสร้างองค์กรของบิ๊กเทคแบบปัจจุบันเท่านั้น
มีสองปรากฏการณ์ที่ทำให้ AI ถูกมองว่าเป็นภัยต่อวิศวกรรมซอฟต์แวร์
- 1. การรับรู้ที่เป็นจริงว่า AI agent คุกคามงานวิศวกรรมซอฟต์แวร์เชิงวิชาชีพ
- สำหรับวิศวกรที่บทบาทถูกย่อส่วนเหลือเพียง การผลิตซอฟต์แวร์คุณภาพต่ำแบบทำซ้ำและขอบเขตแคบ
- AI ทำหน้าที่เป็นตัวทดแทนที่มีประสิทธิภาพได้จริงพอสมควร
- 2. การเหมารวมเกินจริงเกี่ยวกับความสามารถของ AI agent
ข้อจำกัดพื้นฐานของ AI agent
- หากจะให้คำกล่าวข้างต้นเป็นจริง ก็ต้องตั้งอยู่บนมุมมองที่ คับแคบอย่างยิ่ง ว่าซอฟต์แวร์คืออะไร
- เช่นเดียวกับเพลงที่สร้างโดย AI ซึ่งต้องอาศัยมุมมองที่มองดนตรีเป็นเพียงตัวชี้วัดการบริโภค
- มองซอฟต์แวร์เป็นแค่เครื่องมือเพื่อให้บรรลุเป้าหมาย และมีท่าทีว่า “ดีพอใช้ก็พอ”
- จากการทดลองใช้ AI agent โดยตรง พบว่ามันมีประโยชน์จริง แต่ก็มี ขีดจำกัดที่ชัดเจน
- มักพูดเรื่องไม่จริงอย่างน่าเชื่อถือ เข้าใจบริบทได้ไม่ดี และสร้างโค้ดคุณภาพต่ำบ่อยครั้ง
- บางด้านอาจพัฒนาต่อได้ แต่เช่นเดียวกับเพลงหรือข้อความ ก็มี ข้อจำกัดเชิงโครงสร้าง ที่ชัดเจน
- AI agent ไม่มีความคิดที่เป็นอิสระด้วยตัวเอง และไม่สามารถรู้ได้เองว่าผู้ใช้ต้องการอะไร
- กรณีที่มันทำงานได้ดีที่สุดคือเมื่อ คำขอระบุปัญหาไว้อย่างชัดเจน
- ตัวอย่าง: “เขียน unit test”, “สร้างฟังก์ชัน DB ในรูปแบบนี้”
- ความพยายามที่จะขยายความสามารถของมันให้ครอบจักรวาลนั้น มักล้มเหลว
- และมักลงเอยด้วย โค้ดประหลาดคล้ายสัตว์ประหลาด ที่ใหม่ก็จริง แต่ดูแล ทำความเข้าใจ และต่อยอดได้ยาก
ปัญหาของ “Vibe Coding”
- ช่วงแรกอาจดูน่าทึ่ง แต่เมื่อเวลาผ่านไป ข้อบกพร่องเฉพาะตัว จะยิ่งเด่นชัด
- โค้ดที่ เยิ่นเย้อเกินจำเป็น และสไตล์ที่ขาดความใส่ใจ
- โครงสร้างเรียบง่ายแต่ แบนราบและยากจนทางสุนทรียะ
- ร่องรอยเฉพาะแบบที่โผล่ซ้ำ ๆ เริ่มให้ความรู้สึกรำคาญมากขึ้นเรื่อย ๆ
- เมื่อเกิดปัญหา กระบวนการ debug จะกลายเป็น งานวนซ้ำที่ชวนหงุดหงิด
- เปิดวิดีโออื่นดูไป หรือไถโซเชียลมีเดียไปพลางอย่างเหม่อลอย
- แล้วคอยส่งคำสั่งกับ agent ซ้ำ ๆ ว่า “มีบั๊ก แก้อีกที”
- ลักษณะที่มักพบในโค้ดที่สร้างโดย AI
- ปุ่มที่มี padding มากเกินไป
- ระยะห่างและสีที่ไม่สม่ำเสมอ
- ความแบนราบทางสุนทรียะโดยรวม
- องค์ประกอบ UI ที่ไม่ชัดเจนว่ามีไว้ทำไม
- แนวโน้มที่จะใส่ label และคำอธิบายที่ไม่จำเป็นให้กับทุกองค์ประกอบ
ปัญหาเชิงระบบของอุตสาหกรรมซอฟต์แวร์และความจำเป็นของจิตวิญญาณแห่งงานช่าง
- ยากจะปฏิเสธว่าซอร์สโค้ดส่วนใหญ่ไม่ได้ดีนัก โดยเฉพาะในสภาพแวดล้อมขององค์กรขนาดใหญ่
- หากใช้ AI ก็จะสามารถผลิตซอฟต์แวร์คุณภาพต่ำ ได้เร็วขึ้นและมีประสิทธิภาพขึ้น ต่อไป
- แต่ AI ไม่ได้ช่วยแก้ ปัญหาเชิงระบบสำคัญ ที่อุตสาหกรรมซอฟต์แวร์กำลังเผชิญ
- ปัญหารากฐานคือ เรายังไม่รู้ด้วยซ้ำว่าจะสร้างซอฟต์แวร์ให้ดีในสเกลขนาดใหญ่ได้อย่างไร
- การคลี่คลายปัญหานี้ต้องการไม่ใช่ระบบอัตโนมัติ แต่เป็น จิตวิญญาณแห่งงานช่างและการคิดเชิงวิพากษ์ของมนุษย์
ความคล้ายคลึงระหว่างขบวนการ Arts and Crafts กับซอฟต์แวร์
- ผู้เขียนให้ความสำคัญกับขบวนการ Arts and Crafts ในช่วงการปฏิวัติอุตสาหกรรมครั้งที่สอง
- John Ruskin และ William Morris ตอบสนองต่อยุคที่เครื่องจักรและการผลิตเชิงอุตสาหกรรมอันน่าทึ่งกำลังเบียดขับช่างฝีมือรายบุคคล
- พวกเขาไม่ได้มองการผลิตเชิงอุตสาหกรรมว่าเป็นความก้าวหน้าโดยอัตโนมัติ แต่เห็นว่ามันมี ‘สไตล์’ เฉพาะตัว ทั้งในผลผลิตและเงื่อนไขการทำงานที่มันสร้างขึ้น
- วิจารณ์ว่าคนงานกำลังค่อย ๆ กลายเป็น ชิ้นส่วนประกอบของเครื่องจักรอุตสาหกรรมขนาดยักษ์
- ชี้ว่ามีขอบเขตที่เครื่องจักรทำแทนไม่ได้อย่างชัดเจน และสิ่งนั้นไม่เปลี่ยนทั้งในอดีตและปัจจุบัน
- โดยมุ่งฟื้น จิตวิญญาณแห่งงานช่างแบบยุคกลาง กลับมาเป็นแรงบันดาลใจ
การเปลี่ยนผ่านแบบเดียวกันที่ซอฟต์แวร์ต้องการ
- วงการซอฟต์แวร์เองก็ต้องการ การเปลี่ยนผ่านและขบวนการลักษณะคล้ายกัน
- จำเป็นต้องกลับไปศึกษาและฟื้นวิธีคิดกับวิธีทำคอมพิวเตอร์ในยุคแรก ๆ
- มี คลังสมบัติอันอุดมสมบูรณ์ ของแนวคิดที่แม้ถูกกระแสหลักเมินเฉย แต่ไม่เคยสูญหายไป
- เป็นโครงการที่ น่าประทับใจและงดงาม ในแบบที่ต่างจากซอฟต์แวร์ทุกวันนี้
- ปัจจุบันเราเกาะอยู่บน กิ่งก้านที่แคบมากของวิวัฒนาการเทคโนโลยี คือเส้นทางจาก C/Unix ไปสู่ Javascript/เว็บ
- ทั้งที่ยังมีพื้นที่ให้สำรวจอีกกว้างไกลกว่านั้นมาก
- เพียงขยับออกนอกแนวทางดั้งเดิมเล็กน้อย ความช่วยเหลือจาก AI ก็แทบหายไปทันที
- ผู้เขียนลองให้ Claude เขียน Forth และพบว่า ผลลัพธ์แทบจะเป็นตัวถ่วง
- ขอแนะนำ Permacomputing wiki เป็นจุดเริ่มต้น
ภาพอนาคตในยุคของโค้ด AI
- โค้ด AI อาจทำให้ ซอฟต์แวร์คุณภาพต่ำที่ผลิตแบบจำนวนมาก กลายเป็นเรื่องธรรมดายิ่งขึ้น
- ขณะเดียวกัน มันก็อาจเปิดพื้นที่ใหม่ให้กับ วิศวกรที่ต้องการฟื้นจิตวิญญาณแห่งงานช่างและการแสดงออกเชิงสร้างสรรค์
- ผู้เขียนไม่ได้มองในแง่ร้าย: ยิ่งจิตวิญญาณแห่งงานช่างหาได้ยาก มันก็ยิ่งมีคุณค่าในตัวเองมากขึ้น
- ในช่วงเวลาที่ซอฟต์แวร์กระแสหลักเผยให้เห็นขีดจำกัด คุณภาพซอฟต์แวร์ยังคงเสื่อมลง และ ความตื่นตัวทางการเมือง กำลังทำให้คุณค่าของโครงสร้างแบบรวมศูนย์ถูกนำกลับมาทบทวน
- นี่จึงเป็นจังหวะอันเหมาะที่ ซอฟต์แวร์เชิงทดลอง ที่มนุษย์สร้าง และดำเนินการในระดับที่มนุษย์รับไหว จะเปล่งประกายจากชายขอบ
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
ชอบช่วงที่กล่าวถึงแนวคิดของ Jacques Ellul
มันทำให้กลับมาคิดอีกครั้งว่า แก่นแท้ของ ‘ความก้าวหน้า’ ทางเทคโนโลยี คือการยกให้ประสิทธิภาพเป็นคุณค่าสูงสุด
น่าสนใจที่คุณค่านี้แทบไม่เคยถูกตั้งคำถามและถูกยอมรับไปโดยปริยาย แต่ก็ยังเชื่อว่าเรายังเลือกทางอื่นได้
โดยเนื้อแท้แล้วประสิทธิภาพมักแลกมาด้วยการลดทอน ความสามารถในการปรับตัวและความยืดหยุ่นในการฟื้นตัว
ในทางกลับกัน ความประณีตแบบช่างฝีมือ ความใส่ใจ และความน่าอัศจรรย์ วัดได้ยาก เมตริกที่ฉันใช้คืออีเมลจากผู้ใช้จริง ซึ่งไม่สม่ำเสมอและคาดเดาไม่ได้
คิดว่าการใช้ coding agent ก็สามารถสร้าง โค้ดคุณภาพสูง ได้
มันไม่ใช่แค่พรอมป์ครั้งเดียวแล้วจบ แต่ต้องอาศัย กระบวนการที่ประสานกัน ของการวางแผน–ลงมือทำ–ตรวจสอบ–รีวิว
ท้ายที่สุดมันก็ยังเป็นงานวิศวกรรมอยู่ดี แค่เครื่องมือเปลี่ยนไป เหมือนความต่างระหว่างเลื่อยมือกับเลื่อยไฟฟ้า ผลลัพธ์อาจเหมือนกันแต่กระบวนการต่างกัน
ซอฟต์แวร์องค์กรนั้นคุณภาพแย่เป็นพิเศษเพราะขายให้ ผู้จัดการที่ไม่ได้เป็นคนใช้งาน
ขณะที่ซอฟต์แวร์ผู้บริโภค ผู้ใช้เป็นคนเลือกเองจึงมักใช้งานเป็นมิตรกว่า
เวลาเขียนโค้ดให้ตัวเอง เรามักทำแค่ฟีเจอร์ที่จำเป็น จึงอาจหยาบ ๆ แต่ใช้งานได้ดี
coding agent ใช้เหมือน เครื่องฉีดน้ำแรงดันสูง สำหรับล้างโปรเจกต์ได้ มันไม่ใช่งานศิลปะ แต่ก็น่าพอใจ
แค่ไม่ควรเอาไปใช้กับโค้ดที่ละเอียดอ่อน อย่างไรก็ตาม เว็บแอปส่วนใหญ่มักมีเทสต์ที่ดีอยู่แล้ว และตอนนี้แทบไม่มีเหตุผลที่จะต้องทำเองแบบ manual
ผลคือมี ฟีเจอร์และ toggle ที่ไม่จำเป็น เต็มไปหมด
ผู้จัดการต้องการความถูกต้องของข้อมูล แต่พนักงานบ่นว่าการกรอกข้อมูลน่ารำคาญ
หลายครั้งก็ไม่มีงบสำหรับการเชื่อมต่อระบบ หรือเป็นสัญญาระยะสั้นจนทำ การเชื่อมต่อกับ CRM ไม่ได้
ส่วนซอฟต์แวร์องค์กรก็มักบิดเบี้ยวเป็นเวิร์กโฟลว์ประหลาด ๆ เพราะแรงจูงใจของผู้จ่ายเงินกับผู้ใช้ไม่สอดคล้องกัน
วิศวกรซอฟต์แวร์ส่วนใหญ่แม้ก่อนยุค AI ก็ให้ความสำคัญกับ เงินเดือนและประสิทธิภาพ มากกว่าความเป็นช่างฝีมืออยู่แล้ว
เพราะงั้นโค้ดที่ AI สร้างออกมาก็เป็นแค่โค้ดธรรมดาตามนั้น
คิดว่า AI ไม่ได้จะชุบชีวิตความเป็นช่างฝีมือกลับมา แต่จะ ลบแม้แต่ร่องรอยสุดท้ายของมันออกไป มากกว่า
เหมือนที่เครื่องมือไฟฟ้าไม่ได้ทำให้งานไม้แบบทำมือหายไป AI ก็คงเป็นแบบนั้น
ในอนาคตจะมีทั้ง “คนสาย IDE” และ “คนสายพรอมป์ต์ agent” อยู่ร่วมกัน
ดีใจที่มีการพูดถึง Forth เพราะใช้บ่อย
โค้ด Forth ที่ LLM สร้างนั้น สไตล์แย่เหมือนแปลมาจาก C
Forth มาตรฐานควรสั้นและชัดเจน แต่ LLM กลับสร้างโค้ดยาวที่เต็มไปด้วยเงื่อนไขซ้อนกัน
ช่วงนี้กำลังอ่าน Turing’s Cathedral
มันทำให้ตระหนักถึง ความเป็นช่างฝีมือเชิงวิศวกรรม ของอเมริกาหลังสงครามอีกครั้ง
ตอนนี้เราดูเหมือนจะมองทุกอย่างเป็นเรื่องธรรมดา และลืมไปแล้วว่างานวิศวกรรมจริง ๆ เคยเป็นอย่างไร
เดิมทีโค้ดส่วนใหญ่ก็ แย่อยู่แล้ว
ในวัฒนธรรมที่ยึดผลลัพธ์เป็นหลัก คุณภาพจึงกลายเป็นเรื่องรอง และบั๊กก็ถูกมองเป็นส่วนหนึ่งของต้นทุนทางธุรกิจ
AI เข้ากับสภาพแวดล้อมแบบนี้ได้อย่างสมบูรณ์แบบ มันกำลังเติบโตในวัฒนธรรมโค้ดที่มีมาตรฐานต่ำอยู่แล้ว
คิดว่าสามารถใช้ AI เพื่อสร้างซอฟต์แวร์ที่ดีกว่าเดิมได้
แม้แต่ในโค้ดที่ AI สร้างก็ยังสะท้อน การออกแบบ แพตเทิร์น และ best practice ได้
มันคล้ายความต่างระหว่างการทำกีตาร์แบบดั้งเดิมกับการทำกีตาร์สมัยใหม่ด้วย CNC
ถ้าดู วิดีโอการทำกีตาร์ของ Ulrich Teuffel จะเห็นว่าเทคโนโลยีกับศิลปะอยู่ร่วมกันได้
แน่นอนว่าความเป็นช่างฝีมือนั้นมีราคาแพง คนส่วนใหญ่จึงเลือกสินค้าที่ผลิตแบบอุตสาหกรรม
ตอนนี้กำลังนำไปใช้กับโปรเจกต์ขนาดใหญ่ แต่ผลระยะยาวยังไม่แน่ชัด
อัลกอริทึมที่แต่ก่อนเขียนเอง ตอนนี้ให้ agent ทำแทน
เหมือนเปลี่ยนจากการกัดด้วยมือไปใช้ CNC ฉันพัฒนาสแตกเทคโนโลยีเพื่อสร้างผลงานที่คุณภาพสูงขึ้น
ถ้าใช้ AI เพื่อทำซอฟต์แวร์แย่ ๆ ให้ถูกลงได้ ก็ไม่เป็นไร
สิ่งสำคัญคือ สัดส่วนของซอฟต์แวร์ดี ๆ จะเพิ่มขึ้นหรือไม่ และ AI ก็เพิ่มโอกาสนั้นได้
AI เติบโตได้ดีในสภาพแวดล้อมที่ซอฟต์แวร์ถูกปรับให้ถึงระดับ ‘ดีพอใช้’
แทนที่จะมาแทนที่วิศวกรชั้นยอด มันกลับกำลังเปิดเผย ความเป็นจริงของอุตสาหกรรมที่เป็นเชิงกลและยึดเมตริกเป็นศูนย์กลาง อยู่แล้ว
ยิ่งโค้ดที่ผลิตแบบจำนวนมากกลายเป็นเรื่องปกติเท่าไร วิจารณญาณและสุนทรียภาพ ของมนุษย์ก็จะยิ่งเป็นทรัพยากรหายากที่แท้จริง