click 2026-02-09 | ความคิดเห็นหลัก | ใน: เอเจนต์เขียนโค้ดเข้ามาแทนที่ทุกเฟรมเวิร์กที่ผมเคยใช้ (blog.alaindichiappari.dev) นี่แหละคือวิธีพัฒนาซอฟต์แวร์แบบทำให้บำรุงรักษายากอย่างแท้จริง เป็นคนที่กำลังลงมือทำตามแนวทางรักษาตำแหน่งงานของตัวเองไปตลอดชีวิตในยุคใหม่ให้เข้ากับยุค AI hmmhmmhm 2026-02-09 | ความคิดเห็นหลัก | ใน: ฉันมีความสุขมากกว่าตอนเขียนโค้ดด้วยมือตัวเอง (abhinavomprakash.com) โห พูดแรงไปนะ T_T redline2151 2026-02-09 | ความคิดเห็นหลัก | ใน: ฉันมีความสุขมากกว่าตอนเขียนโค้ดด้วยมือตัวเอง (abhinavomprakash.com) ช่วงนี้มีแต่โพสต์แนวปลอบใจตัวเองของนักพัฒนาที่กำลังตกยุคโผล่ขึ้นมาบ่อย ๆ ยังไงก็หยุดกระแสของยุคสมัยไม่ได้อยู่ดี picopress 2026-02-09 | ความคิดเห็นหลัก | ใน: LiteBox - Library OS แบบโอเพนซอร์สที่เน้นความปลอดภัยซึ่ง Microsoft เปิดเผยสู่สาธารณะ (github.com/microsoft) ไม่ได้เจอโปรเจ็กต์ที่ดูน่าสนใจแบบนี้มาพักใหญ่แล้วนะ xguru 2026-02-09 | ความคิดเห็นหลัก | ใน: 18 การคาดการณ์เกี่ยวกับ AI และ UX ในปี 2026 (uxtigers.com) ผู้เขียนบทความนี้ เจคอบ นีลเซน เป็นผู้เชี่ยวชาญด้าน UX ที่มีประสบการณ์มา 42 ปี เขาเคยคาดการณ์ไว้ตั้งแต่ตอนที่ WWW ถูกเปิดเผยสู่สาธารณะว่า "ไฮเปอร์เท็กซ์จะกลายเป็นส่วนติดต่อผู้ใช้แห่งอนาคต" ด้วยเหตุนี้ เขาจึงเขียนหนังสือชื่อ "Hyper Text and Hypermedia" ตั้งแต่ปี 1990 แล้ว เขายังเป็นผู้ร่วมก่อตั้ง Nielsen Norman Group ซึ่งเป็นบริษัทที่ปรึกษาด้าน UX ที่เป็นที่รู้จักมากที่สุดแห่งหนึ่ง (https://www.nngroup.com/) และโดนัลด์ นอร์แมนก็คือคนที่บัญญัติคำว่า UX บทความ 10 Usability Heuristics for UI Design ก็มีชื่อเสียงมากเช่นกัน. bini59 2026-02-09 | ความคิดเห็นหลัก | ใน: เอเจนต์เขียนโค้ดเข้ามาแทนที่ทุกเฟรมเวิร์กที่ผมเคยใช้ (blog.alaindichiappari.dev) มีเฟรมเวิร์กที่จัดระเบียบมาดีและมีข้อมูลที่ AI เรียนรู้ไว้มากอยู่แล้ว แบบนี้จำเป็นต้องสร้างของใหม่ในแบบของตัวเองขึ้นมาจริง ๆ เหรอ กลับรู้สึกว่าเป็นเรื่องที่ทำให้ประสิทธิภาพการทำงานลดลงมากกว่า ผมคิดว่าไม่มีความจำเป็นต้องทิ้งสิ่งที่ช่วยลดต้นทุนในการออกแบบสถาปัตยกรรม และทำให้เราโฟกัสกับแก่นแท้ของงาน (บริการ) ได้ kimjoin2 2026-02-09 | ความคิดเห็นหลัก | ใน: เราไว้อาลัยให้กับงานฝีมือของเรา (nolanlawson.com) ผมก็คิดเหมือนกันว่า ดูจะมีการมอง "โค้ดที่เขียนด้วยมือ" แบบโรแมนติกเกินไปหน่อย แนวคิดแบบ "เขียนน้อยลงแต่ทำได้มากขึ้น" มีมาตลอดอยู่แล้ว ต่อให้ไม่ใช่ AI ก็ตาม ตอนที่ GC ปรากฏขึ้นมาก็น่าจะมีบรรยากาศคล้ายๆ กัน ถึงจะเขียนโค้ดด้วยมือเอง เราอาจรู้สึกว่าโค้ดของเราไม่มีปัญหา แต่พอเกิดปัญหาขึ้นมาก็ต้องไปแกะดูโค้ดภายในหรือไม่ก็ไล่ดูหน่วยความจำกันอยู่ดี ต่อให้เขียนพรอมป์ต์ด้วยมือเอง เราอาจรู้สึกว่าพรอมป์ต์ของเราไม่มีปัญหา แต่พอเกิดปัญหาขึ้นมา ก็คงยังต้องไปแกะดูโค้ดภายในเหมือนกัน แน่นอนว่าเรื่องพวกนี้ส่วนใหญ่ก็คงจะแก้ด้วยบริการ AI อีกที ผมก็แอบจินตนาการเหมือนกันว่า โค้ดที่เขียนด้วยมืออาจกลายเป็นศิลปะร่วมสมัยในความหมายบางอย่างก็ได้..? 555 khris 2026-02-09 | ความคิดเห็นหลัก | ใน: เอเจนต์เขียนโค้ดเข้ามาแทนที่ทุกเฟรมเวิร์กที่ผมเคยใช้ (blog.alaindichiappari.dev) อืม... แนวปฏิบัติแบบนี้น่าจะเป็นตอนที่ Cursor ให้ใช้งานได้ไม่จำกัดมากกว่านะ... กลับกัน อย่างน้อยในช่วงนี้ ทิศทางต่อจากนี้น่าจะเป็นว่าเราจะประหยัดโทเคนและช่วยเสริม AI ให้ดีได้อย่างไร? ทั้งที่สามารถลดความซ้ำซ้อนได้โดยไม่ต้องจ่ายค่าโทเคนแพง ๆ แล้วทำไมถึงจะไม่มีเหตุผลให้ใช้เฟรมเวิร์กล่ะ? xguru 2026-02-09 | ความคิดเห็นหลัก | ใน: DoNotNotify เปลี่ยนเป็นโอเพนซอร์ส (donotnotify.com) DoNotNotify – บันทึกการแจ้งเตือนบน Android และบล็อกอย่างชาญฉลาด ตอนที่โพสต์ขึ้นมาก่อนหน้านี้ มีการพูดกันว่าการที่แอปของบุคคลที่สามซึ่งไม่ได้เป็นโอเพนซอร์สสามารถเห็นข้อความทั้งหมดของฉันได้นั้นเป็นความเสี่ยง และดูเหมือนว่าพวกเขาจะนำข้อกังวลนี้ไปพิจารณาแล้วจนตัดสินใจเปิดซอร์สทั้งหมดไปเลยครับ xguru 2026-02-09 | ความคิดเห็นหลัก | ใน: Vouch - ระบบจัดการความน่าเชื่อถือของผู้มีส่วนร่วมโอเพนซอร์ส (github.com/mitchellh) ดูเหมือนว่าพอได้รับความสนใจก็มีความเข้าใจผิดอยู่บ้าง เลยแยก FAQ ไว้ต่างหาก https://x.com/mitchellh/status/2020628046009831542 ผู้เริ่มต้นและผู้เข้าร่วมใหม่เข้าร่วมได้ยาก ไม่มีเหตุผลอะไรเลยที่การได้รับ Vouch จะต้องยาก จุดประสงค์หลักของ Vouch คือป้องกันการเข้ามามีส่วนร่วมแบบไม่คิดหน้าคิดหลังโดยไม่ลงแรง ในโปรเจ็กต์ของผม (รวมถึงโปรเจ็กต์นี้) ถ้าแนะนำตัวในอิสซูและอธิบายสั้น ๆ ว่าอยากมีส่วนร่วมอย่างไร ก็สามารถได้รับ Vouch ได้ พูดง่าย ๆ คือ ถ้าแนะนำตัวเหมือนการใช้ชีวิตในสังคมทั่วไป ก็จะได้รับ Vouch แต่ถ้าใช้อำนาจในกลุ่มในทางที่ผิด ก็จะถูกลงโทษ เปราะบางต่อ social engineering ผู้ใช้ที่ได้รับ Vouch จะได้เพียงสิทธิ์ในการเข้าร่วมโปรเจ็กต์เท่านั้น จะไม่ได้สิทธิ์ในการ merge pull request, push โค้ด, ทำ release เป็นต้น งานทั้งหมดเหล่านี้ยังถูกจำกัดผ่านการรีวิวที่มีอยู่เดิมและการควบคุมของระบบ นอกจากนี้ มีเพียงผู้ดูแลระบบ/ผู้ร่วมงานเท่านั้นที่สามารถรับรองผู้ใช้ได้ ดังนั้นต่อให้ผู้ใช้ที่มีปัญหาได้รับการรับรอง ก็จะไม่สามารถรับรองผู้ใช้อื่นต่อได้ ไม่มีขั้นตอนอุทธรณ์สำหรับ Denouncing ขั้นตอนอุทธรณ์แตกต่างกันไปตามโปรเจ็กต์ย่อย สำหรับโปรเจ็กต์ของผม หากติดต่อมาหาเราด้วยวิธีใดก็ได้ เช่น Discord หรืออีเมล แล้วคุยกันแบบคนปกติและยอมรับความผิดพลาด เราก็จะให้โอกาสอีกครั้ง ไม่ได้ยากอะไร แก่นของโปรเจ็กต์นี้คือการที่ AI ให้ข้อมูลแก่ผู้คนผ่านการเรียกใช้ API เพื่อลดกำแพงตามธรรมชาติที่มีอยู่เดิมให้เหลือน้อยที่สุด ในโปรเจ็กต์ชุมชนที่มีมนุษย์เป็นศูนย์กลาง จำเป็นต้องมีปฏิสัมพันธ์แบบมนุษย์เฉพาะที่แนวขอบเขตเท่านั้น princox 2026-02-09 | ความคิดเห็นหลัก | ใน: ใช้ Opus 4.6 จาก Anthropic ให้คุ้มค่าสูงสุด (claude.com) แปลได้ไม่ดีนัก... ต่อไปจะพยายามแชร์ให้อ่านง่ายกว่านี้ครับ.. ขอบคุณสำหรับคอมเมนต์ครับ princox 2026-02-09 | ความคิดเห็นหลัก | ใน: เราไว้อาลัยให้กับงานฝีมือของเรา (nolanlawson.com) ผมกลับรู้สึกมีความสุขเสียอีกที่มีเรื่องให้ต้องเรียนรู้เพิ่มขึ้นอย่างมหาศาล แม้แต่สิ่งที่ผมเขียนได้ยาก ผมก็ยังเขียนมันออกมาแล้วตั้งใจศึกษาอย่างเต็มที่อยู่เลย ตั้งแต่แรกผมก็คิดว่าบริษัทขนาดใหญ่หรือโปรเจ็กต์ที่สำคัญมากจริง ๆ นั้น มนุษย์ต้องเป็นคนตรวจดูทั้งหมดอยู่แล้ว ดังนั้นในมุมของคนที่กำลังเรียนรู้ มันเลยสนุกได้ถึงขนาดนี้ kimjoin2 2026-02-09 | ความคิดเห็นหลัก | ใน: เปิดตัว Claude Opus 4.6 Fast Mode เร็วขึ้น 2.5 เท่า แต่แพงขึ้น 6 เท่า (x.com/claudeai) "งานถัดไปควรเป็นอะไรดี?" ดูเหมือนว่าจะมีการคิดเงินเพิ่มครั้งละ $3.46 และน่าจะไม่ครอบคลุมด้วยโมเดลแบบสมัครสมาชิกนะครับ เมื่อไม่นานมานี้ที่ให้ $50 มาก็เหมือนจะให้มาเพื่อให้ลองใช้อันนี้ดูเหมือนกัน 555 crawler 2026-02-09 | ความคิดเห็นหลัก | ใน: เหตุผลที่ฉันเข้าร่วม OpenAI (brendangregg.com) ต่อให้คุณจะบอกว่าบริษัทที่กักตุนหน่วยความจำไว้ถึง 40% ของทั้งโลกกำลังคำนึงถึงประโยชน์สาธารณะของโลกก็ตาม... ehdgns104 2026-02-09 | ความคิดเห็นหลัก | ใน: เราไว้อาลัยให้กับงานฝีมือของเรา (nolanlawson.com) ถ้าพายุแม่เหล็กไฟฟ้าถล่มสักทีแล้วโลกถูกรีเซ็ต ยุคทองก็จะมาถึง jyk2367 2026-02-09 | ความคิดเห็นหลัก | ใน: ผู้สร้าง MoltBot: “ผมปล่อยโค้ดที่ยังไม่ได้อ่าน” (newsletter.pragmaticengineer.com) ผมว่าการเปรียบเทียบกับฟังก์ชัน Excel กับเครื่องคิดเลขมันไม่ค่อยถูกนะ ถ้า LLM มีความแม่นยำ 100% ก็ยอมรับครับ.. parkindani 2026-02-09 | ความคิดเห็นหลัก | ใน: เราไว้อาลัยให้กับงานฝีมือของเรา (nolanlawson.com) มีความเห็นในแง่ลบเยอะจนน่าแปลกใจเลยนะ mammal 2026-02-09 | ความคิดเห็นหลัก | ใน: เหตุผลที่ฉันเข้าร่วม OpenAI (brendangregg.com) นี่มันอะไรกันอีก... จากมุมของ OpenAI ที่ไม่มีอะไรสักอย่างตั้งแต่ชิปเซ็ตไปจนถึงดาต้าเซ็นเตอร์ที่ทำใช้เอง ถ้าซอฟต์แวร์สแต็กถูกปรับให้เหมาะสม ก็จะเอาส่วนเผื่อที่ได้ไปสเกลอัปต่อ ดังนั้นเป้าหมายจึงเป็นการทำกำไรให้สูงสุดมากกว่าการรักษาสิ่งแวดล้อม (เหมือนความเห็นใน HN เรื่อง Jevons paradox) เป็นโพสต์แนว PR ตัวเองเกินไปจนอ่านแล้วชวนกระอักกระอ่วน euphcat 2026-02-09 | ความคิดเห็นหลัก | ใน: เราไว้อาลัยให้กับงานฝีมือของเรา (nolanlawson.com) ผมเป็นนักพัฒนาควบคุมฮาร์ดแวร์ที่อยู่สูงกว่างาน embedded ขึ้นมาสองสามขั้น โดยเน้น Python เป็นหลัก จนถึงเมื่อไม่กี่สัปดาห์ก่อน ผมยังรู้สึกภูมิใจอยู่ลึก ๆ ที่ตัวเองต่อต้าน vibe coding และเวลาตั้งค่า debugging session ได้ลำบาก อย่างมากที่สุดที่ยอมใช้ LLM ก็คือเอาโค้ดที่เขียนยาว ๆ ไปแปะให้ GPT แล้วบอกว่า "ช่วยจับทีว่าผมพลาดตรงไหน" พอตั้งค่า Claude แล้ว ค่อย ๆ อธิบายให้มันฟัง พร้อมกับช่วยกันเขียน CLAUDE.md ไปด้วย ใช้สักครั้งสองครั้งไปเรื่อย ๆ ก็พบว่าเมื่อไหร่ไม่รู้ ผมเริ่มพึ่งพามันจริง ๆ แล้ว ต่อให้เป็นแค่ลูปง่าย ๆ ก็ไม่ต้องคอยกังวลแล้วว่าจะพลาด break/continue หรือเปล่า ถ้าขี้เกียจจะอธิบายเป็นคำพูด ก็เขียนยาว ๆ ไปก่อนแล้วค่อยบอกว่า "ช่วยดูหน่อยว่ามีพิมพ์ผิดไหม" แค่มีโครงสร้างที่สรุปไว้ใน CLAUDE.md มันก็หาบริบทได้อย่างรวดเร็วเอง และพอจะเริ่มทำ subsystem ใหม่ขึ้นมา ก็กลับคิดว่า "อันนี้ต่างหากที่ไม่มีบริบทให้ต้องพึ่งพา งั้นให้มันเขียนไปเลยก็คงได้มั้ง?" แล้วจากนั้นก็เริ่มรู้สึกกลัวขึ้นมาจริง ๆ ทีละนิด การเขียนโค้ดแบบปล่อยสมองว่าง ๆ อย่างนี้ แล้วถ้าตอนลงหน้างานผมอ่านโค้ดนี้ที่ ~ผมเขียน~ มันเขียน ไม่รู้เรื่องขึ้นมาจะทำยังไง? นั่นยังเป็นความกังวลเบา ๆ เสียด้วยซ้ำ สิ่งที่หนักกว่าคือความกระวนกระวายว่าหรือผมจะตามกระแสที่เรียกว่า vibe coding ไม่ทันจริง ๆ แล้ว บวกกับเดิมทีผมเป็นคนที่รู้สึกสนุกกับการเปิดอ่าน manual แต่ตอนนี้ไม่ใช่แค่โอกาสที่จะได้อ่าน manual หายไปเท่านั้น ยังเหมือนกับว่าความรู้ที่สั่งสมมาผ่าน manual กำลังถูกทำให้ไร้ความหมาย จนเกิดเป็น existential fear ขึ้นมาอีก... พูดจริง ๆ เลยนะ ตอนนี้ผมกลัวมากจริง ๆ.. jongyeol 2026-02-08 | ความคิดเห็นหลัก | ใน: Show GN: mcp-baepsae – เซิร์ฟเวอร์ MCP ที่ให้ AI ควบคุม iOS Simulator ได้โดยตรง (github.com/oozoofrog) ถ้ารองรับแอป macOS ด้วย แบบนี้ก็น่าสนใจเลยนะครับ สำหรับ iOS ตอนนี้ผมใช้ https://github.com/joshuayoes/ios-simulator-mcp อยู่แล้ว ไม่ทราบว่ามีจุดต่างอะไรไหมครับ? (เช่น ทำงานได้เร็วกว่าหรือเปล่า) โหลดความคิดเห็นเพิ่มเติม
นี่แหละคือวิธีพัฒนาซอฟต์แวร์แบบทำให้บำรุงรักษายากอย่างแท้จริง เป็นคนที่กำลังลงมือทำตามแนวทางรักษาตำแหน่งงานของตัวเองไปตลอดชีวิตในยุคใหม่ให้เข้ากับยุค AI
โห พูดแรงไปนะ T_T
ช่วงนี้มีแต่โพสต์แนวปลอบใจตัวเองของนักพัฒนาที่กำลังตกยุคโผล่ขึ้นมาบ่อย ๆ ยังไงก็หยุดกระแสของยุคสมัยไม่ได้อยู่ดี
ไม่ได้เจอโปรเจ็กต์ที่ดูน่าสนใจแบบนี้มาพักใหญ่แล้วนะ
ผู้เขียนบทความนี้ เจคอบ นีลเซน เป็นผู้เชี่ยวชาญด้าน 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
แปลได้ไม่ดีนัก...
ต่อไปจะพยายามแชร์ให้อ่านง่ายกว่านี้ครับ..
ขอบคุณสำหรับคอมเมนต์ครับ
ผมกลับรู้สึกมีความสุขเสียอีกที่มีเรื่องให้ต้องเรียนรู้เพิ่มขึ้นอย่างมหาศาล
แม้แต่สิ่งที่ผมเขียนได้ยาก ผมก็ยังเขียนมันออกมาแล้วตั้งใจศึกษาอย่างเต็มที่อยู่เลย
ตั้งแต่แรกผมก็คิดว่าบริษัทขนาดใหญ่หรือโปรเจ็กต์ที่สำคัญมากจริง ๆ นั้น มนุษย์ต้องเป็นคนตรวจดูทั้งหมดอยู่แล้ว ดังนั้นในมุมของคนที่กำลังเรียนรู้ มันเลยสนุกได้ถึงขนาดนี้
"งานถัดไปควรเป็นอะไรดี?"
ดูเหมือนว่าจะมีการคิดเงินเพิ่มครั้งละ $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 อยู่แล้ว ไม่ทราบว่ามีจุดต่างอะไรไหมครับ? (เช่น ทำงานได้เร็วกว่าหรือเปล่า)