ดราม่า GitHub Copilot: นักพัฒนาโกรธเรื่องอำนาจควบคุม ไม่ใช่ย้ายหนี GitHub กันทั้งวงการ

ทั้งหมดนี้เป็นสัญญาณเตือนที่จริงจัง แต่ยังไม่เท่ากับหลักฐานว่าฐานผู้ใช้ GitHub พังลงแล้ว แหล่งข้อมูลที่มีไม่ได้ให้ตัวเลข migration, ข้อมูลลูกค้าองค์กรที่ยกเลิกใช้ หรือหลักฐานระดับ repository ที่ชี้ว่าอำนาจของ GitHub ลดลงอย่างมีนัยสำคัญ สรุปที่ปลอดภัยกว่าคือ นักพัฒนากำลังทบทวนว่าอยากฝากความไว้วางใจไว้กับ GitHub มากแค่ไหน ในช่วงที่ Microsoft ผลัก AI เข้าไปลึกขึ้นในแพลตฟอร์ม

ทำไม Copilot ถึงกลายเป็นชนวน

กระแสต้าน Copilot ไม่ได้เกิดจากคำถามง่าย ๆ ว่า “AI ช่วยเขียนโค้ดมีประโยชน์ไหม” แต่เกิดจากคำถามว่า Copilot ถูกอนุญาตให้ทำอะไร และทำตรงไหน

The Register รายงานว่า discussion ยอดนิยมที่สุดใน GitHub Community ในรอบ 12 เดือนก่อนหน้านั้น คือคำขอให้มีวิธีบล็อก Copilot ไม่ให้สร้าง issues และ pull requests ใน repository รายงานเดียวกันยังระบุว่า discussion ที่ได้รับ upvote สูงเป็นอันดับสองคือ bug report ที่ขอแก้ปัญหาผู้ใช้ไม่สามารถปิด Copilot code reviews ได้

ความต่างตรงนี้สำคัญมาก ตัวช่วยที่แนะนำโค้ดใน editor ส่วนตัวเป็นเรื่องหนึ่ง แต่ระบบ AI ที่เข้ามาอยู่ใน queue ของ issue, flow ของ pull request และพื้นที่ review กลายเป็นส่วนหนึ่งของ governance ของโปรเจกต์ สำหรับ maintainer ความกังวลจึงไม่ได้หยุดที่ “Copilot เขียนโค้ดดีไหม” แต่รวมถึง “เจ้าของโปรเจกต์ยังควบคุมกติกาของชุมชนตัวเองได้หรือไม่”

เมื่อคุณภาพผลิตภัณฑ์ถูกตั้งคำถาม automation ที่ไม่อยากได้ยิ่งดูเสี่ยง

อีกส่วนของความไม่พอใจมาจากประสบการณ์ด้านความน่าเชื่อถือของเครื่องมือ ใน GitHub Community มี discussion ที่ผู้ใช้กล่าวหาว่า Copilot ใน VS Code ไม่น่าเชื่อถือและสร้างความเสียหายต่อโปรเจกต์

กระทู้ลักษณะนี้ไม่ใช่ benchmark อิสระที่พิสูจน์คุณภาพของ Copilot ในทุก workflow หรือสำหรับผู้ใช้ทุกคน แต่ช่วยอธิบายได้ว่าทำไมบางคนจึงไม่มองกิจกรรมของ Copilot ที่ตนไม่ได้ต้องการว่าเป็น “automation harmless ๆ” อีกต่อไป

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

Agent reliability กลายเป็นความเสี่ยงเชิงปฏิบัติการ

หน้าสถานะของ GitHub เองสะท้อนว่าการทำงานแบบ agentic ทำให้ความเสี่ยงสูงขึ้น เมื่อวันที่ 22 เมษายน 2026 เวลา 18:49–19:32 UTC session ของ Copilot Cloud Agent สำหรับ Agent HQ Codex agent เริ่มทำงานไม่สำเร็จจาก entry points เช่น issue assignment และการ mention ด้วย @copilot ใน comment

GitHub ระบุว่าเหตุการณ์นี้กระทบ 0.5% ของงาน Copilot Cloud Agent ทั้งหมด หรือประมาณ 2,000 งานที่ล้มเหลว ขณะที่ Copilot และ agent session ประเภทอื่นไม่ได้รับผลกระทบ

นี่ไม่ใช่การล่มของ GitHub ทั้งแพลตฟอร์ม แต่เป็นตัวอย่างของความเสี่ยงใหม่: เมื่อทีมเริ่มมอบงานจริงให้ AI agent ผ่าน issue หรือ pull request comment ความพร้อมใช้งานของ Copilot ก็กลายเป็นส่วนหนึ่งของแผนส่งมอบซอฟต์แวร์ หน้า news ของ GitHub ยังยอมรับว่ามี availability incidents ช่วงหลัง และบอกว่า outage ส่งผลกระทบต่อลูกค้า

แผน AI ของ Microsoft ทำให้สมการความไว้วางใจเปลี่ยนไป

Business Insider รายงานว่า Microsoft กำลังปรับทีมเพื่อเสริม GitHub และยกเครื่องแพลตฟอร์มให้รองรับ AI coding และ agents มากขึ้น ท่ามกลางการแข่งขันจากเครื่องมือ AI coding อย่าง Cursor และ Claude Code

ในเชิงกลยุทธ์ผลิตภัณฑ์ แนวทางนี้เข้าใจได้ เพราะ repository, pull request, issue และ review คือจุดที่ผู้ช่วยเขียนโค้ดเข้าไปสร้างคุณค่าได้โดยตรง แต่ในเชิงวัฒนธรรมของนักพัฒนา เรื่องนี้ละเอียดอ่อนกว่า

นักพัฒนาจำนวนมากมอง GitHub เป็นเหมือนโครงสร้างพื้นฐานร่วมของโลกซอฟต์แวร์ โดยเฉพาะโอเพนซอร์ส เมื่อฟีเจอร์ Copilot รู้สึกว่าเลี่ยงได้ยาก maintainer บางส่วนจึงอาจไม่ได้มองมันเป็นแค่เครื่องมือเพิ่ม productivity แบบสมัครใจ แต่เป็นการใช้ตำแหน่งศูนย์กลางของ GitHub เพื่อผลักยุทธศาสตร์ AI ของ Microsoft

AI Credits เปลี่ยนเส้นแบ่งให้กลายเป็นเรื่องงบประมาณ

GitHub ระบุว่า Copilot กำลังย้ายไปสู่ billing แบบคิดตามการใช้งาน และตั้งแต่ 1 มิถุนายน การใช้งาน Copilot จะกิน GitHub AI Credits ข้อมูลนี้ไม่ได้พิสูจน์ว่าทุกทีมจะต้องจ่ายแพงขึ้น แต่หมายความว่าองค์กรต้องเข้าใจให้ชัดว่า Copilot ทำงานได้ที่ไหน ใครเป็นคน trigger ได้ และ usage ของ AI ถูกนับเข้ากับงบอย่างไร

สำหรับทีมที่ไม่พอใจอยู่แล้วกับการที่ Copilot เข้าไปปรากฏในพื้นที่ร่วมของ repository การคิดค่าใช้จ่ายตาม usage อาจทำให้ทิศทางของ GitHub ดูไม่ใช่แค่ “ผู้ช่วยเสริม” แต่เป็น layer ที่คิดเงินได้และถูกถักเข้าไปใน workflow การพัฒนา

ไม่ใช่ทุกเรื่องต้านแพลตฟอร์มคือการออกจาก GitHub

กระแสเรื่อง developer independence หรือการลดการพึ่งพาแพลตฟอร์มใหญ่ อาจถูกนำไปรวมกับดราม่า GitHub ได้ง่าย ทั้งที่ไม่ใช่เรื่องเดียวกัน ตัวอย่างเช่น โปรไฟล์ของ David Heinemeier Hansson บน HEY ระบุว่าเขาเป็น co-owner และ CTO ของ 37signals และเป็นผู้สร้าง Ruby on Rails งานเขียนล่าสุดของเขาพูดถึงการออกจาก cloud ของ 37signals รวมถึงการได้รับเซิร์ฟเวอร์ Dell R7625 จำนวน 20 เครื่อง และแผนลดความซับซ้อนของ cloud

แต่โพสต์เหล่านั้นพูดเรื่อง cloud infrastructure ไม่ใช่หลักฐานว่า 37signals หรือ DHH ย้ายออกจาก GitHub ประเด็นนี้ต้องแยกให้ชัด: ความไม่ไว้ใจแพลตฟอร์มรวมศูนย์อาจเพิ่มขึ้นจริง แต่ไม่เท่ากับหลักฐานว่านักพัฒนากำลังทิ้ง GitHub เป็นวงกว้าง

ทีมวิศวกรรมควรทำอะไรตอนนี้

คำตอบเชิงปฏิบัติไม่ใช่การตื่นตระหนก แต่คือทำให้สมมติฐานเกี่ยวกับ GitHub และ Copilot ชัดเจนขึ้น

• ตรวจสอบ entry points ของ Copilot ดูว่า Copilot สามารถปรากฏหรือทำงานตรงไหนได้บ้างใน issues, pull requests, code reviews, comments, issue assignment และ workflow ที่เรียก @copilot
• กำหนด policy ระดับ repository ตัดสินใจว่าฟีเจอร์ Copilot ใดอนุญาต จำกัด หรือห้ามใช้ โดยเฉพาะโปรเจกต์โอเพนซอร์สและ repository ที่มีข้อกำกับด้าน compliance
• ทบทวน AI Credits ก่อน 1 มิถุนายน เพราะการใช้งาน Copilot จะกิน GitHub AI Credits ทีม engineering, platform และ finance จึงควรเข้าใจวิธีนับ usage
• วางแผนรับ incident ของ AI agent หากการส่งมอบงานขึ้นกับ issue assignment, pull request comments หรือ agent sessions ให้ถือว่า availability ของ Copilot เป็น dependency เชิงปฏิบัติการ
• คง fallback ที่ไม่พึ่ง agent ให้เรียบง่าย repository สำคัญควรยังมีเจ้าของงานที่เป็นมนุษย์ ขั้นตอน release ที่เขียนไว้ชัดเจน และทางกู้คืนเมื่อ automation ล้มเหลว

สรุป

ข้อกล่าวหาว่านักพัฒนากำลังทิ้ง GitHub กันครั้งใหญ่ยังไม่มีหลักฐานรองรับจากข้อมูลที่มีอยู่ ภาพที่ชัดกว่าคือ GitHub กำลังเจอปัญหาความไว้วางใจ: Copilot เคลื่อนเข้าไปใน workflow ร่วมของการพัฒนา Microsoft ถูกรายงานว่ากำลังจัด GitHub ให้เป็นศูนย์กลางของ AI coding และ agents เหตุการณ์ด้าน reliability มีน้ำหนักมากขึ้นเมื่อ agent ทำงานจริง และ billing แบบ usage-based สำหรับ AI กำลังมาถึง

GitHub ยังสำคัญมาก คำถามต่อจากนี้คือ นักพัฒนาจะเรียกร้องสิทธิ์ควบคุมมากแค่ไหน เมื่อแพลตฟอร์มที่เคยเป็น “ที่ฝากโค้ด” กำลังกลายเป็นแพลตฟอร์ม AI ที่รุกเข้าไปใน workflow มากขึ้น