วิธียกเลิกการทำโค้ดรีวิว

• เมื่อปริมาณและขนาดของโค้ดที่ AI สร้างเพิ่มขึ้นแบบทวีคูณ วิธีการทำ manual code review แบบเดิมก็ไม่ใช่วิธีที่ใช้ได้อีกต่อไป
• ทีมที่มีอัตราการนำ AI มาใช้สูงมีปริมาณงานที่ทำเสร็จเพิ่มขึ้น 21% และการ merge PR เพิ่มขึ้น 98% แต่กลับเกิดปรากฏการณ์ย้อนแย้งที่ เวลารีวิว PR เพิ่มขึ้น 91%
• แทนที่จะตรวจโค้ดโดยตรง บทบาทของมนุษย์ควรย้ายไปสู่การตรวจสอบต้นน้ำด้วยการรีวิว สเปกและเกณฑ์การยอมรับ (Acceptance Criteria)
• แทนที่จะมีประตูตรวจสอบเพียงจุดเดียว จำเป็นต้องมีโครงสร้างความเชื่อถือหลายชั้นตามแนวคิด Swiss cheese model เช่น การแข่งขันกันของหลายเอเจนต์, deterministic guardrails, BDD, ระบบสิทธิ์, และ adversarial verification
• แนวทาง "ปล่อยขึ้นระบบให้เร็ว สังเกตทุกอย่าง และย้อนกลับให้เร็วยิ่งกว่าเดิม" กำลังกลายเป็นพาราไดม์ใหม่ที่มาแทน การรีวิวช้าแล้วค่อยไปดีบักในโปรดักชัน

---

มนุษย์รับภาระ code review ไม่ไหวอยู่แล้ว

• ความจริงในปัจจุบันคือ PR ถูกปล่อยค้างไว้หลายวัน มีการอนุมัติแบบพิธีการ และรีวิวเวอร์เพียงแค่ ไล่ดู diff 500 บรรทัดผ่าน ๆ
• แม้ code review จะถูกมองว่าเป็น quality gate แต่ก็มีทีมที่ปล่อยซอฟต์แวร์มานานหลายสิบปีโดยไม่ต้องทำ line-by-line review และการที่ code review กลายเป็นเรื่องแพร่หลายก็เพิ่งเกิดขึ้นราว ปี 2012~2014
• ต่อให้มีรีวิวก็ยังเกิด incident ได้อยู่ดี และเพราะเหตุนี้เราจึงสร้างระบบอย่าง feature flag, gradual rollout, immediate rollback เพื่อรับมือมาโดยตลอด

ต้องเลิกพยายามอ่านทุกบรรทัดของโค้ด

• ในทีมที่มีการใช้ AI สูง ทั้ง จำนวนครั้งของการเปลี่ยนแปลงและขนาดของการเปลี่ยนแปลง กำลังเพิ่มขึ้นแบบทวีคูณพร้อมกัน
  • อ้างอิงจากข้อมูลของนักพัฒนามากกว่า 10,000 คน และ 1,255 ทีม (การวิเคราะห์ของ Faros)
• นักพัฒนารู้สึกว่าการรีวิวโค้ดที่ AI สร้างขึ้นต้องใช้ ความพยายามมากกว่า การรีวิวโค้ดของเพื่อนร่วมงาน
• การทำ manual code review ไม่มีทางชนะเกมนี้ได้ และ code review ก็เป็น approval gate จากอดีต ที่ไม่สอดคล้องกับรูปแบบการทำงานในปัจจุบัน

แม้แต่ AI code review ก็ยังเป็นแค่ "รีวิว" อยู่ดี

• ถ้า AI เป็นคนเขียนโค้ดและ AI เป็นคนรีวิว ก็ไม่มีเหตุผลอะไรที่จะต้องแสดงผลผ่าน UI รีวิวสวย ๆ
• เครื่องมือ AI code review ช่วยได้เพียงซื้อเวลา และรีวิวลักษณะนี้จะค่อย ๆ ถูกเลื่อนไปทาง ด้านซ้ายของวงจรพัฒนา (shift left)
  • ไม่มีเหตุผลที่จะเปลืองทรัพยากร CI และทำเวอร์ชันจัดการระหว่างรอบรีวิว
• ในสภาพแวดล้อมที่เอเจนต์เป็นผู้เขียนโค้ด "สายตาคู่ใหม่" ก็เป็นเพียงอีกเอเจนต์หนึ่งที่มีจุดบอดแบบเดียวกัน และคุณค่าที่แท้จริงไม่ได้อยู่ที่ approval gate แต่อยู่ที่ ลูปการวนซ้ำ
• สัญชาตญาณแบบ "ฉันเคยเห็น AI ทำเรื่องโง่ ๆ มาแล้ว ดังนั้นต้องตรวจทุกครั้ง" เคยสมเหตุสมผลในยุคที่ยังตรวจแบบ manual ได้ แต่ในขนาดงานปัจจุบันมัน ทำไม่ได้อีกต่อไป

เปลี่ยนจาก code review ไปเป็น intent review

• เราต้องย้าย checkpoint ของมนุษย์ไปไว้ที่ ต้นน้ำ (upstream)
  • ในการพัฒนาซอฟต์แวร์ก็เคยมีแบบอย่างของการย้าย checkpoint มาแล้ว: waterfall sign-off → continuous integration (CI)
• การพัฒนาแบบขับเคลื่อนด้วยสเปก (Spec-driven development) กำลังกลายเป็นรูปแบบหลักของการร่วมงานกับ AI
  • มนุษย์ควรรีวิวสเปก แผน ข้อจำกัด และเกณฑ์การยอมรับ โดยไม่จำเป็นต้องรีวิว diff 500 บรรทัด
• ในพาราไดม์ใหม่นี้ สเปกคือแหล่งความจริง (source of truth) และโค้ดเป็นผลลัพธ์ที่สร้างจากสเปก
  • สิ่งที่ต้องรีวิวไม่ใช่โค้ด แต่คือขั้นตอน (steps), กฎการตรวจสอบ (verification rules) และ contract ที่โค้ดต้องปฏิบัติตาม
• การอนุมัติแบบ Human-in-the-loop จะเปลี่ยนจาก "เขียนสิ่งนี้ได้ถูกต้องไหม?" ไปเป็น "กำลังแก้ปัญหาที่ถูกต้อง ภายใต้ข้อจำกัดที่ถูกต้องหรือไม่?"
• การตัดสินใจของมนุษย์ที่มีมูลค่าสูงสุดไม่ได้เกิดหลังการสร้างโค้ด แต่เกิดขึ้น ก่อนที่บรรทัดแรกจะถูกสร้าง

สร้างความเชื่อถือหลายชั้น — Swiss cheese model

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

Layer 1: เปรียบเทียบหลายทางเลือก

• แทนที่จะขอคำตอบจากเอเจนต์ตัวเดียว ให้ เอเจนต์สามตัวลองแก้คนละแบบ แล้วเลือกผลลัพธ์ที่ดีที่สุด
• การเลือกไม่จำเป็นต้องทำด้วยมือ อาจจัดอันดับตามเกณฑ์อย่าง การผ่านขั้นตอนตรวจสอบได้มากที่สุด, diff เล็กที่สุด, หรือ ไม่มีการเพิ่ม dependency ใหม่
• ต้นทุนของการมีหลายทางเลือกอยู่ในระดับ ต่ำที่สุดในประวัติศาสตร์วิศวกรรมซอฟต์แวร์

Layer 2: deterministic guardrails

• เราต้องมี วิธีตรวจสอบแบบ deterministic สำหรับงานนั้น ๆ เช่น test, type check, contract verification ซึ่งจัดการกับข้อเท็จจริง ไม่ใช่ความคิดเห็น
• แทนที่จะถาม LLM ว่า "อันนี้ใช้ได้ไหม?" ให้กำหนดขั้นตอนตรวจสอบที่สร้างผลลัพธ์แบบ pass/fail เป็นลำดับชัดเจน
• ลำดับชั้นของ guardrails:
  • แนวทางการเขียนโค้ด — อาจทำเป็น custom linter
  • กฎคงที่ทั้งองค์กร — เรื่องที่ต่อรองไม่ได้ เช่น ห้าม hardcode credential, API key, token
  • domain contracts — กฎตาม framework, service หรือพื้นที่ของ codebase (เช่น ในโดเมนการชำระเงิน จำนวนเงินทั้งหมดต้องใช้ชนิด Money)
  • เกณฑ์การยอมรับ (Acceptance Criteria) — เกณฑ์เฉพาะของงานนั้น
• ขั้นตอนการตรวจสอบต้องถูกนิยาม ก่อนเขียนโค้ด ไม่ใช่สร้างขึ้นภายหลังเพื่อมายืนยันสิ่งที่มีอยู่แล้ว
  • ถ้าเอเจนต์เป็นคนเขียนทั้งโค้ดและเทสต์ ก็เท่ากับแค่ ย้ายปัญหาไปที่อื่น และเกณฑ์การตรวจสอบต้องมาจาก สเปก ไม่ใช่จาก implementation

Layer 3: มนุษย์เป็นผู้กำหนดเกณฑ์การยอมรับ

• จุดที่มนุษย์เพิ่มคุณค่าได้มากที่สุดคือ การนิยามว่าความสำเร็จหน้าตาเป็นอย่างไรตั้งแต่ต้นน้ำ
• BDD (Behavior-Driven Development) กลับมามีความเกี่ยวข้องอีกครั้ง
  • เป็นวิธีอธิบายพฤติกรรมที่คาดหวังด้วยภาษาธรรมชาติและทำให้เป็นเทสต์อัตโนมัติ
  • ในอดีตการเขียนสเปกดูเหมือนงานเพิ่ม เพราะยังต้องเขียนโค้ดเองด้วย แต่ในสภาพแวดล้อมแบบเอเจนต์ สเปกคือผลลัพธ์หลักลำดับแรก
• เมื่อมนุษย์เขียนสเปก เอเจนต์ก็ทำ implementation และ BDD framework เป็นผู้ตรวจสอบ — ถ้าไม่ล้มเหลว ก็ไม่จำเป็นต้องอ่าน implementation เลย
• สิ่งที่มนุษย์ทำได้ดีคือการนิยามว่าอะไรคือ "ความถูกต้อง" การเข้ารหัส business logic และ edge case และการคิดถึงสิ่งที่อาจผิดพลาดได้
• เกณฑ์การยอมรับ ที่มนุษย์เขียนและเครื่องเป็นผู้ตรวจสอบ คือ gate ที่สำคัญจริง ๆ

Layer 4: ทำให้ระบบสิทธิ์เป็นส่วนหนึ่งของสถาปัตยกรรม

• สิ่งที่เอเจนต์แตะต้องได้ และสิ่งใดที่ต้อง escalation ควรถูกออกแบบเป็นการตัดสินใจเชิงสถาปัตยกรรม
• framework สำหรับเอเจนต์ส่วนใหญ่มักจัดการสิทธิ์แบบ all-or-nothing แต่ความละเอียดของสิทธิ์สำคัญมาก
  • เอเจนต์ที่แก้บั๊กใน utility function ไม่จำเป็นต้องมีสิทธิ์เข้าถึงการตั้งค่า infrastructure
  • เอเจนต์ที่เขียนเทสต์ไม่จำเป็นต้องมีสิทธิ์แก้ไข CI pipeline
• ขอบเขตควร แคบที่สุดเท่าที่จะยังทำงานให้เกิดประโยชน์ได้
  • ตัวอย่าง: ถ้างานคือ "แก้บั๊กการ parse วันที่ใน utils/dates.py" ก็ควรอนุญาตให้เข้าถึง เฉพาะไฟล์นั้นและไฟล์เทสต์
• trigger สำหรับ escalation ก็สำคัญเช่นกัน: การแก้ logic ของการยืนยันตัวตน, การเปลี่ยน schema ฐานข้อมูล, การเพิ่ม dependency ใหม่ ฯลฯ ควร เรียก human review อัตโนมัติ โดยไม่ขึ้นกับระดับความมั่นใจของเอเจนต์

Layer 5: adversarial verification

• ต้องแยกความรับผิดชอบ: ให้เอเจนต์หนึ่งทำงาน และ อีกเอเจนต์หนึ่งเป็นผู้ตรวจสอบ — หัวใจสำคัญคือไม่ให้เชื่อใจกัน
  • นี่คือรูปแบบเก่าที่ใช้มานาน เช่น ทีม QA ไม่ควรรายงานตรงต่อ engineering manager และคนเขียนโค้ดไม่ควรเป็นคนเดียวที่รีวิวงานตัวเอง
• บังคับใช้ในเชิงสถาปัตยกรรมได้: เอเจนต์ที่เขียนโค้ดไม่รู้ว่าเอเจนต์ตรวจสอบจะเช็กอะไร และเอเจนต์ตรวจสอบก็แก้โค้ดไม่ได้ — เป็น ความเป็นปฏิปักษ์โดยการออกแบบ
• ไปได้ไกลกว่านั้นด้วยเอเจนต์ตัวที่สามที่พยายาม ทำลายสิ่งที่เอเจนต์ตัวแรกสร้าง โดยมุ่งเป้าไปที่ edge case และ failure mode — เปรียบเหมือนการทำ red team/blue team automation กับทุกการเปลี่ยนแปลง

ความหมายของ "โค้ดที่ดี" กำลังเปลี่ยนไป

• แรงจูงใจของระบบเอเจนต์นั้นเรียบง่าย: ทำงานที่ได้รับมอบหมายให้เสร็จ และทำให้ผู้สั่งพอใจ — ความถูกต้องระยะยาวหรือ ความต้องการทางธุรกิจ ไม่ใช่แรงจูงใจที่มีอยู่โดยธรรมชาติ
• หน้าที่ของมนุษย์คือ เข้ารหัสสิ่งเหล่านี้ลงไปในข้อจำกัด
• เมื่อเอเจนต์เป็นผู้สร้างและผู้ที่อ่านโค้ดก็คือเอเจนต์ด้วยกัน รูปแบบของ "โค้ดที่ดี" จะ เป็นมาตรฐานมากขึ้น และ codebase ใหม่ ๆ ก็จะต้องการการชี้นำลดลง
• ทิศทางในอนาคตคือ "ปล่อยให้เร็ว สังเกตทุกอย่าง และย้อนกลับให้เร็วยิ่งกว่าเดิม"
  • ตรงข้ามกับ "รีวิวช้า ๆ แล้วก็ยังพลาดบั๊กอยู่ดี ก่อนจะไปดีบักในโปรดักชัน"
• เราไม่มีทางชนะได้ด้วยการพยายามอ่านสิ่งที่เครื่องสร้างให้มากขึ้น แต่ต้อง คิดเหนือเครื่องในจุดต้นน้ำ ที่การตัดสินใจสำคัญจริง
• ถ้าเอเจนต์จัดการโค้ดได้ดีอยู่แล้ว มนุษย์จะอ่านโค้ดนั้นรู้เรื่องหรือไม่ ก็ ไม่ใช่ประเด็นสำคัญอีกต่อไป

[shlee1503]

บอกว่าการรีวิวโค้ดเป็นคอขวด งั้นก็ไม่ต้องรีวิวไปเลย ฟังดูแปลกใหม่จนขำเลยครับ 55555555

[bbulbum]

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

[snisper]

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

[hanje3765]

ผมคิดว่าการที่รีวิวหายไปเป็นผลจากแรงจูงใจด้านพฤติกรรม
ถ้าสิ่งที่บริษัทต้องการคือ
อัตราความผิดพลาดต่ำ ก็จะยิ่งบังคับให้ทำรีวิวอย่างเข้มงวดขึ้น
แต่ถ้าคือการปล่อยฟีเจอร์ให้เร็ว รีวิวก็คงจะค่อย ๆ ถูกละเว้นไป
การที่บอกว่ารีวิวกำลังหายไป ทำให้รู้สึกว่าบริษัทให้ความสำคัญกับการปล่อยฟีเจอร์เร็วมากกว่า
แต่ถ้าผมเป็นนักลงทุน ผมก็คงเรียกร้องแบบนั้นเหมือนกัน ฮ่าๆ

[vk8520]

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

[conpages]

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

[moregeek]

จะให้สะสมกล่องดำต่อไปงั้นเหรอ?

[ahwjdekf]

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

[dhlee0305]

นี่ก็เป็นประเด็นที่พอนึกเปรียบเทียบได้คล้ายกับคำพูดที่ว่า "FSD ฉลาดขึ้นแล้ว เพราะงั้นคนขับจะหลับก็ได้"
ในเชิงเทคนิค ดูเหมือนว่ายุคแบบนั้นจะค่อย ๆ มาถึงจริง แต่สิ่งสำคัญคือจะข้ามกำแพงเรื่องความรับผิดชอบไปได้อย่างไร
ผมคิดว่าอย่างน้อยการรีวิวโค้ดก็น่าจะเป็นอุปกรณ์ความปลอดภัยขั้นต่ำ

[brilliant08]

แล้วทำไมการตรวจสอบเจตนาในระดับแนวคิดที่สูงกว่าถึงยังต้องให้คนทำอยู่ล่ะ..?

[adieuxmonth]

จริง ๆ แล้วก็ไม่จำเป็นต้องให้เขียนโค้ดด้วยภาษาโปรแกรมด้วยซ้ำ

[ewpes]

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

[github88]

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

[myc0058]

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

[fantajeon]

อืม~ แค่เขียนให้เกิดข้อถกเถียงแบบนี้ขึ้นมา ก็ดูเหมือนว่าเจตนาจะสื่อก็เพียงพอแล้วนี่นา

[gomjellie]

เป็นบทความแปล: https://rosetta.page/post/…

[brainer]

จริง ๆ แล้วมันเป็นปัญหาที่คัดออกได้ตั้งแต่ขั้นตอน plan อยู่แล้ว

[foriequal0]

ในกระบวนการเขียนโค้ดด้วยมือนั้น นักพัฒนามักจะได้ทำทั้งการวางแผน การออกแบบ การสำรวจ การทำความเข้าใจ การทดสอบ การรีวิวด้วยตัวเอง และยังสื่อเป็นนัย ๆ ถึงกระบวนการรับมือภายหลังเมื่อเกิดปัญหาไปพร้อมกันแบบขนานโดยธรรมชาติ ทำให้แต่ละด้านถูกปรับจูนเข้าหากันอย่างเป็นธรรมชาติอยู่แล้ว ดังนั้นผมจึงคิดว่า ต่อให้การทดสอบหรือการรีวิวจะไม่เพียงพอ มันก็ยังพอทำงานไปได้ในระดับหนึ่ง
แต่ถ้าตัดกระบวนการเขียนด้วยมือออกไป กระบวนการที่เคยมีอยู่โดยนัยเหล่านั้นก็จำเป็นต้องถูกแบ่งขอบเขตออกมาอย่างชัดเจน เนื่องจากผู้ที่เขียนโค้ดกับผู้ที่ตรวจทานยิ่งแยกจากกันมากขึ้น ความไร้ประสิทธิภาพในการสื่อสารก็เพิ่มขึ้น อีกทั้งเพราะความน่าเชื่อถือของผู้ที่สร้างโค้ดลดลง ต้นทุนในการตรวจทานจึงเพิ่มขึ้นด้วย
ผมรู้สึกว่ามันคล้ายกับแนวคิดที่เรียกว่า doorman's fallacy หรือเปล่า

[remin1994]

นี่ก็เป็นประเด็นที่ผมคิดอยู่บ่อย ๆ ในบริษัทเหมือนกัน ดีเลยครับ ส่วนตัวก็อยากลองนำไปใช้กับฮาร์เนสที่กำลังทำอยู่ด้วยเหมือนกัน

[jayhanx]

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

[smoonsf]

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

ณ ตอนนี้ ผมคิดว่าการคงรายละเอียดการเขียนโค้ดในระดับ implementation ให้เป็น black box แทนที่จะลงไปถึงระดับการออกแบบหรือสถาปัตยกรรม เป็นแนวทางที่พึงประสงค์

[moregeek]

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

[raykim]

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

ต่อให้โมเดลล่าสุดจะเก่งแค่ไหน ถ้ายังทำคะแนนเต็มใน SWE benchmark ได้ไม่ "เสมอไป" (6 nine, 0.999999) ผมก็คิดว่าความเป็นไปได้นั้นยังคงเปิดอยู่ครับ

[shakespeares]

รีวิวตามเจตนา ฟังดูเป็นคำที่ดีนะ

[ljyda214]

เคยคิดอยู่ว่าควรรับมืออย่างไรในยุคที่ทุกอย่างเร็วขึ้นด้วย AI
นี่เป็นบทความดี ๆ ที่มอบมุมมองใหม่เกี่ยวกับการรีวิวโค้ด!