ถ้าย้อนกลับไปไม่กี่ปีก่อน การรีวิวซอฟต์แวร์ 15 โปรเจกต์อย่างจริงจังในช่วงเวลาเดียวกันคงดูไม่สมจริงสำหรับผม ผมไม่ได้หมายถึงเปิด 15 repository แล้วกวาดตาดู แต่หมายถึงการตรวจโปรเจกต์จริงซ้ำๆ เพื่อหาบั๊ก assumption ที่ผิด ปัญหา SEO ข้อผิดพลาดในการแปล ความไม่สอดคล้องของ localization เทสต์ที่ขาด regression และโค้ดเก่าที่ไม่เข้ากับระบบส่วนอื่นแล้ว
ข้อจำกัดไม่เคยเป็นความเร็วในการพิมพ์ แต่เป็น attention แต่ละโปรเจกต์มีประวัติ convention edge case และโค้ดที่ดูผิดแต่มีเหตุผลที่ตั้งใจให้เป็นแบบนั้น Review ที่ดีต้องอ่าน ค้นหา เปรียบเทียบ รัน check แล้วค่อยตัดสินว่าอะไรควรเปลี่ยนจริงๆ
Codex เปลี่ยนต้นทุนของงานซ้ำส่วนนี้สำหรับผม มันทำ first pass ใน repository ได้ ตาม reference ได้ ดูไฟล์ที่เกี่ยวข้องได้ ชี้ pattern ที่น่าสงสัย เสนอ test และช่วยตรวจพื้นที่ที่เมื่อก่อนผมต้องเปิดเองทีละไฟล์ มันไม่ได้ทำให้ final decision เป็นอัตโนมัติ แต่มันทำให้ช่วง investigation ที่แพงก่อนตัดสินใจเร็วขึ้นมาก
กฎสำคัญที่สุดของผมง่ายมาก: ผมไม่ได้ใช้ Codex เพื่อเอาตัวเองออกจาก review loop แต่ใช้เพื่อขยายขอบเขตที่ผมสามารถ review ได้
Bottleneck จริงคือ repetition ไม่ใช่การเขียนโค้ด
ถ้าดูแลโปรเจกต์เดียว เราจำ context ได้เยอะอย่างน่าประหลาดใจ แต่เมื่อมีหลายโปรเจกต์ มันไม่ scale งานประเภทเดิมกลับมาซ้ำเสมอ:
- หาบั๊กคล้ายกันใน component ต่างๆ;
- ตรวจว่า refactor ทิ้ง call site เก่าไว้หรือไม่;
- review test หลัง behavior เปลี่ยน;
- หา inconsistency ใน metadata กฎภาษา heading หรือ internal link;
- เทียบ localization key และเนื้อหาที่แปลแล้ว;
- หา error handling ที่ขาดและ edge case;
- เช็กว่า change “เล็ก” ไปแตะไฟล์มากกว่าที่คิดหรือไม่;
- อ่าน diff ที่ทีละอันง่าย แต่รวมกันกินเวลามาก.
งานเหล่านี้ไม่หวือหวา แต่สำคัญทั้งหมด และเมื่อ review แบบเดียวกันต้องทำซ้ำในหลาย codebase ต้นทุนจะสูงมาก
ตรงนี้เองที่ AI coding agent มีประโยชน์กับผมที่สุด มันรับส่วน repetitive ของ search space ไป เพื่อให้ attention ของผมเหลือสำหรับ judgment
ผมเริ่มจาก inspect ไม่ใช่ให้สิทธิ์ rewrite ทุกอย่าง
วิธีง่ายที่สุดที่จะได้ผลลัพธ์แย่คือสั่ง “review ทั้ง project แล้วแก้ทุกอย่าง” ฟังดู efficient แต่เอา discovery, prioritization, architecture, implementation และ validation มารวมใน task เดียวที่ควบคุมยาก
แยก stage แล้วได้ผลดีกว่ามาก
inspect → explain findings → prioritize → change → validate → review diffก่อนอื่นผมอยากให้ agent เข้าใจ area ที่เกี่ยวข้องและอธิบายว่าพบอะไร ผมต้องการ file path ชัดเจน code ที่กระทบ เหตุผลที่น่าสงสัย และ impact ที่เป็นไปได้ จากนั้นค่อยแก้
เรื่องนี้สำคัญเพราะ AI สามารถผิดด้วยความมั่นใจสูง โค้ดที่ดู redundant อาจมีไว้สำหรับ browser เก่า payment edge case migration path หรือ business rule ที่อ่านจากไฟล์เดียวไม่รู้ Inspection ช่วยหยุด assumption ที่ผิดก่อนจะกลายเป็น diff ใหญ่
ผมมอง finding เป็น lead ไม่ใช่ verdict
Codex review ที่ดีไม่ควรจบแค่ “พบ 17 ปัญหา” ตัวเลขแทบไม่มีความหมายถ้าไม่มี evidence
Finding ที่ actionable ควรตอบได้ว่า:
- ปัญหาอยู่ที่ไหน;
- ทำไมจึงเป็นปัญหา;
- behavior ไหนอาจพัง;
- ควรมีconfidenceแค่ไหน;
- check อะไรยืนยันหรือปฏิเสธได้;
- smallest safe fixคืออะไร.
สำคัญมากกับ security, SEO และ business logic Agent อาจชี้จุดที่ควรตรวจ แต่คำอธิบายที่ดูเป็น security ไม่ได้แปลว่าเป็น vulnerability ที่พิสูจน์แล้ว SEO warning ไม่ได้แปลว่า ranking มีปัญหาเสมอ และเงื่อนไขแปลกๆ ไม่ได้เป็น dead code โดยอัตโนมัติ
AI ลดต้นทุนการหา candidate ส่วน verification ยังเป็นตัวตัดสินว่าอะไรจริง
Validation loop ทำให้ workflow น่าเชื่อถือ
Code generation เป็นส่วนที่เห็นชัดของ AI-assisted development แต่ validation คือสิ่งที่ทำให้ใช้กับ production ได้
หลัง change ผมอยากให้ codebase ตอบกลับ ตาม project อาจมี:
- TypeScript หรือ compiler/type checker อื่น;
- lint;
- unit และ integration tests;
- build check;
- targeted search หา name หรือ call site เก่า;
- manual review final diff;
- manual verification behavior ที่ user เห็น.
Command ที่ใช้สำคัญน้อยกว่า loop Agent ตั้ง assumption, repository ส่ง evidence, decision ถัดไปใช้ evidence นั้น
นี่เป็นเหตุผลที่ผมชอบ project แบบ strongly typed ใน AI-assisted work ผมเขียนแยกไว้ว่า ทำไม TypeScript ถึงเข้ากับ Codex ได้ดีใน software delivery จริง: type เปลี่ยน assumption ผิดหลายอย่างให้เป็น machine-readable feedback ทันที
บาง review category เหมาะกับ AI เป็นพิเศษ
Bug และ regression
Agent ตาม value ข้ามไฟล์ ตรวจ caller เปรียบเทียบ implementation คล้ายกัน และหา branch ที่ไม่ consistent ได้ ช่วยจำกัดที่มาของ symptom แต่ก่อนเชื่อ conclusion ผมยัง reproduce หรือ verify behavior เอง
Test
AI มีประโยชน์ในการหาพฤติกรรมที่เปลี่ยนแต่ test coverage ไม่ตาม เสนอ edge case และอธิบายว่า test เดิมปกป้องอะไรจริงๆ รวมถึงชี้ test ที่ตรวจ implementation detail มากกว่า behavior จริง
SEO
Technical SEO มี consistency work เยอะ: metadata, language alternate, indexability, internal link, template, sitemap generation, redirect และ page-level convention Agent เทียบ rule เหล่านี้ใน codebase ใหญ่ได้เร็วกว่าผมเปิดทุก route เอง แต่ผมแยก technical correctness ออกจากคำถามที่ยากกว่าเสมอว่า content เองสมควร rank หรือไม่
Localization และ translation
เป็นหนึ่งในงานที่ซ้ำมากที่สุดของ product หลายภาษา AI เทียบ key หา missing value ตรวจ wrong language เช็ก placeholder และ highlight structural drift ระหว่าง locale ได้ เร็วกว่าการไล่ translation object ใหญ่ด้วยมือมาก แต่ important copy ยังต้องใช้ human judgment
Consistency หลัง refactoring
Large refactor มักพังด้วยเรื่องน่าเบื่อ เช่น import เก่าค้าง route เดียวยังใช้ field name เก่า หรือ test fixture ยังเป็น shape เดิม Repository-wide search ร่วมกับ agent ที่เข้าใจ intent ของ change มีประโยชน์มาก
Parallel work ช่วยเมื่อ task เป็นอิสระเท่านั้น
การเปิด agent หลายตัวแล้วให้เปลี่ยนทุกอย่างพร้อมกันน่าลอง Throughput อาจเพิ่ม แต่ conflict และ assumption ที่ไม่ตรงกันก็เพิ่มได้เหมือนกัน
ผมมอง parallelism เป็น coordination problem Independent audit เป็น candidate ที่ดี: project หนึ่งตรวจ localization ขณะที่อีก project review test หรือ repository แยกกัน inspect พร้อมกันได้ แต่ agent สองตัว rewrite architecture เดียวกันโดยไม่มี shared plan เป็นอีกเรื่อง
ยิ่ง parallel มาก boundary ยิ่งสำคัญ: project ชัด task ชัด definition of done ชัด และ result ที่ review แยกได้
เป้าหมายไม่ใช่จำนวน agent ที่รันสูงสุด แต่คือ useful, verifiable progress สูงสุด
สิ่งที่ผมไม่ delegate แบบตาบอด
- Architecture decision: model เสนอ option ได้ แต่ long-term trade-off อาจต้องใช้ context นอก repository.
- Security conclusion: finding ต้อง verification, threat context และมักต้อง specialized tool.
- Business rule: code อาจ consistent ภายในแต่ implement product behavior ผิด.
- Large destructive refactor: huge diff เข้าใจยากและ approve แบบไม่ระวังง่าย.
- Production deployment: test ผ่านไม่ได้แปลว่า operational risk หาย.
- Final review: ผมอยากรู้ว่าอะไรเปลี่ยนก่อนเอาชื่อตัวเองไปรับผิดชอบ.
ไม่ใช่เพราะ AI ไม่มีประโยชน์ แต่เพราะคำตอบผิดที่ดูน่าเชื่อในพื้นที่เหล่านี้แพงมาก
AI review ไม่แทน static analysis
ผมไม่มอง Codex เป็นตัวแทน compiler, linter, test, scanner หรือ monitoring เครื่องมือเหล่านี้มีข้อดีที่ AI ไม่มี: narrow, deterministic และ repeatable
Workflow ที่แข็งแรงที่สุดคือใช้ร่วมกัน Codex reason จาก context แล้วบอกจุดที่ควรดู Static tool enforce rule ที่แม่น Test verify behavior Log และ monitoring แสดง reality Human review เชื่อมทุก signal กับ product intent
ถ้าไม่มี feedback systems เหล่านี้ ผมจะ trust AI น้อยลง ไม่ใช่มากขึ้น
Productivity gain ใหญ่สุดคือการจัด attention ดีขึ้น
พูดว่า “Codex ช่วยประหยัดเวลา” ง่าย แต่สำหรับผมมันอธิบายไม่หมด
Resource ที่ขาดแคลนใน software development ไม่ใช่ keystroke แต่คือ high-quality attention ก่อน AI coding agent attention จำนวนมากถูกใช้กับ repetitive discovery: search pattern เดิม อ่าน file คล้ายกัน ตาม reference ตรวจว่า change ไปครบทุกที่ และทำ audit เดิมใน repository อื่น
ตอนนี้ผม delegate first-pass work ได้มากขึ้น แล้วเก็บ attention ไว้สำหรับ decision ที่ automate ยาก: finding สำคัญไหม fix เข้ากับ architecture ไหม UX ดีขึ้นไหม risk รับได้ไหม และผมอยาก ship จริงไหม
นี่ทำให้การ maintain และ review หลาย project รู้สึกต่างไป ผมไม่ได้ review น้อยลง หลายครั้งกลับ review ได้มากขึ้น เพราะ mechanical part ไม่กิน budget ทั้งหมด
Workflow ที่ผมเชื่อถือ
- กำหนด review goal ให้แคบ. Bug, test, SEO, localization, refactor หรือ concern ชัดเจน.
- ให้ agent inspect ก่อน edit. ต้องการ evidence และ affected location ก่อน.
- Prioritize finding. ไม่ใช่ทุก theoretical issue ควรเปลี่ยน code.
- Keep change bounded. Small coherent diff validate ง่าย.
- Run machine checks. Typecheck, lint, test, build, search หรือ project-specific validation.
- อ่าน diff เอง. หา unnecessary rewrite, wrong assumption, missing edge case และ change นอก scope.
- Verify important behavior. โดยเฉพาะ user, money, security, SEO และ production infrastructure.
- ค่อยไป project ถัดไป. Parallelism useful แต่ unresolved uncertainty ไม่ควรแพร่.
15 project ไม่รู้สึกเหมือน 15 เท่าของ review work อีกต่อไป
Codex ไม่ได้ทำให้ 15 project ง่าย และไม่ได้เอา responsibility ออกจากผม มันเปลี่ยนความสัมพันธ์ระหว่าง scale กับ repetitive effort
ผมขอ first pass ที่ลึกขึ้น consistency check ที่กว้างขึ้น test idea มากขึ้น และ audit ที่ systematic ขึ้นได้ โดยไม่ต้องใช้ทุกนาที search ทุก file ด้วยตัวเอง แล้วใช้ attention ที่เหลือกับ decision ที่ยังต้องการ developer
นี่คือ AI-assisted development ที่ผมเห็นคุณค่า: ไม่ใช่ autopilot ไม่ใช่ blind trust และไม่ใช่ “generate code จนกว่าจะมีอะไรผ่าน” แต่มันคือ loop ที่แน่นขึ้นระหว่าง machine-scale inspection กับ human-scale judgment.
สำหรับผม นี่คือ leverage จริงของ Codex มันไม่ได้กำจัด review แต่มันทำให้ serious review ใน scale ที่เมื่อก่อนดูแลยากมากเป็นไปได้