Linux Landlock เป็นโมดูลความปลอดภัยแบบเนทีฟของเคอร์เนลที่ช่วยให้โปรเซสที่ไม่มีสิทธิพิเศษสามารถแซนด์บ็อกซ์ตัวเองได้ แต่ไม่มีใครใช้เพราะ API นั้น... ใช้งานยาก!
ปัจจุบัน LLM รวมถึง deep research ยังไม่มีประโยชน์มากนักกับการแก้ปัญหาระดับสูง (เช่น การพัฒนาอัลกอริทึมระดับงานวิจัย)
การเขียนโค้ดที่ต้องเข้าใจการปรับแต่งประสิทธิภาพขั้นสุด การทำงานของระบบที่หลากหลาย และประเด็นทางเทคนิคต่าง ๆ ก็ยังต้องอาศัยฝีมือมนุษย์เช่นกัน นักพัฒนาไม่ใช่แค่โปรแกรมเมอร์ธรรมดา แต่เป็นผู้แก้ปัญหา สักวันหนึ่งการแก้ปัญหาแบบ end to end อาจทำได้ แต่ตอนนี้มันช่วยประหยัดเวลาที่ต้องใช้กับการพิมพ์และการเขียนโปรแกรมง่าย ๆ ทำให้เอาเวลาไปทุ่มกับวิธีเข้าหาปัญหาที่ยากกว่าได้มากขึ้น ดังนั้นในแง่ประสิทธิภาพการทำงาน ผมมองว่าเป็นเรื่องบวก
ในฐานะ Tech Lead ผมทำงานลักษณะนี้ค่อนข้างบ่อยอยู่เหมือนกัน การพยายามวัดเชิงปริมาณโดยอิงจาก story point ก็คล้ายกัน แต่โชคดีที่บริษัทยังไม่ใหญ่ ทำให้ทั้งผู้บริหารและสมาชิกในทีมรับรู้ว่าผมมีบทบาทอะไรอยู่ ดังนั้นตอนนี้ก็ดูเหมือนว่ายังไม่เกิดปัญหาอะไร
ถ้าองค์กรใหญ่ขึ้น ก็คงต้องลองคิดเรื่องวิธีการวัดเชิงปริมาณด้วยเหมือนกัน
มีมุมมองที่ลึกซึ้งอยู่ในนั้นเลย ขอบคุณครับ
คำว่า "ระดับปัจจุบัน" สะดุดตาผมอยู่ ไม่ใช่ว่าเรากำลังมอง LLM ด้วยกรอบแนวคิดเรื่องเวลาของมนุษย์กันอยู่หรอกหรือ?
ดูเหมือนว่าจะถูกรวมเข้าไปในมาตรฐานแล้วนะ
Linux Landlock เป็นโมดูลความปลอดภัยแบบเนทีฟของเคอร์เนลที่ช่วยให้โปรเซสที่ไม่มีสิทธิพิเศษสามารถแซนด์บ็อกซ์ตัวเองได้ แต่ไม่มีใครใช้เพราะ API นั้น... ใช้งานยาก!
เพิ่งเคยได้ยินเรื่อง Landlock เป็นครั้งแรก แต่น่าสนใจดี
สิ่งที่รู้สึกได้ระหว่างเขียนโค้ดกับ AI คือ ต่อให้ให้โค้ดกับ AI ไปแค่บางส่วน ถ้าเราแยกหน่วยงานในลักษณะตามหลักความรับผิดชอบเดียว + ความรู้สึกแบบ TDD จนมันเข้าใจบริบทได้ ก็ต้องจัดให้แม้ไม่ต้องอ่านบริบทใหญ่ทั้งหมด แต่แค่บริบทของส่วนนั้นก็เพียงพอให้จับประเด็นได้
ผมใช้ AI กับงานอดิเรกมากที่สุดในการทำเว็บเกม และก็เห็นด้วยครับ พอขนาดงานใหญ่เกินระดับหนึ่งไป จะมีช่วงที่ AI เหมือนเสียสมาธิหรือโฟกัสตกลงอย่างเห็นได้ชัด ผมเลยใช้มันในลักษณะนี้: รวมโครงสร้างทั้งต้นไม้ภายในเกมกับซอร์สโค้ดทั้งหมดเป็นไฟล์เดียวพร้อม TOC จากนั้นสร้างเธรดใหม่ อัปโหลดไฟล์นั้น แล้วทำงานต่อจากตรงนั้น และเวลาถาม ผมจะระบุชื่อโปรเจกต์ปัจจุบันให้ชัดเจนเสมอพร้อมขอให้มันตอบตามนั้น ถึงอย่างนั้นก็ยังมีบางส่วนที่ยังไม่ค่อยน่าพอใจอยู่บ้าง... แต่ผมพอใจมากกับการที่สามารถทำงานอดิเรกซึ่งเมื่อก่อนเพราะยุ่งกับชีวิตจริงจนไม่กล้าแม้แต่จะเริ่ม ให้ค่อย ๆ เสร็จสมบูรณ์ได้ในเวลาที่ค่อนข้างสั้น
โดนพาดหัวหลอกเลยนะครับ 555 เห็นด้วยครับ~~
ปัจจุบัน LLM รวมถึง deep research ยังไม่มีประโยชน์มากนักกับการแก้ปัญหาระดับสูง (เช่น การพัฒนาอัลกอริทึมระดับงานวิจัย)
การเขียนโค้ดที่ต้องเข้าใจการปรับแต่งประสิทธิภาพขั้นสุด การทำงานของระบบที่หลากหลาย และประเด็นทางเทคนิคต่าง ๆ ก็ยังต้องอาศัยฝีมือมนุษย์เช่นกัน นักพัฒนาไม่ใช่แค่โปรแกรมเมอร์ธรรมดา แต่เป็นผู้แก้ปัญหา สักวันหนึ่งการแก้ปัญหาแบบ end to end อาจทำได้ แต่ตอนนี้มันช่วยประหยัดเวลาที่ต้องใช้กับการพิมพ์และการเขียนโปรแกรมง่าย ๆ ทำให้เอาเวลาไปทุ่มกับวิธีเข้าหาปัญหาที่ยากกว่าได้มากขึ้น ดังนั้นในแง่ประสิทธิภาพการทำงาน ผมมองว่าเป็นเรื่องบวก
แพตเทิร์นที่ทำแบบคร่าวๆ ก่อน แล้วค่อยมาเก็บรายละเอียดที่เหลือทีหลังนี่ดีมากจริงๆ
ผมคิดว่าไม่ใช่แค่ปัจเจกบุคคลที่ไม่ควรกลัว แต่ในระดับองค์กรก็ควรส่งเสริมให้มีการตั้งคำถามที่ดูโง่ ๆ (?) ด้วยเช่นกัน
ในทางปฏิบัติก็มักตั้งค่าสคีมาแล้วรับมาใช้กันเยอะแบบนั้นครับ
ที่แท้ Vibe coding ไม่ใช่มีม แต่เป็นแนวทางการพัฒนาแบบใหม่
น่าจะช่วยกับการเรียนรู้ประเภทอื่นที่ใช้รูปแบบการเขียนคล้ายคัมภีร์ได้เหมือนกันนะ เช่น หนังสือของเพลโต...
ในฐานะ Tech Lead ผมทำงานลักษณะนี้ค่อนข้างบ่อยอยู่เหมือนกัน การพยายามวัดเชิงปริมาณโดยอิงจาก story point ก็คล้ายกัน แต่โชคดีที่บริษัทยังไม่ใหญ่ ทำให้ทั้งผู้บริหารและสมาชิกในทีมรับรู้ว่าผมมีบทบาทอะไรอยู่ ดังนั้นตอนนี้ก็ดูเหมือนว่ายังไม่เกิดปัญหาอะไร
ถ้าองค์กรใหญ่ขึ้น ก็คงต้องลองคิดเรื่องวิธีการวัดเชิงปริมาณด้วยเหมือนกัน
นี่ๆ... ไม่ใช่ว่าทิ้งพวกเราไว้แล้วบรรลุนิพพานไปคนเดียวหรอกใช่ไหม?
รู้สึกเหมือนเคยเห็นเรื่องนี้จากที่ไหนสักแห่ง.. ที่แท้ก็เป็นบทความปี 2023 นี่เอง
เมื่อ 2 ปีก่อนก็มีโพสต์เดียวกันนี้ขึ้นมาแล้ว https://th.news.hada.io/topic?id=10680
ตอนแรกคิดว่าน่าจะใช้ Doc As Prompt ได้ดีด้วย Mistral OCR แต่ผมก็เจอปัญหาคล้ายกันครับ ได้เบาะแสกลับไปเลย
แม้จะลองหลายอย่าง แต่ข้อจำกัดด้านความจำก็ชัดเจนอยู่แล้ว เหมาะในระดับ PoC ดี ในแง่ของการดูความเป็นไปได้/การใช้งานอย่างรวดเร็วก็ถือว่าดี
แต่ปัญหาคือยิ่งต้องการผู้มีประสบการณ์มากขึ้นไปอีก
เมื่อมองว่าเวลาส่วนใหญ่ในการเขียนโค้ดหมดไปกับการดีบักและการอ่านโค้ด ผมคิดว่านี่เป็นการพูดเกินจริงไปมาก คนที่สร้าง AI ต่างก็พูดในทำนองนี้กันหมด แต่ถ้าดูอย่างน้อยจากสถานการณ์ตอนนี้ ก็ดูเหมือนจะยังไม่เป็นแบบนั้น ถ้าไปถึงจุดที่ไม่ต้องใช้แรงคนเลยจริง ๆ จะยังจำเป็นต้องเขียนโค้ดอยู่หรือเปล่า? แค่ใส่คำอธิบาย API แล้วใช้ LLM เป็นแบ็กเอนด์ไปเลยน่าจะดีกว่า