งั้นก็ลาก่อน error EADDRINUSE ได้เลยเหรอ?
ช่วงนี้พอพัฒนานั่นนี่ผ่านเอเจนต์แล้วต้องรันอะไรต่อมิอะไรเต็มไปหมด มันก็ชนกันเองวุ่นวายเลย 55

 

แต่ตัวโมเดลเองก็เปลี่ยนไปภายในไม่กี่เดือน
และก็ต้องปรับ agents ให้เข้ากับโมเดลด้วย...
มันไม่ใช่ว่าการเปลี่ยนแปลงของโมเดลเร็วกว่าการใช้เวลาสร้างโครงสร้าง agents ที่เหมาะสมหรอกหรือครับ
เหมือนเครื่องมือเปลี่ยนไปเสียก่อนที่คนจะคุ้นเคยกับเครื่องมือนั้นเสียอีก...

 

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

 

Gemini ก็โดนปิดแล้ว Claude ก็โดนปิดเหมือนกัน
แต่ถ้าจ่ายเงินใช้ API ก็ไม่มีปัญหาใช่ไหมล่ะ

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

 

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

 

ไม่มีผลการวัดการใช้โทเคนจริงสำหรับงานเดี่ยว และเป็นเพียงการคาดเดาว่าถ้าใช้ magpie จำนวนการลองใหม่จะลดลงได้ประมาณนี้สินะ

 

การเปรียบเทียบเวลาในการคอมไพล์ดูแปลก ๆ นะครับ ทำไมถึงเอา ms/token มาเทียบกัน?

 

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

 

ดูเหมือนว่าจะมีกรณีแบบนั้นเกิดขึ้น เพราะ x ค่อนข้างลำบากในการครอลข้อมูล เราจะลองปรับปรุงดูครับ

 

นี่น่าจะเป็นครั้งแรกที่สรุปผิดว่าไม่มีเนื้อหานะ..

 

สายงานที่ผมทำอยู่ก็ไม่ได้สุดโต่งถึงขนาดนั้นเหมือนกัน แต่ผมทำวิจัยและพัฒนาในสาย AI อยู่

นอกจากเฟรมเวิร์กที่นิยมใช้กันทั่วไปแล้ว ในทางปฏิบัติก็มีกรณีที่สภาพแวดล้อมเป้าหมายสำหรับการ deploy โมเดลแตกต่างจากสภาพแวดล้อมที่ใช้ฝึกมา

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

บางครั้งก็มีกรณีที่ต้องออกแบบโมเดลด้วยตัวเอง ซึ่งแม้จะเขียน test code โดยใช้ข้อมูลบางชุดได้ แต่ค่าต่าง ๆ สามารถเปลี่ยนไปตามความน่าจะเป็นขึ้นอยู่กับ dataset และปรากฏการณ์อย่างค่าพุ่งระเบิดในบางช่วงเวลาก็ครอบคลุมด้วย test code ได้ยาก

ผมคิดว่าน่าจะยังมีสภาพแวดล้อมอีกไม่น้อยที่ทดสอบได้ยากกว่าของผมครับ

 

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

จริง ๆ แล้วทุกวันนี้พอลองสร้างโปรเจกต์ด้วยเครื่องมือ AI coding จะพบว่า ถ้ามีแค่ README + เอกสาร API + test code ของโปรเจกต์เดิม ก็สามารถทำซ้ำฟังก์ชันหลักได้เร็วอย่างน่าทึ่ง ผมดูแลอยู่ 7 โปรเจกต์และรู้สึกได้ด้วยตัวเองว่า ยิ่งเป็นโปรเจกต์ที่มีการทดสอบดี กลับยิ่งทำซ้ำได้ง่ายอย่างน่าประหลาด

แต่มีจุดหนึ่งที่ถูกมองข้ามไปในกรณี Cloudflare vs Vercel คือ "การทำซ้ำ" กับ "การให้บริการจริง" เป็นคนละปัญหากันโดยสิ้นเชิง หากจะทำซ้ำทั้ง edge case ของ Next.js, ecosystem ของปลั๊กอิน และการพึ่งพาคอมมูนิตี้ต่าง ๆ ให้ได้ครบ แค่ test code อย่างเดียวก็ยังไม่พอ สุดท้ายแล้ว moat อาจเป็นการผสมกันของ test code + community + ความรู้ความชำนาญด้านการดำเนินงานก็เป็นได้ครับ

 

โปรเจ็กต์นี้คงไม่ถึงขั้นที่ GC จะกลายเป็นปัญหาได้ครับ ผมมองว่าในบรรดา "โปรเจ็กต์ส่วนใหญ่ในช่วงหลัง" การเลือกใช้ภาษาโปรแกรมมิงจริง ๆ แล้วหลายครั้งก็เป็นเรื่องของความชอบมากกว่าจะเป็นเพราะข้อดีหรือข้อจำกัดของภาษานั้น ๆ ถึงอย่างนั้น ถ้าถามว่าในฐานะภาษาโปรแกรมมิงเอนกประสงค์ Rust มีข้อได้เปรียบเชิงเปรียบเทียบเหนือ Go ตรงไหน ผมก็คงตอบว่าคือระดับของ abstraction ที่ Rust มอบให้ และความสามารถในการจับข้อผิดพลาดได้หลายอย่างตั้งแต่ตอนคอมไพล์ แน่นอนว่า Go เองก็มีข้อดีเหนือ Rust เช่น การเขียน asynchronous programming ได้ง่ายกว่า เวลาในการคอมไพล์ที่เร็วกว่า และไวยากรณ์ที่กระชับกว่า เป็นต้น

 

แม้จะเป็นสัญญาในระดับเดียวกัน แต่ความน่าเชื่อถือหรือภาพลักษณ์กลับให้ความรู้สึกต่างกันมากจริง ๆ
คงต้องยกเลิกการสมัครสมาชิก gpt แล้วมั้งครับ

 

ว้าว เจ๋งมากเลยครับ ดูเหมือนว่าจะเป็นเพราะ RustPython สินะครับ ขอให้ได้ผลลัพธ์ที่ดีครับ!

 

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