15 คะแนน โดย GN⁺ 2026-02-09 | 14 ความคิดเห็น | แชร์ทาง WhatsApp
  • หลังจากใช้เครื่องมือสร้างโค้ดบนฐาน LLMซ้ำ ๆ ก็ได้ค้นพบอีกครั้งถึงภาวะจดจ่อและความสุขที่รู้สึกเมื่อเขียนโค้ดด้วยตัวเอง
  • การเขียนโค้ดไม่ใช่แค่การผลิตงาน แต่คือกระบวนการทำความเข้าใจพื้นที่ของปัญหาและขัดเกลาความคิด ซึ่งการสร้างอัตโนมัติกลับรบกวนสิ่งนี้
  • การตรวจสอบความถูกต้องของโค้ดที่ไม่ได้เขียนเองทำได้ยาก และมีเพียงตอนเขียนเองเท่านั้นที่เราจะซึมซับบริบทได้อย่างแท้จริง
  • ใช้ LLM แบบจำกัดเพื่อป้อนบริบทด้วยตนเอง และใช้แค่แก้ไขโค้ดบางส่วนหรือสร้างเทสต์ ทำให้ยังคงรักษาการควบคุมกระบวนการคิดไว้ได้
  • เน้นให้ความสำคัญกับความลึกของความคิดและความสุขมากกว่าผลิตภาพ และย้ำว่าหากเครื่องมือรบกวนการคิด ก็ควรระวังมัน

ประสบการณ์การใช้ตัวสร้างโค้ด LLM และความรู้สึกลังเลใจ

  • เคยใช้ claude-code หลายครั้ง แต่ทุกครั้งกลับรู้สึกหดหู่และหมดแรง สุดท้ายก็ลบมันทิ้ง
    • โค้ดที่สร้างอัตโนมัติดู “เหมือนจะใช้ได้” แต่ทำให้ตัวเองสูญเสียความหมายของสิ่งที่ต้องทำ
    • ทุกครั้งที่หยุดใช้เครื่องมือ ก็ได้ความสนุกของการเขียนโค้ดกลับคืนมา
  • การเขียนโค้ดไม่ใช่แค่การลงมือทำให้เสร็จ แต่เป็นกระบวนการสำรวจพื้นที่ปัญหาและเรียนรู้ผ่านความล้มเหลว
    • หากอยากเข้าใจ API อย่างแท้จริง ก็ต้องลองใช้ด้วยตัวเอง การอ่านเอกสารอย่างเดียวไม่พอ
    • การลงมือเขียนโค้ดนั้นเองคือวิธีทำให้ความคิดเป็นรูปธรรม

ความสัมพันธ์ระหว่างการคิดกับความถูกต้อง

> "ถ้าคุณไม่เขียน แต่แค่คิดอย่างเดียว คุณก็แค่หลงคิดไปเองว่ากำลังคิดอยู่" - Leslie Lamport

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

ความเสพติดและผลข้างเคียงของ ‘Vibe coding’

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

วิธีที่เครื่องมือหล่อหลอมการคิด

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

สมดุลระหว่างความสุขกับผลิตภาพ

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

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

 
nimgnos 2026-02-09

ก็เหมือนกับที่แม้จะมีเครื่องคิดเลขอยู่แล้ว แต่ก็ยังมีคนที่ชอบคำนวณด้วยมือหรือคิดเลขในใจอยู่ดี

 
su79eu7k 2026-02-09

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

 
naruchingu 2026-02-10

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

 
wkdehf555 2026-02-09

ฟังดูเหมือนเป็นการบอกว่าจะเผชิญหน้าตรง ๆ กับทิศทางที่บริษัทต่าง ๆ กำลังมุ่งไปเสียมากกว่า..

 
dolsangodkimchi 2026-02-09

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

 
foriequal0 2026-02-09

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

 
geeksk553 2026-02-09

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

ไม่ได้หมายถึงผมหรอกนะ (อย่างเช่น Linus Torvalds หรือ Robert Martin)

 
dieafterwork 2026-02-10

ผมใช้มันแค่กับสคริปต์ Python เท่านั้น จะบอกว่าสนุกก็คงไม่ค่อยใช่นัก

 
cocofather 2026-02-10

ลองไปหาอ่านบทความเกี่ยวกับ Linus Torvalds แล้ว เหมือนว่าเขาใช้มันเป็นงานอดิเรก และยังไม่ได้ใช้กับการพัฒนา Linux ครับ

 
GN⁺ 2026-02-09
ความคิดเห็นจาก Hacker News
  • เปรียบการเขียนโค้ดกับงานไม้ แม้เครื่องจักรจะทำเฟอร์นิเจอร์ได้ แต่ก็ยังมีคนที่ทำด้วยมืออยู่ การเขียนโค้ดด้วยมือ ก็อาจยังทำเพื่อความสนุกได้ แต่ต่อไปในเชิงอาชีพคงยากขึ้น

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

    • มุมมองที่ว่า “ความเข้าใจอย่างลึกซึ้งช่วยเพิ่มความเร็วในระยะยาว” น่าประทับใจ
    • ฉันก็ทำงานแบบเดียวกัน และแนะนำทีมว่าควร optimize เพื่อ อีก 2 ปีข้างหน้า ไม่ใช่แค่ 6 เดือน
    • ทำเองเฉพาะส่วนที่มีการเรียนรู้ ที่เหลือก็พยายามทำให้เป็นอัตโนมัติมากที่สุด
    • พอใช้หลายเอเจนต์จะมี การสลับบริบท บ่อยขึ้น และกลับรู้สึกว่าสูญเสียภาพรวมของบริบททั้งหมดไป
  • ปัญหาของ vibecoding คือความรู้สึกว่า “มันดีจัง” อาจทำให้มองผลลัพธ์จริงผิดเพี้ยนไป

    • มันอาจให้ความรู้สึกดีกับบางคนเท่านั้น สำหรับฉัน ความสุขมาจากการเข้าใจปัญหาและโค้ดอย่างลึกซึ้ง
    • “การอ่านเอกสารแบบ vibe” นั้นดี แต่ vibe coding ทำให้โค้ดยืดยาว มี abstraction มากเกินไป เข้าใจยาก และไม่อยากเอาชื่อตัวเองไปผูกไว้ด้วย
    • ต่อให้วางแผนไว้ สุดท้ายก็มักมี หลายกรณีที่ต้องกลับไปเริ่มใหม่ตั้งแต่ต้น จนรู้สึกสูญเปล่า
    • แยกได้ยากว่าผลิตภาพเพิ่มขึ้นจริง หรือแค่รู้สึกไปเอง
    • เคยลองกับ Windows Copilot แต่ช้าและคุณภาพต่ำจน ไม่รู้สึกสนุกเลย
  • ตั้งคำถามเชิงประชดว่า “แค่มีความสุขแล้วปริมาณโค้ดจะเพิ่มขึ้น 200 เท่าหรือ?”

  • AI มีคุณค่าอย่างชัดเจน เช่น ตอนแปลง ตาราง DB ที่มี 300 คอลัมน์ เป็น Rust struct แค่ใช้พรอมต์ 15 คำก็สร้างโค้ด 900 บรรทัดได้ งานซ้ำๆ แบบนี้ AI เหมาะมาก แต่ก็ไม่ได้อยากโยนทุกอย่างให้มัน ทำแค่ในระดับการใช้งานที่ ยังทำให้มีความสุข

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

    • ฉันรันหลายเอเจนต์พร้อมกัน ทั้งพัฒนาฟีเจอร์ แก้บั๊ก และอัปเดตเอกสาร งานยังมีอีกมาก ไม่ใช่การ doomscroll
  • สงสัยว่าช่วงนี้ การจ้างนักพัฒนา เปลี่ยนไปอย่างไรบ้าง อนุญาตให้ใช้ LLM หรือยัง หรือยังคงให้เขียนโค้ดด้วยมือตามเดิม

    • บริษัทใหญ่ยังเปลี่ยนช้าอยู่ เพราะ ปัญหาเรื่องกรรมสิทธิ์ทางกฎหมาย ทำให้ลังเลที่จะใช้โค้ดจาก AI
    • ต่อไปน่าจะต้องการทั้ง การเขียนโค้ดด้วยมือและการเขียนโค้ดด้วย AI การรับคนก็คงแค่มีด่านเพิ่มขึ้นอีกหนึ่งอย่างเหมือนที่เป็นมาตลอด
    • บริษัทขนาดกลางหยุดรับคนหรือเลือก รับเฉพาะนักพัฒนาที่ใช้ AI ส่วนบริษัทใหญ่ก็ยังคงถาม Leetcode กับ system design
    • บริษัทส่วนใหญ่ยังไม่ตระหนักถึงขอบเขตของ การโกงด้วย LLM
  • ฉันพัฒนาด้วย model-driven development (MDD) มาตั้งแต่ก่อนมี LLM แล้ว และทำได้เร็วระดับ vibecoding โมเดลข้อมูลก็คือตัวแอปพลิเคชันเอง ส่วน LLM แค่ช่วยเขียนขั้นตอนต่างๆ ให้เร็วขึ้นอีกนิด ทิศทางของโมเดลข้อมูล ยังเป็นสิ่งที่ฉันตัดสินใจอยู่

  • AI coding แบ่งได้เป็น 3 แบบ

    1. ค้นหาโค้ดที่มีอยู่แล้วบนอินเทอร์เน็ต
    2. โค้ดใหม่ทั้งหมด โดย AI เป็นแค่ตัวช่วยพิมพ์
    3. การสร้างโค้ดแบบซ้ำๆ และมี boilerplate เยอะ — นี่คือ ความล้มเหลวของเฟรมเวิร์ก
    • งานที่ AI ทำได้ดี จริงๆ อาจเป็น งานที่เราไม่ควรทำตั้งแต่แรก ความท้าทายที่แท้จริงคือการหาภาษาที่ สื่อสิ่งที่เราต้องการได้อย่างงดงาม
    • เฟรมเวิร์กพัฒนาไม่ทัน และ LLM ก็กลายเป็น เครื่องมือแบบค้อนที่มองทุกปัญหาเป็นตะปู ไปแล้ว
  • สังคมสมัยใหม่กำลังเปลี่ยนเป็น โครงสร้างที่ได้โดปามีนจากการกดปุ่ม เลยยิ่งทำให้รู้สึกว่าทุกอย่างกำลังเละเทะ

    • เป็นการเหน็บแนมความจริงที่ว่าเครื่องสล็อตได้กลายเป็น UX ขั้นสูงสุด ไปเสียแล้ว
 
redline2151 2026-02-09

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

 
cjm01115 2026-02-09

นี่มันเกินเส้นไปมากแล้ว

 
geeksk553 2026-02-09

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

 
hmmhmmhm 2026-02-09

โห พูดแรงไปนะ T_T