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

สรุป

ผู้เขียน: นักพัฒนาต้องพัฒนาความสามารถของตัวเองและรักษามันไว้ แม้แต่ 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

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

เรื่องนี้เชื่อมโยงกับมาตรฐานกฎหมายแรงงานของแต่ละประเทศพอสมควร... บริษัทจำนวนมากในสหรัฐฯ ก็มักใช้วิธีเวียนกันเข้าเวร และถ้าช่วงไหนไม่สะดวกก็สลับลำดับกันไป เป็นเรื่องปกติ เพราะมันเหนื่อยพอสมควร... บางบริษัทก็มีทีมที่รับผิดชอบ on-call โดยเฉพาะ
ในยุโรป แค่เพราะลักษณะงานเปลี่ยนไป หรือเพราะเป็นการทำงานนอกเวลา ก็มักแทบจะต้องมีค่าตอบแทนแยกต่างหาก
ส่วนบ้านเรา ด้วยผลของระบบเงินเดือนแบบเหมารวม ก็เลยมักทำกันแบบพอประมาณ ทั้งที่ on-call ก็เป็นการทำงานอย่างชัดเจน แต่กลับถูกทำให้ดูเหมือนว่าเงินชดเชยสำหรับช่วงเวลาดังกล่าวเป็นสวัสดิการเสียมากกว่า

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

ฮาร์ดแวร์ของ Apple นั้นยอดเยี่ยมก็จริง แต่ซอฟต์แวร์กลับเต็มไปด้วยเจตนาที่จะล่ามผู้ใช้ไว้
ต่อให้แค่อยากให้แอปที่ตัวเองสร้างและบิลด์ขึ้นมาทำงานได้เฉพาะบนอุปกรณ์ของตัวเอง ก็ยังต้องมีค่าสมาชิกราคา 100 ดอลลาร์

ถ้าคุณเป็นนักพัฒนาที่ใช้แอปโอเพนซอร์สขนาดเล็กถึงกลางและบิลด์ใช้เอง
บนอุปกรณ์ของ Apple แค่จะ sideload ก็ต้องเจลเบรกด้วยการอาศัยช่องโหว่ แบบนั้นใช้ Android ไปเลยยังสะดวกกว่า

ของเราคือ ค่ารอเวรจ่ายครึ่งหนึ่งของค่าจ้างรายชั่วโมง, สนับสนุนค่าโทรคมนาคม, และเวลาที่ต้องเข้าไปช่วยจะคิดเป็น OT 1.5 เท่า

มีสาวก C# แฝงตัวอยู่ตรงกลางนะ

> พูดกันตรง ๆ ตอนนี้ต่อให้พัฒนา Java ก็ไม่ได้จำเป็นต้องใช้ผลิตภัณฑ์ของ JetBrains เสมอไป

ตรงส่วนนี้... ค่อนข้างเห็นด้วยได้ยากนิดหน่อยนะ ฮือ...