1. ชอบหรือไม่ชอบในรูปแบบ ("อารมณ์แบบ LinkedIn เหรอ?")

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

2. คำยืนยันจากการลงมือปฏิบัติ "ความปรารถนาอันหนักแน่น"

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

3. การวิเคราะห์รากฐานทางปรัชญาและศาสนา

• การรีแบรนด์ภูมิปัญญาเก่า: มีความเห็นว่านี่เป็นเพียงการนำแนวคิด 'เปรต (Hungry Ghosts)' ของพุทธศาสนา หรือประเด็นคลาสสิกในปรัชญาตะวันตก (เช่น Augustine) มาห่อใหม่ด้วยศัพท์ร่วมสมัยอย่าง Thin/Thick
• ความใช้ได้ของข้อสังเกต: แม้ไม่ใช่เนื้อหาใหม่ แต่หลายคนก็เห็นด้วยว่าเป็นข้อคิดที่จัดระเบียบมาได้ดีและเหมาะกับสังคมปัจจุบัน

4. ข้อจำกัดของตรรกะแบบแบ่งขั้ว

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

5. การชี้ไปที่สาเหตุเชิงโครงสร้างและสภาพแวดล้อม

• ไม่ใช่ความผิดของปัจเจก: ปัญหาพื้นฐานคือระบบรางวัลโดพามีน (System) ที่บริษัท IT ออกแบบขึ้นอย่างจงใจ
• ข้อจำกัดในโลกความจริง: มีการโต้แย้งสมมติฐานที่ว่า "พวกเราอุดมสมบูรณ์อยู่แล้ว" พร้อมสะท้อนความจริงว่าการไล่ตาม 'ความปรารถนาอันหนักแน่น' อย่างมีพื้นที่หายใจนั้นทำได้ยาก เพราะมีภัยคุกคามต่อการดำรงชีวิต เช่น ค่าที่อยู่อาศัย ค่ารักษาพยาบาล และความยากจนทางเศรษฐกิจ

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

บทความนี้น่าจะมีทั้ง Part 1 ที่กล่าวถึงเหตุผลว่าทำไมวิศวกรอาวุโสถึงลาออก และ Part 2 เรื่อง The Economic Intervention That Stops Engineer Attrition ด้วยนะครับ

https://codegood.co/writing/…

เมื่อวานก็ยังเห็นโพสต์บน Facebook บอกว่าการเคลียร์พื้นที่ทั้งเครื่อง Mac (สั่งให้ Claude ลบให้เอง) สะดวกมากอยู่เลย...

ทำให้นักบริหารมาเห็นโพสต์นี้ไม่ได้เหรอ..

เจ๋งมาก

เวลาเห็นอะไรแบบนี้ ผมจะมองแค่ความสำคัญของ system prompt ของเครื่องมือครับ ตอนนี้เวลาใช้ใน Cursor ส่วนตัวผมคิดว่า opus >= gpt 5.2 > gemini 3 ส่วนอย่าง Sonnet หรือ 5.1 อะไรพวกนั้น... สำหรับผมไม่ใช้แล้วครับ เพียงแต่.. gpt 5.2 ความต่างตามระดับ effort ค่อนข้างชัด.. แต่ effort สูงตลอดก็ไม่ได้แปลว่าจะดีกว่าเสมอไปนะครับ เพราะงั้นผมเลยใช้ opus กับ gemini เป็นหลัก บางครั้งพอเจอโจทย์ยากมาก ๆ ก็ให้ทั้ง 3 ตัวเขียนโค้ด แล้วให้ประเมินโค้ดของกันและกัน จากนั้นผมค่อยตรวจดูและนำไปใช้ครับ

ดูเหมือนว่ายังมีคนจำนวนมากที่รัน --dangerously-skip-permissions โดยไม่ได้อยู่ในสภาพแวดล้อมแซนด์บ็อกซ์นะครับ ไม่รู้ว่าไม่เข้าใจความหมายของคำว่า danger หรือเปล่า ฮือๆ

พูดไม่ผิดเลย

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

เอเจนต์ที่ใช้เครื่องมือนี่อันตรายจริง ๆ นะ แค่ฟังมันพูดอย่างเดียวพอเถอะ

จริงด้วยครับ ผมไม่ค่อยได้ใช้แอป Notepad ที่มาพร้อมกับ Windows 11 เลยไม่ทราบ ขอบคุณครับ

แค่กด F5 ในโปรแกรมจดบันทึกก็พอ

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

รู้สึกว่าเอาไปตั้งเป็นประเด็นก็ยังแปลก ๆ เลยขอเขียนไว้ในคอมเมนต์ตรงนี้ครับ

อย่างแรกเลยคือชอบมาก ๆ ครับ
ทั้งเรื่องที่มีการประทับเวลาไว้ด้วย
แล้วในฐานะคนที่เคยลบเมโมแล้วเสียใจหนักมาก สิ่งที่ชอบที่สุดคือในโปรแกรมมันลบเมโมไม่ได้

แต่สำหรับสิ่งที่ต้องทำกับแท็ก ผมว่าถ้ามีตัวอย่างการเขียนอยู่ในไกด์ด้วยก็น่าจะดีกว่านี้ครับ

ส่วนตัวค่อนข้างเสียดายมากที่สภาพแวดล้อมการทำงานเป็นเครือข่ายภายในแยกออกมา เลยใช้งานไม่ได้

พี่เบ็กครับ ผมอยากนับถือคุณเป็นรุ่นพี่ครับ

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

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

เป็นบทความที่โดนใจมากครับ

รู้สึกเห็นด้วยครับ