สตาร์ทอัปนี้เก็บ Claude และ Codex ไว้ แล้วส่งงานเอกสารให้ AI ในเครื่อง

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

Grayhat Developers บริษัทซอฟต์แวร์ที่มีคนไม่ถึง 40 คน เล่าสิ่งที่เกิดขึ้นเมื่อแยกงานเหล่านั้นในเอกสารก่อนตีพิมพ์วันที่ 5 พฤศจิกายน 2026 วิศวกรลองใช้โมเดลที่โฮสต์เองสำหรับงานพัฒนา และพบว่าการแทนเอเจนต์เขียนโค้ดเชิงพาณิชย์ทำให้งานบางอย่างในคลังโค้ดช้าลงหรือยากขึ้น จึงเก็บเอเจนต์เดิมไว้สำหรับงานซับซ้อน แล้วนำงานค้นเอกสาร เตรียมข้อมูล และซิงก์ทิกเก็ตบางส่วนไปให้บริการในเครื่อง

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

การแก้บั๊กมีต้นทุนรวบรวมบริบทก่อนแตะโค้ด

Grayhat ใช้ Outline ทำเอกสาร Plane ติดตามงาน และ ERPNext เก็บข้อมูลองค์กร ทีมวางบริการเหล่านี้บนเครื่องในสำนักงานและเชื่อมระบบตัวตนผ่าน Authentik เครื่องเดียวกันโฮสต์ตัวเชื่อมต่อ Model Context Protocol หรือ MCP ด้วย ส่วนเครื่องที่สองรันการอนุมานของโมเดล เหตุผลที่แยกเป็นเรื่องการใช้งานจริง ระบบเอกสารและทิกเก็ตให้บริการหน้าจอตามปกติได้ขณะงานโมเดลใช้ทรัพยากรประมวลผลบนอีกเครื่อง

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

จุดส่งต่องานในกระบวนการของ Grayhat ภาพต้นฉบับโดย Telli.sh อิงกรณีศึกษาวันที่ 5 พฤศจิกายน

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

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

ทีมซื้อกำลังประมวลผลและประเมินว่าย้ายงานได้เท่าไร

ผู้เขียนรายงานฐานค่าใช้จ่าย AI เชิงพาณิชย์ราว 325 ดอลลาร์สหรัฐต่อเดือน แบ่งเป็นประมาณ 175 ดอลลาร์สำหรับ Claude เจ็ดที่นั่ง 140 ดอลลาร์สำหรับ Codex เจ็ดบัญชี และเครดิต 10 ดอลลาร์ อีกตัวเลขคือโทเคนที่บันทึกได้กว่า 25.93 พันล้านโทเคนจากบริการเหล่านี้ เอกสารไม่ได้ยืนยันว่าโทเคนที่บันทึกอยู่ในรอบบิลเดียวกับค่าใช้จ่าย 325 ดอลลาร์ ใช้แต่ละตัวเลขตามสิ่งที่มันวัด เพราะการหารสองตัวเลขเพื่อหาต้นทุนต่อโทเคนจะขาดข้อมูลเรื่องช่วงเวลา

ทีม Grayhat ประเมินว่าการถ่ายโอนบริบท ทำเอกสาร และประสานงานโครงการคิดเป็น 30–40% ของภาระงาน AI เชิงพาณิชย์ ผู้เขียนคาดว่าระบบในเครื่องรับได้ประมาณ 90% ของงานกลุ่มนี้ คูณสัดส่วนจะได้ 27–36% ของงานเชิงพาณิชย์ทั้งหมด เมื่อเทียบสัดส่วนกับฐาน 325 ดอลลาร์ จะได้ประมาณ 88–117 ดอลลาร์ต่อเดือน ตัวเลขเป็นการประเมินสัดส่วนงานและค่าใช้จ่ายเทียบเท่าจากกรณีศึกษาวันที่ 5 พฤศจิกายน เอกสารไม่ได้ทดลองเปรียบเทียบบิลก่อนและหลังแบบควบคุมตัวแปร

ประมาณการของ Grayhat เริ่มจากสัดส่วนงานและจบที่ค่าใช้จ่ายเทียบเท่า ภาพต้นฉบับโดย Telli.sh

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

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

หน้าจอที่สองเปลี่ยนคนรับผิดชอบการตั้งค่า

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

หน้าจอที่สองของ Grayhat ตั้งค่าเครื่องมือทำงานจากส่วนกลาง ภาพที่ 2 จาก “Create Your Own Work Stack” โดย Saad Ahmed Bazaz, Talha Amjad, Abdurrehman Subhani, Sohaib Ahmed Bazaz และ Abdullah Aamir ภายใต้ CC BY 4.0.

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

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

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

ให้ระบบในเครื่องทำงานที่มีเจ้าของผลลัพธ์ชัดเจน

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

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

การเขียนโค้ดซับซ้อนเป็นตัวอย่างกลับกัน การย้ายฐานข้อมูลอาจต้องดูสัญญาข้อมูลในอดีต แก้หลายบริการ และตรวจการย้อนกลับ Grayhat พบว่าระบบในเครื่องที่ทดลองติดขัดกับงานคลังโค้ดขนาดใหญ่ โดยเฉพาะเมื่อโมเดลต้องอ่านบริบทกว้างและตอบทันเวลา กรณีศึกษาระบุฮาร์ดแวร์ โมเดล และประสบการณ์ของทีม จึงมีเหตุผลให้ลองกับภาระงานของคุณเองก่อนขยายสิ่งที่มอบหมาย

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

การทดลองสั้น ๆ ช่วยแยกงานที่มีประโยชน์จากภาระดูแลระบบ

1. กำหนดผลลัพธ์สามชิ้น เลือกสรุปทิกเก็ตที่มีลิงก์ การแก้เอกสาร และปัญหาฉบับร่าง เขียนหนึ่งประโยคต่อชิ้นว่าใครรับและต้องมีหลักฐานอะไร เก็บตัวอย่างที่ไม่ผ่านคู่กับตัวอย่างที่ดี รวมถึงข้อผิดพลาดที่มองข้ามง่าย
2. วัดเส้นทางปัจจุบัน นับตัวอย่างที่ทำสำเร็จ การแก้สำคัญ และเวลาค้นบริบทในสัปดาห์ทำงานปกติหนึ่งสัปดาห์ แยกบันทึกการใช้บริการเชิงพาณิชย์ตามกระบวนการเท่าที่ทำได้ จดว่าการย้ายงานทำให้จำนวนที่นั่งหรือค่าใช้เกินเปลี่ยนจริงไหม และแยกจดงานที่ทีมไม่ต้องทำเลย
3. เชื่อมเครื่องมือภายในหนึ่งตัว เริ่มจากสิทธิ์อ่านและโครงการที่ระบุชื่อ ยืนยันว่าพนักงานที่มีสิทธิ์ดึงปัญหาที่รู้จักได้ ส่วนคนนอกโครงการเข้าถึงไม่ได้ จำกัดผู้ทดลองไว้ที่กลุ่มเล็กซึ่งทำงานที่เลือกอยู่แล้ว ให้มีทางทำมือจนเสร็จเมื่อเครื่องมือล้มเหลว
4. เทียบร่างก่อนให้สิทธิ์เขียน ให้ผู้ตรวจคนเดิมรับหรือปฏิเสธตามเกณฑ์เดียวกัน บันทึกลิงก์ผิดปัญหา ข้อมูลหมดอายุ และข้อสรุปไร้หลักฐาน เพิ่มการดูตัวอย่าง การอนุมัติ และบันทึกที่เก็บได้นาน ก่อนให้ผู้ช่วยแก้ระบบติดตามงานจริง
5. ตรวจว่างานอะไรย้ายไปจริง เปรียบเทียบงานที่รับได้ เวลาตรวจ การใช้งานจริง และใบแจ้งหนี้ รวมเวลาบำรุงเครื่อง เวลาหยุดให้บริการ และการแก้ตัวเชื่อม รวมถึงความช่วยเหลือที่ให้ผู้ใช้โดยตรง แอปที่ใช้ได้หลังผู้เชี่ยวชาญสอนทีละคนสิบนาทียังมีต้นทุนการเริ่มใช้

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

ภาคผนวกของ Grayhat ให้ขนาดอ้างอิงสำหรับการเทียบ เครื่องมือใช้หน่วยความจำระบบ 16 GB ส่วนเครื่องอนุมานแยกมี 32 GB และ RTX 4080 ที่มี VRAM 16 GB ทีมรายงานว่าเพิ่มการเฝ้าดูเครือข่าย การจัดเวลา และเครื่องสำรองไฟเมื่อเห็นความต้องการด้านปฏิบัติการ เป็นข้อมูลที่ใช้จัดงบทดลองได้ เพราะแสดงสิ่งที่ต้องทำเพื่อรันบริการที่เพื่อนร่วมงานพึ่งพา นอกเหนือจากค่าให้โมเดลตอบ

เลือกว่า AI ควรใช้ชั่วโมงถัดไปกับงานไหน

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

แหล่งข้อมูล

• เอกสารก่อนตีพิมพ์ของ Grayhat Developers วันที่ 5 พฤศจิกายน 2026
• เอกสารฉบับเต็มพร้อมประมาณการภาระงาน โครงสร้างพื้นฐาน และภาพที่ 2
• ภาพต้นฉบับของภาพที่ 2
• สัญญาอนุญาต CC BY 4.0 สำหรับภาพในเอกสาร

---

หากต้องการเก็บบทสนทนาเบื้องหลังการส่งต่องานในแบบที่ค้นหาได้ สร้างบัญชี Telli.sh