21 คะแนน โดย GN⁺ 2026-03-14 | 7 ความคิดเห็น | แชร์ทาง WhatsApp
  • การแพร่หลายของเครื่องมือเขียนโค้ดด้วย AI กำลังทำให้เห็นชัดถึง ความแตกต่างด้านแรงจูงใจ ที่มีอยู่ในหมู่นักพัฒนามาโดยตลอด แต่ก่อนหน้านี้มองไม่ค่อยเห็น
  • ความเศร้าจากการสูญเสียความพึงพอใจเชิงช่างฝีมือในการเขียนโค้ดด้วยตัวเอง กับความเศร้าจาก การเปลี่ยนแปลงของระบบนิเวศและสภาพแวดล้อมด้านอาชีพ รอบโค้ด เป็นความสูญเสียคนละแบบ
  • จากมุมมองของนักพัฒนาที่เขียนโปรแกรมมาตั้งแต่ยุค 1980 การเขียนโค้ดด้วย AI คือ ส่วนต่อขยายตามธรรมชาติของลำดับขั้นของนามธรรม ตั้งแต่ C64 BASIC ไปจนถึงแอสเซมบลี จากฟังก์ชันไปสู่การออกแบบระบบ
  • ประสบการณ์หลายสิบปีในการอ่านและรีวิวโค้ดยังคงใช้ได้ในฐานะ สัญชาตญาณและวิจารณญาณ สำหรับตัดสินคุณภาพของโค้ดที่ AI สร้างขึ้น
  • กุญแจสำคัญคือการตระหนักว่าตนเองกำลังรู้สึกเศร้าจากความสูญเสียแบบไหน เพราะการสูญเสียเชิงช่างฝีมือกับการสูญเสียเชิงบริบทนั้นต้องการ วิธีรับมือที่ต่างกัน

การเริ่มต้นของการไว้อาลัย

  • James Randall เป็นนักพัฒนาที่เริ่มเขียนโปรแกรมตั้งแต่อายุ 7 ขวบในยุค 1980 และอธิบายว่าประสบการณ์ของการค้นพบและการค่อย ๆ แกะปัญหาด้วยความพากเพียรนั้นถูก "บีบอัด" ลง
    • มันไม่ได้หายไปทั้งหมด แต่มีบางอย่างสูญหายไประหว่างกระบวนการบีบอัดนั้น
  • Nolan Lawson แสดงความรู้สึกสูญเสียอย่างตรงไปตรงมามากกว่าในบทความ "We Mourn Our Craft"
    • เราจะโหยหาความรู้สึกของการปั้นโค้ดด้วยมือ ประสบการณ์ไล่บั๊กด้วยดีบักเกอร์ตอนตี 2 และความภูมิใจที่ว่า "ฉันเป็นคนสร้างมัน"
  • ความรู้สึกเหล่านี้เป็นอารมณ์ที่แท้จริงต่อการสูญเสียจริง แต่เมื่ออ่านแล้วก็ยังรู้สึกต่อเนื่องว่าพวกเขากำลัง ไว้อาลัยให้กับคนละสิ่ง

แก่นของความแตกแยก

  • การเขียนโค้ดด้วย AI กำลังเผยให้เห็น ความแตกแยกที่มีอยู่มาโดยตลอดแต่ไม่ชัดเจนนัก ในหมู่นักพัฒนา
  • ก่อนยุค AI ทั้งสองฝ่ายต่างก็ทำงานในแบบเดียวกัน: ใช้เอดิเตอร์เดียวกัน ภาษาเดียวกัน และเวิร์กโฟลว์ pull request แบบเดียวกัน
    • นักพัฒนาแนวช่างฝีมือ กับ นักพัฒนาแนวมุ่งผลลัพธ์ นั่งทำงานข้างกัน ปล่อยผลิตภัณฑ์เดียวกันออกมา และแทบแยกไม่ออก
    • แรงจูงใจ ของการทำงานไม่เคยมองเห็น เพราะ กระบวนการ เหมือนกัน
  • ตอนนี้ได้เกิดทางแยกขึ้นแล้ว: จะมอบหมายให้เครื่องเขียนโค้ดและคอยกำกับว่าจะสร้างอะไร หรือจะลงมือเขียนโค้ดด้วยตัวเอง
    • ณ ช่วงเวลาที่ต้องเลือกนี้เอง เหตุผล ที่แต่ละคนเริ่มเขียนโปรแกรมตั้งแต่แรกจึงปรากฏชัด
  • แม้แต่ในชั้นเรียนคณิตศาสตร์และวิทยาการคอมพิวเตอร์สมัยมหาวิทยาลัย ก็มีความแตกแยกแบบเดียวกันอยู่แล้ว: คนที่ชอบบทพิสูจน์และทฤษฎีในตัวมันเอง กับคนที่สนใจเฉพาะตอนที่ นำไปประยุกต์ใช้ เท่านั้น

ความเศร้าของฉันต่างออกไป

  • ตลอด 18–24 เดือนที่ผ่านมา ผู้เขียนได้ผ่านทั้งช่วงเวลาแห่งความเศร้าและการปรับตัวจริง ๆ
  • เคย กลัวว่าจะไม่สามารถเข้าใจเครื่องมือใหม่ได้ แต่ในความเป็นจริงกลับเข้าใจมันได้
  • เคยกังวลว่าจะสูญเสียความสามารถในการตัดสินคุณภาพของโค้ดที่ AI สร้าง แต่ประสบการณ์หลายสิบปีในการอ่านและรีวิวโค้ด ไม่ได้ระเหยหายไป
    • เมื่อมีบางอย่างผิดพลาดก็ยังมองออก และ สายตาเชิงประเมิน ก็ยังคงอยู่เหมือนเดิม
  • เคยกลัวว่าความสนุกแบบการแก้ปริศนาจะจบลง แต่จริง ๆ แล้วแค่ขยับขึ้นไปอีกหนึ่งระดับ
    • ตั้งแต่การจัดวางไบต์บน C64 → การเขียนฟังก์ชัน → การออกแบบระบบ เป็น รูปแบบเดียวกันกับทุกการเปลี่ยนผ่าน ในอาชีพที่ผ่านมา
    • ตอนนี้ปริศนาได้ย้ายไปอยู่ในเรื่องสถาปัตยกรรม การจัดองค์ประกอบ และการสั่งการผู้ช่วย
  • ความกลัวส่วนใหญ่ไม่สามารถคงอยู่ได้เมื่อปะทะกับความเป็นจริง แต่ก็ยังมีความเศร้าบางส่วนหลงเหลืออยู่

ความเศร้าที่เหลืออยู่

  • ไม่ใช่ความเศร้าที่ไม่ได้เขียน HTML ด้วยมือ แต่เป็นความเศร้าต่อ ระบบนิเวศเว็บแบบเปิด เอง
    • การที่ AI เรียนรู้จากทรัพยากรส่วนรวม และการ รวมศูนย์เพิ่มเติม ของผู้ที่กำหนดประสบการณ์อินเทอร์เน็ตของผู้คน คือความสูญเสียที่เกิดขึ้นจริง
    • เป็นปัญหาที่ไม่หายไป ไม่ว่าจะเพิ่มผลิตภาพส่วนตัวได้มากแค่ไหนก็ตาม
  • ความเศร้าต่อ ภูมิทัศน์อาชีพที่เปลี่ยนไป
    • งานพัฒนาเว็บที่ทำมานานกว่า 30 ปี ไม่ได้เป็นสนามที่ร้อนแรงอีกต่อไป
    • แอปมือถือได้ดึงบางส่วนไป และตอนนี้ วิศวกรรม AI ก็ขึ้นมาอยู่ในตำแหน่งนำ
    • แม้จะคิดว่าตัวเองกำลังเปลี่ยนผ่านได้สำเร็จ แต่ความกังวลนั้นเป็นเรื่องจริงและยังไม่จบสิ้น
  • แก่นของความเศร้านี้คือ ไม่ได้โหยหาการเขียนโค้ดในตัวมันเอง
    • แต่เศร้ากับการที่ โลกที่อยู่รอบโค้ด กำลังเปลี่ยนไป
    • ความเศร้าของ Randall และ Lawson เป็นเรื่องของ จิตวิญญาณช่างฝีมือ เอง ขณะที่ความเศร้าในบทความนี้เป็นเรื่องของ บริบทและเหตุผล

ไม่มีฝ่ายไหนผิด

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

ทำให้คอมพิวเตอร์ทำงาน

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

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

 
github88 2026-03-16

ตื่นตูมกันเกินไปแล้ว

 
ahwjdekf 2026-03-15

ผมมองว่างานอย่างเว็บโปรแกรมมิ่งให้ AI ทำแทนได้ถือเป็นเรื่องที่ดีมาก

 
brilliant08 2026-03-17

ดูเหมือนว่าการเขียนโปรแกรมแบบอื่นจะมีคุณค่าที่สูงส่งอะไรบางอย่างสินะ

 
onetoday 2026-03-14

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

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

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

 
snisper 2026-03-14

ถ้ากังวลเรื่อง AI ขนาดนั้น ก็แค่ไม่ต้องใช้มันก็พอไม่ใช่เหรอ

 
savvykang 2026-03-16

ผมสงสัยว่าตอนที่เครื่องมือ RAD ออกมา ผู้คนตอบสนองกันอย่างไร

 
GN⁺ 2026-03-14
ความเห็นจาก Hacker News
  • ผมคิดว่าบทความนี้เข้าใจประเด็นผิดทั้งหมด นักพัฒนาแบบ craft ก็ให้ความสำคัญกับผลลัพธ์เหมือนกัน แต่เป็นผลลัพธ์ที่ยั่งยืนและขยายต่อได้
    เป้าหมายของโปรแกรมเมอร์ที่ดีคือการ ทำให้ตัวเองไม่จำเป็นอีกต่อไป สมัยก่อนเคยนับ cycle ใน assembly และแพ็กบิตกันเป็นเรื่องปกติ แต่ต่อมาการใช้ compiler ก็กลายเป็นเรื่องธรรมดา เคยมีช่วงที่ต้องเขียนแอป CRUD เองทั้งหมด แต่ตอนนี้ framework ทำแทนแล้ว การจัดการหน่วยความจำ type system ภาษาแบบ high-level รวมถึงระบบ no-code/low-code ล้วนเป็นส่วนหนึ่งของวิวัฒนาการ สุดท้ายแล้วจุดประสงค์ของการเขียนโปรแกรมก็คือทำให้คอมพิวเตอร์ทำสิ่งที่เราไม่ต้องทำเอง
    ผมคิดว่ารอยแยกที่แท้จริงคือ ความต่างทางวิธีคิด ระหว่างคนที่มองว่า ‘ซอฟต์แวร์เป็นสิ่งที่ปรับปรุงและทำความเข้าใจได้’ กับคนที่มองว่า ‘มันเป็นอุปสรรคชวนงงที่คนอื่นสร้างไว้’
    • ผมชอบมุมมองนี้ พอทำงานกับระบบเดิมนานพอ รายละเอียดทุกอย่างจะเริ่มมีความหมาย และจะพอเดาได้ว่าถ้าเปลี่ยนอย่างหนึ่งแล้วทั้งระบบจะได้รับผลกระทบยังไง แต่ผมก็กังวลว่าใน ยุคของซอฟต์แวร์ AI ความเข้าใจแบบนี้อาจเป็นไปไม่ได้ โค้ดจะถูกสร้างอัตโนมัติมากเกินไปจนมองภาพรวมไม่ออก สุดท้ายถ้าแก้ยาก การสั่ง AI สร้างใหม่อาจสมเหตุสมผลกว่า เพราะงั้น modularity น่าจะยิ่งสำคัญขึ้น
    • ผมเห็นด้วยแทบทั้งหมด ยกเว้นประโยคสุดท้าย ผมว่าไม่ใช่เรื่องระดับสติปัญญา แต่เป็นเพราะคนกลุ่มที่สองจำนวนมากมีความสามารถต่ำกว่าจริง
    • ผมสงสัยว่าการแบ่งแบบนี้คล้ายการแบ่งของ Pirsig ระหว่าง ‘classical vs romantic’ หรือเปล่า แบบแรกพยายามเข้าใจโครงสร้างและหลักการ ส่วนแบบหลังให้ความสำคัญกับรูปลักษณ์ ความรู้สึก และประโยชน์ใช้สอย
    • ประโยคที่ว่า “โปรแกรมเมอร์ที่ดีทำให้ตัวเองไม่จำเป็นอีกต่อไป” เมื่อก่อนเคยได้ยินบ่อย แต่เดี๋ยวนี้แทบไม่เห็นแล้ว
  • รอยแยกที่แท้จริงคือระหว่างคนที่เชื่อว่าความก้าวหน้าทางเทคโนโลยีเป็นสิ่งดีโดยเนื้อแท้ กับคนที่รู้ว่าในประวัติศาสตร์ การเพิ่มผลิตภาพไม่เคยนำไปสู่การลดชั่วโมงทำงาน
    ระบบทำงานวันละ 8 ชั่วโมงไม่ได้เกิดจากเทคโนโลยี แต่เป็นผลจากการต่อสู้ทางการเมือง
    • รอยแยกที่แท้จริงคือระหว่าง เจ้าของทุนกับแรงงาน นายทุนใช้ชีวิตจากเศษกระดาษที่รับมรดกมา แล้วกินส่วนหนึ่งของผลผลิตจากแรงงาน
    • น่าสนใจที่เริ่มเห็นการถกเถียงแบบนี้ใน Hacker News บ่อยขึ้น ถ้า AI มาแทนที่นักพัฒนา คนฉลาดและมีแรงจูงใจอาจ ตื่นตัวทางการเมือง ก็ได้ ในประวัติศาสตร์ เมื่อบริษัทใหญ่เกินไป สุดท้ายก็มักถูกปฏิบัติราวกับเป็นรัฐ
    • มีความเห็นสุดโต่งมากเกินไป สุดท้ายรอยแยกที่แท้จริงคือระหว่าง คนที่สนับสนุนวิทยาศาสตร์และเทคโนโลยี กับคนที่เกลียดมัน
  • ตอนนี้มันไม่ใช่แค่เรื่องของ คนที่ชอบพิมพ์บน mechanical keyboard อีกแล้ว ความต่างจริง ๆ คือคนที่ชอบเข้าใจระบบและสร้างของใหม่ กับคนที่อยากโยนเรื่องนั้นให้คนอื่นทำแล้วเก็บแต่ผลลัพธ์
    แต่ถ้าคนที่รับช่วงเป็นมนุษย์ อย่างน้อยก็ยังแบ่งเครดิตกันได้ผ่านการสอนงานหรือการจัดสภาพแวดล้อม
    • ตลกดีที่ “รอยแยกที่แท้จริง” มักจบลงด้วยภาพของ ‘ฉันผู้เหนือกว่าทางสติปัญญาหรือศีลธรรม’ กับ ‘พวกเขาที่ด้อยกว่า’ เสมอ
    • ผมเองก็ชอบเข้าใจระบบและสร้างของใหม่ แต่ก็ชอบ มอบงานซ้ำ ๆ ให้ AI ทำ ด้วย แบบนี้แปลว่าผมไม่ควรมีอยู่เหรอ? ผมไม่เห็นด้วย
    • นักพัฒนามีอยู่สองแบบ แบบ A ใส่ใจละเอียดทั้ง security, testing, CI แต่ในมุมผู้ใช้อาจรู้สึกอืดอาด แบบ B อาจไม่เก่งเรื่อง test หรือ deploy แต่ให้ความสำคัญกับประสบการณ์ผู้ใช้ ทั้งสองแบบจำเป็นทั้งคู่ เพียงแต่ AI น่าจะเริ่มแทนที่ฝั่งของแบบ A ก่อน
    • ให้ความรู้สึกประมาณ “Claude, ช่วยยกของหนักนี่ให้หน่อย”
    • แต่ละคนมีจุดที่รู้สึกสนุกไม่เหมือนกัน ผมชอบ กระบวนการแก้ปริศนา มากกว่า ชอบการแก้ปัญหาเฉพาะหน้ามากกว่าการวางแผนล่วงหน้า
  • ก่อนยุค AI คนทั้งสองกลุ่มก็ทำงานแบบเดียวกัน — ใช้ editor เดียวกัน ภาษาเดียวกัน และ PR workflow เดียวกัน ความต่างอยู่ที่ แรงจูงใจ เลยมีคนที่ชอบให้ AI เขียนโค้ดแทน และมีคนที่เสียดายเพราะส่วนที่ตัวเองเคยสนุกด้วยหายไป
    บทความของ Kellan “Code has always been the easy part” ก็พูดในทิศทางเดียวกัน คนรุ่นเราเข้าสู่วงการเทคโนโลยีเพราะเสพติด ความรู้สึกมีอำนาจควบคุม ที่เว็บมอบให้
    • ความต่างจริง ๆ คือ มาตรฐานด้านคุณภาพ บางคนใช้เวลาหลายชั่วโมงกับแค่ชื่อตัวแปรเดียว บางคนคิดแค่ว่า “รันได้ก็พอ” ทั้งสองแบบมีคุณค่า แต่โมเดลกำลังพัฒนาเร็วมาก อย่าใช้เกณฑ์ของปีที่แล้วมาตัดสิน ผลลัพธ์พื้นฐานอาจอยู่ระดับกลาง ๆ แต่ถ้าใช้เป็นก็รีดคุณภาพได้สูงกว่านั้นมาก
    • ใครบอกว่าเขียน Perl ไม่สนุกในเชิงสุนทรียะ? ผมภูมิใจมากที่ใช้ Perl เป็น มันมี ความสะใจจากการควบคุมภาษาที่อ่านยากได้อย่างคล่องมือ
    • Perl มีเสน่ห์ของมันจริง ๆ syntax อย่าง unless ก็ช่วยให้ถ่ายทอด flow ได้เป็นธรรมชาติ แต่พอวิวัฒนาการหยุดลง แต่ละคนก็ขยายมันกันคนละทางจนเกิด codebase ที่เปราะบาง
    • ผมไม่ได้สนุกกับการเขียนโค้ดโดยตัวมันเอง แต่ชอบ ความพอใจตอนแก้ปัญหาสำเร็จ และรู้สึกว่าวิธีคิดแบบนี้ช่วยให้สมองยังยืดหยุ่น
    • มันไม่ใช่การแบ่งสองขั้ว ผมเป็นลูกผสมของทั้งสองแบบ พอ AI มาทำโค้ดงานแทน ก็เลยมีเวลาว่างกลับไปสนุกกับการเขียนโค้ดแบบดั้งเดิมที่บ้าน
  • ผมเป็นพวกเน้นผลลัพธ์ และให้ความสำคัญกับ คุณภาพของผลลัพธ์ มาก หมกมุ่นกับความสมบูรณ์ของผลิตภัณฑ์ที่เสร็จแล้วมากกว่ากระบวนการเขียนโค้ด แต่ทุกวันนี้แอปกลับช้ากว่าเมื่อ 15 ปีก่อนและมีบั๊กมากกว่า แม้แต่แอป Claude เองยังมีปุ่มที่กดไม่ติดโผล่มาให้เห็น
    AI coding ช่วยเพิ่มผลิตภาพได้แค่ราว 10% คอขวดที่แท้จริงคือ การเข้าใจว่าจะต้องสร้างอะไรและการโน้มน้าวให้คนเห็นตรงกัน การเขียนโค้ดเป็นเพียงเครื่องมือเพื่อทำความเข้าใจสิ่งนั้น
    • ผมเองก็ใช้ AI กับ การค้นข้อมูลและตรวจสอบความถูกต้อง มากกว่าการเขียนโค้ด ผมให้ LLM หลายตัวทำหน้าที่ reviewer แล้ววิจารณ์กันเอง มันช่วยมากเวลาต้องจัดการ business logic ที่ซับซ้อน AI ยังมีประโยชน์กับ การสำรวจ edge case ด้วย
    • เห็นด้วยว่าการเขียนโค้ดไม่ใช่คอขวด การบอกว่า AI ทำให้ผลิตภาพเพิ่ม 10 เท่านั้นฟังไม่สมเหตุสมผล ผมเขียนโค้ดเร็วอยู่แล้ว AI เลยไม่ได้ช่วยมาก กลับกันมันทำให้เกิดสถานการณ์ที่ ความเร็วถูกบังคับให้มาก่อนคุณภาพ เพื่อนร่วมทีมใช้ AI ปั่นโค้ดออกมาหลายพันบรรทัดจนคุณภาพตกฮวบ
    • ดูเหมือนคุณกำลังสับสนระหว่างคุณภาพของโค้ดกับความสมบูรณ์ของผลิตภัณฑ์ ปัญหาส่วนใหญ่เกิดจาก การตัดสินใจทางธุรกิจ
    • ถ้าบอกว่า “สนใจแค่ผลลัพธ์” ก็ถามกลับได้เหมือนกันว่า แล้วทำไมไม่จ้างคนนอกทั้งหมดแทนที่จะทำเอง?
  • ผมคิดถึง “เว็บยุคที่เขียน HTML ด้วยมือ” เสียดายที่ ระบบนิเวศเว็บแบบ DIY ที่คนธรรมดาสร้างเอง กำลังถูกแทนที่ด้วยเครื่องมือ AI ที่บริษัทเป็นเจ้าของ ตอนนี้เราอาจยังอยู่แค่ช่วงเปลี่ยนผ่าน แต่ ความเสื่อมถอยของเว็บแบบเปิด กำลังเร่งตัวขึ้น
  • Generative AI ก็ใช้ต่อยอดจากความเป็นช่างฝีมือได้เหมือนกัน เช่นโหลดโค้ดโอเพนซอร์สมาถามว่า “ทำไมมันถึงทำงานแบบนี้?” เพื่อพัฒนาแบบ อิงความเข้าใจ
    • ความสนุกของการแก้ปริศนาไม่ได้หายไป แต่ ย้ายขึ้นไปอีกหนึ่งระดับ ตอนนี้อาณาเขตของช่างฝีมือคือการออกแบบโครงสร้างและเหตุผลของทั้งระบบ
    • แน่นอนว่าผลลัพธ์นั้นควร ส่งกลับไปมีส่วนร่วมกับ upstream
    • จริง ๆ แล้วเรื่องแบบนี้เมื่อก่อนก็ทำได้ผ่าน search engine อยู่แล้ว
  • ทั้งสามสถานการณ์ล้วนแย่ ① AI อ่อนแอ → Great Depression 2.0, ② AI ระดับที่คาดไว้ → การผูกขาดโดยมหาเศรษฐีจำนวนน้อย, ③ AI ทรงพลังมาก → มนุษยชาติสูญพันธุ์ ปริมาณ AI ในอุดมคติคือ 0
    ถึงอย่างนั้นก็ควรพยายามต่อต้าน
    • เมื่อก่อนผมก็คิดแบบนั้น แต่ช่วงนี้พอเห็น ข้อจำกัดจริงหลังยุค AI boom ก็รู้สึกว่าตลาดน่าจะปรับฐานในไม่ช้า ตอนนี้มันใกล้เคียงยุค AOL มากกว่า
    • ปัญญาที่แท้จริงไม่ใช่แค่เปลี่ยนข้อความเป็นการเรียกใช้เครื่องมือ แต่ต้องรวมถึง การวางแผน การวิจารณ์ และการแก้ปัญหาอย่างสร้างสรรค์
    • จริง ๆ แล้วทั้งสถานการณ์ 1 และ 2 ก็เป็นคนกลุ่มเดียวกันที่ได้ประโยชน์ ส่วนข้อ 3 เป็นเพียง ภาพลวง เพื่อเบี่ยงเบนความสนใจของสาธารณะ
  • พอทำงานในสตาร์ทอัพมานาน ผมก็เลิกยึดติดกับ ‘craftsmanship’ ไปแล้ว แต่กลับพอมองออกว่า การไม่มี AI code review หรือ PR ที่ใหญ่เกินไป อันตรายแค่ไหน นี่ไม่ใช่เรื่องของจิตวิญญาณช่างฝีมือ แต่เป็นเรื่องของ ความแม่นยำและการจัดการ technical debt
    • ปัญหาไม่ใช่คนที่ “มุ่งผลลัพธ์” แต่คือ คนที่เอาหน้าเก่งแต่เลี่ยงงาน ต่อให้โค้ดของพวกเขาพังไปแล้ว พวกเขาก็ย้ายไปโปรเจกต์อื่นก่อนอยู่ดี
    • จากประสบการณ์ของผม มันไม่ใช่เรื่อง ‘craftsmanship vs ผลลัพธ์’ แต่คือ ความสามารถในการสร้างทั้งอาคารให้ดี มากกว่า ให้ AI รับงานบางส่วนแบบผู้รับเหมาช่วงก็ดี แต่ตอนนี้มันเหมือน จ้างภายนอกทั้งโปรเจกต์ จนผลงานออกมาเละ
  • นักพัฒนามีสองประเภท คือคนที่รักการเขียนโค้ดมากจน ไม่ยอมไปเป็นผู้จัดการ กับคนที่ถ้ามีโอกาสก็พร้อมไปเป็นผู้จัดการทันที คนประเภทหลังได้ประโยชน์จาก AI มากกว่า
    • คนที่เก่งเรื่องจัดการคนก็ควรเป็นผู้จัดการ และยังมีประเภทที่สามด้วย — คนที่ชอบออกแบบระบบและมอบงาน implementation ให้คนอื่นทำ