Anthropic ได้ปล่อย Claude Code เวอร์ชัน 2.1.207 ออกมาในเดือนนี้ และสิ่งที่ซ่อนอยู่ในบันทึกการเปลี่ยนแปลง (release notes) คือการเปลี่ยนแปลงที่จะเขียนกฎเกณฑ์ใหม่สำหรับการพัฒนาที่ใช้ AI ช่วยเหลือ (AI-assisted development) โดยตอนนี้ Auto mode ได้กลายเป็นค่าเริ่มต้น (default) ในสามแพลตฟอร์มคลาวด์หลักที่โฮสต์เอเจนต์นี้ ได้แก่ Amazon Bedrock, Google Vertex AI และ Microsoft Azure Foundry การเปลี่ยนค่าเพียงจุดเดียวนี้ส่งผลต่อผู้ที่ถือครองอำนาจในการอนุมัติ (approval chain) เมื่อโค้ดที่เขียนโดยเครื่องถูกส่งเข้าสู่ repository ของคุณ

วิธีแบบเดิมนั้นใช้ไม่ได้ผล

จนถึงเวอร์ชันนี้ Claude Code ทำงานในโหมด manual เป็นค่าเริ่มต้น เอเจนต์จะทำการเตรียมการแก้ไขไฟล์ (stage a file edit), เตรียมคำสั่ง shell หรือจัดคิว git commit จากนั้นจะหยุดรอ เพื่อให้มนุษย์อ่านความแตกต่างของโค้ด (diff), ตรวจสอบคำสั่ง และคลิกอนุมัติ ทฤษฎีนี้ฟังดูสมเหตุสมผล นั่นคือการไม่ปล่อยให้ AI เข้าไปแตะต้องโค้ดในส่วน production โดยไม่มีคนเซ็นอนุมัติ

แต่ความเป็นจริงกลับต่างออกไป Anthropic พบว่า 93% ของผู้ใช้ในโหมด manual กดอนุมัติ prompt โดยที่ไม่ได้อ่านเลย นักพัฒนาปฏิบัติกับหน้าจออนุมัติเหมือนเป็นสิ่งที่น่ารำคาญมากกว่าจะเป็นจุดตรวจสอบ พวกเขากด "yes" ติดๆ กันเพื่อให้ทำงานได้อย่างต่อเนื่อง (flow) ซึ่งทำให้ด่านตรวจแบบ manual นั้นไร้ประโยชน์ การควบคุมความปลอดภัยที่ทุกคนข้ามผ่านไปได้นั้นไม่ใช่การควบคุม แต่มันคืออุปสรรค (friction) ที่แอบอ้างว่าเป็นความปลอดภัย

Auto Mode เข้ามาแทนที่การคลิกของมนุษย์ได้อย่างไร

Auto mode เปลี่ยนจากการอนุมัติโดยมนุษย์แบบขอไปที (rubber-stamp) มาเป็นการใช้โมเดล AI ตัวที่สองแทน โดย classifier ตัวนี้จะตรวจสอบทุกการกระทำที่เอเจนต์พยายามจะทำก่อนที่จะดำเนินการจริง มันจะตรวจสอบว่าขั้นตอนนั้นยังสอดคล้องกับงานเดิมหรือไม่ และเอเจนต์เริ่มออกนอกลู่นอกทางหรือไม่ หาก classifier อนุมัติการกระทำนั้น เอเจนต์จะดำเนินการต่อทันที ไม่มีการแจ้งเตือน ไม่มีการป๊อปอัป และไม่ต้องรอให้คุณทานมื้อเที่ยงเสร็จ

นี่คือตาข่ายนิรภัย (safety net) รูปแบบใหม่ classifier ไม่เหนื่อยล้าตอนตี 2 ไม่ข้ามการอ่านเพราะใกล้ถึงกำหนดส่งงาน และมันใช้ความเข้มงวดในการตรวจสอบกับการกระทำที่ร้อยเท่ากับที่ใช้กับการกระทำแรก ซึ่งวิศวกรที่เหนื่อยล้าไม่สามารถทำแบบเดียวกันได้

การพลิกกลับของการกำกับดูแล (Governance)

การเปลี่ยนแปลงที่ลึกซึ้งกว่านั้นคือเรื่องของค่าเริ่มต้น (defaults) และความรับผิดชอบ ก่อนเวอร์ชัน 2.1.207 ทีมต่างๆ ต้องเลือกใช้ auto mode ด้วยตัวเอง แต่ตอนนี้ภาระได้ถูกพลิกกลับกัน: คุณต้องดำเนินการอย่างชัดเจนเพื่อปิดการใช้งานมัน หากบริษัทของคุณจัดการข้อมูลที่มีกฎระเบียบควบคุม เช่น ในภาคการเงินหรือการดูแลสุขภาพ นี่ไม่ใช่แค่การปรับเปลี่ยน UX เล็กน้อย แต่มันคือเหตุการณ์เชิงนโยบาย (policy event) ทีมตรวจสอบความสอดคล้อง (compliance team) ของคุณจำเป็นต้องทราบว่าการ commit แบบอัตโนมัติอาจกำลังเกิดขึ้นใน repository ของคุณแล้ว เว้นแต่จะมีใครบางคนสั่งปิดฟีเจอร์นี้อย่างชัดเจน

สิ่งที่คุณควรทำในตอนนี้

อย่างแรก ให้ตรวจสอบสถานะปัจจุบันของคุณ ขุดลึกลงไปใน log และประวัติ git ล่าสุดของคุณ หากคุณเห็นการ commit ที่ระบุว่าเป็นของ Claude Code แต่ไม่มี prompt การอนุมัติจากมนุษย์ที่สอดคล้องกันในบันทึกเซสชัน แสดงว่า auto mode กำลังทำงานอยู่ อย่าทึกทักเอาเองว่าการตั้งค่าเดิมของคุณจะถูกนำมาใช้ต่อ

หากคุณต้องการกลับไปใช้การควบคุมแบบ manual โปรดทราบว่าวิธีการแบบเดิมใช้ไม่ได้แล้ว Anthropic ได้ยกเลิกการรองรับ environment variables เดิมที่ใช้สลับโหมดนี้ ตอนนี้คุณต้องตั้งค่า disableAutoMode ในไฟล์การตั้งค่าที่จัดการไว้ (managed settings file) วิธีการแก้ไขแบบเก่า (legacy workarounds) ใน shell configs หรือ container images ของคุณจะล้มเหลวโดยไม่แจ้งเตือน ดังนั้นควรตรวจสอบ deployment pipelines ของคุณหลังจากอัปเกรด

คุณไม่สามารถปรับจูน (fine-tune) classifier ได้ ไม่มีปุ่มปรับความดุดันหรือระดับความเสี่ยง การควบคุมที่ใช้งานได้จริงเพียงอย่างเดียวของคุณคือการควบคุมการเข้าถึง (access controls) จงจำกัดขอบเขตความเสียหาย (blast radius) ให้แคบลง จำกัดเอเจนต์ให้อยู่เฉพาะในไดเรกทอรีที่กำหนด ให้สิทธิ์การใช้งาน (credentials) แบบมีอายุสั้นพร้อมสิทธิ์ขั้นต่ำที่จำเป็น หาก classifier พลาดการตรวจสอบการกระทำที่ไม่เหมาะสม เอเจนต์ที่มีขอบเขตการทำงานที่จำกัดจะสร้างความเสียหายได้น้อยกว่าเอเจนต์ที่ถือสิทธิ์ admin

เมื่อใดที่ Auto Mode จะคุ้มค่า

ประโยชน์ของมันคือความเร็วในการทำงานที่ไม่จำเป็นต้องใช้เวลาของมนุษย์ Auto mode ทำงานได้ดีเยี่ยมในงานที่มีขอบเขตชัดเจนและทำซ้ำๆ ซึ่งมีความเสี่ยงต่ำและมีรูปแบบที่แน่นอน ลองนึกถึงการจัดรูปแบบไฟล์ (formatting pass) จำนวนหนึ่งร้อยไฟล์หลังจากที่คุณอัปเดตกฎ linter หรือการอัปเดต patch-level dependency เมื่อมีการแจ้งเตือนด้านความปลอดภัย เอเจนต์สามารถวนลูป (iterate), นำไปใช้, ทดสอบ และ commit ได้โดยไม่ต้องดึงวิศวกรออกจากสมาธิที่กำลังจดจ่อ (deep focus)

เรื่องนี้สำคัญเพราะเวลาของวิศวกรมีจำกัด ทุกนาทีที่เสียไปกับการคลิก "approve" เพื่อแก้ไขช่องว่าง (whitespace) คือนาทีที่ถูกขโมยไปจากงานด้านสถาปัตยกรรม, การตอบสนองต่ออุบัติการณ์ (incident response) หรือการทำงานที่ยากจริงๆ 20% ที่ยังต้องใช้การตัดสินใจของมนุษย์ Auto mode จะช่วยคืนเวลานั้นกลับมาให้คุณ

แต่ความเร็วที่ปราศจากวินัยก็คือหนี้ทางเทคนิค (technical debt) ที่เพิ่มขึ้นอย่างรวดเร็วเท่านั้น classifier จะตรวจสอบว่าการกระทำนั้นตรงกับ prompt หรือไม่ แต่มันไม่ได้ตรวจสอบว่าโค้ดที่ได้นั้นผ่านชุดทดสอบการรวมระบบ (integration suite) ของคุณหรือไม่ เคารพกฎเกณฑ์พื้นฐานของโดเมน (domain invariants) หรือเป็นไปตามคู่มือสไตล์ (style guide) ของคุณหรือไม่ คุณยังคงต้องมี CI gates, การตรวจทานโค้ด (code review) และการทดสอบอัตโนมัติก่อนที่สิ่งใดจะถูกส่งไปยัง production

ความซับซ้อนของระบบ Multi-Cloud

เนื่องจากค่าเริ่มต้นนี้ถูกเปิดใช้งานพร้อมกันทั้งใน Bedrock, Vertex AI และ Azure Foundry องค์กรที่ใช้งานระบบแบบ multi-cloud จึงจำเป็นต้องคำนึงถึงความสอดคล้องกัน คุณไม่สามารถปล่อยให้ auto mode ทำงานด้วยสิทธิ์ที่หลวมบน AWS ในขณะที่จำกัดสิทธิ์อย่างเข้มงวดบน GCP ได้ เว้นแต่คุณจะตั้งค่าแต่ละแพลตฟอร์มอย่างรอบคอบ หากคุณมองว่าคลาวด์ทั้งสามนี้เป็นเครือข่ายการทำงานเดียวกัน (operational mesh) ให้กำหนดมาตรฐานนโยบาย disableAutoMode และขอบเขตของ Identity ของคุณตั้งแต่วันนี้ ความคลาดเคลื่อน (Drift) ระหว่างแพลตฟอร์มนั้นมองไม่เห็นจนกว่ามันจะทำให้การ build พัง หรือที่แย่กว่านั้น

สิ่งที่ควรระลึกไว้เสมอคือสิ่งที่ classifier มองไม่เห็น มันประเมินว่า agent ทำงานตรงตามเป้าหมายหรือไม่ แต่ไม่ได้ประเมินว่าการ refactor นั้นจะส่งผลกระทบต่อเนื่อง (ripple effects) ไปยัง codebase ของคุณหรือไม่ agent ที่กำลังดึง shared utility ออกมาอาจดูเหมือนทำงานได้ตรงตาม prompt ทุกประการ ในขณะที่กำลังเปลี่ยนแปลง interface ที่บริการปลายน้ำ (downstream services) อีกสิบแห่งต้องใช้งานอยู่โดยไม่รู้ตัว classifier ไม่ใช่สถาปนิกอาวุโส (senior architect) แต่มันคือเครื่องมือตรวจสอบงาน (task checker)

รายการตรวจสอบสำหรับ Sprint ถัดไป

หากคุณกำลังจัดการกับการเปลี่ยนผ่านนี้ นี่คือขั้นตอนที่เป็นรูปธรรมที่คุณควรทำในสัปดาห์นี้:

  • ตรวจสอบ log ย้อนหลังสองสัปดาห์ ไล่ดูทุก Claude Code commit และทำเครื่องหมาย (flag) รายการใดก็ตามที่เกิดขึ้นโดยไม่มีการขออนุมัติจากมนุษย์
  • จำกัดขอบเขตของ credentials สร้าง service account เฉพาะสำหรับ agent ให้สิทธิ์การเขียน (write access) เฉพาะในไดเรกทอรีที่จำเป็นต้องใช้เท่านั้น ห้ามให้สิทธิ์เข้าถึง production databases, deployment keys หรือแหล่งเก็บข้อมูลลูกค้าโดยเด็ดขาด
  • อัปเดตเอกสารประกอบ ลบการอ้างอิงถึงการสลับค่า (toggles) ของ environment variable แบบเก่า และแนะนำวิศวกรที่เข้าเวร (on-call engineers) ให้ไปใช้การตั้งค่า disableAutoMode แบบ managed
  • แบ่งส่วนตามความเสี่ยง อนุญาตให้ใช้ auto mode สำหรับงานดูแลความเรียบร้อย (hygiene tasks) ในสภาพแวดล้อม dev เท่านั้น เช่น การจัดรูปแบบโค้ด (formatting) และการอัปเดต dependency เล็กน้อย แต่ต้องใช้ manual mode หรือการตรวจสอบโดยมนุษย์อย่างเต็มรูปแบบสำหรับงานใดก็ตามที่เกี่ยวข้องกับ business logic, การยืนยันตัวตน (authentication) หรือโค้ดที่จัดการข้อมูล
  • สรุปงานให้ทีม compliance อธิบายว่า classifier คือการตรวจสอบแบบอัตโนมัติ ไม่ใช่การลงนามอนุมัติโดยมนุษย์ และแสดงให้พวกเขาเห็นว่าค่าเริ่มต้นแบบ opt-out ใหม่นี้ส่งผลอย่างไรต่อนโยบายการควบคุมการเปลี่ยนแปลง (change-control policies) ที่มีอยู่เดิม

รักษา Guardrails ไว้ แต่เลิกทำพิธีกรรมที่เปล่าประโยชน์

auto mode ช่วยให้การเขียนโค้ดโดยมี AI ช่วยเหลือทำได้รวดเร็วขึ้น โดยการตัดขั้นตอนการขออนุมัติที่กลายเป็นพิธีกรรมซ้ำซากใน manual mode ออกไป การใช้โมเดลที่สองมาตรวจสอบ agent เป็นมาตรการป้องกันที่ดีกว่าการปล่อยให้โปรแกรมเมอร์ที่เหนื่อยล้ากด "yes" รัวๆ ตอนเที่ยงคืน แต่ค่าเริ่มต้นคือการตัดสินใจที่ทำไว้ล่วงหน้า และค่าเริ่มต้นนี้ตั้งสมมติฐานว่าคุณต้องการความเป็นอิสระ (autonomy) จนกว่าคุณจะสั่งเป็นอย่างอื่น

ให้ถือว่าเวอร์ชัน 2.1.207 เป็นการเปลี่ยนแปลงโครงสร้างพื้นฐาน (infrastructure change) ไม่ใช่แค่การอัปเกรดเพื่อความสะดวกสบาย ตรวจสอบสิทธิ์ของคุณ เขียน runbooks ใหม่ และตัดสินใจอย่างรอบคอบว่า workflow ใดควรเป็นแบบอัตโนมัติ และ workflow ใดควรใช้มนุษย์ ปล่อยให้ agent จัดการงานที่น่าเบื่อและซ้ำซาก (grunt work) ส่วนหน้าที่ของคุณคือการทำให้แน่ใจว่ากำแพงที่ล้อมรอบงานเหล่านั้นแข็งแรงพอที่จะป้องกันความผิดพลาดได้

เข้าร่วมการสนทนาได้ที่ GyaanSetu AI Community on Telegram