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

 

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

 

ไม่ได้เจอโปรเจ็กต์ที่ดูน่าสนใจแบบนี้มาพักใหญ่แล้วนะ

 

ผู้เขียนบทความนี้ เจคอบ นีลเซน เป็นผู้เชี่ยวชาญด้าน UX ที่มีประสบการณ์มา 42 ปี
เขาเคยคาดการณ์ไว้ตั้งแต่ตอนที่ WWW ถูกเปิดเผยสู่สาธารณะว่า "ไฮเปอร์เท็กซ์จะกลายเป็นส่วนติดต่อผู้ใช้แห่งอนาคต"
ด้วยเหตุนี้ เขาจึงเขียนหนังสือชื่อ "Hyper Text and Hypermedia" ตั้งแต่ปี 1990 แล้ว

เขายังเป็นผู้ร่วมก่อตั้ง Nielsen Norman Group ซึ่งเป็นบริษัทที่ปรึกษาด้าน UX ที่เป็นที่รู้จักมากที่สุดแห่งหนึ่ง (https://www.nngroup.com/) และโดนัลด์ นอร์แมนก็คือคนที่บัญญัติคำว่า UX

บทความ 10 Usability Heuristics for UI Design ก็มีชื่อเสียงมากเช่นกัน.

 

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

 

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

แนวคิดแบบ "เขียนน้อยลงแต่ทำได้มากขึ้น" มีมาตลอดอยู่แล้ว
ต่อให้ไม่ใช่ AI ก็ตาม ตอนที่ GC ปรากฏขึ้นมาก็น่าจะมีบรรยากาศคล้ายๆ กัน

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

ผมก็แอบจินตนาการเหมือนกันว่า โค้ดที่เขียนด้วยมืออาจกลายเป็นศิลปะร่วมสมัยในความหมายบางอย่างก็ได้..? 555

 

อืม... แนวปฏิบัติแบบนี้น่าจะเป็นตอนที่ Cursor ให้ใช้งานได้ไม่จำกัดมากกว่านะ... กลับกัน อย่างน้อยในช่วงนี้ ทิศทางต่อจากนี้น่าจะเป็นว่าเราจะประหยัดโทเคนและช่วยเสริม AI ให้ดีได้อย่างไร?

ทั้งที่สามารถลดความซ้ำซ้อนได้โดยไม่ต้องจ่ายค่าโทเคนแพง ๆ แล้วทำไมถึงจะไม่มีเหตุผลให้ใช้เฟรมเวิร์กล่ะ?

 

DoNotNotify – บันทึกการแจ้งเตือนบน Android และบล็อกอย่างชาญฉลาด

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

 

ดูเหมือนว่าพอได้รับความสนใจก็มีความเข้าใจผิดอยู่บ้าง เลยแยก FAQ ไว้ต่างหาก
https://x.com/mitchellh/status/2020628046009831542

  • ผู้เริ่มต้นและผู้เข้าร่วมใหม่เข้าร่วมได้ยาก
    • ไม่มีเหตุผลอะไรเลยที่การได้รับ Vouch จะต้องยาก
    • จุดประสงค์หลักของ Vouch คือป้องกันการเข้ามามีส่วนร่วมแบบไม่คิดหน้าคิดหลังโดยไม่ลงแรง
    • ในโปรเจ็กต์ของผม (รวมถึงโปรเจ็กต์นี้) ถ้าแนะนำตัวในอิสซูและอธิบายสั้น ๆ ว่าอยากมีส่วนร่วมอย่างไร ก็สามารถได้รับ Vouch ได้
    • พูดง่าย ๆ คือ ถ้าแนะนำตัวเหมือนการใช้ชีวิตในสังคมทั่วไป ก็จะได้รับ Vouch
    • แต่ถ้าใช้อำนาจในกลุ่มในทางที่ผิด ก็จะถูกลงโทษ
  • เปราะบางต่อ social engineering
    • ผู้ใช้ที่ได้รับ Vouch จะได้เพียงสิทธิ์ในการเข้าร่วมโปรเจ็กต์เท่านั้น
    • จะไม่ได้สิทธิ์ในการ merge pull request, push โค้ด, ทำ release เป็นต้น
    • งานทั้งหมดเหล่านี้ยังถูกจำกัดผ่านการรีวิวที่มีอยู่เดิมและการควบคุมของระบบ
    • นอกจากนี้ มีเพียงผู้ดูแลระบบ/ผู้ร่วมงานเท่านั้นที่สามารถรับรองผู้ใช้ได้
    • ดังนั้นต่อให้ผู้ใช้ที่มีปัญหาได้รับการรับรอง ก็จะไม่สามารถรับรองผู้ใช้อื่นต่อได้
  • ไม่มีขั้นตอนอุทธรณ์สำหรับ Denouncing
    • ขั้นตอนอุทธรณ์แตกต่างกันไปตามโปรเจ็กต์ย่อย
    • สำหรับโปรเจ็กต์ของผม หากติดต่อมาหาเราด้วยวิธีใดก็ได้ เช่น Discord หรืออีเมล แล้วคุยกันแบบคนปกติและยอมรับความผิดพลาด เราก็จะให้โอกาสอีกครั้ง ไม่ได้ยากอะไร
  • แก่นของโปรเจ็กต์นี้คือการที่ AI ให้ข้อมูลแก่ผู้คนผ่านการเรียกใช้ API เพื่อลดกำแพงตามธรรมชาติที่มีอยู่เดิมให้เหลือน้อยที่สุด
  • ในโปรเจ็กต์ชุมชนที่มีมนุษย์เป็นศูนย์กลาง จำเป็นต้องมีปฏิสัมพันธ์แบบมนุษย์เฉพาะที่แนวขอบเขตเท่านั้น
 

แปลได้ไม่ดีนัก...
ต่อไปจะพยายามแชร์ให้อ่านง่ายกว่านี้ครับ..
ขอบคุณสำหรับคอมเมนต์ครับ

 

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

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

 

"งานถัดไปควรเป็นอะไรดี?"
ดูเหมือนว่าจะมีการคิดเงินเพิ่มครั้งละ $3.46 และน่าจะไม่ครอบคลุมด้วยโมเดลแบบสมัครสมาชิกนะครับ
เมื่อไม่นานมานี้ที่ให้ $50 มาก็เหมือนจะให้มาเพื่อให้ลองใช้อันนี้ดูเหมือนกัน 555

 

ต่อให้คุณจะบอกว่าบริษัทที่กักตุนหน่วยความจำไว้ถึง 40% ของทั้งโลกกำลังคำนึงถึงประโยชน์สาธารณะของโลกก็ตาม...

 

ถ้าพายุแม่เหล็กไฟฟ้าถล่มสักทีแล้วโลกถูกรีเซ็ต ยุคทองก็จะมาถึง

 

ผมว่าการเปรียบเทียบกับฟังก์ชัน Excel กับเครื่องคิดเลขมันไม่ค่อยถูกนะ
ถ้า LLM มีความแม่นยำ 100% ก็ยอมรับครับ..

 

มีความเห็นในแง่ลบเยอะจนน่าแปลกใจเลยนะ

 

นี่มันอะไรกันอีก... จากมุมของ OpenAI ที่ไม่มีอะไรสักอย่างตั้งแต่ชิปเซ็ตไปจนถึงดาต้าเซ็นเตอร์ที่ทำใช้เอง ถ้าซอฟต์แวร์สแต็กถูกปรับให้เหมาะสม ก็จะเอาส่วนเผื่อที่ได้ไปสเกลอัปต่อ ดังนั้นเป้าหมายจึงเป็นการทำกำไรให้สูงสุดมากกว่าการรักษาสิ่งแวดล้อม (เหมือนความเห็นใน HN เรื่อง Jevons paradox)

เป็นโพสต์แนว PR ตัวเองเกินไปจนอ่านแล้วชวนกระอักกระอ่วน

 

ผมเป็นนักพัฒนาควบคุมฮาร์ดแวร์ที่อยู่สูงกว่างาน embedded ขึ้นมาสองสามขั้น โดยเน้น Python เป็นหลัก จนถึงเมื่อไม่กี่สัปดาห์ก่อน ผมยังรู้สึกภูมิใจอยู่ลึก ๆ ที่ตัวเองต่อต้าน vibe coding และเวลาตั้งค่า debugging session ได้ลำบาก อย่างมากที่สุดที่ยอมใช้ LLM ก็คือเอาโค้ดที่เขียนยาว ๆ ไปแปะให้ GPT แล้วบอกว่า "ช่วยจับทีว่าผมพลาดตรงไหน"

พอตั้งค่า Claude แล้ว ค่อย ๆ อธิบายให้มันฟัง พร้อมกับช่วยกันเขียน CLAUDE.md ไปด้วย ใช้สักครั้งสองครั้งไปเรื่อย ๆ ก็พบว่าเมื่อไหร่ไม่รู้ ผมเริ่มพึ่งพามันจริง ๆ แล้ว

ต่อให้เป็นแค่ลูปง่าย ๆ ก็ไม่ต้องคอยกังวลแล้วว่าจะพลาด break/continue หรือเปล่า ถ้าขี้เกียจจะอธิบายเป็นคำพูด ก็เขียนยาว ๆ ไปก่อนแล้วค่อยบอกว่า "ช่วยดูหน่อยว่ามีพิมพ์ผิดไหม" แค่มีโครงสร้างที่สรุปไว้ใน CLAUDE.md มันก็หาบริบทได้อย่างรวดเร็วเอง และพอจะเริ่มทำ subsystem ใหม่ขึ้นมา ก็กลับคิดว่า "อันนี้ต่างหากที่ไม่มีบริบทให้ต้องพึ่งพา งั้นให้มันเขียนไปเลยก็คงได้มั้ง?"

แล้วจากนั้นก็เริ่มรู้สึกกลัวขึ้นมาจริง ๆ ทีละนิด การเขียนโค้ดแบบปล่อยสมองว่าง ๆ อย่างนี้ แล้วถ้าตอนลงหน้างานผมอ่านโค้ดนี้ที่ ~ผมเขียน~ มันเขียน ไม่รู้เรื่องขึ้นมาจะทำยังไง? นั่นยังเป็นความกังวลเบา ๆ เสียด้วยซ้ำ สิ่งที่หนักกว่าคือความกระวนกระวายว่าหรือผมจะตามกระแสที่เรียกว่า vibe coding ไม่ทันจริง ๆ แล้ว บวกกับเดิมทีผมเป็นคนที่รู้สึกสนุกกับการเปิดอ่าน manual แต่ตอนนี้ไม่ใช่แค่โอกาสที่จะได้อ่าน manual หายไปเท่านั้น ยังเหมือนกับว่าความรู้ที่สั่งสมมาผ่าน manual กำลังถูกทำให้ไร้ความหมาย จนเกิดเป็น existential fear ขึ้นมาอีก...

พูดจริง ๆ เลยนะ ตอนนี้ผมกลัวมากจริง ๆ..

 

ถ้ารองรับแอป macOS ด้วย แบบนี้ก็น่าสนใจเลยนะครับ

สำหรับ iOS ตอนนี้ผมใช้ https://github.com/joshuayoes/ios-simulator-mcp อยู่แล้ว ไม่ทราบว่ามีจุดต่างอะไรไหมครับ? (เช่น ทำงานได้เร็วกว่าหรือเปล่า)