1 คะแนน โดย GN⁺ 2 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • การพัฒนา Android เริ่มต้นในปี 2014 จากคอร์สเรียน Java ในมหาวิทยาลัยและคอร์สออนไลน์ฟรีที่เพื่อนร่วมชั้นแชร์ให้ พร้อมกับแอปสิ่งที่ต้องทำแอปแรก และประสบการณ์ที่ซอฟต์แวร์ในมือสัมผัสโลกจริงได้กลายเป็นแรงขับเคลื่อน
  • ตลอดอาชีพ 10 ปีที่ผ่านมา เป็นช่วงเวลาที่ได้ยืนยันจุดหมายของเทคโนโลยีผ่านการดูแลแอปที่สร้างประโยชน์จริงให้ผู้ใช้ เช่น แอปหาคู่ การเข้าถึงยา และการช่วยเหลือด้านการเดินทาง
  • ผ่านคอร์สเรียน แฮกกาธอน งานแรก และ Droidcon NYC จึงตระหนักได้ว่าสิ่งที่คงอยู่ยาวนานกว่าผลงานคือ ความเชื่อมโยงกับผู้คน และการส่งต่อความรู้สู่สาธารณะ
  • แม้ LLM จะพัฒนาจนสามารถเขียนโค้ดที่คอมไพล์ได้และช่วยรีวิวได้แล้ว แต่มันกลับทำให้ความเข้าใจที่เกิดจากการค้นหา การโต้แย้ง การโหวต และการลองผิดลองถูกแบบ Stack Overflow อ่อนแอลง
  • การพัฒนาซอฟต์แวร์คือทั้ง ศิลปะและงานฝีมือ ที่ไม่อาจถูกแทนที่ได้ด้วยการทำงานซ้ำ ๆ แบบอัตโนมัติเพียงอย่างเดียว และควรเป็นกิจกรรมที่มนุษย์ร่วมกันสร้างและแบ่งปันเพื่อมนุษย์

จุดเริ่มต้นที่ทำให้เข้าสู่การพัฒนา Android

  • การพัฒนา Android เริ่มขึ้นในปี 2014 ระหว่างเรียนวิชา Java ในมหาวิทยาลัย จากคอร์สออนไลน์ฟรีที่เพื่อนร่วมชั้นแชร์ให้ โดยเป้าหมายแรกคือการสร้างแอปรายการสิ่งที่ต้องทำที่มี local storage
  • ช่วงเวลาที่รันแอปที่ทำเสร็จแล้วบนโทรศัพท์และเอาไปให้พ่อแม่ดู กลายเป็น “ช่วงเวลาที่หลอดไฟสว่างขึ้น” เพราะมันคือซอฟต์แวร์จริงที่ถือไว้ในมือและโต้ตอบได้โดยตรง ซึ่งมีความหมายอย่างมาก
  • แอปคือเครื่องมือที่อยู่ในกระเป๋าตลอดเวลา ช่วยเรื่องการจัดระเบียบและประสิทธิภาพการทำงาน และจากประสบการณ์นี้ก็สัมผัสได้ว่าจุดหมายของเทคโนโลยีคือการมอบเครื่องมือที่ส่งผลเชิงบวกต่อผู้คน
  • ในปี 2018 ยังได้ทำงานกับ แอปหาคู่ ที่ภายหลังทำให้ได้พบกับภรรยา จึงได้สัมผัสโดยตรงยิ่งขึ้นว่าซอฟต์แวร์ส่งผลต่อโลกจริงอย่างไร
  • หลังจากนั้นตลอด 10 ปี ได้ขัดเกลาทักษะในฐานะนักพัฒนา Android พร้อมดูแลแอปที่สร้างประโยชน์จริงให้ผู้ใช้ เช่น การค้นหาคนพิเศษ การเพิ่มการเข้าถึงยา และการสนับสนุนการเดินทาง

ผู้คนที่หล่อหลอมเส้นทางนักพัฒนา

  • สิ่งที่คงอยู่ยาวนานกว่าแอปเอง คือ ความเชื่อมโยงกับผู้คน ที่ทำให้แอปเหล่านั้นเกิดขึ้นได้
  • คอร์สเรียนและความรู้สาธารณะ

    • เป้าหมายในช่วงแรกคือดูดซับข้อมูลให้ได้มากที่สุด จึงเข้าเรียนทุกสัปดาห์และเรียนรู้เนื้อหา Android ที่อาจารย์สอน
    • ยังเรียนอีกคอร์สที่ Googler สอนวิธีสร้างแอปพยากรณ์อากาศ และถึงขั้นใช้เวลาระหว่างคาบกับช่วงพักกลางวันมาสร้างแอปอย่างหมกมุ่น
    • ความรู้ลึกซึ้ง ของคนหลังกล้องและท่าทีที่อยากแบ่งปันความรู้นั้นสู่สาธารณะ สร้างความประทับใจอย่างมาก
  • แฮกกาธอนและการสร้างทีม

    • หลายปีถัดมาคือช่วงเวลาของการฝึกฝนผ่านการลงมือทำจริง โดยเข้าร่วมแฮกกาธอนมากกว่า 10 งานและได้เชื่อมต่อกับว่าที่วิศวกรซอฟต์แวร์หลายร้อยคน
    • ขับรถกับเพื่อน 2 ถึง 8 ชั่วโมง อดนอนเกือบตลอด 3 วัน เพื่อสร้างทั้งแอปโซเชียล ตัวติดตามสัตว์เลี้ยง และเกม CTF ด้วยแท็ก NFC
    • แม้จะประคองตัวด้วยคาเฟอีนและถกเถียงกันเรื่อง tech stack แต่เสียงหัวเราะ มิตรภาพ และ ความภูมิใจ ที่ได้สร้างบางอย่างร่วมกันในฐานะทีม คือรางวัลที่แท้จริง
    • ไม่สำคัญนักว่าจะสร้างอะไรหรือได้รางวัลหรือไม่ เพราะประสบการณ์นั้นเองคือรางวัล
  • งานแรกและ RxJava

    • หลังเรียนจบ วันแรกของการเป็นนักพัฒนา Android มืออาชีพในบริษัทการตลาดดิจิทัล เริ่มต้นด้วยคำถามจากเพื่อนร่วมงานข้างโต๊ะว่า “รู้อะไรเกี่ยวกับ RxJava บ้าง”
    • แม้จะตกใจเพราะไม่รู้จัก RxJava เลย แต่เพื่อนร่วมงานคนนั้นไม่ได้ตัดสิน กลับอธิบายเรื่อง reactive programming บริบทของแอปที่จะทำร่วมกัน และวิธีตามให้ทันอย่างรวดเร็ว
    • ทั้งสองกลายเป็นเพื่อนร่วมงานที่สร้างเสียงหัวเราะในออฟฟิศ พร้อมกับรักษาความหลงใหลต่อการทำงานและการเติบโตเอาไว้อย่างลึกซึ้ง
  • Droidcon NYC และการคืนความรู้สู่ชุมชน

    • เพื่อนร่วมงานคนเดิมพาไปงาน Android conference แรกคือ Droidcon NYC และบรรยากาศที่มีวิศวกรหลายร้อยคนกับวิทยากรหลายสิบคนซึ่งสนใจเรื่องเฉพาะทางเดียวกัน ก็ส่งอิทธิพลอย่างมาก
    • การเห็นวิทยากรแบ่งปันความรู้ด้วยความสมัครใจ กลายเป็นแรงบันดาลใจให้อยากแบ่งปันความเชี่ยวชาญของตัวเองแก่คนรุ่นถัดไปของวิศวกร Android
    • การมองหาโอกาสช่วยวิศวกรคนอื่น และ ส่งต่อความช่วยเหลือ ที่เคยได้รับ กลายเป็นหลักการสำคัญในอาชีพ

รูปแบบการพัฒนาที่ LLM สัญญาไว้กับประสบการณ์จริง

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

การทำงานอัตโนมัติที่บั่นทอนการเรียนรู้และการทำงานร่วมกัน

  • วิศวกรมักชอบระบบอัตโนมัติ แต่สิ่งที่ระบบอัตโนมัติทำงานได้ดีที่สุดคือ งานเล็กน้อยและซ้ำ ๆ
  • หากเวลาต้องสร้างบางอย่างกลับเลือกมอบหมายให้เครื่องแทนที่จะใช้ทักษะที่ขัดเกลามาตลอด 10 ปี ความสามารถในการคิดเชิงวิพากษ์ที่จำเป็นต่อการสร้างซอฟต์แวร์ที่ทนทานและอยู่ได้นานก็อาจอ่อนแอลง
  • แม้จะมีมุมมองว่า LLM เขียนโค้ดได้รวดเร็ว จึงเปิดพื้นที่ให้คิดเชิงวิพากษ์ต่อระบบได้มากขึ้น แต่ก็ทำให้พลาด การลองผิดลองถูก ซึ่งเป็นหัวใจของการเรียนรู้การพัฒนาซอฟต์แวร์ได้ง่าย
  • การลองผิดลองถูกไม่ได้หมายถึงแค่ว่าแอปทำงานหรือแครชเท่านั้น แต่คือกระบวนการทดลองหลายแนวทางเพื่อหา architecture, library, pattern และ style ที่เหมาะที่สุดกับเป้าหมาย
  • ฟีดแบ็กต่อวิธีแก้ก็เช่นกัน หากแทนที่จะนั่งคุยกับเพื่อนร่วมงานเรื่องตัวเลือกในการ implement และ trade-off กลับไปถามกล่องดำ การสนทนาที่อิงจากสิ่งที่ใช้ได้หรือใช้ไม่ได้จริงในโปรเจกต์ก็จะหายไป
  • การคุยเรื่อง trade-off มักไม่ได้ตั้งอยู่บนทฤษฎี แต่ตั้งอยู่บนประสบการณ์ที่อีกฝ่ายเคยผ่านมาด้วยตัวเอง และบทสนทนาแบบนั้นเองที่ทำให้การตัดสินใจเชิง implementation ลุ่มลึกขึ้น

ซอฟต์แวร์เพื่อมนุษย์

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

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

 
GN⁺ 2 시간 전
ความคิดเห็นจาก Hacker News
  • คอมเมนต์ที่เล่าถึงประสบการณ์อีกด้านของการไม่ได้เป็นส่วนหนึ่งของชุมชนโปรแกรมมิงที่นี่ถูกพูดถึงได้ดีแล้ว แต่ยังมีอีกประเด็นที่ควรคิดต่อ
    เราควรจำผู้คนที่อยู่ปลายน้ำของซอฟต์แวร์ทั้งหมดนี้ไว้ด้วย คนที่เราอาจไม่ได้พูดคุยด้วยโดยตรง ไม่ได้หมายถึงแค่ “ผู้ใช้” เท่านั้น เพราะมีซอฟต์แวร์จำนวนมากที่ทำมาสำหรับนักพัฒนา แต่ถึงอย่างนั้นผู้ใช้ก็ยังควรถูกนำมาพิจารณา
    การโยนคุณภาพซอฟต์แวร์ให้กับ เครื่องบีบโค้ดเชิงความน่าจะเป็น กำลังทำให้คุณภาพของซอฟต์แวร์ที่ออกสู่โลกนี้ลดลงอย่างรวดเร็ว ก่อนยุค LLM ก็มีปัญหาอย่างความผิดพลาดของมนุษย์หรือแรงจูงใจทางการเงินที่บิดเบี้ยวอยู่แล้ว และนี่คือสิ่งที่ถูกซ้อนเพิ่มเข้าไปอีก การปล่อยซอฟต์แวร์คุณภาพต่ำและเป็นปฏิปักษ์ต่อผู้ใช้ก่อให้เกิดความเสียหายทั้งเล็กและใหญ่กับผู้คนจริง ๆ การไหลลื่นเข้าสู่ generative AI แบบ “หลีกเลี่ยงไม่ได้” นี้กำลังทำร้ายทุกฝ่ายที่เกี่ยวข้อง ไม่ว่าจะเป็นนักพัฒนา ผู้ใช้ หรือนักลงทุน เพียงแต่เพราะผลกระทบเกิดขึ้นต่างเวลากัน ต่างรูปแบบกัน และค่อย ๆ ดำเนินไป จึงมองข้ามได้ง่าย ทั้งที่มันกำลังเกิดขึ้นจริง
    “AI” คือ โทษภัย ฉันถูกทิ้งไว้ข้างหลังก็ได้

    • ผมไม่แน่ใจจริง ๆ ว่าคำกล่าวที่ว่าการยกคุณภาพให้ “เครื่องบีบโค้ดเชิงความน่าจะเป็น” จะทำให้คุณภาพซอฟต์แวร์ร่วงฮวบเป็นเรื่องจริงหรือไม่ และคิดว่าคุณเองก็คงยากจะมั่นใจ ตอนนี้ทั้งหมดมันยังใกล้เคียงกับความรู้สึกมากกว่า
      ในฐานะคนที่ดูแลโปรเจกต์ส่วนตัวอยู่ไม่กี่ตัว ผมพูดได้ว่าคุณภาพดีขึ้นอย่างเป็นรูปธรรมจากการใช้ AI สร้าง CI pipeline ที่เหมาะสม ขยายขอบเขตการทดสอบ และวางสถาปัตยกรรมที่ดีกว่า เพราะเมื่อก่อนผมไม่มีทรัพยากรมากพอจะลงทุนให้ระบบแข็งแรงแบบนั้น แต่ AI ทำให้มันเป็นไปได้
      แน่นอน คุณอาจบอกได้ว่าโค้ดของผมห่วยและการทดสอบก็ไม่ได้เรื่อง แต่ดูเหมือนคุณจะตั้งข้อสรุปไว้ล่วงหน้าแล้ว จากประสบการณ์ทำงานในอุตสาหกรรมนี้มา 25 ปี ผมบอกได้ว่าคำตัดสินนั้นผิด เพียงแต่ไม่มีใครรู้ว่า codebase ระดับค่ากลางจะออกมาเป็นอย่างไร ผมอาจเป็นคนที่ขยันเป็นพิเศษก็ได้ ยุค agentic coding เพิ่งมีมาแค่ราว 6–12 เดือนเท่านั้น ดังนั้นยังควร ชะลอการตัดสิน ไว้ก่อน
    • ผมเห็นด้วยว่าซอฟต์แวร์ที่ LLM สร้างขึ้นมีโอกาสสูงที่จะส่งผลลบต่อชีวิตของผู้คน ในอีกด้านหนึ่ง มันก็คงทำให้เกิดซอฟต์แวร์จำนวนมากที่เมื่อก่อนสร้างไม่ได้
      สำหรับบางการใช้งาน ซอฟต์แวร์ห่วย ๆ ก็อาจดีกว่าไม่มีอะไรเลย โดยรวมแล้วมันจะเป็นเรื่องดีหรือร้ายคาดเดาได้ยาก
    • ถ้ามองว่า “AI คือโทษภัย” แบบนี้ ก็อาจบอกได้ว่า structured programming, คอมไพเลอร์, การเขียนโปรแกรมเชิงวัตถุ, การสร้างโค้ด และวิศวกรรมแบบ agentic ล้วนเป็นโทษภัยเหมือนกัน
      สิ่งที่ของพวกนี้มีร่วมกันคือมันเป็นเครื่องมือที่คนขี้เกียจใช้เป็นไม้เท้าเพื่อเข็นโค้ดที่พอทำงานได้แต่มีปัญหาออกมาได้ ความขี้เกียจคือการเลือก และการเลือกเป็นสิ่งที่มนุษย์ซึ่งมีเจตจำนงและความรับผิดชอบเป็นผู้ทำ
    • ผมเห็นด้วยเต็มที่กับคำพูดที่ว่าซอฟต์แวร์คุณภาพต่ำและเป็นปฏิปักษ์ต่อผู้ใช้ทำอันตรายต่อผู้คนจริง ๆ
      ถ้าเรากำลังใช้เครื่องมือ AI เพื่อสร้างซอฟต์แวร์ที่แย่ลงให้เร็วขึ้น เราก็ควรทบทวนวิธีใช้มันใหม่ ถ้าใช้สิ่งนี้แล้วไม่สามารถส่งมอบ ซอฟต์แวร์ที่ดีกว่า ได้ ก็ไม่รู้เหมือนกันว่าจะใช้มันไปเพื่ออะไร
    • ไม่มีหลักฐานว่าคุณภาพลดลงเลย ที่จริงออกจะใกล้เคียงกับตรงกันข้าม
      ผมเห็นกรณีที่เครื่องมือ รีวิวโค้ด ด้วย AI มีประสิทธิภาพสูงมากในการจับข้อบกพร่องที่ไม่อย่างนั้นคงถูก deploy ออกไปแล้ว
  • ประสบการณ์การเขียนโปรแกรมของผมต่างจากผู้เขียนมากจนทำให้สงสัยว่าผมพลาดอะไรไปหรือเปล่า ผมเขียนโปรแกรมคนเดียวมาตลอด และนึกไม่ออกเลยว่าเคยได้คุยเรื่องโปรแกรมมิงแบบลึก ๆ กับใคร ไม่ว่าจะออนไลน์หรือออฟไลน์ มันฟังดูเป็นเรื่องสนุกและน่าตื่นเต้น แต่ก็น่าเสียดายที่ผมไม่เคยมีโอกาสแบบนั้น
    สำหรับผม AI คือสิ่งแรกที่ทำให้ผมได้รับ อะไรสักอย่างที่คล้ายความเห็น เกี่ยวกับปัญหาหรือสถานการณ์เฉพาะหน้าที่เจอ ผมสามารถถามได้อย่างเจาะจงมากว่าแนวทางไหนดีที่สุดสำหรับสิ่งที่กำลังทำอยู่ จากนั้นก็อ่านคำตอบ ทบทวน แล้วค่อยตัดสินใจว่าจะไปทางไหน ผมยังคงได้คำตอบเหลวไหลอยู่บ่อย ๆ แต่แม้ในตอนนั้นมันก็ช่วยให้ผมคิดลึกขึ้นเกี่ยวกับวิธีเข้าหาปัญหา ด้วยการถามตัวเองว่า “สิ่งที่ AI พูดมาเป็นความจริงไหม?”

    • AI เหมือนเอา Google กับการดีบักด้วยเป็ดยางสีเหลืองมารวมกัน
    • ชุมชน Android เคยเหนียวแน่นมากมาเป็นเวลานาน และคุยเรื่องแบบนี้กันต่อเนื่องทั้งออนไลน์และออฟไลน์ ผู้เขียนต้นฉบับเองก็เป็นผู้มีส่วนร่วมที่ค่อนข้างแอ็กทีฟ
      น่าเสียดายที่ก่อนการเข้าซื้อกิจการ Twitter เป็นศูนย์กลาง และหลังจากนั้นก็รู้สึกว่าชุมชนไม่เหมือนเดิมอีกแล้ว
    • ผมก็คล้ายกัน เลยเริ่มเปิดเวิร์กช็อปเอง ซึ่งยอดเยี่ยมมากและได้เรียนรู้เยอะทุกครั้ง ถ้าอยากเจอผู้คนไม่ว่าจะในหัวข้อไหน ก็แค่ จัดเวิร์กช็อป เอง
    • เราควรไล่ดูและชั่งน้ำหนัก ผลกระทบลำดับที่สอง มุมมองแบบเพื่อนร่วมทางนี้อาจเป็นเพียงหนึ่งในหลายมุมมอง แต่ทรงพลังมาก
    • ปัญหาของ AI แบบปิด คือบริษัทอย่าง Anthropic, Google และ OpenAI ได้ประโยชน์จากการใช้ AI มากกว่าผู้ใช้
      เครื่องมืออย่าง PostgreSQL, GCC, Git, HTTP, Emacs ไม่ได้ “ได้” อะไรจากการที่คุณใช้มัน มันอาจได้รับความนิยมเพิ่มขึ้นและมีผู้ร่วมพัฒนามากขึ้นได้ แต่ก็แค่นั้น ยิ่งใช้ Claude มากเท่าไร Anthropic ก็ยิ่งรวยขึ้น และยิ่งอยู่ในตำแหน่งอำนาจที่เอื้อต่อการครอบงำโลกของการเขียนโปรแกรมได้ง่ายขึ้น ดังนั้นไม่ว่าคุณจะชอบ AI แบบปิดแค่ไหน เราก็ควรคิดใหม่ว่าเรากำลังยกอะไรให้เป็นสิ่งแลกเปลี่ยน มันไม่ใช่แค่ 200 ดอลลาร์ต่อเดือน
  • Mario Savio เคยพูดไว้ตอนที่การปฏิวัติอุตสาหกรรมมาถึงจุดสูงสุด
    จะมีช่วงเวลาหนึ่งที่การทำงานของเครื่องจักรน่ารังเกียจเสียจน คุณเจ็บปวดในใจจนไม่อาจมีส่วนร่วมได้ และไม่อาจแม้แต่จะมีส่วนร่วมแบบเฉื่อยชาได้ เมื่อนั้นคุณต้องเอาร่างของคุณไปทาบบนเฟือง ล้อ คันโยก และอุปกรณ์ทั้งหมด แล้วทำให้มันหยุด และต้องบอกคนที่เดินเครื่องและเป็นเจ้าของเครื่องจักรนั้นว่า ถ้าเราไม่เป็นอิสระ เครื่องจักรก็จะทำงานต่อไปไม่ได้เลย
    ตอนนั้นเครื่องจักรก็เข้ามาทำงานหลายอย่างแล้ว แต่เราก็ยังทำงานกันได้ดีอยู่ สุดท้ายแล้วสิ่งนี้ก็คงจะกลายเป็นการใช้เครื่องมือ และพาสติปัญญาของมนุษย์ไปสู่อีกจุดสูงสุดหนึ่ง

    • เห็นด้วยได้ยากกับคำว่า “พาสติปัญญาของมนุษย์ไปสู่อีกจุดสูงสุดหนึ่ง” ตอนนี้ยังไม่เห็นสัญญาณว่าสติปัญญาของมนุษย์กำลังเข้าใกล้จุดสูงสุดในประวัติศาสตร์
      ถ้าจะพูดว่าเป็นความรู้ของมนุษย์ก็อาจใช่ แต่ไม่ใช่สติปัญญา ในฐานะหมู่คณะเราโง่ และกำลังไปในทางที่โง่ลง และแนวโน้มขี้เกียจไม่คิดที่ AI สร้างขึ้นจะยิ่งเร่งกระแสนั้น
    • ไม่เข้าใจว่าทำไมต้องส่งเสริมสติปัญญา ถ้าทุกคน “ฉลาด” กันหมดแล้วจะต่างอะไร? อย่างมากที่สุดเราก็มีชีวิตอย่างแข็งแรงอยู่บนก้อนหินนี้ได้สัก 50 ปี
      ฉันเองก็คิดว่าตัวเองค่อนข้าง “ฉลาด” แต่ก็รู้สึกว่าแนวคิดนี้ถูกยกให้สำคัญเกินจริง อยากใช้ชีวิตแบบโง่ ๆ ไม่กังวล ขี่จักรยาน ยิงธนูขึ้นฟ้า กินเอสการ์โกต์ แล้วพอถึงเวลาก็อยากตายในขณะหลับ แต่ในโลกจริงกลับต้องทำงานและต้องคอยมองหาสถานดูแลผู้สูงอายุ
    • เครื่องมือก่อนหน้านี้ที่ปลดปล่อยเราจากแรงงานทางกาย ได้พาความสามารถทางร่างกายของมนุษย์ไปสู่อีกจุดสูงสุดหรือเปล่า?
    • คำพูดนั้นไม่ได้เกี่ยวกับการทำให้เป็นอุตสาหกรรมโดยตัวมันเอง แต่เกี่ยวกับการไม่สมรู้ร่วมคิด เครื่องจักรเป็นอุปมาของระบบ และเป็นบริบทของยุค 1960
    • “เรา” ในที่นี้คือใคร? คุณทำงานกับเครื่องจักรในโรงงานโดยตรงหรือเปล่า? รู้ไหมว่าคนที่ควบคุมเครื่องจักรในปี 1900 รู้สึกอย่างไร?
      ยังไงก็ตาม การถูกแทนที่ทางกลไกกับการถูกแทนที่ในการคิดนั้นเทียบกันไม่ได้ แต่คอมเมนต์สายโปร-AI ที่ไม่คิดมากที่สุดกลับมักขึ้นไปอยู่บนสุด
  • บทความนี้ทำให้ฉันตระหนักหลายอย่าง คิดว่าพอจะเข้าใจความเจ็บปวดของผู้เขียน และตอนอ่านก็รู้สึกได้ชัดเจนอยู่แล้ว สิ่งที่ค่อนข้างน่าแปลกใจคือสิ่งที่สร้างความแตกต่างคือ “ผู้คน” และฉันก็ตระหนักว่านั่นอาจมีผลอย่างมากต่อวิธีที่ฉันมองเทคโนโลยีนี้ เพราะฉันแทบไม่เคยมีประสบการณ์แบบนั้นเลย
    สำหรับฉัน การสร้างซอฟต์แวร์ส่วนใหญ่เป็นกระบวนการที่โดดเดี่ยว และเป็นสิ่งที่ฉันหมกมุ่นมากกว่าคนรอบตัวมาก ฉันไม่ได้อยู่ในพื้นที่ที่เน้นเทคโนโลยี และก็ไม่ได้อยู่ในสภาพแวดล้อมที่ได้คุยกับคนที่รู้เรื่องการเขียนโปรแกรม วิศวกรรมซอฟต์แวร์ หรือ AI มาก ๆ แม้ฉันจะเคยต้องเรียนรู้เทคโนโลยีใหม่หรือภาษาใหม่แบบเดียวกับผู้เขียน แต่ก็ไม่ได้มีนักพัฒนาที่มีประสบการณ์กว่ามาช่วยสอน ฉันเรียนเองคนเดียวที่บ้าน
    LLM ทิ้งเราไว้ในสภาวะที่มีข้อเท็จจริงหลายอย่างเป็นจริงพร้อมกัน และถ้าจะเดินหน้าต่อ เราต้องหาวิธีปรับและคลี่คลายมัน เราอาจเรียนรู้หรือไม่เรียนรู้ขณะใช้ LLM ก็ได้ ซึ่งเป็นผลจากแนวทาง ความต้องการ และแรงใจของผู้ใช้เอง เช่นเดียวกับเกือบทุกอย่าง การใช้ LLM ก็มีเรื่องของความชำนาญ และระดับความชำนาญของผู้ใช้ก็มีผลต่อการรับรู้ต่อเทคโนโลยี รวมถึงวิธีที่คนรอบข้างมองมันด้วย ผู้ใช้ที่ยังไม่ชำนาญมักก่อให้เกิดความรู้สึกด้านลบมากกว่า
    บางคนชอบทำสิ่งที่เครื่องทำได้ดีด้วยตัวเอง จึงไม่อยากให้เครื่องทำให้ ส่วนบางคนเกลียดงานแบบนั้น จึงอยากให้เครื่องทำแทน ช่วงหนึ่งของปีนี้ ฉันได้ตระหนักว่าฉันชอบสร้างระบบ ออกแบบ และแก้ปัญหามากกว่าการเขียนโปรแกรมเองเสียอีก
    การพัฒนาซอฟต์แวร์คือหลายสิ่งที่ถูกมัดรวมกันไว้ และเมื่อพูดถึงมันราวกับเป็นสิ่งเดียวก็ยิ่งทำให้สับสน บางคนอยากคิดตรรกะของแอปพลิเคชันเองแล้วให้ LLM เขียนโค้ด บางคนอยากให้ LLM คิดวิธีแก้ ลงมือทำ และทดสอบให้เสร็จ คนสองแบบนี้แตกต่างกันมากทั้งในเป้าหมายและความต้องการ เมื่อใครสักคนมอง Claude หรือ ChatGPT เขาอาจเห็นสิ่งที่ต่างจากที่คุณเห็นโดยสิ้นเชิง

    • สรุปได้ดีมาก ฉันก็อยู่ฝั่งเดียวกัน แทบไม่เคยมีใครให้โยนไอเดียไปมาและระดมสมองเรื่องรายละเอียดของโค้ดด้วยเลย
      ส่วนใหญ่ต้องไปขุดจากหนังสือและบทความออนไลน์ แล้วสร้างแบบจำลองทางความคิดของตัวเองขึ้นมาว่ามันทำงานอย่างไร และกระบวนการนั้นก็ช่วยได้มากทีเดียว
      ตอนนี้ AI กลายเป็นทั้งเครื่องมือสำหรับการเรียนรู้ เครื่องมือที่แสดงแนวทางที่ถูกต้อง และเครื่องมือที่อธิบายอย่างละเอียดว่าสุดท้ายแล้วมันกลายเป็นอะไร คุณถามคำถามได้ ชี้ข้อผิดพลาดได้ สลับไปมาระหว่างหลายการติดตั้งใช้งานได้ และท้ายที่สุดก็กลายเป็นโปรแกรมเมอร์ที่ดีกว่าเดิม อย่างที่หลายคนพูด AI มีความหมายไม่เหมือนกันสำหรับแต่ละคน สำหรับฉันมันเป็นเครื่องมือที่เพิ่มพลัง เปิดโลก และทำให้ถ่อมตัว มีเรื่องให้เรียนรู้อยู่เสมอมากเกินไปและเวลามักไม่พอ แต่ตอนนี้มันไม่ได้รู้สึกเป็นแบบนั้นเสมอไปแล้ว
  • ปัญหาของAI แบบกรรมสิทธิ์คือบริษัทอย่าง Anthropic, Google, OpenAI ได้ประโยชน์จากการใช้งาน AI มากกว่าผู้ใช้ เครื่องมืออย่าง PostgreSQL, GCC, Git, HTTP, Emacs ไม่ได้ “ได้” อะไรจากการที่เราใช้มัน อาจแค่มีชื่อเสียงมากขึ้นและมีคนร่วมพัฒนามากขึ้น แต่ก็เท่านั้น
    ยิ่งใช้ Claude มากขึ้น Anthropic ก็ยิ่งรวยขึ้น และยิ่งอยู่ในตำแหน่งที่มีอำนาจจะครอบงำการเขียนโปรแกรมของโลกได้ง่ายขึ้น ดังนั้นต่อให้คุณจะชอบ AI แบบกรรมสิทธิ์แค่ไหน เราก็ควรคิดใหม่ว่าเรากำลังยกอะไรให้มันเป็นสิ่งตอบแทน นั่นไม่ใช่แค่ 200 ดอลลาร์ต่อเดือน
    ฉันสนับสนุนโมเดลแบบเปิดและเอเจนต์โอเพนซอร์ส แต่ไม่อยากให้บริษัทยักษ์ใหญ่มีอำนาจมากไปกว่านี้ แค่นึกภาพว่าอีก 5 ปีข้างหน้า ถ้าบริษัทใหญ่เหล่านี้มีอำนาจเหนือเรามากขึ้น วิศวกรรมซอฟต์แวร์จะเปลี่ยนไปอย่างไรก็น่ากลัวแล้ว เช่น อาจกลายเป็นว่าต้องจ่ายเพิ่มถ้าไม่อยากเห็นโฆษณาคั่นระหว่างพรอมป์ต์ใน Claude Code หรือต้องจ่ายเพิ่มถ้าไม่อยากให้โค้ดที่สร้างขึ้นแทรกโฆษณาไว้ในแอป คุณอยากให้ประสบการณ์แย่ ๆที่เราเผชิญกันอยู่ทั่วอินเทอร์เน็ตตอนนี้ ฝังลึกเข้าไปถึงเวิร์กโฟลว์งานวิศวกรรมซอฟต์แวร์จริงหรือ?

    • ตอนที่ฐานข้อมูลเริ่มออกมาใหม่ ๆ ในยุค 70~90 มีบริษัทฐานข้อมูลแบบกรรมสิทธิ์มากมาย เช่น Oracle, IBM, Sybase, SQL Server แต่ตอนนี้ฐานข้อมูลโอเพนซอร์สกลายเป็นตัวเลือกพื้นฐานไปแล้ว
      ตอนนี้ผู้คนกำลังมองแค่สภาพของ LLM ในปัจจุบันแล้วก็ทำนายแบบสุดโต่งกันไปต่าง ๆ นานา แต่เราไม่รู้หรอกว่าตลาดจะพัฒนาไปอย่างไร
      ความสามารถด้านการเขียนโปรแกรมและวัฒนธรรม vibe coding ตอนนี้ก็คล้ายกับรถยนต์ไฟฟ้าในช่วงแรก ๆ รถยนต์ไฟฟ้ามีบทบาทบางอย่างที่เหมาะกว่ารถสันดาปภายในอยู่แล้ว แต่กว่าจะทำสิ่งเดียวกันได้อย่างสมบูรณ์จริง ๆ ก็ต้องใช้เวลาอีก 10 ปี ระหว่างนั้นก็มีคนมากมายที่ลดค่ารถยนต์ไฟฟ้าว่าเป็นของเล่นแปลกใหม่ ใช้งานไม่ได้จริง แพง และอันตราย เพราะไม่มีโครงสร้างพื้นฐานและเทคโนโลยียังไม่สุกงอม
      ตอนนี้คูเมืองที่แท้จริงที่เห็นได้ก็คงมีแค่ความต้องการดาต้าเซ็นเตอร์ แต่สิ่งนี้ก็จะขยายขนาดและกลายเป็นสินค้ามาตรฐาน และการผลิต RAM ก็จะตามทันด้วย
  • มนุษย์ส่วนใหญ่ได้จุดมุ่งหมายและความหมายจากการทำงาน เป็นแบบนี้มาตลอด คิดว่าจะเกิดอะไรขึ้นถ้า ลบความหมายออกจากชีวิตผู้คนในวงกว้าง? คงดูไม่สวยนัก

    • ปัญหาไม่ใช่การลบความหมายออก คนธรรมดาที่มีความคิดก็สามารถหาสิ่งที่ทำเพื่อเติมเต็มชีวิตได้ จริง ๆ แล้วสำหรับคนส่วนใหญ่ งานกลับเป็นสิ่งที่ขัดขวางเรื่องนั้นเสียมากกว่า
      ปัญหาที่แท้จริงคือสถานการณ์จะ “น่าสนใจ” ขึ้นมาตั้งแต่ตอนที่คุณลบเงินเดือนที่จำเป็นสำหรับ ชนชั้นกรรมาชีพ ออกไปทั้งหมด
    • ถ้าลบความหมายออกจากชีวิตผู้คนในวงกว้าง คุณก็จะได้วลีขยะสไตล์ AI แบบนี้: “ผู้เชี่ยวชาญด้านการส่งอีเมลถึงปลายทางด้วย AI ที่ทดสอบและแก้ไขอีเมลให้คุณ — ได้รับการสนับสนุนจากผู้เชี่ยวชาญระดับ Top-Rated”
  • เห็นด้วยกับบทความนี้ ปฏิกิริยาของฉันต่อสิ่งที่กำลังเกิดขึ้นตอนนี้ก็เป็นแบบ “ปล่อยฉันไว้ข้างหลังเถอะ”
    แต่การโหยหาความสนุกของวิธีเติบโตมาเป็นนักพัฒนาแบบเก่านั้นไม่ใช่แค่เหตุผลที่ผิดเท่านั้น แต่ถ้ามองแบบดาร์วินแล้วยังอันตรายมากด้วย ลูกค้าสุดท้ายแล้วไม่สนหรอกว่าคุณสร้างมันอย่างไร แต่สน การซัพพอร์ตระยะยาว, ต้นทุน, ความคาดการณ์ได้ และเรื่องทำนองนั้น
    ถึงอย่างนั้นก็ไม่แน่ใจว่าจะพูดได้ไหมว่าอุตสาหกรรมนี้ได้ก้าวหน้าแบบที่ให้ผลสุทธิเป็นบวกจริง ๆ ทั้งหมดมันเป็นความยุ่งเหยิงครั้งใหญ่ ในหลายกรณี AI แค่ผลักเราไปในทิศทางเดิมด้วยโหมดเทอร์โบ ทำให้ทุกอย่างสกปรกขึ้น แพงขึ้น และอันตรายขึ้นด้วย
    ฉันพูดว่า “ปล่อยฉันไว้เถอะ” เพราะถ้าคิดจากหลักการแรกอย่างจริงจัง ฉันมองความยุ่งเหยิงนี้เป็นโอกาสได้

    • ลูกค้าอาจสน ว่ามันถูกสร้างขึ้นอย่างไร ก็ได้
  • บทความนี้ดูเหมือนจะสร้าง ทางเลือกปลอมแบบมีแค่สองขั้ว ว่าจะไม่ใช้ AI เลย หรือไม่ก็มอบทุกอย่างให้ AI ทำ ซึ่งในความเป็นจริงมันไม่ได้เป็นแบบนั้น คุณเลือกเองได้ว่าจะให้ AI รับงานไปมากน้อยแค่ไหน ยังมีพื้นที่มหาศาลสำหรับความเชี่ยวชาญของมนุษย์ ชุมชน และความหลงใหลในเทคโนโลยี
    เวลาดูการถกเถียงสาธารณะเรื่อง AI ฉันนึกถึงความบิดเบือนทางความคิดใน cognitive behavioral therapy โดยเฉพาะการคิดแบบขาวดำและการคาดการณ์หายนะ ซึ่งก็มักเป็นอาการของความกังวลหรือภาวะจิตเภทเหมือนกัน บางครั้งก็อดสงสัยไม่ได้ว่าสังคมทั้งสังคมจะมีอาการแบบนี้ได้ไหม
    https://en.wikipedia.org/wiki/Splitting_(psychology)
    https://en.wikipedia.org/wiki/Cognitive_distortion#Decatastr...

    • สำหรับโปรเจกต์ส่วนตัว ฉันเห็นด้วยจริง ๆ แต่ในที่ทำงานเราไม่ได้มีสิทธิ์เลือกเสมอไป
      ถ้าทีมเริ่มถูกวัดจากปริมาณ PR ที่จัดการได้และปริมาณ token ที่ใช้ ฉันอาจดู “แย่” กว่าคนที่ทำ vibe coding แบบเต็มตัวอยู่ข้าง ๆ ถ้าฉันไม่ทำ vibe coding ฉันก็กลัวว่าจะเสียเปรียบเรื่องการเลื่อนตำแหน่ง
      ตัวชี้วัดที่บอกว่า vibe coding อาจไม่ดีนั้นเป็น ตัวชี้วัดตามหลัง ปัญหาของ vibe coding อย่างปัญหาด้านประสิทธิภาพ การเสื่อมคุณภาพของบริการ หรือการย้ายข้อมูลครั้งใหญ่ มักจะโผล่มาทีหลังเสมอ
    • ใช่ เพื่อความเป็นธรรม คนที่อยู่ฝั่งรับทั้งหมดกับฝั่งปฏิเสธทั้งหมดก็คงมีอยู่ และพวกเขาก็มักจะเสียงดัง
      แต่พวกเขาเป็นคนส่วนน้อย และคนส่วนใหญ่จะหาจุด กึ่งกลาง เจอเอง
  • ฉันเป็นนักพัฒนา PHP ระดับซีเนียร์ และเพิ่งถูกย้ายไปโปรเจกต์ Ruby on Rails เมื่อไม่นานมานี้ เป็นสภาพแวดล้อมที่ไม่คุ้นเคยเลย ลูกค้าแนะนำให้ใช้ LLM ให้มากที่สุดเท่าที่จะทำได้
    ปัญหาคือถ้าปล่อยให้ AI เขียนโค้ด มันแทบจะ เป็นไปไม่ได้เลยที่จะเรียนรู้ codebase ถ้าคุณไม่ตั้งใจขุดลึกลงไป คุณแทบจะไม่มีโอกาสได้เห็นโค้ดเกินไม่กี่บรรทัดในแต่ละครั้ง และเพราะข้อเรียกร้องเรื่องความเร็ว คุณอาจไม่มีเวลาทำแบบนั้นด้วย ผลคือไม่มีใครในทีมรู้ลึกจริง ๆ ว่าส่วนต่าง ๆ ของโค้ดทำงานอย่างไร นี่ต่างจากวิธีเขียนโค้ดที่ผมใช้มาตลอด 25 ปีอย่างมาก และก็สนุกน้อยกว่าด้วย
    เมื่อ 100 ปีก่อน คุณซื้อเฟอร์นิเจอร์ที่ทำโดยช่างฝีมือได้อย่างเดียว เป็นช่างฝีมือจริง ๆ เดี๋ยวนี้มีทั้ง IKEA และงานทำมือให้เลือก คนส่วนใหญ่ไม่สนหรอกว่ามันถูกสร้างอย่างไร ขอแค่ใช้งานได้ตามหน้าที่ก็เลือก IKEA ยังมีคนที่ชอบเฟอร์นิเจอร์ทำมืออยู่ และพวกเขาก็ยอมจ่ายแพง
    ซอฟต์แวร์ก็ดูเหมือนกำลังไปในทิศทางนั้น ซึ่งน่าเศร้าแต่ฉันก็เห็นด้วย การพัฒนาซอฟต์แวร์จะกลายเป็นงานอดิเรก เหมือนที่หลายคนทำงานไม้ในเวลาว่าง อาจเหลือผู้เชี่ยวชาญจริง ๆ อยู่เพียงไม่กี่คน ซึ่งส่วนใหญ่ทำงานที่ปรึกษา หรืออาจทำข้อมูลสำหรับการเรียนรู้ หรือออกแบบเฟรมเวิร์กที่ AI จะเชี่ยวชาญก็ได้ ไม่รู้เหมือนกัน แต่ต่อจากนี้มันจะต่างออกไปแน่ และไม่ใช่ทุกอย่างจะไปในทางที่ดี
    ตอนนี้ AI กำลังสร้างของให้มนุษย์ และบางครั้งก็สร้างให้ AI ตัวอื่น ไม่นานจากนี้ AI จะสร้างของให้ AI ตัวอื่น และบางครั้งค่อยสร้างให้มนุษย์ ต่อไปในอนาคต AI จะสร้างของให้ AI เป็นหลัก และการสร้างเพื่อมนุษย์จะกลายเป็นเรื่องที่พบได้น้อย

    • ที่ที่ฉันอยู่ยังซื้อเฟอร์นิเจอร์จากช่างฝีมือได้อยู่เลย ฉันซื้อเตียงจากร้านแถวบ้าน ราคาไม่ได้แพงเลยและก็พอใจมาก
      คุณน่าจะลองดูว่าประเทศคุณยังเป็นแบบนั้นไหม คนมักคิดไปเองว่า IKEA ฆ่าร้านท้องถิ่นหมดแล้ว แต่ถ้าลองหาดูจะพบว่ามี ร้านเฟอร์นิเจอร์ท้องถิ่น อยู่เยอะมาก
    • ฉันไม่มีเงินพอจะจ่ายให้ช่างฝีมือ เลยซื้อ IKEA ยังเหลือช่างฝีมือไม่มากพอที่จะผลิตในปริมาณที่ทำให้ราคาลดลงได้
  • บทความนี้ดูเหมือนเขียนโดย LLM หรือไม่ก็เขียนด้วยสไตล์การเขียนบล็อกมาตรฐานยุคนี้ ซึ่งตัวสไตล์เองก็ค่อย ๆ กลายเป็นเหมือน LLM มากขึ้นเรื่อย ๆ
    Sam Kriss เพิ่งชี้ “ร่องรอย” แบบนั้นได้ดีในบทความล่าสุดของเขา: https://samkriss.substack.com/p/if-you-let-ai-do-your-writin...

    • โดยเฉพาะใน HN มันเหมือนมีเกม “จับว่าเป็น LLM” อยู่ และแทบทุกบทความที่ลิงก์มาก็ต้องมีคอมเมนต์ว่ามันเขียนโดย AI
      ไม่เข้าใจกันหรือว่า “ร่องรอย” ของ AI นั้น ตามนิยามแล้วก็มาจากมนุษย์นั่นแหละ? บทความของ Sam Kriss วิจารณ์สำนวนฟุ้ง ๆ แต่กลับยก Salman Rushdie กับ Arundhati Roy มาเป็นตัวอย่างว่าก็ใช้ “ลูกไม้ราคาถูก” แบบเดียวกับ AI ซึ่งต่อให้เคารพแค่ไหนฉันก็รับไม่ได้ มันอันตรายจนเกือบจะกลายเป็นการเหมารวมว่าใครใช้คำเปรียบเปรยแปลก ๆ ก็คือใช้ LLM มนุษย์เขียนอะไรประหลาด ๆ กันมานานมากแล้วโดยไม่ต้องมี LLM
      แล้วบทความนี้มันมี “ร่องรอย” อะไรตรงไหน? อ่านแล้วตรงไปตรงมามาก และก็ไม่มีคำเปรียบเปรยแปลก ๆ เลย ขีดยาว em dash เองก็ไม่ใช่เบาะแสอะไรจริง ๆ ด้วย ซ้ำไปกว่านั้น การใช้ “ - ” แบบเว้นวรรค-ขีดกลาง-เว้นวรรคอย่างในบทความนี้กลับดูเป็นมนุษย์ดีด้วยซ้ำ ที่สำคัญที่สุด ฉันอยากให้ ประโยชน์แห่งความสงสัย กับคนที่เขียนบทความว่าไม่อยากเขียนโปรแกรมด้วย LLM
      ประมาณว่า “เครื่องจักรที่ตีเด็กกำพร้าทำให้ฉันเต็มไปด้วยความวิตกกังวลและความหวาดกลัวเชิงอัตถิภาวนิยม แต่ถ้าจะถ่ายทอดสิ่งนั้นให้ผู้อ่าน ฉันคงต้องปล่อยให้เครื่องนั้นตีเด็กกำพร้าสักสองสามคน” มันฟังดูประหลาด
    • ไม่มีเวลามานั่งดูขยะที่ AI สร้าง ต้องกลับไปให้ Claude เขียนโค้ดต่อแล้ว ;)