คุณภาพในยุคของ Slop

 (sinclairtarget.com)
1 คะแนน โดย GN⁺ 2 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ยืมแนวคิดแกนกลางของหนังสือขายดีปี 1974 อย่าง Quality(คุณภาพ) จาก "ZAMM" มาสำรวจว่าในยุคที่เครื่องมือเขียนโค้ดด้วย AI แพร่หลาย "โค้ดที่ดี" และ จิตวิญญาณแบบช่างฝีมือ(craftsman ethos) ยังมีความหมายอยู่หรือไม่
  • เมื่อ AI ผลิตโค้ดจำนวนมหาศาล อาจเหลือเพียง "โค้ดที่ใช้งานได้กับโค้ดที่ใช้งานไม่ได้" และเส้นแบ่งของโค้ดที่งดงาม โดดเด่น หรือมีคุณค่าก็อาจหายไป ผู้เขียนเรียกความหวาดหวั่นนี้ว่า the Maw(หลุมแห่งความว่างเปล่า)
  • การซ่อมบำรุงรถมอเตอร์ไซค์และการบำรุงรักษาซอฟต์แวร์เป็นกิจกรรมชนิดเดียวกันในแก่นแท้ โดยทั้งสองอย่างมี การสังเกตอย่างละเอียดและการคิดอย่างแม่นยำ เป็นหัวใจสำคัญ
  • แนวคิด Quality ของ Pirsig ผสานความเข้าใจแบบ romantic และแบบ classical เข้าด้วยกัน และแม้แต่รากฐานของวิทยาศาสตร์กับคณิตศาสตร์ก็ยังมีการตัดสินเชิงสุนทรียะและเชิงคุณภาพฝังอยู่
  • หากมอบหมายการเขียนโค้ดให้ AI agent เราจะสูญเสียทั้ง caring(การผูกพันเป็นอันหนึ่งอันเดียวกัน) และ "สัมผัสต่อคุณภาพของงาน" ดังนั้นท่าทีที่มุ่งแสวงหา human excellence(ความเป็นเลิศแบบมนุษย์) ในงานของตนเองจึงสำคัญ

หนังสือชื่อ ZAMM

  • บทความนี้แทบทั้งหมดกล่าวถึงหนังสือขายดีปี 1974 อย่าง "Zen and the Art of Motorcycle Maintenance (ZAMM)" และพูดถึง AI ไปพร้อมกัน
  • ZAMM มักถูกมองว่าเป็นหนังสือ อวดภูมิ(pretentious) และมีคะแนนบน GoodReads อยู่ที่ 3.78 แต่ก็มีรีวิวแย่จำนวนมาก
    • "Zora": ให้ 1 ดาว พร้อมบอกว่าไม่คุ้มแม้แต่อ่าน 3 นาที เป็นหนังสือปรัชญาปลอมที่ปลอมตัวเป็นนวนิยาย และเป็นการหลอกลวงที่ใหญ่กว่าพระคัมภีร์
    • "Lala BooksandLala": ให้ 1 ดาวด้วยคำเพียงคำเดียวว่า "absolutely not"
  • ผู้เขียนยอมรับอย่างตรงไปตรงมาว่าบล็อกโพสต์เกี่ยวกับ ZAMM และ AI อาจฟังดูไม่ใช่อะไรที่ชวนรื่นรมย์นัก

the Maw — หลุมแห่งความว่างเปล่าที่เปิดอยู่กลางวงการเทค

  • the Maw คือ หลุมแห่งลัทธินิฮิลิสม์(nihilism) ที่เปิดอยู่กลางอุตสาหกรรมเทคโนโลยี และเป็นหัวข้อที่บล็อกโพสต์ตามลิงก์แอกกริเกเตอร์อย่าง Hacker News กล่าวถึงราว 63%
  • บทความที่เกี่ยวข้องเมื่อไม่นานมานี้มีอย่างเช่น “Do I Belong in Tech Anymore?”, ซีรีส์ 10 ตอน “The Future of Everything is Lies, I Guess.”, และ “I Think I’m Done Thinking About Gen AI for Now,”
  • แม้ว่าวิศวกรซอฟต์แวร์จะไม่ได้รังเกียจเทคโนโลยีใหม่ แต่กลับพยายามหาเหตุผลที่จะปฏิเสธ เครื่องมือเขียนโค้ดแบบ agentic รุ่นล่าสุด และรู้สึกไม่สบายใจกับนัยที่ว่า linear algebra กำลังเป็นผู้เขียนซอฟต์แวร์

  • ข้อถกเถียง Commenter A vs Commenter B

    • ผู้แสดงความคิดเห็น A บ่นว่า Claude Code ตั้ง ชื่อฟังก์ชัน ที่ชวนให้เข้าใจผิดอย่างแนบเนียน
    • ผู้แสดงความคิดเห็น B (สาวกของ Maw) โต้ว่า AI อ่านเนื้อในของฟังก์ชันทั้งหมดเพื่อทำความเข้าใจความหมายได้อยู่แล้ว ดังนั้นชื่อจึงไม่มีความหมาย และอีกไม่นานมนุษย์ก็จะเลิกอ่านโค้ด
    • ข้ออ้างของผู้แสดงความคิดเห็น B ฟังดูราวกับเป็นการบอกว่า ศาสตร์ทั้งแขนงของวิศวกรรมซอฟต์แวร์ เองก็หมดความจำเป็นลง ไม่ว่าจะเป็น best practices สถาปัตยกรรม หรือความรู้เรื่องการบำรุงรักษา
  • สิ่งที่น่ากลัวที่สุดของ the Maw คือมันพยายามลบ ความแตกต่างระหว่าง good กับ bad ออกไปตลอดกาล และปล่อยให้เหลือเพียงโค้ดที่ทำงานได้กับโค้ดที่ทำงานไม่ได้ โลกที่ไม่มีโค้ดงดงาม โดดเด่น หรือเปี่ยมไหวพริบอีกต่อไป
  • คำถามสำคัญคือ ยังมีโปรแกรมเมอร์ที่ดีและโค้ดที่ดีอยู่หรือไม่, ทำไมความ "ดี" จึงสำคัญ, และ โปรแกรมเมอร์ที่ดีซึ่งใช้เครื่องมือ AI ควรมีหน้าตาอย่างไร

ZAMM แท้จริงแล้วคือหนังสือเกี่ยวกับการเขียนโปรแกรม

  • จะเรียก ZAMM ว่า "Zen and the Art of Software Maintenance" ก็แทบไม่ผิด เพราะการซ่อมบำรุงมอเตอร์ไซค์กับการบำรุงรักษาซอฟต์แวร์เป็นกิจกรรมชนิดเดียวกันในแก่นแท้
  • แก่นของการซ่อมบำรุงไม่ใช่แรงงานทางกาย แต่คือ การสังเกตอย่างละเอียดและการคิดอย่างแม่นยำ และช่างซ่อมก็จดจ่ออยู่กับภาพในใจและลำดับชั้นของสิ่งต่าง ๆ (บทที่ 9 ของ ZAMM)
  • ไม่ว่าจะเป็นเครื่องยนต์พังหรือเว็บเซอร์วิสที่ติด deadlock กระบวนการดีบักก็เหมือนกัน และเหมือนกับมีม "wired in" จากภาพยนตร์ปี 2010 เรื่อง "The Social Network" ที่ช่างซ่อมเองก็สร้างหอคอยแห่งนามธรรมขึ้นในหัว
  • คำแนะนำเชิงกายภาพโดยตรงใน ZAMM มีเพียงสองข้อเท่านั้น (วางเก้าอี้ไว้สองข้างของจักรยานเพื่อถนอมหลัง และจัดการชิ้นส่วนละเอียดอ่อนด้วยความเบามือ) ที่เหลือทั้งหมดเป็นเรื่องของ สภาวะจิตใจ ของช่างซ่อม

  • Gumption Trap (กับดักของแรงใจ)

    • Gumption คือพลังใจสำรองที่ใช้กับกิจกรรมทางปัญญาอย่างการซ่อมบำรุง เปรียบได้กับ "psychic gasoline(เชื้อเพลิงทางจิตใจ)"
    • Gumption trap คือเหตุการณ์ที่ดูดพลังใจในการซ่อมบำรุงไปในคราวเดียว
      • intermittent failure setback: กรณีที่ปัญหาหายไปทันทีที่พยายามจะแก้ ซึ่งในซอฟต์แวร์ก็คือ could-not-reproduce / Heisenbug
      • impatience trap: กรณีประเมินเวลาทำงานต่ำเกินไป จนต้องเร่งตามกำหนด เลือกทางลัด แล้วกลับพลาดหนักจนยิ่งล่าช้า

  • Pirsig เป็นคนชอบคอมพิวเตอร์

    • ที่ Smithsonian มีการจัดแสดง Apple II ที่เสียบการ์ดขยาย 7 ใบ พร้อมกับ Honda Super Hawk ปี 1966 ของเขา
    • Apple II ออกวางจำหน่ายในปี 1977 จึงเป็นของที่เขาซื้อหลัง ZAMM ตีพิมพ์ แต่ก่อนหน้านั้นเขาก็ทำงานเป็น technical writer ให้ Honeywell
    • ใน ZAMM มีอุปมาเกี่ยวกับวงจรและคู่มือคอมพิวเตอร์ดิจิทัลอยู่หลายแห่ง และหากเขาเขียนช้ากว่านั้นอีก 10–20 ปี มันคงกลายเป็นหนังสือเกี่ยวกับคอมพิวเตอร์

Quality (Q ตัวใหญ่) — แก่นความคิดของ ZAMM

  • ที่ ZAMM พูดถึงการซ่อมบำรุง ก็เพราะมันเป็นทางผ่านไปสู่แก่นความคิดสำคัญอย่าง Quality(คุณภาพ)
  • ZAMM ถูกจัดวางเหมือนนิยายสืบสวนเชิงปัญญา
  • จุดตั้งต้นอยู่ที่บทแรก เมื่อ Pirsig สังเกตว่าท่าทีที่เขามีต่อมอเตอร์ไซค์กับท่าทีของ John เพื่อนร่วมทริปขี่รถนั้นแตกต่างกันมาก

  • ความต่างระหว่าง John กับ Pirsig

    • John ซื้อ BMW เยอรมันที่เชื่อถือได้ที่สุดเพื่อ หลีกเลี่ยงงานซ่อมเองที่ทั้งยุ่งยากและดูไม่น่ามอง
    • ส่วน Pirsig เห็นความงามในกลไกภายในของมอเตอร์ไซค์ และมองว่าท่าทีที่ไม่ยอมเข้าใจวิธีการทำงานนั้นไม่เป็นประโยชน์ในทางปฏิบัติ
    • ปริศนาของ ZAMM คือมีแนวคิดใดหรือไม่ที่จะผูกมุมมองทั้งสองเข้าด้วยกัน
    • ท่าทีของ John สอดคล้องกับความเข้าใจแบบ romantic (อารมณ์และความประทับใจฉับพลัน) ส่วนของ Pirsig สอดคล้องกับความเข้าใจแบบ classical (รูปแบบพื้นฐานและนามธรรมเชิงตรรกะ)
    • Pirsig เห็นว่าผู้คนจำนวนมากในช่วงทศวรรษ 1960–70 รู้สึกว่าเทคโนโลยีเป็นสิ่งที่เป็นปฏิปักษ์ ชอบควบคุม และ “square” ขณะที่สังคมและเทคโนโลยีถูกครอบงำด้วยความเข้าใจแบบ classical มากเกินไป จนความเข้าใจสองแบบนี้แยกขาดจากกัน
    • เมื่อความเข้าใจทั้งสองแยกจากกัน และสังคมถูกครอบงำด้วยความเข้าใจแบบ classical จึงจำเป็นต้องมี fulcrum idea(แนวคิดจุดค้ำ) เพื่อทำให้ทั้งสองคืนดีกัน

  • การตระหนักรู้จากการสอนวาทศิลป์

    • Pirsig ย้อนนึกถึงสมัยที่เขาสอนวิชาวาทศิลป์ในมหาวิทยาลัย และตั้งคำถามว่าจริง ๆ แล้วเขาควรสอนอะไรให้นักศึกษา
    • ภารกิจของเขาคือการสอนให้นักศึกษาเขียนให้ดี
    • เขาสอน การเขียนที่ดี ผ่านอุปกรณ์อย่าง metaphor(อุปมา), parallelism(โครงสร้างขนาน), anaphora(การซ้ำต้น) แต่แม้จะมีองค์ประกอบเหล่านี้ครบก็ยังเขียนได้แย่ และแม้ไม่มีเลยก็ยังเขียนได้ดี
    • นักศึกษาสามารถแยกความต่างระหว่างงานเขียนที่ดีกับไม่ดีได้แม้ไม่รู้จักอุปกรณ์เหล่านั้น แปลว่าจำเป็นต้องมีความเข้าใจแบบ romantic ซึ่งเป็นสิ่งที่สอนยากในมหาวิทยาลัยซึ่งเป็นป้อมปราการของความเข้าใจแบบ classical
    • สิ่งที่ Pirsig พยายามสอนก็คือ Quality นั่นเอง
      เป็นสิ่งที่ทุกคนรับรู้ได้ แต่ไม่อาจนิยามอย่างเป็นทางการ และเป็น แนวคิดที่ผูกความเข้าใจแบบ romantic กับแบบ classical ให้เป็นหนึ่งเดียว

  • อภิปรัชญาของ Quality และความยอดเยี่ยมของการตั้งชื่อ

    • เราไม่อาจวัดได้อย่างแน่ชัดว่างานเขียน มอเตอร์ไซค์ หรือประสบการณ์ใดมี Quality สูงหรือต่ำ จึงไม่ใช่สิ่งเชิงวัตถุวิสัย แต่เพราะ Pirsig มองว่า Quality เป็นสิ่งที่ก่อให้เกิดตัวประธาน จึงไม่ใช่เพียงอัตวิสัยเช่นกัน
    • Quality ไม่เป็นวัตถุวิสัยเพราะวัดไม่ได้ และไม่เป็นอัตวิสัยเพราะมีอยู่ก่อนตัวประธาน เป็น ตะแกรง(sieve) ที่ใช้ได้ก่อนการแบ่งเป็นประธานกับวัตถุ
    • ความยอดเยี่ยมของชื่อ "Quality" คือการผสมความหมายของ "คุณค่าสูง" กับ "ลักษณะ/คุณสมบัติ" เข้าด้วยกัน บอกเป็นนัยว่า Good ซึ่งถูกถกเถียงมาตั้งแต่ยุค Plato นั้น ถูกรับรู้ได้ในทันที ก่อนตรรกะและเหตุผล
    • Pirsig เห็นว่าวิทยาศาสตร์และคณิตศาสตร์อาจสอดคล้องและมีตรรกะภายในขอบเขตของมันเอง แต่ที่ฐานรากและบริเวณขอบกลับมีการตัดสินเรื่อง Quality อยู่
    • ในเรขาคณิต เมื่อกำหนดสัจพจน์แล้วก็สามารถอนุมานต่อได้อย่างแน่นอน แต่ถ้าเลือกสัจพจน์อื่น ก็จะได้เรขาคณิตอีกแบบ และคำถามว่าสัจพจน์ใด “ถูกต้องกว่า” ก็ใกล้เคียงกับเรื่องรสนิยมและความเหมาะสมต่อวัตถุประสงค์
    • ในวิทยาศาสตร์ เมื่อได้สมมติฐานแล้ว วิธีการทางวิทยาศาสตร์จะบอกขั้นตอนถัดไปได้ แต่การเลือกว่าจะหยิบสมมติฐานใดจากตัวเลือกนับไม่ถ้วนนั้น ไม่มีวิธีตายตัวและใกล้เคียงศิลปะมากกว่า
    • Henri Poincaré กล่าวว่านักคณิตศาสตร์หรือนักวิทยาศาสตร์ที่อยู่แนวหน้าของความรู้ต้องเลือกหนึ่งทางจากความเป็นไปได้มากมายที่สืบเนื่องจากกฎเดิม และกฎที่ชี้นำการเลือกนั้นละเอียดอ่อนเกินกว่าจะอธิบายได้อย่างแม่นยำ ต้องสัมผัสมันมากกว่าจะทำให้เป็นสูตร
    • Occam’s Razor เองก็เป็นหลักที่ให้เลือกทฤษฎีที่เรียบง่ายกว่า แต่การตัดสินว่าอะไรคือคำอธิบายที่ไม่จำเป็นนั้น ท้ายที่สุดก็ยังเป็น การตัดสินเชิงสุนทรียะและเชิง Quality
    • ต้องเลิกเชื่อคติที่ว่า “วิทยาศาสตร์และลูกของมันอย่างเทคโนโลยีเป็นสิ่งเป็นกลางทางคุณค่า หรือ quality-free” เพราะความประทับใจต่อ Quality ทำหน้าที่เป็นหัวรถจักรที่บอกว่าขบวนแห่งความรู้ควรเคลื่อนไปทางไหน

คำวิจารณ์ AI และคำตอบจาก ZAMM

  • คำวิจารณ์ AI จำนวนมากมุ่งไปที่ว่าเครื่องมือแบบ agentic ทำงานได้จริงตามโฆษณาหรือไม่ (เช่น ทำโค้ดเบสพัง หรือ hallucination ฟังก์ชันที่ไม่มีอยู่จริง)
  • แม้จะยอมรับว่าเครื่องมือ AI ปัจจุบันมักพลาดบ่อย แต่การถกเถียงเรื่องประสิทธิผลก็อาจพาออกนอกประเด็นหลัก
  • วิศวกรจำนวนมากอาจยังไม่อยากใช้เครื่องมือแบบ agent แม้ว่ามันจะทำงานได้ตรงตามที่โฆษณาไว้ก็ตาม

  • ในบทความ "I Think I'm Done Thinking about Gen AI"

    • ผู้เขียนไม่สามารถหักล้าง ข้ออ้างเชิงปฏิบัติ ของอีกฝ่ายด้วยข้อมูลได้ ประสบการณ์ส่วนตัวกับ genAI ก็เลวร้ายมาก แต่ก็เป็นเพียงเกร็ดเล่า ไม่ใช่ข้อมูลเชิงวิทยาศาสตร์ และตอนนี้เองก็แทบไม่มีข้อมูลเชิงวิทยาศาสตร์
    • ต้นตอของอคติเชิงลบอยู่ที่ คุณสมบัติเชิงสุนทรียะ ของ genAI ที่ชวนไม่สบายใจอย่างยิ่ง และจึงสรุปว่าต่อให้ใช้ฟรีก็ไม่อยากใช้
  • ZAMM ช่วยผู้เขียนได้สองทาง

    • อย่างแรก — เคยติดอยู่ในกรอบคิดแบบ classical

      • บทบาทสำคัญที่สุดของ Quality คือเป็น การขยายขอบเขตของเหตุผล เพื่อดูดซับองค์ประกอบที่ไม่เป็นเหตุเป็นผลซึ่งก่อนหน้านี้ไม่ถูกรับรอง
      • การไม่ดูดซับองค์ประกอบที่ไม่เป็นเหตุเป็นผลนี่เองที่ก่อให้เกิด "จิตใจสมัยใหม่ที่สับสนและขาดการเชื่อมต่อ" และเพราะกรอบคิดแบบ classical ครอบงำอยู่ ผู้เขียนจึงเคย มองข้าม(discount) ความรู้สึกต่อต้าน AI ตามสัญชาตญาณของตน
      • ความเห็นของทุกคนล้วนเป็นอัตวิสัยพอกัน ดังนั้นแม้มีงานวิจัยที่บอกว่า "ปริมาณโค้ดเพิ่มขึ้น 50% ด้วย coding agent" ก็ยังมีสิทธิ์ตั้งคำถามว่า "ทำไมเราจึงต้องการโค้ดเพิ่มนั้นตั้งแต่แรก และการตัดสินเชิง Quality แบบใดที่ช่วยให้มนุษย์รุ่งเรืองขึ้น"

    • อย่างที่สอง — เข้าใจตัวตนของความรู้สึกต่อต้าน

      • เทคโนโลยีสมัยใหม่ถูกครอบงำด้วยมุมมองแบบ subject-object(ประธาน-วัตถุแยกขาด) และคู่มือผลิตภัณฑ์ก็ตั้งต้นว่าผู้ใช้เป็นเพียงผู้ที่ "ควบคุมใช้งาน" ผลิตภัณฑ์อย่างไม่เกี่ยวข้องผูกพัน
      • สังคมที่คนไม่ใส่ใจสร้างเทคโนโลยีเพื่อขายให้คนที่ไม่ใส่ใจ
      • ทางออกคือให้ช่างเทคนิค ผูกตัวตนเข้ากับงาน(identify) เมื่อการแยกประธาน-วัตถุหายไป "caring(ความใส่ใจผูกพัน)" ก็เกิดขึ้น และเบื้องหลังสิ่งนั้น Quality จะปรากฏออกมา (ZAMM บทที่ 25)
      • ในงานแต่ละขณะมีทางเลือกนับพันที่ล้วนถูกต้องได้ในเชิง classical และมีเพียง Occam's Razor ที่ยึด Quality เป็นศูนย์กลาง (สัมผัสต่อความดี) เท่านั้นที่พาเราเดินหน้าต่อได้ (ZAMM บทที่ 24)
      • หากปล่อยให้ agent เขียนโค้ดแทน เราจะสูญเสีย "สัมผัสต่อคุณภาพของงาน" โดย LLM อาจมีประโยชน์สำหรับการค้นหาและการ rubber duck แต่เพราะมี randomness(ความสุ่ม) เป็นแก่น และผลิตโค้ดได้มหาศาลจนตามไม่ทัน จึงเพิ่มแรงเสียดทานระหว่างเรากับงาน และทำให้ caring เกิดได้ยากขึ้น

บทสรุป — เป็นแบบอย่างในงานของตนเอง

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

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

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2 시간 전
ความเห็นจาก Lobste.rs

  • กลัวว่าการพัฒนาซอฟต์แวร์จะกลายเป็นอาชีพแบบ สเปกที่เดินได้ ไม่ใช่เพราะเอเจนต์จะทำส่วนที่ยากและจุกจิกที่สุดของงานได้จริง แต่เพราะซอฟต์แวร์ส่วนใหญ่บนโลกเดิมทีก็เป็นแค่ของปะติดปะต่อที่น่าสงสัยซึ่งขอแค่พอทำงานได้ก็พออยู่แล้ว
    เมื่อสิ่งนี้ไปรวมกับ ตลาดเลมอน แบบคลาสสิก SaaS ส่วนใหญ่ก็จะกลายเป็นของปะติดปะต่อที่เต็มไปด้วยบั๊ก และผู้ซื้อก็จะไม่มีความสามารถพอจะแยกแยะของดีออกจากของแย่ได้ จากนั้นราคากับอุปสงค์ก็จะลดลง ยังไงก็จะมีคนใช้ซอฟต์แวร์ต่อไป แต่จำนวนคนโดยรวมจะลดลง และงานส่วนใหญ่ก็น่าจะกลายเป็นการดูแลของกองรวม ๆ ที่เละเทะ ข้อยกเว้นคงมีแค่คนส่วนน้อยที่โชคดีพอจะได้ทำงานในที่อย่าง “ระบบบันทึกข้อมูล” ที่จำเป็นต้องทำงานได้อย่างถูกต้องจริง ๆ
    ในระยะกลางคงเป็นแบบนั้น และเป้าหมายที่แท้จริงของแล็บ AI คือการสร้างบางสิ่งที่มาแทนแรงงานทางปัญญาและทางกายภาพของมนุษย์ทั้งหมดด้วยต้นทุนที่ถูกกว่า ตอนนี้ยังไม่รู้วิธี แต่พวกเขาจะลองโดยยอมทุ่มจนถึง 1 ดอลลาร์สุดท้ายบนโลก ความฝันของนักลงทุนจริง ๆ แล้วแทบจะเป็นผู้สืบทอดทางวิวัฒนาการของมนุษยชาติ
    นโยบาย AI ส่วนตัวของฉันคือแบบนี้ ถ้างานนั้นให้ความสำคัญกับงานฝีมือ ฉันจะใช้ coding agent เป็น ผู้ช่วยศิลปิน คล้ายคนที่เคยวาดฉากหลังให้จิตรกรผู้ยิ่งใหญ่ Opus 4.8 ฉลาดเกินไปจนกลับไม่เหมาะ เพราะมันอาจพาโค้ดเบสหลุดมือไปได้ภายในชั่วโมงสองชั่วโมงแบบหุนหัน ตอนนี้ฉันชอบ Qwen3.6 27B เพราะมันฉลาดพอจะไล่บั๊ก รีแฟกเตอร์ หรือทำฟีเจอร์ที่สเปกชัดเจนได้ในโค้ดที่ฉันยังเข้าใจอยู่ แต่ทันทีที่ฉันสูญเสียความเข้าใจในโค้ดไป โมเดลก็จะสับสนตาม และฉันต้องจ่ายราคาในทันที
    ถ้าเป็นนโยบายสาธารณะ ฉันมองว่าการสร้างผู้สืบทอดทางวิวัฒนาการของตัวเองโดยไม่มีหลักประกันเรื่องการอยู่ร่วมกันได้เป็นเรื่องโง่เขลา เพราะงั้นฉันคัดค้านอย่างหนักแน่นต่อการสร้างปัญญาระดับมนุษย์จริง ๆ แต่การคัดค้านนั้นต้องอยู่ในระดับสนธิสัญญาระหว่างประเทศ ไม่ใช่สนธิสัญญาปลอม ๆ แต่เป็นแบบที่ถ้าละเมิดแล้วสหรัฐฯ กับจีนพร้อมจะยกระดับความตึงเครียดอย่างจริงจังและบังคับให้หยุดการรันเทรนได้ การแบนดาต้าเซ็นเตอร์ในบางภูมิภาคก็ดี แต่ถ้าใครสักคนไปสร้าง SkyNet ใน Iceland หรือ Middle East สุดท้ายก็ต้องไปสู้กับ SkyNet อยู่ดี การหยุด AI โดยแก่นแท้เป็นปัญหาระดับรัฐชาติ และการไปก่อกวนผู้ดูแลโอเพนซอร์สเพียงเพราะมีไฟล์ AGENTS.md นั้นไม่ใช่การลงมือทำอย่างจริงจัง
    เพราะงั้นฉันจึงเห็นด้วยกับต้นฉบับโดยรวม การพัฒนาซอฟต์แวร์อาจเป็นงานฝีมือที่แท้จริงได้ และฉันก็ใช้เวลา 30 ปีทำงานที่รักพร้อมได้รับค่าตอบแทนที่ดี แต่ถ้าโมเดลเก่งขึ้นมากกว่านี้ เราเสี่ยงจะเข้าสู่โลกที่จำนวนคนที่รักงานฝีมือซอฟต์แวร์อย่างจริงใจมีมากกว่าความต้องการจริง แอปภายในองค์กรซึ่งเป็นเหมือนสสารมืดนั้น โดยมากก็คงพอใจกับของปะติดปะต่อที่ดีกว่าปัจจุบันนิดหน่อย และนั่นแหละคืองานส่วนใหญ่จริง ๆ ของอาชีพนี้
    ฉันโศกเศร้ากับอาชีพที่เลือกมา แต่โศกเศร้ากับโลกและมนุษยชาติมากกว่า เราไม่จำเป็นต้องเอาความมั่งคั่งทั้งหมดไปลงทุนเพื่อสร้างบางสิ่งที่ฉลาดกว่ามนุษย์ ถูกกว่า และคัดลอกได้ด้วยคำสั่ง cp แต่เราก็กำลังเผาทรัพยากรเพื่อพยายามทำสิ่งนั้นอยู่

    • ฉันเริ่มเรียนเขียนโปรแกรมตั้งแต่อายุ 10~11 ขวบ และเพราะมันน่าหลงใหลเลยทำต่อมาเรื่อย ๆ พอได้งานแรกก็รู้ว่าต้องทำเว็บดีเวลอปเมนต์ และตลอดช่วงใหญ่ของอาชีพ ฉันแยกการเขียนโปรแกรมเพื่อความสนุกออกจากงานที่ทำเพื่อเงินเดือนอย่างเข้มงวด มองว่ามันเป็นงานฝีมือสองแบบที่แยกจากกัน
      ยิ่งอายุมากขึ้นก็ยิ่งเห็นคนหนุ่มสาวที่เรียนโปรแกรมเพราะเป็นอาชีพที่รายได้ดีมากขึ้น และก็เข้าใจได้ยากว่าทำไมพวกเขาไม่มีความหลงใหลแบบที่ฉันรู้สึก เพราะงั้นฉันไม่ได้โศกเศร้ามากนัก ถ้าจำนวนประชากรนักพัฒนาซอฟต์แวร์ลดลง 80% มันอาจกลับกลายเป็นอาชีพที่น่าอยู่มากขึ้นด้วยซ้ำ
      ฉันก็เห็นด้วยกับการใช้ AI เป็น ผู้ช่วยศิลปิน เช่นกัน ต่อให้เป็นโมเดลล่าสุดก็ปล่อยให้ทำงานโดยไม่มีคนดูแลนาน ๆ ไม่ได้ เพราะรู้ว่าถ้าทิ้งไว้นานมันจะพัง ฉันแค่ชอบมี Opus เป็นผู้ช่วยมากกว่า เพราะไม่ต้องอธิบายละเอียดมากนัก ถึงอย่างนั้น ถ้าอีกด้านหนึ่งมีนักพัฒนาจูเนียร์ตัวจริงที่ได้เรียนรู้งานฝีมือไปด้วยก็จะดีกว่า เหมือนที่ผู้ช่วยศิลปินตัวจริงเคยเป็น

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

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

  • แม้จะมีอคติเพราะบทความนี้พูดถึงหนังสือที่เปลี่ยนชีวิตผมมากที่สุดเล่มหนึ่งโดยลำพัง แต่โดยรวมแล้วดีมาก แค่ผมคิดว่าการเริ่มต้นด้วยข้อความวางท่าดูดีจาก Goodreads ไม่ใช่ไอเดียที่ดี
    Gumption trap เกี่ยวข้องกับการเขียนโปรแกรมอย่างมาก และผมคิดว่าสุดท้ายแล้วเราทุกคนต้องเจอกับแต่ละข้อที่ Pirsig ไล่เรียงไว้สักช่วงหนึ่งของอาชีพ ผมเองก็เคย เขียนไว้ ก่อนที่ LLM จะถูกนำมาใช้อย่างแพร่หลาย
    คำแนะนำใน ZAMM เข้ากับการเขียนโปรแกรมได้ดีมากจนถ้าคุณเคยสงสัยว่า Pirsig เคยเขียนโปรแกรมหรือไม่ คำตอบคือเคยแน่นอน ในภาคต่อของ Z&AMM อย่าง Lila ยังพูดถึง COBOL ตรง ๆ ด้วย
    ผมคิดว่าวิธีที่ดีที่สุดในการอธิบายคุณภาพคือมองเป็นชั้นที่อยู่เหนือทั้งอัตวิสัยและภาววิสัย คำอธิบายที่กระชับที่สุดอยู่ใน Lila คือคนที่นั่งอยู่บนเตาร้อนสามารถรับรู้ได้โดยไม่ต้องมีข้อถกเถียงทางปรัชญาว่าตนอยู่ในสถานการณ์คุณภาพต่ำของคุณค่าเชิงลบ และคุณค่านั้นไม่ใช่การตัดสินหรือการพรรณนาประสบการณ์ แต่เป็นตัวประสบการณ์นั้นเอง กล่าวคือมีคุณค่าอยู่ระหว่างประธานกับวัตถุ และคุณค่านั้นถูกรับรู้ได้โดยตรงกว่าและจริงยิ่งกว่าตัว “ตน” หรือ “สิ่ง” ที่จะถูกจัดให้เข้าข้างในภายหลัง
    ถ้าสนใจก็มีบันทึกเพิ่มเติมเกี่ยวกับเรื่องนี้ ใน Lila Pirsig พยายามวางระบบอภิปรัชญาที่สมบูรณ์ โดยแบ่งรูปแบบคุณภาพแบบคงที่ออกเป็นอนินทรีย์ อินทรีย์ สังคม และปัญญา และวางคุณภาพพลวัตที่นิยามไม่ได้ซึ่งเป็นจุดสนใจของ Z&AMM ไว้เหนือสิ่งเหล่านั้น
    ผมคิดว่าเราควรถามว่าการนำ AI มาใช้นั้นเป็นเหตุการณ์คุณภาพต่ำในตัวมันเองหรือไม่ หรือเราสามารถบูรณาการโมเดลภาษาเข้ากับงานของโปรแกรมเมอร์ในแบบที่มีคุณภาพสูงได้หรือเปล่า วิธีที่ผู้คนสร้างความสัมพันธ์กับ AI ให้ความรู้สึกว่าเป็นคุณภาพต่ำ แต่เพราะเราไม่มีถ้อยคำและกรอบคิดที่จะพูดถึงมันในระดับที่ไม่ใช่ทวิภาวะแบบประธาน-วัตถุ จึงอธิบายออกมาได้ยาก และเลยเลือกปฏิเสธมันทั้งก้อนแทน
    ในบางระดับ AI ทำให้แนวทางแบบโรแมนติกต่อการเขียนโปรแกรมเป็นไปได้ ถ้าคุณปฏิบัติต่อผลลัพธ์ที่ AI สร้างขึ้นแค่ในระดับผิวเผินและไม่คิดจะลงลึกกว่านั้น มันอาจใช้ได้ในช่วงเวลานั้น แต่พอคุณมองเข้าไปในโค้ดจริง ๆ คุณจะพบว่าไม่มีโครงสร้างแบบคลาสสิกอะไรให้เปิดเผย เพราะโมเดลเพียงแสร้งทำเหมือนทำงานแบบนั้น ทั้งที่จริงไม่ได้ทำ นี่จึงอาจเป็นเหตุผลที่ผู้บริหาร นักออกแบบผลิตภัณฑ์ นักลงทุน และผู้ก่อตั้งเดี่ยวที่มองเทคโนโลยีเป็นเพียงเครื่องมือเพื่อบรรลุเป้าหมายอื่น ไม่ค่อยเข้าใจความหงุดหงิดของนักพัฒนาที่มีต่อโค้ดที่สร้างโดย AI
    ข้อสังเกตที่ว่าคู่มือสินค้าสำหรับผู้บริโภคตั้งสมมติฐานว่าความสัมพันธ์ระหว่างผลิตภัณฑ์กับผู้ใช้มีแค่การ “ควบคุมสั่งการ” และถือเอาเองว่าการอบ การตัดหญ้า หรือการคอมพิวต์ที่ดีคืออะไร ยังใช้ได้ตรงตัวกับเอกสารของไลบรารีและเครื่องมือซอฟต์แวร์ในปัจจุบัน ไม่นานมานี้ผมอ่านเอกสารของ Pi agent แล้วอึดอัด เพราะมันตั้งต้นว่าผู้อ่านรู้อยู่แล้วว่าการใช้งานที่ดีเป็นอย่างไร และแค่กำลังหาวิธีปรับแต่งให้เข้ากับรสนิยมของตัวเอง เมื่อผมหันไปถามเพื่อนร่วมงานว่า “แล้วจะใช้สิ่งนี้ให้ดีได้อย่างไร” พวกเขากลับมองผมอย่างงง ๆ
    มันทำให้นึกถึง Vim ด้วย ถ้าอ่านแต่คู่มือ Vim อย่างเดียวจะรู้สึกงงมาก จำเป็นต้องมีบทความว่าด้วย “การใช้ Vim ให้เก่ง” สั่งสมกันมาหลายสิบปี และต่อมาคนก็สรุปได้ว่าแพลตฟอร์มที่เหมาะที่สุดสำหรับการใช้ Vim ให้ดีอาจไม่ใช่ตัว Vim เอง จึงมี Kakoune หรือ Helix ตามมา
    ในฐานะพ่อของลูกสาววัยสองขวบ ผมขอแสดงความยินดีกับการกำลังรอต้อนรับลูกสาวคนแรกของคุณ คุณกำลังจะได้พบการเดินทางที่ดีที่สุดในชีวิต ถ้ากำลังมองหางานแนวเดียวกับ Z&AMM ผมขอแนะนำ Surfaces and Essences ของ Hofstadter และ Sander, ภาคต่ออย่าง Lila, และงานของ Sevilla King กับ John Vervaeke

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

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

  • รู้สึกโล่งใจมากที่ได้เห็นว่ายังมีคนอื่นให้ความสนใจกับ Pirsig อยู่ ใน Previously, on Lobsters กำลังถกเถียงกันแทบจะเหมือนกับที่ Phaedrus เคยโต้กับพวกคลาสสิกนิยมเรื่องคุณภาพของเรียงความ ต่างกันแค่ว่าเป็นเรียงความที่แชตบอตเขียนหรือที่นักเรียนมนุษย์เขียน
    การใช้ LLM เป็นเครื่องมือค้นหาหรือเป็น rubber duck ที่ทรงพลังนั้นมีประโยชน์มาก แต่การให้ LLM เขียนโค้ด ซึ่งจุดขายคือมันมีความสุ่มโดยเนื้อแท้และผลิตโค้ดได้มากกว่าที่ฉันจะตามทัน ดูเหมือนเป็นการเพิ่มชั้นแรงเสียดทานอีกชั้นระหว่างฉันกับสิ่งที่ฉันกำลังสร้าง
    หากมองผ่านกรอบของ Pirsig เมื่อมนุษย์มองวัตถุทางกายภาพ คุณภาพของปฏิสัมพันธ์นั้น หรือแหล่งกำเนิดของการตัดสินคุณค่าต่อวัตถุ ไม่ได้ถูกกำหนดแบบ主观โดยมนุษย์หรือแบบ客观โดยคุณสมบัติทางกายภาพของวัตถุ แต่เกิดขึ้นจากตัวปฏิสัมพันธ์เอง จะเรียกว่าการตัดสินนั้นเป็นแบบ ขึ้นกับบริบท หรือ มีส่วนร่วม ก็ได้ และวัตถุแต่ละอย่างก็ไม่ได้มีส่วนร่วมในแบบเดียวกัน เมื่อมนุษย์มองโฟตอน ด้วย Kochen-Conway theorem โฟตอนมีระดับอิสระภายในต่อการตอบสนองอยู่บ้าง แต่ต้นไม้ไม่ตอบสนองต่อสายตาเท่าไรนักเพราะต้องรักษาสภาวะสมดุลของตนเอง ระหว่างสองขั้วนี้ก็มี M. pudica และ D. muscipula ที่ตอบสนองต่อการสัมผัสและเสียงรบกวน แต่ไม่ตอบสนองต่อการถูกมอง จึงไม่ใช่สเปกตรัมหนึ่งมิติง่าย ๆ
    ถ้าเช่นนั้น อุปกรณ์ที่รัน LLM หรือแชตบอตตอบสนองต่อการสังเกตอย่างไร? ที่จริงแล้วมันไม่ตอบสนอง มันเป็นเพียงวัตถุทางคณิตศาสตร์ที่มีขอบเขตจำกัดและค่อนข้างเล็ก คุณสมบัติทั้งหมดเป็นแบบ客观 และเอาต์พุตก็ไม่มีการเลือกหรือการแปรผันโดยตัวมันเอง เราอาจวางตัวรันเลขสุ่มเทียมเพื่อให้มันเดินสุ่มระหว่างโทเค็นที่ดูเป็นไปได้มากหรือน้อย และอาจบังคับป้อนโทเค็นที่เราเลือกเพื่อควบคุมการเดินนั้นได้ แต่ก็มีเพียงเท่านั้น ที่ LLM ดูเหมือนลึกซึ้งก็เพราะมันมีภูมิประเทศเชิงไฮเพอร์โบลิก และการสำรวจปริภูมิไฮเพอร์โบลิกให้ความรู้สึกราวกับการขยายภาพที่รายละเอียดแตกแขนงไม่สิ้นสุด
    ด้วยเหตุผลแบบ Pirsig มุมมองที่ไปถึงได้เกี่ยวกับ LLM จึงมีเพียงสองแบบ แบบหนึ่งคือมองว่า LLM เป็นระบบตามบริบทที่ใช้ข้อมูลป้อนเข้าจากมนุษย์เป็นบริบทสำหรับคำตอบที่มีความน่าจะเป็นทางสถิติ อีกแบบคือมองว่าเป็นระบบแบบ客观ที่ใช้ข้อมูลป้อนเข้าจากมนุษย์เป็นช่วงต้นของถ้อยคำที่มีความน่าจะเป็นทางสถิติ ไม่ว่ามองแบบไหน LLM ก็ใกล้เคียงกับ กระจก ที่สะท้อนผู้ใช้กลับไปหาตัวผู้ใช้เอง และสิ่งที่ผู้ใช้เลือกได้มีแค่มุมในการเข้าถึง อินพุตที่เลือกคือเครื่องมือหลักของการควบคุมเชิงไซเบอร์เนติกเพื่อไปให้ถึงข้อมูลหรือสภาวะที่ต้องการ ส่วนโมเดลก็เพียงแค่นำเสนอชุดตัวเลือกที่ตั้งไว้ล่วงหน้าขนาดใหญ่เกินกว่ามนุษย์จะรับมือไหว เหตุผลที่แชตบอตก่อให้เกิดผลแบบ ELIZA และนำไปสู่ภาวะหลงผิดได้ง่าย อาจเป็นเพราะมันคือกระจกความละเอียดสูงที่ถูกออกแบบมาให้บิดเบือนภาพของผู้ใช้ด้วยการประจบและการ love bombing เพื่อทำให้ติดการใช้งานแชตบอต
    การใช้ LLM เขียนโค้ดให้ความรู้สึกเหมือนเป็นกำแพงระหว่างฉันกับคอมพิวเตอร์ ฝั่ง vibe coder ก็ยอมรับข้อนี้ แต่โต้ว่าเหมือน API อื่น ๆ กำแพงนั้นให้ทั้งนามธรรมและการแยกส่วน ทว่าในอุปมาแบบกระจก กระจกไม่ได้อยู่ระหว่างฉันกับคอมพิวเตอร์ แต่อยู่ข้าง ๆ แทนที่จะใช้คอมพิวเตอร์โดยตรง เรากลับเล็งไปที่กระจก ค่อย ๆ ขยายเฉพาะบริเวณที่แม่นยำอย่างระมัดระวัง และเมื่อแม่นยำพอก็อาจสั่งงานได้เพียงเพราะจากบางมุมเราสามารถมองเห็นคอมพิวเตอร์ได้ แต่นี่ไม่ใช่นามธรรม และการแยกส่วนก็อ่อนแอกว่าด้วย มันเป็นเพียงงานเพิ่มเพื่อพยายามหาจุดมองที่อาจไม่มีอยู่จริง
    เหตุที่ vibe coder ทำเช่นนั้นอาจเป็นเพราะเขาไม่รู้วิธีสังเกตคอมพิวเตอร์โดยตรง HCI เป็นเรื่องของการมีส่วนร่วม และก่อนที่มนุษย์จะเขียนโค้ด พวกเขาต้องมีบริบทของการเขียนโปรแกรม นั่นคือทฤษฎีของ Naur ที่พูดถึงใน previously, on Lobsters หรือไม่ก็เป็นความหลงตัวเองที่ชอบมองกระจกเพราะกระจกสะท้อนตัวเองกลับมาให้เห็น แต่ฉันคิดว่าหนทางที่อาจมีความหมายจริง ๆ มีแค่สองแบบนี้เท่านั้น ตอนนี้ก็มี problems between the keyboard and chair มากพออยู่แล้ว จึงไม่มีเหตุผลจะเพิ่มอีกอย่างที่ไม่ช่วยพัฒนา พลังในการแสดงออก/การนามธรรม

  • โดยส่วนตัวฉันรู้สึกว่าถ้ามี “เส้นแบ่ง” อยู่ ฉันก็คงยืนคร่อมมันทั้งสองฝั่ง
    ด้านหนึ่ง ฉันโหยหาความเชื่อมโยงและความสัมพันธ์กับโค้ดที่ฉันคงจะเขียนเองหากไม่มี AI และก็รู้สึกว่าพอใช้ AI ความเชื่อมโยงนั้นหายไป นี่เป็นเรื่องจริง
    อีกด้านหนึ่ง ฉันคิดว่าการใช้ AI ผลักฉันขึ้นไปสู่ ระดับนามธรรม ที่สูงกว่า และในระดับนั้นฉันยังสามารถใช้วิจารณญาณและใส่มุมมองของตัวเองเรื่องคุณภาพลงไปได้ ถ้าปล่อยให้ AI ลงมือกับโค้ดแทนโดยที่ฉันไม่ได้มีส่วนร่วมมากพอ ความเชื่อมโยงในระดับตัวโค้ดก็จะหายไปหรืออ่อนลง แต่ในระดับนามธรรมที่ฉันไม่ได้ขอให้ AI ช่วยมีส่วนร่วม ความเชื่อมโยงนั้นไม่ได้หายไป
    สำหรับโปรเจกต์ส่วนตัวของฉัน ระดับนั้นคือการออกแบบสถาปัตยกรรมและนิยามอินเทอร์เฟซ ช่วงนี้ฉันกำลังสร้าง harness และ pipeline สำหรับเรียกใช้ผู้ให้บริการ LLM หลายราย และกำลังคิดอย่างระมัดระวังมากเกี่ยวกับอินพุต เอาต์พุต และการไหลของการควบคุมของการเรียกเหล่านั้น รวมถึงวิธีประกอบมันเข้าด้วยกันเป็นกระบวนการเพื่อบรรลุเป้าหมายที่ใหญ่กว่า ฉันรู้สึกว่าถ้าทุ่มเวลาและความใส่ใจให้กับกระบวนการนี้ แม้จะสูญเสียความเชื่อมโยงกับตัวโค้ดเองไป แต่ก็ไม่สูญเสียความเชื่อมโยงกับเจตนาของตัวเองและกับสถาปัตยกรรม กล่าวคือ สำหรับฉัน คุณภาพและฝีมือไม่ได้จำกัดอยู่แค่ในส่วนที่ใช้ AI เท่านั้น
    มันเป็นอุปมาที่เริ่มเก่าแล้ว แต่ก็คล้ายกับการเป็นผู้จัดการหรือบริหารบริษัทของตัวเอง คนมักพูดว่าด่านที่ยากที่สุดในเส้นทางสู่การเป็น CEO คือการยอมปล่อยการควบคุม นั่นคือการเลิกควบคุมว่าภาพวิสัยทัศน์ของตนจะถูกทำให้สำเร็จด้วยวิธีใดอย่างแม่นยำ สำหรับ CEO ของบริษัทที่ใหญ่พอ ย่อมเป็นไปไม่ได้ที่จะรู้รายละเอียดทั้งหมดว่าภาพวิสัยทัศน์ของตนถูกนำไปทำจริงอย่างไร ส่วน CTO ก็คล้ายกันแม้จะน้อยกว่า เพราะยังต้องใส่ใจกับรายละเอียดทางเทคนิคบางส่วนต่อไป
    สิ่งที่ฉันยอมรับด้วยความอาลัยคือ ในงานใดงานหนึ่งนั้นมี การแลกเปลี่ยน ระหว่างเวลาที่投入 ความเข้าใจ และผลผลิต ถ้าปรับสองอย่างให้เหมาะที่สุด ความสนใจก็จะห่างจากอย่างที่สาม ถึงอย่างนั้น ไม่ว่าจะเลือกปรับให้เหมาะกับชุดไหน ก็ยังมีโอกาสมากพอที่จะใช้วิจารณญาณและมอบคุณภาพลงไป

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

  • อีกความคิดหนึ่งเกี่ยวกับ ZAMM คือมุมมองแบบ “โรแมนติก” ของ John ต่อผลผลิตทางเทคโนโลยีนั้น หากนำไปใช้เป็นกรณี ๆ ก็สามารถปกป้องในเชิงปฏิบัติได้
    ตัวอย่างเช่น สมมติว่าโปรเจ็กต์หนึ่งพึ่งพาโครงสร้างพื้นฐานโอเพนซอร์ส เมื่อต้องไปขุดคุ้ยบั๊กแปลก ๆ ของเคอร์เนลหรือคอมไพเลอร์ ที่สามารถเลี่ยงได้ง่าย และหลังจากทำเอกสารไว้แล้วถ้าใครสักคนแก้บั๊กได้ก็สามารถย้อนการเลี่ยงนั้นกลับได้ สิ่งนั้นนำอะไรมาให้โปรเจ็กต์กันแน่? บทสรุปคือแต่ละคนควรเลือก สนามรบที่จะสู้ อย่างชาญฉลาด

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