ป้ายกำกับ: AI Coding

ย้อนกลับไปตอนที่บริษัทประกาศว่าจะซื้อ Claude Code ให้ทีมใช้ ผมยอมรับว่าตอนนั้นยังครึ่งๆ กลางๆ กับความคาดหวัง เคยลองเล่น AI coding assistant มาหลายตัวแล้ว ส่วนใหญ่จบลงที่ “ช่วยได้บ้าง แต่ต้องคอยแก้เยอะจนบางทีเขียนเองเร็วกว่า” แต่รอบนี้บริษัทจริงจัง ซื้อเป็น Standard Seat ให้ทั้งทีมใช้กันเต็มรูปแบบ ตอนนั้นโมเดลหลักที่วิ่งอยู่เบื้องหลังคือ Opus 4.5

เดือนแรก: จาก “ลองเล่น” กลายเป็น “พึ่งพา”

สองสามสัปดาห์แรกเป็นช่วงปรับตัว ทีมเราคุ้นกับการเขียนโค้ดเองมาตลอด การเปลี่ยนมาสั่งงาน AI แทนมันรู้สึกแปลกๆ เหมือนต้องหัดไว้ใจใครสักคนที่เพิ่งเจอกัน แต่พอผ่านไปได้สักพัก ทุกคนเริ่มเห็นแพทเทิร์นเดียวกัน คือ Claude Code จัดการงานที่กินเวลาแบบ routine ได้ดีมาก ไม่ว่าจะเป็นการ refactor โค้ดเก่า เขียน test เพิ่ม หรือไล่ debug ปัญหาที่ต้องกระโดดข้ามหลายไฟล์

ผลคือ throughput ของทีมขยับขึ้นชัดเจน จนงานเริ่มไหลเร็วกว่าที่ quota ของ Standard Seat จะตามทัน คนในทีมเริ่มเจอ usage limit บ่อยขึ้นเรื่อยๆ โดยเฉพาะช่วงปลายสัปดาห์ที่ทุกคนพยายามเคลียร์งานให้ทันก่อนปิด sprint

อัพเกรดเป็น Premium Seat: จุดเปลี่ยนที่ไม่มีใครคาดคิด

พอ pattern การติด limit เริ่มชัดว่าไม่ใช่เรื่องบังเอิญ บริษัทตัดสินใจอัพเกรดทั้งทีมเป็น Premium Seat ซึ่งให้ quota การใช้งานสูงกว่า Standard Seat มาก ผลลัพธ์ที่น่าแปลกใจคือหลังจากอัพเกรดแล้ว แทบไม่มีใครเจอ weekly limit อีกเลย ทั้งที่ปริมาณงานที่ส่งเข้าไปก็ไม่ได้ลดลง กลับกันคือเพิ่มขึ้นด้วยซ้ำ เพราะทุกคนกล้าใช้งานเต็มที่มากขึ้นเมื่อไม่ต้องคอยกังวลเรื่อง quota

ตรงนี้เองที่ผมเริ่มสังเกตเห็นการเปลี่ยนแปลงที่ลึกกว่าเรื่องตัวเลข usage

เมื่อ Dev ไม่ได้ “เขียนโค้ด” อีกต่อไป

สิ่งที่เปลี่ยนไปมากที่สุดในทีมไม่ใช่ความเร็ว แต่คือ “บทบาท” ของ Dev เอง จากที่เคยนั่งพิมพ์โค้ดทีละบรรทัด ตอนนี้งานส่วนใหญ่กลายเป็นการ

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

พูดง่ายๆ คือ Dev กลายเป็นคนที่ “guide” งานมากกว่า “ลงมือทำ” เอง ทักษะที่สำคัญขึ้นเรื่อยๆ ไม่ใช่การจำ syntax หรือ API ได้แม่น แต่เป็นความสามารถในการสื่อสารความต้องการให้ชัดเจน และความสามารถในการอ่านโค้ดที่คนอื่น (หรือ AI) เขียนมาแล้ววิจารณ์ได้อย่างมีหลักการ เหมือนย้ายจากตำแหน่ง “ช่าง” มาเป็น “หัวหน้าช่าง” ในเวลาไม่ถึงปี

ไม่ใช่ทุกอย่างจะราบรื่น: บทเรียนเรื่องความไม่สม่ำเสมอของโมเดล

ระหว่างทางก็มีจังหวะที่สะดุดเหมือนกัน มีบาง version ของ Opus ที่อัพเดทมาแล้วรู้สึกว่าทำงานได้ “ไม่ฉลาด” เท่าที่คาดหวัง บางครั้งตอบสั้นเกินไป บางครั้งตีความ requirement ผิดจุด ทำให้ทีมต้องคอยตรวจสอบผลลัพธ์อย่างละเอียดขึ้น ไม่ใช่ปล่อยให้ทำงานแบบ “hands-off” เต็มร้อยเหมือนที่เคยหวังไว้

บทเรียนตรงนี้คือ การทำงานร่วมกับ AI ไม่ใช่การตั้งค่าครั้งเดียวแล้วจบ แต่เป็นกระบวนการที่ต้องคอยปรับตัวตามพฤติกรรมของโมเดลที่เปลี่ยนไปเรื่อยๆ ทีมที่รอดคือทีมที่มี process การรีวิวที่แข็งแรง ไม่ใช่ทีมที่ไว้ใจ AI แบบไม่มีเงื่อนไข

Skill คือตัวเปลี่ยนเกมจริงๆ

สิ่งที่ช่วยดึงคุณภาพงานกลับมาได้มากคือการใช้ skill ต่างๆ ที่ทีมทดลองใช้กัน ไม่ว่าจะเป็น superpowers, andrej-karpathy-skills, grill-me, รวมถึง skill เฉพาะทางอย่าง WordPress skills และ Shopify skills ที่ตรงกับ stack ของงานจริง

การมี skill ที่เขียนไว้ชัดเจนทำให้ผลลัพธ์ของ Claude Code สม่ำเสมอขึ้นมาก ลดความสุ่มเสี่ยงที่จะได้ผลลัพธ์แปลกๆ และทำให้ AI เข้าใจ context ของโปรเจกต์แต่ละแบบได้เร็วขึ้น มันเหมือนการมี onboarding document ที่ AI อ่านแล้วเข้าใจทันที ไม่ต้องอธิบายใหม่ทุกครั้ง

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

แล้วต่อจากนี้จะเป็นอย่างไร

ผมเองก็ยังตอบไม่ได้เต็มปากว่าอีกหนึ่งหรือสองปีข้างหน้าทิศทางจะไปทางไหน โมเดลจะฉลาดขึ้นแค่ไหน บทบาทของ Dev จะเปลี่ยนไปอีกมากน้อยแค่ไหน แต่มีข้อเท็จจริงหนึ่งที่ชัดเจนอยู่ตรงหน้า

บริษัทไม่ได้รับ Dev เพิ่มมาสองปีแล้ว

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

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