ความพยายามครั้งแรก 95% คือขยะ: เส้นทางของ Staff Engineer กับ Claude Code

 (sanity.io)
24 คะแนน โดย GN⁺ 2025-09-03 | 5 ความคิดเห็น | แชร์ทาง WhatsApp
  • Staff Engineer คนหนึ่งแชร์ประสบการณ์ทดลองเวิร์กโฟลว์การพัฒนาร่วมกับ AI โดยใช้ Claude Code เป็นเวลา 6 สัปดาห์
  • แนวคิดที่มอง AI เป็น ‘นักพัฒนาจูเนียร์ที่ไม่เรียนรู้’ คือกุญแจของการผสานใช้งานให้สำเร็จ
  • ความพยายามครั้งแรกส่วนใหญ่ ล้มเหลว 95% แต่จะค่อย ๆ ขัดเกลาเป็นโค้ดที่ใช้งานได้ผ่านกระบวนการทำซ้ำ
  • ใช้ ไฟล์คอนเท็กซ์รายโปรเจกต์ (Claude.md) และ การเชื่อมต่อเครื่องมือผ่าน MCP เพื่อแก้ปัญหาที่ AI ขาดคอนเท็กซ์
  • บทบาทของนักพัฒนากำลังย้ายจากการเขียนโค้ดไปสู่ การแก้ปัญหาและการออกแบบสถาปัตยกรรม ซึ่งเป็นแพตเทิร์นการเพิ่มผลิตภาพแบบใหม่ในยุค AI

ภูมิหลังและแนวทาง

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

กระบวนการเปลี่ยนผ่านของกระบวนทัศน์การพัฒนา

  • ช่วง 5 ปีแรกยังใช้รูปแบบการพัฒนาที่อาศัยหนังสือและเอกสาร SDK
  • หลังจากนั้น 12 ปีเปลี่ยนไปใช้ องค์ความรู้จากมวลชนผ่านการค้นหา (google)
  • ตลอด 18 เดือนล่าสุดได้ทดลอง การเขียนโค้ดโดยมี AI ช่วยผ่าน Cursor
  • ในช่วง 6 สัปดาห์ก่อนหน้า ได้พบการเปลี่ยนแปลงครั้งใหญ่จาก การมอบหมายงานให้ AI แบบองค์รวมผ่าน Claude Code
  • การปรับตัวเข้ากับ Claude Code ทำให้สัมผัสได้ถึงผลิตภาพที่ดีขึ้นภายในเวลาเพียงไม่กี่ชั่วโมง

เวิร์กโฟลว์โปรดักชันที่ขับเคลื่อนด้วย AI ในทางปฏิบัติ

  • เมื่อต้องทำงานกับโค้ดที่จะขึ้นโปรดักชัน มักใช้ AI เพื่อช่วยในเรื่องของการ "คิด" เป็นหลัก
  • การสร้างโค้ดที่สมบูรณ์แบบในครั้งเดียวเป็นไปไม่ได้ หน้าที่ของวิศวกรคือการหาวิธีแก้ปัญหาที่ดีที่สุด
    • ความพยายามครั้งแรก (ล้มเหลว 95%): เป็นช่วงที่ AI กำลังสะสมบริบทของระบบ และนักพัฒนากำลังกำหนดปัญหา แต่โค้ดแทบทั้งหมดผิด
    • ความพยายามครั้งที่สอง (ล้มเหลว 50%): ความเข้าใจคอนเท็กซ์ดีขึ้นและแนวทางเริ่มชัดขึ้น แต่ครึ่งหนึ่งยังใช้ไม่ได้
    • ความพยายามครั้งที่สาม (โค้ดใช้งานได้): หลังผ่านการทำซ้ำและรีวิว จะได้โค้ดฐานที่ใช้งานจริงได้และค่อยปรับปรุงต่อได้
  • กระบวนการนี้ไม่ใช่ความล้มเหลว แต่เป็น การทดลองที่วางแผนไว้โดยตั้งใจและการเพิ่มประสิทธิภาพแบบวนซ้ำ

ปัญหาเรื่องคอนเท็กซ์และทางแก้

  • AI ไม่สามารถเก็บความทรงจำข้ามเซสชันได้ จึงมีข้อจำกัดที่ต้องอธิบายเรื่องเดิมซ้ำทุกครั้ง
  • ทางแก้คือใช้ ไฟล์ Claude.md เพื่อบันทึกการตัดสินใจด้านสถาปัตยกรรม แพตเทิร์น และลิงก์เอกสารต่าง ๆ
  • ผ่านการเชื่อมต่อ MCP เพื่อเชื่อมกับ Linear, Notion, GitHub, codebase และฐานข้อมูล ให้คอนเท็กซ์โดยอัตโนมัติ
    • ใช้ Linear เพื่อให้คอนเท็กซ์ของตั๋วงาน
    • ใช้ Notion หรือ Canvas เพื่อเข้าถึงเอกสาร
    • ใช้ ฐานข้อมูลที่ไม่ใช่โปรดักชัน เพื่อตรวจสอบโครงสร้างข้อมูล
    • ใช้ GitHub เพื่อดึงข้อมูลภูมิหลังจาก PR เก่า
    โฆษณา

การใช้งาน Claude หลายอินสแตนซ์แบบขนานและกลยุทธ์หลัก

  • ใช้ Claude หลายอินสแตนซ์แบบขนาน โดยมองเหมือนกำลังบริหาร 'ทีมพัฒนาเล็ก ๆ ที่สูญเสียความจำทุกวัน'
  • วางกลยุทธ์อย่าง ห้ามทำงานขนานในโดเมนปัญหาเดียวกัน, บันทึกงานทั้งหมดลงในเครื่องมือจัดการโปรเจกต์อย่าง Linear และ ระบุให้ชัดว่าโค้ดส่วนไหนที่มนุษย์แก้เอง
  • ใช้ AI อย่างจริงจังไม่เฉพาะการเขียนโค้ด แต่รวมถึง การรีวิวโค้ด ด้วย: ช่วยตรวจหาการขาดเทสต์ บั๊กที่ชัดเจน และจุดที่ควรปรับปรุงได้รวดเร็ว ลดงานซ้ำซ้อน
  • ตามนโยบายของบริษัทผู้เขียน (Sanity) แม้โค้ดจะถูกสร้างโดย AI ความรับผิดชอบด้านคุณภาพสุดท้ายยังอยู่ที่วิศวกร
  • ในสภาพแวดล้อมที่แยกไม่ออกว่าโค้ดมาจาก AI หรือมนุษย์ ความยึดติดทางอารมณ์ลดลง ทำให้ รีวิวโค้ดได้อย่างวิพากษ์และเป็นกลางมากขึ้น

กระบวนการรีวิวโค้ด 3 ขั้นตอน

  • การเขียนโค้ดเป็นเพียงส่วนหนึ่งของงาน และการตรวจทานโค้ดก็สำคัญไม่แพ้กัน
  • รีวิวรอบที่ 1 : การตรวจเบื้องต้นโดย Claude
    • ตรวจหา ช่องโหว่ของ test coverage และบั๊กที่เห็นได้ชัด
    • เสนอแนวทางปรับปรุงเพื่อประหยัดเวลาของเพื่อนร่วมทีมในการรีวิว
  • รีวิวรอบที่ 2 : ผู้เขียนตรวจเอง
    • ตรวจสอบ ความสามารถในการบำรุงรักษา, สถาปัตยกรรม, ตรรกะทางธุรกิจ, และ ความเป็นเนื้อเดียวกับระบบ
    • แม้จะเป็นโค้ดที่ AI สร้างขึ้น แต่วิศวกรยังคงเป็นผู้ รับผิดชอบขั้นสุดท้าย
  • รีวิวรอบที่ 3 : การรีวิวตามปกติของทีม
    • ไม่มีใครรู้ว่าส่วนใดเป็นโค้ดที่ AI สร้าง ใช้ มาตรฐานคุณภาพเดียวกัน
    • สามารถตรวจทานอย่างเป็นกลางได้โดยไม่มี ความยึดติดทางอารมณ์
  • ความ ผูกพันทางอารมณ์กับโค้ดที่ AI เขียนลดลง จึงรีวิวได้อย่างเป็นกลาง
โฆษณา

การทดลอง Slack-Triggered Agent และระบบงานอัตโนมัติ

  • ทดลองนำร่อง เอเจนต์ที่เชื่อม Slack ด้วย Cursor: แก้ไข business logic แบบง่ายได้สำเร็จ แต่ล้มเหลวกับเลย์เอาต์ CSS ที่ซับซ้อน
  • ณ เวลานี้ยังมีข้อจำกัด เช่น ไม่รองรับ private NPM package, commit ที่ไม่มีลายเซ็น, การเลี่ยงระบบติดตามอย่างเป็นทางการ
  • ถึงอย่างนั้นก็ยังคาดหวังกับภาพอนาคตที่เอเจนต์จะจัดการตั๋วงานซ้ำ ๆ แบบง่ายในเวลากลางคืนได้

ค่าใช้จ่ายและ ROI

  • ค่าใช้งาน Claude Code เป็นเงินจำนวนไม่น้อยที่บริษัทจ่ายให้วิศวกร
  • แต่การลงทุนนั้นให้ผลตอบแทนด้านผลิตภาพ
    • ความเร็วในการปล่อยฟีเจอร์เพิ่มขึ้น 2~3 เท่า
    • จัดการหลาย development thread พร้อมกันได้
    • ไม่ต้องเขียนโค้ดซ้ำ ๆ หรือ boilerplate ด้วยตัวเองอีก
  • ในช่วงเริ่มต้นของการใช้ AI ควรมี งบประมาณ $1000~1500 ต่อเดือนสำหรับวิศวกรอาวุโส และคาดว่าความคุ้มค่าจะดีขึ้นเมื่อทักษะสูงขึ้น

ปัญหาและข้อจำกัดที่ยังคงมีอยู่ของการพัฒนาแบบมี AI ช่วย

  • ปัญหาด้านการเรียนรู้: AI ไม่สามารถเรียนรู้จากความผิดพลาดและจะทำความเข้าใจผิดซ้ำ ๆ ทางแก้คือการจัดทำเอกสารให้ครบถ้วนและเสริมคำสั่งที่ชัดเจน
  • ปัญหาด้านความน่าเชื่อถือ: AI มักส่งโค้ดที่ผิดด้วยความมั่นใจ จึงต้องตรวจสอบเสมอ โดยเฉพาะในส่วนที่เกี่ยวกับ state management ที่ซับซ้อน ประสิทธิภาพ และความปลอดภัย
  • ปัญหาข้อจำกัดด้านคอนเท็กซ์: codebase ขนาดใหญ่เกินหน้าต่างคอนเท็กซ์ของ AI จึงจำเป็นต้องแตกปัญหาเป็นหน่วยย่อยและให้คอนเท็กซ์ที่ชัดเจน

การเปลี่ยนแปลงทางความรู้สึกจากโค้ดไปสู่ปัญหา

  • ปล่อยวางความยึดติดกับโค้ด แล้วเปลี่ยนมาสู่ แนวคิดที่ยึดการแก้ปัญหาเป็นศูนย์กลาง
  • การลบโค้ดที่ผิดได้อย่างรวดเร็ว, การรีวิวที่เป็นกลางมากขึ้น, และ ภาระทางใจต่อการรีแฟกเตอร์ที่ลดลง => เป็นการเปลี่ยนแปลงเชิงบวก
  • หากมีเครื่องมือ AI ที่ดีกว่าออกมา ก็พร้อมจะเปลี่ยนทันที
  • แก่นสำคัญไม่ใช่ 'ตัวโค้ด' แต่คือ คุณค่าของปัญหาที่ต้องแก้
โฆษณา

คำแนะนำเรื่องการนำ AI มาใช้ในมุมมองวิศวกร

  • 1. เปิดให้ทดลอง AI หลายโซลูชัน: ทีมควรได้ลองใช้เครื่องมือต่าง ๆ ด้วยตัวเองเพื่อเพิ่มขีดความสามารถในการทำงานจริง
  • 2. เริ่มใช้ AI กับงานที่ซ้ำและง่ายก่อน: คาดหวังผลลัพธ์ได้เร็ว
  • 3. กันงบสำหรับการลองผิดลองถูก: เดือนแรกต้องยอมรับความสับสนวุ่นวาย
  • 4. ออกแบบกระบวนการรีวิวใหม่: เพิ่มการตรวจสอบให้เหมาะกับลักษณะของโค้ดจาก AI
  • 5. จัดทำเอกสารอย่างเข้มงวด: คอนเท็กซ์ที่ดีช่วยคูณผลิตภาพ
  • วิศวกรที่กำลังปรับตัวเข้าสู่เวิร์กโฟลว์ AI แบบใหม่ จะตระหนักว่ามี มีดเล่มใหม่ที่คมกริบ เพิ่มเข้ามาในกล่องเครื่องมือ
  • วิศวกรที่ยอมรับเวิร์กโฟลว์ AI จะ วิวัฒน์ไปสู่บทบาทใหม่ที่คอย orchestration เอเจนต์ AI หลายตัว พร้อมโฟกัสที่สถาปัตยกรรม การรีวิว และการแก้ปัญหาที่ซับซ้อน

ก้าวต่อไปของคุณ

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

บทความที่เกี่ยวข้อง

5 ความคิดเห็น

 
helio 2025-09-05

"ถ้าต้องเป็นขั้นตอนที่ซับซ้อนขนาดนี้ ก็คิดว่าสู้เขียนโค้ดเองน่าจะดีกว่า"
 
skageektp 2025-09-05

ท่าทีของหัวหน้าทีมที่ไม่สั่งงานสมาชิกในทีม แต่ลงมือจัดการเองเลย 5555
 
greenbhj 2025-09-05

เหมือนจะเป็นแบบนั้น แต่จริงๆ แล้วไม่ใช่เลย
ตลอด 6 เดือนที่ผ่านมาได้ลองทดลองแบบวนซ้ำทั้งขนาดเล็กและขนาดใหญ่มาแล้ว
 
iolothebard 2025-09-05

เลือกฟีเจอร์เล็ก ๆ ที่กำหนดขอบเขตไว้ชัดเจนสักหนึ่งอย่าง แล้ว
ให้ AI มีโอกาสสามครั้งในการนำฟีเจอร์นั้นไปพัฒนา และ
ลองตรวจทานผลลัพธ์เหมือนกับกำลังเมนเทอร์นักพัฒนามือใหม่
ถ้ามันทำได้โดยไม่ต้องมีฉันก็ถือว่า “คุ้ม” แต่ถ้ายังต้องมีฉันอยู่... งั้นให้ฉันทำเองเลยก็ “คุ้ม” กว่า
 
GN⁺ 2025-09-03
ความเห็นจาก Hacker News

  • รู้สึกว่าสิ่งสำคัญคือการสั่งงานโดยคำนึงถึงข้อจำกัดด้านการรับรู้ของเอเจนต์ เช่น ไม่ควรขอให้เปลี่ยนแปลงครั้งใหญ่ทันที แต่ควรวางแผนก่อน แล้วค่อยสั่งให้ทำทีละขั้นเล็ก ๆ พร้อมทดสอบแต่ละขั้นไปด้วย และในขั้นที่ซับซ้อนก็ควรให้มันเขียนโค้ดเพื่อทำให้ปัญหาและแนวทางแก้ไขมองเห็นได้ชัดขึ้น ถ้าล้มเหลวในขั้นไหนก็ควรเพิ่ม logging ลงในโค้ด บันทึก log แล้วทดสอบ จากนั้นตรวจดู log เพื่อหาสาเหตุและลองทำซ้ำเป็นวงรอบ วิธีนี้จะได้ผลดี นอกจากนี้ถ้าใช้แนวทางการออกแบบของโค้ดเดิมเพื่อให้โมเดลเข้าใจว่าควรแก้ตรงไหน ก็ช่วยไม่ให้ AI ยัดทุกอย่างรวมไว้ในไฟล์เดียวได้ เคยเห็นหลายคนแชร์ทิปพวกนี้ในบล็อกต่าง ๆ และแม้จะยังไม่สมบูรณ์แบบ แต่ประสบการณ์ก็ไม่ได้ออกมาไร้ประโยชน์ถึง 95%

    • ฉันลองสิ่งเหล่านี้มาหมดแล้ว แต่โค้ดที่ได้ส่วนใหญ่ก็ยังใช้การไม่ค่อยได้อยู่ดี และถึงจะทำงานพอใช้ได้ สุดท้ายก็มักต้องมานั่งแก้เองถึงจะเอาไปใช้ได้จริง บางครั้งมันก็ทำงานได้ดีมากจนรู้สึกตื่นเต้น แต่ส่วนตัวแล้วยังไม่ค่อยรู้สึกว่าประสิทธิภาพดีขึ้นมากนัก
    • สำหรับงานขนาดใหญ่และซับซ้อน รู้สึกว่าวิธีสั่งว่า "อย่าเพิ่งเขียนโค้ดตอนนี้ ผมจะอธิบายแต่ละขั้นอย่างละเอียด" ได้ผลดี เช่น ให้ภาพรวมเป็นลำดับขั้นอย่างการอ่าน input, การสร้าง candidate, การให้คะแนน candidate, การจัดลำดับความสำคัญและ sorting, การสร้างโครงสร้างข้อมูลผลลัพธ์, การบันทึกลง DB เป็นต้น Claude จะจัดขั้นเหล่านี้เป็นรายการ TODO และเอกสาร ทำให้ต่อยอดงานในครั้งถัดไปได้สะดวก จริง ๆ แล้วเคยทำงานไปหนึ่งชั่วโมงแล้วหยุด จากนั้นสั่งว่า “ให้สร้างโค้ดสำหรับสเตจที่เสร็จแล้วและใส่คอมเมนต์ไว้เพื่อมาต่อครั้งหน้า” ก็สามารถทำงานต่อเนื่องได้ง่าย
    • แม้จะใช้ LLM/เอเจนต์หลายตัวมานาน ก็ยังรู้สึกว่ายากที่จะได้ผลลัพธ์ที่มีประโยชน์ ถ้าอยากหลีกเลี่ยงผลลัพธ์ไร้สาระ ต้องใช้พลังกับการเขียนพรอมป์มากกว่าลงมือทำเองเสียอีก และยังต้องคอยระวังถ้อยคำ น้ำเสียง และไม่ให้เกิดการเชื่อมโยงที่ไม่ต้องการ จนรู้สึกกังวลไปเปล่า ๆ ถ้ามีเครื่องมือสำหรับจัดการ LLM prompt แบบที่คล้ายเฟรมเวิร์กฝั่งฟรอนต์เอนด์ก็คงดี อยากให้มันช่วยจัดโครงสร้าง prompt ทั่วไปหรือใส่ best practice เป็นค่าเริ่มต้น เพื่อให้เวลาค้นหาอะไรในโค้ด ออกแบบฟีเจอร์ใหม่ หรือเขียนเทสต์ จะได้คิดน้อยลงมาก
    • ถ้าต้องทำตามขั้นตอนที่ประณีตขนาดนี้ ฉันคิดว่าเขียนโค้ดเองไปเลยยังจะดีกว่า
    • พอลองทำโปรเจกต์ส่วนตัวด้วย AI และ vibe coding ก็พบว่าแนวทาง test-driven development เข้ากันกับ vibe coding ได้ดีมาก แนะนำให้แตกปัญหาออกเป็นหน่วยเล็ก ๆ ที่ทดสอบได้ แล้วให้ AI เขียน unit test ก่อน จากนั้นค่อยให้มันลงมือเขียนโค้ดจริง

  • รู้สึกว่าถึงเวลาแล้วที่บทความแนวนี้ควรมีตัวอย่างงานที่เป็นรูปธรรมจริง ๆ ว่า "เอเจนต์กระจายงานประมวลผล" อย่างไร ไม่ใช่แค่การรีแฟกเตอร์ธรรมดาหรือ React boilerplate มีคนบอกว่า Sanity มีฟีเจอร์ที่ถูกขอมานานและเอเจนต์ช่วยทำแบบขนานได้เยอะ แต่คำกล่าวทำนองว่า "โค้ด 80% ถูกเขียนโดยจูเนียร์ที่ไม่เรียนรู้อะไรเลย" ฟังแล้วยากจะเชื่อ

    • สำหรับฉัน คำว่า "จูเนียร์ที่ไม่เรียนรู้" เป็นคำเปรียบเทียบที่ผิด Claude ใกล้เคียงกับซีเนียร์ที่การศึกษาสูงแต่ไม่มีประสบการณ์ภาคปฏิบัติ รู้คำตอบจากเอกสารเป็นอย่างดี มีความรู้แบบสารานุกรมยอดเยี่ยม แต่ขาดเซนส์หน้างาน ช่วงหลังฉันใช้ Claude สร้าง commercial codebase แล้วพบว่าส่วนใหญ่ input จะเน้นไปที่ 'รสชาติของโค้ด' และนิยามของความสำเร็จ ขณะที่ตัวโค้ดเองเป็นเพียงของใช้ครั้งเดียว
    • ทั้งที่โค้ดจาก AI เพิ่มขึ้นเรื่อย ๆ แต่ในโลกโอเพนซอร์สก็ยังมี issue ค้างแก้เต็มไปหมด เรื่องนี้ช่างน่าประหลาดจริง ๆ
    • ถ้าแสดงตัวอย่างงานจริงที่มอบให้ AI พร้อมผลลัพธ์ให้เห็น ก็จะเปิดโอกาสให้ตั้งคำถามกับความคาดหวังที่เกินจริงได้ แต่ตอนนี้กลับมีแต่เรื่องเล่าว่า Claude Code ยอดเยี่ยมแค่ไหน โดยแทบไม่มีตัวอย่างใช้งานจริง
    • เวลาเห็นบล็อกเทคจากวิศวกรที่กลายเป็นสายเซลส์ ใช้คำอย่าง "learnings" แทน "lessons" ก็รู้สึกว่ามันสวนทางกับเส้นทางของฉันเอง ที่ยิ่งมีประสบการณ์พัฒนาเยอะขึ้นก็ยิ่งพึ่ง Google น้อยลง แล้วหันไปอ่านเอกสารตรง ๆ มากกว่า

  • ผู้เขียนบอกว่าผลิตภาพดีขึ้นก็จริง แต่ก็ยังพูดถึงข้อจำกัดที่คนมักวิจารณ์กันอยู่ครบ จนสุดท้ายเหมือนแทบไม่มีประเด็นใหม่ ฉันมั่นใจว่าไม่มีใครมอบหมายการพัฒนาฟีเจอร์หลักให้ Claude Code หรอก

  • การหลีกเลี่ยง boilerplate เป็นทั้งงานของนักพัฒนาและเป็น abstraction ที่ช่วยอำนวยความสะดวกให้ตัวเราในอนาคต ถ้าใช้ AI สร้าง boilerplate ขึ้นมา พอภายหลังต้องแก้ทุก instance ทีละจุดจะยิ่งลำบาก และถ้าโค้ด boilerplate ที่กระจายอยู่หลายที่ไม่สอดคล้องกัน ปัญหาก็จะหนักขึ้นอีก

    • เฟรมเวิร์กหรือเครื่องมือส่วนใหญ่ก็มีตัวสร้าง boilerplate อัตโนมัติอยู่แล้ว เลยสงสัยว่าการยอมเสีย token และค่าใช้จ่ายให้ AI มาทำเรื่องนี้ จะคุ้มค่ามากนักหรือไม่

  • ที่น่าสนใจคือคนนี้ใช้ AI ทำ implementation ขั้นพื้นฐาน แต่ฉันกลับทำตรงกันข้าม คือจะลงมือสร้างฐานก่อนด้วยตัวเองเสมอ เพื่อให้เข้าใจโครงสร้างและกลไกการทำงานอย่างแม่นยำ หลังจากนั้นค่อยให้ AI รับผิดชอบเฉพาะ boilerplate ที่ซ้ำ ๆ AI เก่งเรื่องทำตามแบบ แต่เปราะบางมากในเรื่องการออกแบบสถาปัตยกรรม

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

  • เงินเดือนพื้นฐานของนักพัฒนาก็แพงอยู่แล้ว แล้วยังจะต้องเพิ่มค่าใช้จ่ายเดือนละ 1,000-1,500 ดอลลาร์เพื่อปัญหาเล็กน้อยที่อาจช่วยให้ผลิตภาพดีขึ้นหรือไม่ก็ไม่รู้ ฟังดูน่าสงสัย อย่างน้อยหัวหน้าของฉันคงไม่ชอบแน่

    • บริษัทฮาร์ดแวร์ซื้อไลเซนส์เครื่องมือ EDA หลายตัวทุกปี ซึ่งแพงกว่าค่าแรงนักพัฒนาเสียอีก ถ้าผลิตภาพดีขึ้นอย่างเห็นได้ชัด 1,000 ดอลลาร์ก็แทบไม่ใช่เงินก้อนใหญ่เลย
    • ถ้าเงินเดือนนักพัฒนาแพงขนาดนั้น การไม่ลงทุนต่างหากที่ดูไม่สมเหตุสมผล ถ้า 1k-1.5k ดอลลาร์ต่อเดือนช่วยเพิ่มผลิตภาพได้อย่างชัดเจน การลังเลต่างหากที่ไม่มีประสิทธิภาพ และการมองเฉพาะต้นทุน AI แบบนี้ก็เป็นมุมมองที่ง่ายเกินไป ควรย้ำด้วยว่าถ้า AI ช่วยลดจำนวน developer ที่ต้องใช้ได้ นั่นก็คือผลประหยัดจริงเช่นกัน
    • ตัวฉันเองใช้ intellij pro AI ยังไม่ถึงเดือนละ 20 ดอลลาร์เลย เลยสงสัยว่า Claude จะแพงขนาดนั้นจริงหรือ ก็ไปหาข้อมูลดูแล้วพบว่ามันอาจเป็นไปได้ ไม่ว่าอย่างไร ความจริงก็คือค่าสมาชิก AI กำลังถูกเพิ่มเข้าไปในงบประมาณของใครสักคน และเหมือนกับที่บริษัทจ่ายค่าอินเทอร์เน็ตความเร็วสูงอยู่แล้ว ค่า AI ก็กำลังกลายเป็นต้นทุนพื้นฐานเช่นกัน
    • และต้องจำไว้ว่าราคานี้จริง ๆ แล้วตั้งอยู่บนเงินอุดหนุน
    • ฉันกำลังรอดูอย่างสนใจว่าบริษัทต่าง ๆ จะเปลี่ยนไปอย่างไร สิ่งที่ชัดเจนคือท้ายที่สุดแล้วประเด็นสำคัญอยู่ที่นักพัฒนาจะถูกประเมินด้วยเกณฑ์แบบไหน ความเสี่ยงที่จะเสียเปรียบในการประเมินผลงาน/การเลิกจ้างเพราะใช้ AI จะเพิ่มขึ้นหรือไม่ และจะพิสูจน์อย่างไรว่าเจ้าของผลงานตัวจริงคือเรา ไม่ใช่ LLM

  • ฉันยังไม่ค่อยเข้าใจวิธีใช้ MCP (Multi-Channel Processor) ที่กล่าวถึงในบทความ เพราะ Claude code ก็เรียกบริการ third-party แทบทุกอย่างผ่านเชลล์ด้วย curl หรือ gh ได้อยู่แล้ว แต่ถ้าใช้ MCP กลับอาจมีปัญหาได้ด้วยซ้ำ (เช่น linear MCP server จะตัด issue ถ้ายาวเกินไป แต่ถ้าเรียก API ตรงจะไม่มีข้อจำกัดนี้) เลยสงสัยว่าฉันพลาดอะไรไปหรือเปล่า

  • Anthropic ลงบทสัมภาษณ์กับ Boris Cherny (ผู้สร้าง Claude Code) ซึ่งแชร์ไอเดียเกี่ยวกับอนาคตของ agent coding และวิธีใช้งาน Claude Code ด้วย https://youtu.be/iF9iV4xponk

  • พอเห็นการพูดถึง "งบ $1000-1500/เดือน" ก็อดคิดไม่ได้ว่า หรือคนพูดอาจใช้แค่ API key และไม่รู้ว่ามีแพ็กเกจรายเดือนอย่าง claude MAX อยู่ด้วย เพราะถ้าเดือนละ $100~200 ตราบใดที่ไม่ได้ยิง query แบบไร้ทิศทางซ้ำไปซ้ำมา ก็น่าจะครอบคลุมได้สบาย

    • รู้สึกว่า $1k-1.5k เป็นตัวเลขที่แพงเกินไป แพ็กเกจ Max แบบ 20x ราคาเดือนละ $200 ก็ครอบคลุมปริมาณการใช้งานได้มากพอแล้ว และโควต้าจะรีเซ็ตทุก 5 ชั่วโมง ถึงอย่างนั้นถ้ายังใช้เกินลิมิตทุกวัน ระดับนั้นจ่ายแบบตาม token จริง ๆ อาจจะแพงกว่าเสียอีก

  • ถ้าคิดจะใช้ Claude หรือเอเจนต์อื่น ๆ ขอแนะนำอย่างแรงว่าต้องมี logging ถ้าใส่ log file ทั้งหมดเข้าไปให้ AI โอกาสที่จะช่วยสรุปปัญหา หรือนำทางไปสู่ขั้นตอนถัดไปจะสูงขึ้นมาก logging คือทุกสิ่งจริง ๆ