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

ดูเหมือนว่า yolo mode ถูกเปลี่ยนเป็น auto run mode แล้วครับ

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

ดูเหมือนว่าลิงก์จะทำงานได้ไม่ค่อยดี เลยลองใหม่อีกครั้งครับ https://chatgpt.com/canvas/shared/68341217ae788191b66a523c948b1a8e

สวัสดีครับ/ค่ะ ด้วยความสงสัยเลยลองพิมพ์ว่า "จะเอาไปใส่ในเว็บฟรอนต์ ช่วยเขียนอัลกอริทึม quicksort เป็น js ให้หน่อย" แต่สำหรับผม/ฉันแล้วค่อนข้างดูออกยากว่าอะไรคือปัญหา ถ้าช่วยบอกให้หน่อยจะเป็นประโยชน์มากเลยครับ/ค่ะ ขอบคุณล่วงหน้าครับ/ค่ะ https://chatgpt.com/share/68340f9b-b684-8002-8dd5-495d477065cd

เป็นโปรเจกต์ Common Lisp สินะ เพราะอย่างนั้นถึงใช้ชุด ocicl+make ได้สินะ ให้ Vibe AI จัดการอันนี้แล้วสั่งให้ทำเป็น typescript+deno ไปเลยน่าจะดูแลง่ายกว่านะ

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

สุดท้ายนี้มีเรื่องที่อยากถามคือ คุณ superscv คิดว่าควรใช้ LLM กับการเขียนโค้ดอย่างไรถึงจะดี

เกาหลีเองก็คงต้องค่อย ๆ (...) ขยายอายุเกษียณอย่างต่อเนื่องในที่สุดเพราะปัญหาเงินบำนาญ...
จุดเปลี่ยนน่าจะเป็นตอนที่ขยายไปเรื่อย ๆ จนเลยอายุขัยเฉลี่ย
(เหมือนจะเคยได้ยินว่ารัสเซียเป็นแบบนั้นไปแล้ว.. )

สรุป

ผู้เขียน: นักพัฒนาต้องพัฒนาความสามารถของตัวเองและรักษามันไว้ แม้แต่ AI เองก็ยังทำงานได้ไม่ดีนัก

crawler: หือ? แต่ของฉันใช้ได้ดีนะ?

superscv: มีปัญหาเยอะ...

crawler: ก็ต้องปรับจูนให้ดีแล้วค่อยใช้สิ

superscv: ดูเหมือนจะออกห่างจากสารที่ผู้เขียนตั้งใจจะสื่อมาตั้งแต่แรกมากเกินไปแล้ว..

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

ถ้าจะดูว่าทำไมสารของผู้เขียนถึงให้ความรู้สึกหนักแน่น ก็เพราะมันถูกสร้างขึ้นในฐานะมุมมองตอบโต้ต่อแนวคิดที่ว่า จะสามารถพัฒนาได้ด้วย copilot (มีนัยของการพึ่งพา copilot ในการพัฒนาค่อนข้างสูง) ผู้เขียนจึงเลือกเดินเกมด้วยสารในลักษณะว่า อย่ามีท่าทีที่บั่นทอนคุณค่าการมีอยู่ของนักพัฒนาเอง

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

อย่างไรก็ตาม ในข้อความที่คุณเขียนตอนแรก ผมเห็นด้วยได้ยากกับส่วนที่ว่าเป็น 'มุมมองที่มีอคติ' ก็เลยตอบกลับมาก่อนครับ

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

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

ถัดมาคือกรณีที่คนทั่วไปซึ่งไม่มีความรู้ด้านการพัฒนาใช้ LLM
ผมคิดว่าไม่ว่าจะในบทความ บน Hacker News หรือแม้แต่ตัวผมเอง ก็ไม่เคยพูดถึงกรณีนี้นะ แต่ถึงอย่างนั้น ตอนนี้มันก็พัฒนามาถึงระดับที่ผู้ใช้พอใจกับผลลัพธ์ได้แล้ว
ไม่อย่างนั้น Bolt.new, v0, จนถึง Cursor ก็คงไม่ได้รับการประเมินแบบทุกวันนี้หรอกครับ

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

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

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

ลองขอ GPT ง่าย ๆ ว่า "จะเอาไปใส่ในเว็บฟรอนต์ ช่วยเขียนอัลกอริทึม quicksort ด้วย js ให้หน่อย" ดูก็ได้ครับ ถ้าคุณมองไม่เห็นปัญหาในผลลัพธ์ที่มันให้มา ผมคิดว่าบทสนทนานี้ก็คงไม่มีความหมายมากนัก

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

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

บริษัทเป็นสถานที่สำหรับมาเรียนรู้หรือ? หรือเป็นสถานที่ที่นำวงล้อที่คนอื่นสร้างไว้แล้วมาสร้างคุณค่าใหม่?

https://th.news.hada.io/topic?id=21091
พออ่านบทความนี้แล้ว ก็รู้สึกสงสัยว่าแบบนี้มันถูกต้องจริงเหรอครับ

ข้อ 1 นี่เหมือนฝันร้ายจริง ๆ เป็นการเปลี่ยนแปลงที่ไม่อยากยอมรับเด็ดขาด มันกำลังทำให้การติดตามประวัติซอร์สโค้ดหมดความหมายไปเลย

ผมให้บอต AI ของ GN+ ดึงสคริปต์จาก YouTube ออกมาแล้วสั่งให้สรุปให้ ปรากฏว่าประสิทธิภาพค่อนข้างดีเลยครับ
ก่อนหน้านี้มีวิดีโอให้ดูเยอะเกินไปจนลำบาก แบบนี้น่าจะดีมากครับ

ก็เพราะยังไม่เคยเจอโปรเจ็กต์ Electron ที่ทำได้ดีจริง ๆ ไง ~
... เหมือนกำลังจะพูดแบบนั้นเลยนะ 555