การสร้างคืออะไร

 (beej.us)
1 คะแนน โดย GN⁺ 6 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • แม้จะทำโปรเจ็กต์ให้เสร็จด้วย generative AI แต่ถ้าคนที่ขอและผู้ที่ลงมือสร้างจริงเป็นคนละคน ก็ยากจะได้ ความภูมิใจว่า ‘ฉันเป็นคนทำ’
  • การเขียนพรอมป์ต์ต้องอาศัยวิสัยทัศน์ การตัดสินใจ การสื่อสาร และทักษะ แต่ใกล้เคียงกับ ทักษะการมอบหมายให้สิ่งอื่นสร้างแทน มากกว่าทักษะการลงมือทำเอง
  • ระบบแฟลชการ์ดภาษาสเปน 177 บรรทัดที่เขียนเองใช้เวลานานกว่า Claude ราว 50 เท่า แต่ให้ความภูมิใจมากกว่าโค้ดใด ๆ ที่ AI สร้าง
  • ในขณะที่คอมไพเลอร์ แอสเซมเบลอร์ และค้อนให้ความรู้สึกเป็นเครื่องมือของผู้สร้าง AI ที่ตอบสนองต่อภาษามนุษย์กลับดูคล้ายคนที่รับคำสั่ง จึงทำให้ เส้นแบ่งระหว่างเครื่องมือกับผู้รับจ้างสร้างแทน พร่าเลือน
  • การสร้างผ่าน AI อาจนับเป็นงานสร้างสรรค์ได้ แต่การทำให้ผลงานเสร็จ กับการลงมือสร้างเอง ไม่ได้ให้ความอิ่มเอมส่วนตัวเท่ากัน และก็ยากจะกำหนดเส้นแบ่งนั้นให้ชัดเจน

ความสำเร็จที่ AI เปลี่ยนความหมายไปในการพัฒนา

  • นักพัฒนาที่ใช้ generative AI และ LLM มักพบกับการเปลี่ยนแปลงที่สวนทางกัน
    • อาจสูญเสีย งานฝีมือแบบช่าง, การแก้ปัญหาระดับล่าง และความสนุกของการเขียนโค้ดด้วยมือตัวเอง
    • แต่อาจได้ทำโจทย์ระดับสูงมากขึ้น ปิดโปรเจ็กต์ที่ค้างไว้ และพบความสนุกแบบใหม่
  • นอกเหนือจากข้อดีข้อเสียเหล่านี้ คำถามสำคัญคือจะ รู้สึกได้หรือไม่ว่าเป็นสิ่งที่ตัวเองสร้าง เมื่อผลลัพธ์นั้นถูกทำให้เสร็จโดย AI
  • เรื่องนี้เริ่มจากประสบการณ์ของนักพัฒนาที่เขียนโค้ดมาตั้งแต่ยุคไมโครคอมพิวเตอร์ในทศวรรษ 1980 ทำงานในวงการมา 20 ปี และปัจจุบันสอนวิทยาการคอมพิวเตอร์
    • เขาประเมินตัวเองว่าอยู่ฝั่งหายนะ 65% บนสเกลระหว่าง AI ยูโทเปียกับหายนะ
    • ใช้ Claude Code ควบคู่กับการเขียนโค้ดเอง

‘ความสารพัดเก่ง’ ที่ตกแต่งด้วยผลลัพธ์จาก AI

  • ช่วงต้นเรื่องมีผลงานหลายชิ้นที่ดูเหมือนทำขึ้นเอง
    • นิยายวิทยาศาสตร์ฉากต่อสู้ The Vorrkai Interval
    • ภาพพิมพ์ไม้โทนพาสเทล Mirrors of the Machine
    • ระเบียงหน้าบ้านไม้ซีดาร์ที่สร้างใหม่
    • โค้ดเกมผจญภัย roguelike แบบ TUI ที่เขียนด้วย Rust
  • แต่ในความจริง นิยาย ภาพ และโค้ดนั้น AI เป็นผู้สร้าง ส่วนระเบียงสร้างโดยช่างฝีมือที่รับค่าจ้าง
  • บทบาทของผู้เขียนคือเริ่มต้นงานและสื่อสารความต้องการ จึงรู้สึกกระอักกระอ่วนหากจะพูดว่าผลงานเหล่านี้เป็นสิ่งที่ตนสร้าง

ทำไมจึงพูดได้ยากว่า ‘ฉันเป็นคนสร้าง’

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

แฟลชการ์ด 177 บรรทัดที่เขียนด้วยมือ

  • ภรรยาขอระบบเรียนภาษาสเปนแบบง่าย ๆ ที่ใส่คำศัพท์ที่ต้องการลงในสเปรดชีตแล้วดูเป็นแฟลชการ์ดได้
  • เขารับหน้าที่ลงมือทำเอง และสั่ง Claude ว่าอย่าสร้างโค้ด ให้ช่วยตอบเพียงข้อมูลพื้นฐาน เช่น วิธีที่ง่ายที่สุดในการดึงข้อมูลจาก Google Sheets
    • ใช้ CSV endpoint ของ Google Sheets
    • เขียนทั้งหมด 4 ไฟล์ รวม 177 บรรทัด: JavaScript 112 บรรทัด, CSS 33 บรรทัด, HTML 32 บรรทัด
  • แม้จะใช้เวลานานกว่าตอนให้ Claude ทำประมาณ 50 เท่า แต่เขาสามารถใส่ชื่อตัวเองและพูดได้ว่าเป็นคนสร้างมันขึ้นมา
  • ถึงจะไม่ใช่โค้ดชิ้นใหญ่หรือปฏิวัติวงการ แต่เขาภูมิใจกับมันมากกว่าโค้ดใด ๆ ที่ Claude เขียน
  • เช่นเดียวกับที่ภรรยาซึ่งเป็นคนเริ่มความต้องการ ไม่ได้พูดว่าเธอเป็นคนเขียนระบบแฟลชการ์ด คนที่ร้องขอก็ไม่เท่ากับผู้สร้างเสมอไป

การเขียนพรอมป์ต์คือทักษะอีกแบบหนึ่ง

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

พื้นที่สีเทาระหว่างคอมไพเลอร์กับ AI

  • เวลาเขียนโปรแกรม C หรือ Rust ผู้เขียนไม่ได้เขียน machine code ที่รันจริงด้วยมือตัวเอง แต่ก็ยังรู้สึกว่าตัวเองเป็นคนเขียนโปรแกรมนั้น
  • การแปลงจากโค้ด C ไปเป็น machine code ใกล้เคียงกับกระบวนการที่แม่นยำทางคณิตศาสตร์ แต่ก็ยังมีคำถามบางอย่างคงอยู่
    • Clang และ GCC สร้างชุดคำสั่งต่างกัน ผลลัพธ์จึงไม่ได้ถูกกำหนดอย่างเคร่งครัดให้มีเพียงแบบเดียว
    • machine code อาจต่างกันในแต่ละแพลตฟอร์ม แต่โค้ด C ยังพกพาได้
    • แม้จะ build แค่บน Linux ก็ยังอาจมองได้ว่าโปรแกรมที่รันบน Windows เป็นสิ่งที่ตนเขียน
  • เมื่อขอให้ Claude แปลงโปรแกรม C แบบ recursive Fibonacci เป็นแอสเซมบลี x86_64 Linux ก็ได้โค้ดที่ build และรันได้
    • เอาต์พุตแสดงลำดับ Fibonacci ถูกต้องตั้งแต่ 0: 0 ถึง 9: 34
    • ยังใช้ XOR เพื่อตั้งค่าสถานะจบการทำงานเป็น 0 ด้วย
  • เพราะต้นฉบับโค้ด C เขียนเอง แม้แอสเซมบลีจะถูกสร้างโดย Claude เขาก็ยังรู้สึกว่าโปรแกรมนั้นเป็นสิ่งที่ตนเขียน
  • การแปลงจากแอสเซมบลีไปเป็น machine code เป็นกระบวนการที่เข้มงวดและไร้ปัญญา จึงถูกมองเหมือน การใช้เครื่องมือที่ไม่ได้แย่งบทบาทการสร้างไป คล้ายการใช้ค้อนตอกตะปู

เกณฑ์ที่แบ่งเครื่องมือออกจากผู้สร้างแทน

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

สิ่งที่ผู้เขียนมีส่วนลงแรงจริงในผลงานเหล่านั้น

  • สำหรับฉาก SF เขาใช้พรอมป์ต์ให้สร้างสามย่อหน้าและชื่อนิยาย โดยมีฮีโร่กับผู้ลี้ภัยสองคนติดอยู่ใต้การโจมตีด้วยเลเซอร์ของศัตรู ก่อนจะหาทางหนีได้
  • สำหรับภาพ เขาขอให้สร้างแฮ็กเกอร์สไตล์พ่อมดสองคนที่นั่งหันหน้าเข้าหากันและจดจ่อกับคอมพิวเตอร์ ในสไตล์ภาพพิมพ์ไม้โทนพาสเทล พร้อมใช้สีที่ตรงข้ามกันแต่เสริมกันทั้งสองฝั่ง
  • สำหรับเกม เขาขอเกมแฟนตาซี TUI ที่คล้าย Ultima I
    • ต้องการอักขระ 3×3 ต่อหนึ่งช่องแผนที่, 7×7 ช่องแผนที่ต่อหนึ่งหน้าจอ, และแอนิเมชันน้ำ
    • มีโลกแบบ procedural ด้วย Perlin noise, มอนสเตอร์ที่กำหนดไว้ล่วงหน้าและเคลื่อนที่แบบสุ่ม, และค่าสถานะแบบ D&D
    • ใช้ตัวละครผู้เล่นทั่วไปที่ไม่มีอาชีพ เขียนด้วย Rust และ Ratatui และแยก UI ออกจาก game logic
  • สำหรับงานไม้ เขาขอเพียงว่า “ช่วยเปลี่ยนระเบียงหน้าบ้านให้หน่อย” แต่ตะปูหนึ่งตัวในเศษไม้ที่อยู่ในรูปเปิดเรื่อง เขาเป็นคนตอกเองจริง ๆ
  • เครื่องหมาย em dash ที่ใช้ในบทความนี้เป็นการเลือกโดยตั้งใจ และ Vim digraph คือ ^K-M

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

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

 
GN⁺ 6 시간 전
ความคิดเห็นใน Hacker News

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

    • ชีสเบอร์เกอร์ที่สั่งเมื่อสัปดาห์ก่อนในร้านอาหาร โดยขอไม่ใส่ผักกาดหอมและเพิ่มหัวหอม ก็ทำให้สงสัยว่าเรียกได้ไหมว่าฉัน “สร้าง” มันขึ้นมา เพราะมันคงไม่มีอยู่ถ้าไม่มีคำขอของฉัน
      กรณีอย่างแซนด์วิชเนยถั่วกับแยม ที่ลงมือทำเองโดยไม่มีความคิดสร้างสรรค์ เราก็ยังบอกว่าทำขึ้นมา และแม้ใช้เครื่องมืออย่างเลื่อยวงเดือนที่มาทดแทนแรงงานมือก็เช่นกัน
      แต่การดาวน์โหลด Articulated dragon.stl จากเว็บแล้วแค่กดปุ่มพิมพ์ กับการออกแบบเองแล้วพิมพ์ออกมา นั้นต่างกัน
      การใช้งาน CNC และเครื่องพิมพ์ 3D ก็ต้องใช้ความรู้และทักษะที่ต่างจากงานทำมือ แต่ยิ่งเครื่องมือง่ายขึ้น เส้นแบ่งก็ยิ่งพร่าเลือน
      แม้ไม่มีเส้นแบ่งที่ชัดเจน แต่มันอยู่ที่ไหนสักแห่งระหว่าง “เครื่องมือใหม่คือการโกง ต้องทำทุกอย่างด้วยมือ” กับ “สั่งแซนด์วิชแล้วนั่งรอ”
    • ตรรกะที่ว่า “ถ้าไม่มีฉัน มันคงไม่มีอยู่” นั้นใช้ได้ยาก
      ถ้ามอบหมายโปรเจกต์ให้คนอื่นทำ อาจพูดได้ว่าบริหารจัดการหรือออกแบบบางส่วน แต่ยากที่จะรับเครดิตว่าลงมือทำเอง
      แม้ไม่ได้ผลิตจริง ก็ยังภูมิใจกับการกำหนด ทิศทางและวิสัยทัศน์ เพื่อแก้ปัญหาได้อย่างเต็มที่
    • คำว่า “ฉันสร้างมันขึ้นมา” เป็นแนวคิดที่ควรสงวนไว้ให้กับ การเอามือลงไปคลุกดินเหนียวที่สกปรกด้วยตัวเอง และมีความแตกต่างเฉพาะตัวจากวิธีอื่นที่ได้มาเพียงผลลัพธ์
    • making มีนัยของการลงมือทำเองอย่างกระตือรือร้นมากกว่า ส่วน producing มีนัยของการกำกับและประสานงานมากกว่า
      หลังจากเริ่มทำงานกับโปรดิวเซอร์ในการพัฒนาเกม ความแตกต่างนี้ก็ชัดเจนขึ้น
    • มันเป็นสิ่งที่ทำด้วย LLM ไม่ใช่สิ่งที่ทำเอง

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

  • ในสายเทคโนโลยีมีทั้งคนที่ชอบรายละเอียดและคนที่ชอบระบบ โดย สายเน้นระบบ จะรู้สึกว่า LLM สนุกและน่าพึงพอใจ ขณะที่สายเน้นรายละเอียดอาจรู้สึกตรงกันข้าม
    คนรู้จักที่เคยมีชื่อเสียงด้าน computer vision ยุคก่อน neural network เคยบอกว่าในอดีตเขาแก้ปัญหาเป็นคนแรก ๆ ได้มากมาย แต่ตอนนี้การพัฒนาซอฟต์แวร์ส่วนใหญ่เป็นงานประกอบสิ่งที่รู้กันอยู่แล้ว จึงน่าเบื่อ
    LLM ดูเหมือนยิ่งเร่งแนวโน้มนี้ให้เร็วขึ้น

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

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

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

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

  • ใช้ LLM เพราะมันเร็วกว่า แต่กลับไม่ได้รับความสนุกแบบเดิมอีกแล้ว
    ความเร็วไม่จำเป็นต้องสำคัญกว่าความสนุกเสมอไป และต้องเรียนรู้ที่จะกลับมาโฟกัสกับการเขียนเอง โดยไม่มองว่ามัน “ไม่มีประสิทธิภาพ”
    อยากได้ความรู้สึกตอนอายุ 13 ที่นั่งเขียนโค้ดตอนดึกกลับคืนมา และบทความของ Beej ก็น่าประทับใจเสมอ

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

  • เป็นเวลาประมาณสองเดือนที่นอกจากดื่มเหล้าแล้ว แม้แต่ทีวีก็ยังไม่อยากดู แต่พอเลิกเหล้ามาหลายสัปดาห์ ความอยากสร้างสรรค์เหมือนค่อย ๆ กลับมา
    เคยออกแบบและสร้างกล้องกับหุ่นยนต์ขับเคลื่อนอัตโนมัติขนาดเล็กด้วยตัวเอง และในที่สุดก็ซ่อมกล้องที่กลิ้งไปมาในรถจนเสียได้แล้ว
    เคยทำวิดีโอด้วยเลนส์ C-mount วินเทจแต่ละตัว ก่อนจะหมดความสนใจ เหลือแค่กล่องเลนส์กับกล้องที่กลายเป็นของประดับ แต่โปรเจกต์ฮาร์ดแวร์เหล่านี้ทำให้ได้ งานวิศวกรซอฟต์แวร์สองตำแหน่ง
    เวลาพูดว่า “ผมสร้างเอง” กับโปรเจกต์ที่ Claude Code สร้างโค้ดให้ ความเคารพมักลดลงทันที แต่ท้ายที่สุดเงินและอิสรภาพคือหัวใจสำคัญ และผมเองก็อยากได้อิสรภาพก่อนแล้วค่อยทำสิ่งที่ชอบ

    • ไม่ควรกดดันตัวเองมากเกินไป
      ถ้ายังไม่ได้ตรวจสอบ ก็น่าลองพิจารณาความเป็นไปได้ของ ADHD หรือปัจจัยอื่น ๆ ด้วย
      มนุษย์ไม่ใช่เครื่องจักร แต่เป็นสิ่งมีชีวิตทางชีววิทยาที่ซับซ้อน ดังนั้นการเข้าใจลักษณะเฉพาะของตัวเองจะช่วยได้มากในการกลับมาเดินไปในทิศทางที่ถูกต้อง

  • งานที่เพิ่งมอบให้ AI ทำเมื่อเร็ว ๆ นี้ แม้แต่รายละเอียดคร่าว ๆ ก็ยังจำได้ยาก ในขณะที่ โค้ดเบสกว่า 100,000 บรรทัด ที่เขียนไว้เมื่อหลายปีก่อน ตอนนี้ก็ยังไล่ตามในหัวได้โดยรวม

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

  • สมัยเป็นนักศึกษา OSU ตอนเรียนรู้ system programming เชิงปฏิบัติด้วยตัวเอง ใช้ Beej's Guide to Network Programming อ้างอิงทุกวัน
    เคยเสียดายว่าเว็บไซต์ฟรีนี้มีประโยชน์กว่ามหาวิทยาลัยราคาแพงมาก แต่ตอนนี้ Beej ไปสอนที่ OSU แล้ว ถือเป็นวงจรที่ยอดเยี่ยมและเป็นการจ้างงานที่ดีมาก

    • ปีหน้าจะรับผิดชอบวิชา software engineering สองวิชา โดยตั้งใจจะทิ้งเนื้อหาเดิมแทบทั้งหมดแล้วจัดใหม่
      จะเน้นการออกแบบระดับระบบ การใช้ AI อย่างจริงจัง และโปรเจกต์กับทีมที่ใหญ่ขึ้น
      การเรียนเขียนโค้ดยังคงจำเป็น แต่ ทักษะ software engineering ที่ในอดีตมักไปเรียนรู้จากงานจริง ตอนนี้ควรถูกวางไว้ในช่วงต้นของการศึกษามากขึ้น
      ก็อดคิดไม่ได้ว่าถ้า LLM มาช้ากว่านี้สัก 15 ปีก็คงดี

  • Le Corbusier และ Frank Lloyd Wright ไม่ได้ลงมือสร้างอาคารเอง แต่เป็นผู้ออกแบบ และอาคารเหล่านั้นก็ได้รับการยอมรับอย่างไม่ต้องสงสัยว่าเป็นผลงานของพวกเขา
    Steve Jobs ก็ไม่ได้ออกแบบแผงวงจรหรือเขียนโค้ดเอง แต่เขาสร้าง Mac, iPod, iPhone และจิตรกรยุคเรอเนซองส์ก็มีเวิร์กช็อปที่ลูกศิษย์เป็นผู้ลงมือทำ
    การสร้างสรรค์ซอฟต์แวร์เป็นมากกว่าการเขียนโค้ด คือการเข้าใจตลาดและความต้องการ ทำการตลาดและเขียนข้อความ ตัดสินใจว่าจะสร้างหรือทิ้งอะไร และจินตนาการรูปแบบสุดท้าย
    ช่างฝีมือที่สร้างบ้านของ Wright อาจภูมิใจได้ว่าตนทำหลังคา กำแพง หรือน้ำตก แต่บ้านทั้งหลังนั้นเป็นของ Wright อย่างชัดเจน
    เสียงคร่ำครวญในตอนนี้ดูใกล้เคียงกับ ความกลัวอย่างมีเหตุผลต่อการสูญเสียการผูกขาดทางทักษะ
    อาจเปลี่ยนไปเหมือนหลังจากเฟอร์นิเจอร์ทำมือถูก IKEA เข้ามาแทนที่ แล้วช่างไม้ฝีมือดีหันไปโฟกัสตลาดระดับไฮเอนด์ แต่ต่างกันตรงที่ลูกค้าของงานโปรแกรมมิ่งส่วนใหญ่เป็นองค์กร และเกณฑ์ผ่านคือคำถามแบบสองขั้วว่า “มันทำงานได้ไหม”