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

นี่มันอะไรกัน...
กินข้าวก็อิ่ม

พูดอะไรที่มันก็แน่อยู่แล้ว

https://github.com/smtg-ai/claude-squad

ดูคล้ายกับโอเพนซอร์สตัวนี้เหมือนกันนะ

ความจริง
Pro & Max: แค่รันหนึ่งเซสชันก็โทเคนไม่พอแล้ว
API แบบคิดค่าบริการตามการใช้งาน: จ่ายไหวเหรอ?

https://ruby-news.kr/articles/…
สรุปจากบริการที่ผมทำขึ้นเอง เป็นสิ่งที่แปลไว้แล้วจึงคล้ายกัน แต่ของ GeekNews เรียบเรียงได้ดีกว่าและอ่านสบายกว่าครับ

น่าจะรวมออปชันไว้ด้วยนะครับ

เจ๋งมาก!

• การบีบสัปดาห์ทำงานจาก 5 วันให้เหลือ 4 วันอาจทำให้เกิดความเครียดได้ แต่
• ระบบทำงาน 4 วันต่อสัปดาห์โดยยังคงรักษาระดับรายได้ไว้

เป็นประโยคที่น่าประทับใจมากครับ~

ให้ความรู้สึกประมาณว่า 'ตัดออกไปวันหนึ่ง แล้วลองทำงานที่เดิมเคยทำแบบชิล ๆ ตลอด 5 วันให้แน่นขึ้น'

เลยคิดว่าน่าจะมีองค์กรบางประเภทที่สามารถนำไปใช้ได้ครับ ฮ่าๆ..

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

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

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

ถ้าคุณใช้ Claude Code ผมแนะนำให้ใส่คำสั่งชี้นำการให้เหตุผลที่กำหนดไว้ล่วงหน้าอย่าง think deeply หรือ ultrathink ไว้ในพรอมป์ต์ และลองเปลี่ยนเป็น plan mode ด้วย Shift+Tab แล้วค่อยทำงานดูครับ

555

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

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

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

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

คนที่บอกว่าได้ประสบการณ์ที่ดี ผมก็ไม่รู้ว่าใช้บริการอะไร และเอาไปใช้กับงานที่ซับซ้อนแค่ไหน

คงจะแก่เร็วขึ้นสินะ

ปกติเรามักเข้าใจกันว่ายิ่งเวลาผ่านไปความเร็วในการหมุนจะยิ่งช้าลง แต่นี่กลับหักมุมเลยนะครับ

ผมก็ลองย้ายจาก pip ไปใช้ uv เหมือนกัน แล้วก็รู้สึกว่าความเร็วที่เร็วมากนี่อย่างเดียวก็คุ้มพอให้ย้ายแล้วจริงๆ

คิดถึงตอนช่วงโควิดที่ทำงานวันละ 6 ชั่วโมงจัง ฮือ

ตอนที่ VisiCalc, Lotus 1-2-3 อะไรพวกนี้ออกมาแล้ว ก็ยังมีคนเคาะลูกคิดกับเครื่องคิดเลขกันอยู่... ช่องว่างของเวลาที่คนทั่วไปจะรับรู้ได้จริงมันก็มากกว่าที่คิดนะ

"ถ้ายอมสละการหายใจ 1 ชั่วโมง อัตราการรอดชีวิตจะลดลง"
"ความอิ่มจะเพิ่มขึ้นระหว่างมื้ออาหาร"

ถ้าเป็นปัญหาเล็กน้อย บางบริษัทก็มักใช้แอปยืนยันตัวตนแบบพุชอย่าง DUO (เช่น ล็อกอิน Okta/Jira, อนุมัติ pull request ฯลฯ) ดังนั้นในกรณีของ OS ที่ไม่เป็นทางการแบบนี้ ก็น่าจะมีข้อจำกัดในการติดตั้งและใช้งานอยู่บ้างนะครับ แน่นอนว่าถ้าใช้โทรศัพท์สองเครื่องก็คงแก้ได้ แต่ก็...

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

อ๋อ.. หมายถึงเก็บข้อมูลไว้ใน .env แล้วให้ .env.schema เป็นฝ่ายอ่านเข้ามาสินะ