Cloudflare สร้าง OAuth ร่วมกับ Claude และเปิดเผยพรอมต์ทั้งหมด

 (github.com/cloudflare)
16 คะแนน โดย GN⁺ 2025-06-03 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Cloudflare เปิดตัว เฟรมเวิร์กผู้ให้บริการ OAuth 2.1 ในรูปแบบไลบรารี TypeScript สำหรับ Cloudflare Workers
  • การพัฒนาส่วนใหญ่ เขียนโดยใช้ Claude LLM ของ Anthropic และได้รับการตรวจทานอย่างละเอียดโดยวิศวกรความปลอดภัยของ Cloudflare
  • ไลบรารีนี้มอบ การทำให้การยืนยันตัวตนสำหรับ API endpoint เป็นอัตโนมัติ และ การจัดการโทเค็นแบบอัตโนมัติ
  • รองรับฟีเจอร์หลักอย่าง มาตรฐาน OAuth ล่าสุดและ PKCE, การลงทะเบียนไคลเอนต์แบบไดนามิก, การกำหนด scope การเข้าถึง และอื่น ๆ
  • เน้น การออกแบบด้านความปลอดภัย เช่น การเข้ารหัสแบบ end-to-end ในจุดสำคัญและ refresh token แบบใช้ครั้งเดียว

บทนำและความสำคัญของเฟรมเวิร์กผู้ให้บริการ OAuth 2.1 สำหรับ Cloudflare Workers

โปรเจกต์โอเพนซอร์สนี้เป็นไลบรารี TypeScript ที่ออกแบบมาเพื่อให้สามารถ สร้างเซิร์ฟเวอร์ยืนยันตัวตน OAuth 2.1 ได้ง่ายในสภาพแวดล้อม Cloudflare Workers
เมื่อเทียบกับโปรเจกต์ประเภทเดียวกัน จุดแข็งอยู่ที่ ความสามารถในการขยายตัวและการผสานรวมอย่างลื่นไหล ที่ออกแบบมาเฉพาะสำหรับแพลตฟอร์ม Cloudflare รวมถึง การออกแบบที่ยึดความปลอดภัยเป็นศูนย์กลาง
ให้ความสำคัญกับอัลกอริทึม การปฏิบัติตามมาตรฐานโปรโตคอล (RFC-8414, RFC-7591 ฯลฯ) และความชัดเจนของโครงสร้างไลบรารี
โดยเฉพาะอย่างยิ่ง มีการออกแบบรายละเอียดด้านความปลอดภัย เช่น การเก็บโทเค็นและค่า secret สำคัญในรูปแบบแฮช และการเข้ารหัส props แบบ end-to-end
นอกจากนี้ยังน่าสนใจตรงที่โค้ดแกนหลักและเอกสารส่วนใหญ่ของไลบรารีถูกจัดทำขึ้นโดยอาศัยความร่วมมือกับ Claude LLM

ฟีเจอร์หลักและข้อดี

  • ครอบโค้ด Worker ด้วย OAuthProvider เพื่อ เพิ่มความสามารถยืนยันตัวตนให้กับ API endpoint โดยอัตโนมัติ
  • การจัดการโทเค็น (การสร้าง การเก็บ การตรวจสอบ การเพิกถอน ฯลฯ) ทำให้อัตโนมัติ จึงไม่ต้องพัฒนาเองโดยตรง
  • ผู้ใช้สามารถรับ ข้อมูลผู้ใช้ที่ผ่านการยืนยันตัวตนแล้ว เป็นพารามิเตอร์ภายใน fetch handler และนำไปใช้ได้ทันที
  • ไม่จำกัดวิธีจัดการผู้ใช้ การยืนยันตัวตน หรือการทำ UI (นักพัฒนาสามารถเลือกโครงสร้างและเฟรมเวิร์กได้อย่างอิสระ)
  • ในสตอเรจของไลบรารีจะเก็บ เฉพาะข้อมูลแฮชเท่านั้น และไม่เก็บตัว secret เช่นคีย์ลับโดยตรง

แก่นของวิธีใช้งาน

  • สามารถ export อินสแตนซ์ OAuthProvider เป็น entrypoint ของ Worker เพื่อทำหน้าที่เป็น fetch handler ได้
  • ใช้ตัวเลือก apiRoute และ apiHandler เพื่อกำหนดช่วงของ API endpoint ที่ต้องการการยืนยันตัวตน และ handler จริงตามลำดับ
  • สามารถกำหนดพาธของ OAuth endpoint มาตรฐานต่าง ๆ เช่น authorizeEndpoint, tokenEndpoint, clientRegistrationEndpoint
  • หากจำเป็น สามารถแยกละเอียดนโยบาย เช่น scope หรือ public client registration ได้
  • ผ่าน defaultHandler จึงจัดการคำขอนอกเหนือจาก API และคำขอที่ยืนยันตัวตนไม่สำเร็จได้อย่างยืดหยุ่น

อ็อบเจ็กต์ตัวช่วยและ API

  • สามารถใช้ env.OAUTH_PROVIDER ใน fetch handler เพื่อจัดการงานอย่างการแยกวิเคราะห์คำขอที่เกี่ยวข้องกับ OAuth การดูข้อมูลไคลเอนต์ และการทำอนุมัติให้เสร็จสมบูรณ์
  • ในการประมวลผลคำขอ API หาก access token ใช้งานได้ จะเข้าถึง ข้อมูล props รายผู้ใช้ในสถานะที่ได้รับสิทธิ์แล้ว ได้ทันทีผ่าน ctx.props
  • ยังมี API ทางการสำหรับการลงทะเบียนไคลเอนต์ รายการ authorization grant รวมถึงการดูและเพิกถอน grant ของผู้ใช้เฉพาะราย

Token Exchange Callback

  • รองรับ callback (tokenExchangeCallback) ที่สามารถ อัปเดตค่า props แบบไดนามิก ระหว่างการออกหรือรีเฟรชโทเค็น
  • รองรับสถานการณ์ซับซ้อน เช่น การแลกเปลี่ยนโทเค็นเพิ่มเติมที่เชื่อมกับ OAuth client (upstream token exchange)
  • ใน callback สามารถคืนค่า accessTokenProps, newProps, accessTokenTTL เป็นต้น เพื่อกำหนดพฤติกรรมแบบกำหนดเอง
  • ผ่านการปรับแต่ง accessTokenTTL สามารถทำให้เวลาหมดอายุของโทเค็นสอดคล้องกับระบบ OAuth ต้นทางได้
  • เนื่องจาก props อาจมีข้อมูลอ่อนไหว จึงมีการเก็บค่าทั้งหมดนี้ด้วยการเข้ารหัสแบบ end-to-end

การตอบกลับข้อผิดพลาดแบบกำหนดเอง

  • ใช้ตัวเลือก onError เพื่อดำเนินการภายนอกเมื่อเกิดข้อผิดพลาดได้ เช่น ส่ง Notification หรือทำ custom logging
  • หากกำหนด Response ที่จะส่งกลับเอง ก็สามารถ override รูปแบบข้อความผิดพลาดที่ OAuthProvider ส่งให้ผู้ใช้ได้ตามต้องการ

รายละเอียดการออกแบบด้านความปลอดภัย

การเข้ารหัสแบบ end-to-end

  • ข้อมูลที่เกี่ยวกับโทเค็นและ secret จะถูกเก็บเป็นแฮชเท่านั้น และ ข้อมูล grant props จะถูกเข้ารหัสและเก็บด้วยตัวโทเค็นเอง เพื่อเพิ่มความสามารถในการรับมือกรณีข้อมูลรั่วไหล
  • ค่าอย่าง userId และ metadata จะไม่ถูกเข้ารหัสเพื่อใช้สำหรับการตรวจสอบย้อนหลัง (audit) และการเพิกถอน โดยนักพัฒนาสามารถเพิ่มการเข้ารหัสเองได้หากต้องการ

การออกแบบ refresh token แบบใช้ครั้งเดียว

  • ตามข้อกำหนดของ OAuth 2.1 ที่ระบุเงื่อนไขว่า “ผูกกับไคลเอนต์หรือใช้ครั้งเดียว” ไลบรารีนี้เลือกใช้แนวทางประนีประนอมคือ อนุญาต refresh token แบบขนานได้สูงสุด 2 ตัว
  • แนวทางนี้ช่วยเป็นกลไกป้องกันในกรณีที่การบันทึกโทเค็นใหม่ล้มเหลวจากปัญหาเครือข่าย ทำให้ยังสามารถใช้โทเค็นเดิมได้อีกหนึ่งครั้ง

กระบวนการพัฒนาด้วย Claude

  • ไลบรารีนี้และเอกสารจำนวนมากมีการสร้างร่างขึ้นโดยใช้ Anthropic Claude LLM และได้รับการรีวิวอย่างละเอียดโดยวิศวกรของ Cloudflare ให้สอดคล้องกับ RFC และมาตรฐานความปลอดภัย
  • ในช่วงแรกมีความกังขาต่อการสร้างโค้ดด้วย AI แต่จากประสบการณ์จริงด้านคุณภาพและประสิทธิภาพการทำงานที่ดีขึ้น มุมมองดังกล่าวได้เปลี่ยนไป
  • กระบวนการพัฒนา พรอมต์ของ Claude และขั้นตอนการปรับปรุงโค้ดทั้งหมดถูกเปิดเผยอย่างโปร่งใสผ่านประวัติ Git commit

อื่น ๆ

  • ต้องผูก Workers KV namespace (OAUTH_KV) และอ้างอิง storage-schema.md
  • API และ helper ทั้งหมดอ้างอิงได้จากคำจำกัดความของอินเทอร์เฟซ OAuthHelpers
  • ปัจจุบันไลบรารีอยู่ในสถานะ เบต้า/พรีรีลีส และ API อาจมีการเปลี่ยนแปลงในอนาคต

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2025-06-03
ความคิดเห็นบน Hacker News

  • คัดมาจาก Readme ไลบรารีนี้ (รวมถึงเอกสารสคีมา) เขียนขึ้นโดยอาศัยความช่วยเหลือจาก Claude โมเดล AI ของ Anthropic เป็นส่วนใหญ่ วิศวกรของ Cloudflare ตรวจทานอย่างละเอียดและใส่ใจเรื่องความปลอดภัยกับการปฏิบัติตามมาตรฐานมาก แม้แต่ผลลัพธ์ช่วงแรกก็ยังถูกปรับปรุงไปมาก โดยหลัก ๆ คือเพิ่มพรอมป์ต์ให้ Claude แล้วตรวจผลลัพธ์วนซ้ำไปเรื่อย ๆ สามารถเข้าไปดูได้จริงใน commit history ว่าพรอมป์ต์ Claude อย่างไร และได้โค้ดแบบไหนออกมา เดิมทีมีจุดยืนแบบสายสงสัยตามขนบว่า “ไม่ควรปล่อยให้ LLM เขียนไลบรารีสำหรับ authentication” จนถึงเดือนมกราคม 2025 ตัวฉันเองก็ยังสงสัย AI มาก และคิดว่า LLM ก็เป็นแค่ ‘เครื่องสร้าง Markov chain แบบหรู ๆ’ ที่ไม่ได้สร้างความแปลกใหม่หรือโค้ดที่ใช้ได้จริง เริ่มโปรเจ็กต์นี้แบบทำเอาสนุก แต่กลับช็อกที่โค้ดออกมาดีกว่าที่คิด มันไม่สมบูรณ์แบบ แต่ถ้าขอให้ AI แก้ก็แก้ได้ถูกต้อง ตรวจเทียบทีละบรรทัดกับ RFC ต่าง ๆ และรีวิวร่วมกับผู้เชี่ยวชาญด้านความปลอดภัย ตอนแรกตั้งใจจะพิสูจน์ความสงสัยของตัวเอง แต่ผลกลับพิสูจน์ว่าตัวเองคิดผิด แนะนำให้ดูประวัติ commit โดยเฉพาะช่วงแรก ๆ เพื่อเห็นกระบวนการนี้

    • ถ้าวิศวกรที่มีประสบการณ์พรอมป์ต์ได้เหมาะสม ก็พอคาดหวังได้ว่า LLM จะสร้างโค้ดระดับนี้ได้ OAuth ไม่ใช่เทคโนโลยีใหม่ และน่าจะมีตัวอย่างโอเพนซอร์สกับเคส implementation หลายภาษาจำนวนมากถูกใช้เป็นข้อมูลไปแล้ว แต่ก็ยังสงสัยกับคำกล่าวอ้างว่า LLM จะสร้างนวัตกรรมอย่างก้าวกระโดดในงานวิจัยใหม่จริง ๆ วัสดุศาสตร์ เศรษฐศาสตร์ การประดิษฐ์ ฯลฯ เพราะนั่นเป็นงานที่ต้องการ ‘ความสามารถในการเรียนรู้แบบเรียลไทม์’ อย่างแท้จริง ขณะที่ LLM ปัจจุบันแสดงความสามารถได้บนฐานข้อมูลเก่าที่มันรู้อยู่แล้วเป็นหลัก ผลงานที่ดูมีความหมายส่วนใหญ่ก็มักเป็นแค่กรณี cherry-pick ในสภาพแวดล้อมที่จำกัดมาก ถ้ามีวิศวกรเก่ง ๆ อยู่แล้ว การสร้างโค้ดใหม่จากข้อมูลในอดีตก็ดูเป็นเรื่องธรรมดา แต่ก็ยังสงสัยว่าภาระด้านสิ่งแวดล้อมและสังคมจากการนำ LLM มาใช้จะมากเกินกว่าประสิทธิภาพที่ได้จริงหรือไม่

    • รู้สึกสับสนกับประโยค “ฉันก็คิดเหมือนกับ (@kentonv) จนถึงเดือนมกราคม 2025” เพราะ kentonv เป็นผู้ใช้อีกคนหนึ่ง เลยสงสัยว่านี่คือบัญชีรองของเจ้าตัวเอง หรือเป็นการพิมพ์ผิดหรือเข้าใจผิดกันแน่ แก้ไข: พบว่าข้อความส่วนใหญ่คัดมาจาก README ถ้าใช้เครื่องหมาย > และ * เพื่อแยกคำอ้างอิงให้ชัดน่าจะสับสนน้อยกว่านี้ แนบลิงก์ โปรไฟล์ kentonv

    • “คิดว่า LLM เป็นเครื่องสร้าง Markov chain แบบหรู ๆ” กับ “ประหลาดใจที่ AI สร้างโค้ดที่ค่อนข้างดีได้” ไม่ใช่ความเห็นที่ขัดกัน รู้สึกว่า LLM มีประโยชน์มาก แต่แก่นแท้ก็ยังใกล้เคียงกับเครื่องสร้างแพตเทิร์นอยู่ดี ประเด็นสำคัญคือ แค่นั้นก็มากพอแล้ว และมนุษย์เองก็อาจมีโครงสร้างที่ไม่ได้ต่างกันมากนัก

    • ช่วงนี้มีจุดยืนสงสัยมากกว่า pro-AI แต่ก็ยังพยายามนำ AI เข้ามาใน workflow ต่อไป ในทางปฏิบัติกลับรู้สึกว่าอธิบายให้ AI เข้าใจยากกว่า เลยทำเองตรง ๆ จะง่ายกว่า ไม่ได้สนุกมากนัก แต่เพราะมันเป็นเครื่องมือของ “อนาคต” ก็คิดว่าควรฝึกไว้ ตอนนี้มองว่า AI tooling ที่ใช้งานจริงยังอยู่ในระดับเริ่มต้นมาก และยังสนใจรอดูตัวอย่าง UX แปลกใหม่ต่อไป

    • มีการชี้ให้ไปดู commit history โดยตรงว่าในช่วงแรก Claude ได้รับพรอมป์ต์อย่างไรและสร้างโค้ดจริงออกมาแบบไหน ลิงก์ตรงไปยัง หน้าคอมมิตแรกสุด มีคำสั่งที่ชัดเจนและเฉพาะเจาะจงมาก และ คอมมิตตัวอย่าง 1, คอมมิตตัวอย่าง 2 ก็น่าดูเช่นกัน

  • คัดมาจาก คอมมิตปัญหา ใน workers-oauth-provider ของ Cloudflare Claude ทำบั๊กไว้ในคอมมิตก่อนหน้า พยายามแก้ด้วยพรอมป์ต์หลายรอบแล้วแต่ก็ยังไม่สำเร็จ สุดท้ายมนุษย์ต้องลงมือแก้เอง และยังบันทึกประเด็นของสเปก OAuth 2.1 ไว้ใน README ด้วย ประสบการณ์แบบนี้ทำให้รู้สึกอินมากกับการใช้งาน AI ของตัวเองเหมือนกัน มักจะเห็นมันไปได้ดีถึงครึ่งทาง แล้วส่วนที่เหลือกลับยากขึ้น

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

    • หากจะบรรเทาปัญหานี้ การเตรียมชุดทดสอบหรือสเปกที่ชัดเจนแล้วให้ AI แก้ตามนั้นจะช่วยได้ เมื่อไม่กี่เดือนก่อน AI ยังใช้เวลานานมากในการแก้ปริศนาตามสเปกแบบนี้ และผลงานก็คุณภาพต่ำกว่าการตอบเร็ว ๆ แต่ช่วงหลังความสามารถของโมเดลดีขึ้นมาก งานลักษณะนี้เลยค่อนข้างสนุก และถ้างานสามารถทำให้เป็นสเปกได้ ประโยชน์ใช้สอยก็สูงขึ้น ส่วนตัวรู้สึกว่า sonnet 3.7 ก้าวกระโดดจาก 3.5 มาก และ Gemini 2.5 Pro น่าประทับใจกว่า sonnet 4 ทำผิดพลาดน้อยกว่า แต่ก็ยังต้องชี้นำ AI ให้ดีในมุมมองวิศวกรรมซอฟต์แวร์ เช่น การจัดระเบียบข้อกำหนด การสำรวจทางออกทางเทคนิค การออกแบบสถาปัตยกรรม การเขียน user story และสเปก ตลอดจนการเขียนโค้ด จึงจะได้ผลลัพธ์คุณภาพดี อีกอย่างคือ ถ้าใส่ตัวอย่างที่ดีเพิ่มเติมให้ AI ผลจะยิ่งดีขึ้น ล่าสุดตอนทำแอปด้วย OpenAI Realtime API ช่วงแรกก็ล้มเหลวหมด แต่พอเพิ่มเอกสารสองหน้าและเดโมโปรเจ็กต์หนึ่งอันเข้าไปใน workspace ก็ได้ผลลัพธ์ที่ต้องการทันที (แม้ในกรณีของฉันจะต้องใช้ API ต่างออกไปก็ตาม)

    • พบว่าเนื้อหาในบรรทัด 163~172 ของคอมมิตมีข้ออ้างที่ชัดเจนว่าไม่ตรงกับข้อเท็จจริง หรืออย่างน้อยก็ขึ้นกับการตีความใน implementation ของ A/S แต่ละเจ้า Auth0 authorization server มีการตั้งค่า “leeway” โดยคำนึงถึงสภาพเครือข่าย แต่ authorization server บางแห่งเข้มงวดกว่ามาก รายละเอียดการออกแบบต่างกันในแต่ละ implementation จึงคิดว่าโอกาสที่ LLM จะ implement ได้อย่างปลอดภัยโดยอาศัยแค่มาตรฐาน (RFC) และโอเพนซอร์สที่เปิดเผยอยู่ สุดท้ายก็ยังต้องอาศัยการตรวจทานจากมนุษย์ในระดับใกล้เคียงกับการลงมือทำเองอยู่ดี

    • อยากรู้ผลการศึกษาระยะยาวว่าเครื่องมือที่อิง LLM ช่วยประหยัดแรงคนได้จริงหรือแค่สร้างภาพลวงตาของ productivity

    • จากประสบการณ์แบบนี้ มองว่าเครื่องมือ AI ไม่ได้ “เข้าใจ” จริง ๆ แต่สร้างผลลัพธ์เชิง emergent จากคลังข้อมูลแพตเทิร์นขนาดมหาศาลมากกว่า

  • อนาคตของ AI coding น่าจะไม่ใช่แฟนตาซีแบบ LinkedIn/X ที่บอกว่าวิศวกรซอฟต์แวร์จะหายไป แล้วนักธุรกิจกดปุ่มครั้งเดียวทุกอย่างเสร็จ แต่จะเป็นทิศทางที่วิศวกรมีประสบการณ์ใช้ AI สร้างโค้ดบางส่วน แล้วตรวจทานและทดสอบอย่างละเอียด คำถามสำคัญจริง ๆ คือ “ถ้า kentonv ทำไลบรารีนี้คนเดียวโดยไม่ใช้ AI จะทำได้เร็วกว่าไหม?”

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

    • สำหรับคำถามว่าถ้าทำเองโดยไม่ใช้ AI จะเร็วกว่าไหม คิดว่าไม่อย่างแน่นอน จากเครื่องมือที่เรามีตอนนี้และ know-how ที่พัฒนาขึ้นเรื่อย ๆ คาดว่าในอีก 3-6 เดือนข้างหน้า การใช้ AI เขียนโซลูชันใหม่โดยตรงจะยิ่งเร็วขึ้น แต่ก็คิดว่าสำคัญมากที่จะต้องมี codebase ที่เอกสารดี โครงสร้างชัด และมี feedback loop ที่เร็ว (lint/unit test ดี ๆ) เรากำลังมุ่งไปทางนั้น

    • จากประสบการณ์ เมื่อ AI สร้างโค้ดบางส่วนให้แล้ว ต้องรีวิวและทดสอบอย่างละเอียด ซึ่งกระบวนการนี้กลับ <i>ช้ากว่า</i> ที่ฉันเขียนเอง ดังนั้นในตอนนี้ AI ยังไม่ได้ช่วยมากนัก สุภาษิตที่ว่าผู้ช่วยที่แย่สู้ไม่มีผู้ช่วยไม่ได้ ยังใช้ได้ดี ตอนนี้ AI ก็เป็น “ผู้ช่วยที่แย่” แบบนั้นเอง

    • ถ้าโครงสร้างคือ “วิศวกรมีประสบการณ์ให้ AI สร้างโค้ดบางส่วน แล้วตัวเองรีวิวและทดสอบอย่างละเอียด” งั้นก็แปลว่าแทนที่จะมี kentonv 20 คน อาจเหลือแค่ 2 คนก็พอไม่ใช่หรือ แล้วจะยังมีงานให้คนอีก 18 คนอยู่ต่อไปไหม เคสของผู้เขียนเป็นโปรเจ็กต์ที่ยากทางเทคนิค แต่สงสัยว่ากับการพัฒนาแอป LoB ที่ค่อนข้างธรรมดาจะเปลี่ยนไปอย่างไร

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

  • การได้เห็นประเด็นและความเห็นหลากหลายแบบนี้ในตัวมันเองก็น่าทึ่งแล้ว ขอบคุณ Cloudflare ที่สมกับเป็นผู้นำด้านความปลอดภัยอินเทอร์เน็ต และแสดงให้เห็นความพยายามเชื่อมโลกด้วยวิธี ‘vibe coding’ แบบใหม่ รู้สึกว่าการเปิดเผยพรอมป์ต์ โค้ด ฯลฯ แบบนี้ช่วยจุดความอยากสำรวจการเขียนโปรแกรมให้กับนักพัฒนาคนอื่นด้วย vibe programming เป็นเครื่องมือที่มีความหมายมากสำหรับฉัน เพราะช่วยให้หลุดจากความหดหู่และกลับมาเขียนโค้ดในแบบที่คุ้นเคยได้ หวังว่าประสบการณ์แบบนี้จะเป็นประโยชน์กับคนอื่นด้วย และคาดว่าทั้งคนรุ่นปัจจุบันและอนาคตจะใช้วิธีนี้กัน แต่ก็คิดว่าควรคุยกันด้วยว่าวิธีนี้อาจเชื่อมโยงกับสุขภาพจิตหรือปัญหาทางจิตใจของผู้คนได้อย่างไร สุดท้ายต้องไม่ลืมว่าเครื่องมือเหล่านี้เป็นเพียงตัวช่วยของมนุษย์ และควรคิดต่อว่าจะใช้อย่างไรให้เรายังเติบโตด้วยความหลงใหลได้ หวังว่าจะมีกรณีศึกษาในโลกโอเพนซอร์สออกมาอีกมาก ที่แสดงให้เห็นไม่ใช่แค่ความสามารถทางเทคนิค แต่รวมถึงตรรกะและแนวทางทำโปรเจ็กต์อย่างรอบคอบด้วย ขอชื่นชม Cloudflare อีกครั้ง

  • มีการรวบรวมตัวอย่างการโต้ตอบด้วยพรอมป์ต์ที่เป็นตัวแทนไว้ ใน ตัวอย่าง prompt transcript มีการเปิดเผยค่าใช้จ่ายจริงด้วย (รวม $6.45) และยังแนะนำข้อมูลอย่าง คอมมิตที่เกี่ยวข้อง 1, คอมมิตที่เกี่ยวข้อง 2 เป็นต้น น่าแปลกใจที่ข้อมูลประสบการณ์ตรงเกี่ยวกับ AI workflow แบบจริงจัง (โดยเฉพาะจากคนมีประสบการณ์) กลับมีน้อยมากและถูกกระแส hype กลบไป อยากเห็นข้อมูลเคส live coding จริง ๆ ไม่ใช่แค่ todo list และอาจดูบทความของ antirez, tptacek เพิ่มเติมได้ด้วย (กรณีของ antirez, บทความของ tptacek)

    • ไม่ได้ติดตามแบบเป๊ะ ๆ แต่ประเมินว่าค่าใช้ Claude น่าจะราว ๆ $50 ซึ่งถือว่าแทบไม่มีนัยสำคัญเมื่อเทียบกับเวลาที่ประหยัดได้

  • ฉันมองว่า “vibecoding” สุดท้ายจะอยู่ไม่รอด ยังต้องอาศัยการตรวจสอบและแก้บั๊กโดยโปรแกรมเมอร์เก่ง ๆ อยู่ดี และก็มีบั๊กที่ AI แก้ไม่ได้ด้วย สุดท้ายเครื่องมือแบบนี้เป็นเพียงตัวช่วยเร่งความเร็วให้คนที่รู้งานนั้นดีอยู่แล้วเท่านั้น ถ้าเป็นหน้าเว็บพื้นฐานมาก ๆ อาจพอได้ แต่เครื่องมือสร้างอัตโนมัติแบบนั้นก็มีมาหลายปีแล้ว

    • ตอนนี้ vibecoding เหมาะที่สุดกับงานที่ stakes ต่ำ เช่น GUI, แอป CRUD, การทดลองใช้ครั้งเดียว เป็นต้น มันมีประโยชน์มากในแง่การมอบพลังใหม่ให้คนที่เดิมไม่มีพลัง ในกรณีนี้คิดว่าไม่ใช่ vibecoding แต่เป็น LLM-assisted coding มากกว่า

    • ในความเป็นจริงรู้สึกว่าคำว่า vibecoding มักถูกใช้เป็นหุ่นฟางเพื่อโจมตี ถ้าส่วนใหญ่คือเอาโค้ดที่ LLM เขียนมาแล้วแก้นิดหน่อยเพื่อใช้งาน แบบนั้นก็นับเป็น vibe coding ได้ไม่ใช่หรือ

  • ขอบคุณมากที่ OP เปิดเผยไม่ใช่แค่โค้ดที่สร้างด้วย AI แต่รวมถึงพรอมป์ต์ด้วย ส่วนตัวพยายามใช้ LLM พัฒนาโค้ดที่ไม่ใช่งานเว็บ (ช่วงนี้คือ reverse engineer SAP ABAP แล้วทำ implementation .NET ให้ข้อมูลเข้ากับ Snowflake) และเจอปัญหา hallucination ทุกครั้ง ได้ยินว่าคนอื่นมีเคสสำเร็จเยอะเลยเคยคิดว่าเป็นเพราะพรอมป์ต์ของตัวเองไม่ดี แต่พอเห็นกรณีที่เปิดเผยครั้งนี้ ก็รู้สึกว่าตัวเองไม่ได้ไกลจากจุดนั้นมาก เหตุผลที่ LLM ไม่ค่อยเวิร์กกับฉันน่าจะเป็นเพราะปัญหาที่ทำค่อนข้างเฉพาะทางและใหม่พอสมควร ถ้าไม่ใช่โจทย์ที่ถูกเรียนรู้มาเยอะอย่างเคส OAuth ที่เปิดบน GitHub แล้ว LLM ก็ตามได้ไม่ดีนัก

  • โค้ดแบบที่ทำซ้ำมานับร้อยครั้งและเป็นงานซ้ำลักษณะนี้เหมาะกับ AI อย่างสมบูรณ์ ตัวโค้ดรวมราว 1200 บรรทัด ถือว่าขนาดเล็ก กลับรู้สึกแปลกที่แม้ใช้ AI แล้วก็ยังใช้เวลามากกว่าสองวัน

  • หลายเดือนที่ผ่านมาใช้ Claude ผ่าน Cursor ทำ greenfield project ของตัวเอง แล้วรู้สึกอย่างแรกคือ productivity สูงขึ้นมหาศาล อย่างที่สองคือเหนื่อยล้าทางจิตใจมากกว่าเดิมมาก และอย่างที่สามคือแม้ในช่วงเวลาสั้น ๆ เครื่องมือก็เริ่มพัฒนาเร็วมาก จนทำให้สองผลข้างต้นยิ่งชัดขึ้น

    • ประสบการณ์ของฉันเองและของนักพัฒนาคนอื่นก็เหมือนกัน LLM assisted coding ช่วยเพิ่ม productivity ได้มากจริง แต่ก็กินพลังงานมากขึ้นพอ ๆ กัน มันแปลกจนเกือบประหลาด

    • มีคนถามกับประเด็น “ทำไมถึงเหนื่อยกว่าแบบนี้” ฉันเองใช้มันในลักษณะ “pair programming” กับเอเจนต์ของฉัน (Devstral) และมองว่าการรีวิวง่ายกว่าการต้องพิมพ์โค้ดทั้งหมดเองมาก ในแง่เวลาเป็นข้อได้เปรียบใหญ่ ในแบบ vibe coding บริบทของ codebase มักหายไป ทำให้การรีวิวภายหลังและอุปสรรคในการเข้ามาเริ่มงานสูงขึ้นมาก แต่ในแบบ pair programming บริบทจะสะสมไปพร้อมกัน เลยรู้สึกว่ารีวิวเร็วกว่าเยอะ

    • ฉันกลับตรงกันข้ามเลย AI ช่วยเก็บรายละเอียดจุกจิกทั้งหมดให้เอง เลยรู้สึกโล่งใจมาก ทำให้มีอิสระไปโฟกัสที่เป้าหมายระดับสูงอย่างสถาปัตยกรรมได้

  • รู้สึกขำไม่น้อยที่บริษัทอย่าง Cloudflare กลับเจอ error "Too Many Requests"

    • ฉันก็เหมือนกัน