ปฏิทินของผู้นำอาจเต็มไปด้วยประชุม การอนุมัติ และเรื่องด่วน จนไอเดียจบลงที่เอกสารหรือคำสั่งให้ทีมไปลองทำ Hursh Agrawal เสนอว่า coding agent ช่วยให้เขากลับมาสร้างต้นแบบได้ แม้มีเวลาลงมือเป็นช่วงสั้น ๆ ระหว่างงานบริหาร
Hursh เป็น CTO และผู้ร่วมก่อตั้ง The Browser Company เขาเล่าวิธีทำงานในวิดีโอบนช่อง AI Engineer โดยมองการสร้างต้นแบบเป็นส่วนหนึ่งของงานผู้นำ ต้นแบบช่วยให้ทีมลองสิ่งที่เขาต้องการสื่อสารได้ ส่วนผลลัพธ์ในบทความนี้เป็นคำบรรยายของผู้ใช้ระบบ ไม่ใช่ผลทดสอบเปรียบเทียบที่ตรวจสอบแยกต่างหาก
workflow ที่เขาอธิบายให้ AI รับงานลงมือทำ ขณะที่มนุษย์ให้เป้าหมาย ใส่บริบท ตัดสินใจเรื่อง trade-off และตรวจงานก่อนนำไปใช้จริง
เปลี่ยนมุมมองจากผู้สั่งงาน เป็นผู้นำที่สร้างต้นแบบ
Hursh รายงานว่าตารางของเขามีประชุมประจำมากกว่า 15 ครั้งต่อสัปดาห์ มีผู้รายงานตรง 7 คน และในช่วงที่เล่าบทบรรยายนี้เขาส่งงานพัฒนาได้ 2 ถึง 10 PR ต่อสัปดาห์ เขาเชื่อมความเปลี่ยนแปลงนี้กับการใช้ coding agent รับงานยาว ตัวเลขเป็นผลที่เขารายงานเอง ไม่ใช่เป้าหมายที่ทุกทีมจะได้ตาม
ตัวอย่างประยุกต์สำหรับธุรกิจไทยคือการเลือกสร้างของจริงขนาดเล็ก เช่น หน้าเสนอขาย ระบบสรุปคำถามลูกค้า dashboard สำหรับทีมขาย หรือ flow คัดกรองลีด โดยต้องเลือกงานให้ตรงกับทักษะและเครื่องมือของทีม ตัวอย่างเหล่านี้เป็นข้อเสนอของบทความ ไม่ใช่กรณีศึกษาที่ Hursh นำเสนอ
Hursh ให้น้ำหนักกับบริบทที่ผู้นำมี เช่น เป้าหมายธุรกิจ ข้อจำกัด สิ่งที่ทีมเคยลอง และ trade-off ที่ยอมรับได้ การให้ข้อมูลเหล่านี้เป็นส่วนหนึ่งของวิธีที่เขาใช้กำกับ agent แทนการสั่งงานแบบกว้าง ๆ
ใช้งาน AI ด้วยตัวเอง เพื่อรู้ว่า model ทำอะไรได้จริง
Hursh อธิบายว่าความสามารถและการตอบสนองต่อ prompt ของแต่ละ model เปลี่ยนไปตามรุ่น เขาจึงเลือกใช้งานด้วยตัวเองเพื่อเรียนรู้ขอบเขตของมัน แทนการตัดสินใจจากกระแสหรือความเห็นเพียงอย่างเดียว
ในมุมของเขา เวลา hands-on ช่วยให้ผู้นำแปลงความเข้าใจเรื่อง model เป็นทิศทางให้ทีม และสร้างต้นแบบที่ทีมทดลองได้เพื่อสื่อสารสิ่งที่เป็นไปได้
ตัวอย่างประยุกต์: ร้านค้าหลายสาขาอาจเลือกคำถามลูกค้าหลายเคสมาทำต้นแบบให้ AI ร่างคำตอบภายใต้เงื่อนไขที่ชัดเจน เช่น ใช้ข้อมูลสินค้าที่มี ส่งต่อพนักงานเมื่อเจอเรื่องคืนเงิน และใช้โทนภาษาของแบรนด์ จากนั้นให้คนตรวจผลก่อนตัดสินใจลงทุนต่อ ไม่ถือว่าต้นแบบนี้ผ่านเพียงเพราะได้คำตอบในครั้งแรก
ข้อสังเกตสำคัญ: การทดลองเองไม่ได้แปลว่าผู้บริหารต้องแทรกงานทีมทุกเรื่อง แต่เป็นการสร้าง intuition ที่ทำให้ตั้งคำถามได้ถูกจุด และเลือกโจทย์ที่คุ้มกับธุรกิจมากขึ้น
เลือกงานต้นแบบ 4 แบบ และอย่าแตะงานวิกฤต
Hursh สรุปงานต้นแบบที่เหมาะกับผู้นำเป็น 4 กลุ่ม ตัวอย่างงานธุรกิจในรายการต่อไปนี้เป็นข้อเสนอประยุกต์ของบทความ
- เครื่องมือภายใน: เช่น ระบบสรุปเคสลูกค้าจากแชต ระบบจัดหมวดเอกสาร หรือรายงานยอดขายรายวัน
- งานปรับคุณภาพชีวิต: ลดงานจุกจิกที่สร้างความหงุดหงิด เช่น แบบฟอร์มรับบรีฟที่ข้อมูลไม่ครบ หรือการค้นหาข้อมูลกระจัดกระจาย
- ชิ้นงานเพื่อยกย่องทีม: เช่น สรุปผลงานทีมรายเดือน หรือหน้ารวบรวมคำชมจากลูกค้าเพื่อใช้ในการประชุมทีม
- ต้นแบบเชิงวิสัยทัศน์: ทดลองว่า AI ทำให้สินค้า บริการ หรือประสบการณ์ลูกค้าเปลี่ยนไปอย่างไร
Hursh ให้น้ำหนักกับต้นแบบเชิงวิสัยทัศน์ และแนะนำว่าอย่ารับงานที่อยู่บน critical path เพราะตารางของผู้นำอาจถูกขัดด้วยเรื่องด่วนหรือประชุม เมื่อประยุกต์กับธุรกิจ จึงควรเลือกงานที่หยุดหรือแก้ไขได้โดยไม่ทำให้การดำเนินงานหลักขึ้นกับต้นแบบนั้น
ข้อเสนอในการทดลองคือจำกัดผลกระทบด้วยข้อมูลตัวอย่าง บัญชีทดสอบ หรือกลุ่มพนักงานภายใน พร้อมกำหนดผู้ตรวจผลก่อนนำไปใช้กับลูกค้า
จัดตารางแบบ Overnight Loop
workflow ที่นำไปใช้ได้จริงไม่จำเป็นต้องกินเวลาทั้งวัน Hursh แบ่งวันออกเป็น 3 ช่วง คือ ช่วงเช้าเพื่อทบทวนงานที่ AI ทำไว้ ช่วงสั้นระหว่างวันเพื่อคอยให้ทิศทาง และช่วงท้ายวันเพื่อเตรียมงานยาวให้ agent ทำต่อ
- ช่วงเช้า: อ่านรายงาน ตรวจสิ่งที่ AI ทำ และทดสอบผลลัพธ์ก่อนเลือกว่าจะรับ แก้ หรือหยุดงาน
- ระหว่างวัน: ใช้ช่วงสั้นระหว่างประชุมให้ทิศทาง เติมข้อมูล หรือเก็บ feedback
- ช่วงท้ายวัน: รวบรวมบริบท กำหนดผลลัพธ์และเกณฑ์ตรวจสอบ แล้วเตรียมงานให้ agent ทำต่อ โดยตัวอย่างของ Hursh ใช้ช่วงประมาณ 5 โมงเย็น
ตัวอย่างประยุกต์สำหรับงานธุรกิจคือวิเคราะห์ไฟล์ยอดขาย สรุปเสียงลูกค้า ร่างแผนแคมเปญ หรือจัดโครงเอกสาร SOP หากเครื่องมือรองรับงานต่อเนื่อง สิ่งที่ต้องเตรียมคือโจทย์และขอบเขตข้อมูลที่ครบพอ พร้อมแผนตรวจผล ไม่ใช่เพียงคำสั่งสั้น ๆ ว่า “ช่วยวิเคราะห์ยอดขายให้หน่อย”
ให้ context มากกว่าสั่งเป็นรายการงาน
Hursh เปลี่ยนจากการแตกงานแล้วสั่งทีละขั้น มาพิจารณาว่า agent ต้องรู้อะไรบ้างจึงจะตัดสินใจในทิศทางเดียวกับเขา โดยเฉพาะงานที่ทำต่อหลายชั่วโมงโดยไม่มีคนคอยตอบ
บริบทที่เขาให้รวมถึงปัญหาที่ต้องแก้ เป้าหมายธุรกิจ สิ่งที่เคยลอง สิ่งที่ได้ผลหรือไม่ได้ผล และ trade-off ที่ต้องพิจารณา รายการด้านล่างเป็นโครง prompt ที่บทความเสนอให้ปรับกับงานธุรกิจ
ตัวอย่างโครงสร้าง prompt สำหรับงานธุรกิจ
- เป้าหมาย: ต้องการผลลัพธ์อะไร และวัดผลจากอะไร
- ผู้ใช้: ใครจะใช้ มี pain point แบบไหน
- ข้อมูลอ้างอิง: เอกสารเดิม ตัวอย่างงานเก่า FAQ feedback หรือข้อมูลยอดขาย
- ข้อจำกัด: งบ เวลา โทนแบรนด์ นโยบายข้อมูล และสิ่งที่ห้าม AI ตัดสินใจเอง
- เกณฑ์ตรวจ: AI ต้องตรวจอะไรบ้างก่อนส่ง และต้องรายงานเรื่องใดกลับมา
- รูปแบบผลลัพธ์: เช่น ตารางสรุป ข้อเสนอ 3 ทางเลือก ไฟล์ร่าง หรือรายการงานที่จัดลำดับแล้ว
Hursh เชื่อมวิธีนี้กับทักษะมอบหมายงานให้คน ได้แก่ ตั้งเป้าหมาย ให้บริบท และติดตามผล โครง prompt ข้างต้นเป็นวิธีจัดข้อมูลเหล่านี้ให้ตรวจสอบได้ ไม่ใช่สูตรที่รับประกันว่า agent จะตัดสินใจถูกทุกครั้ง
บังคับให้ AI ตรวจงานก่อนส่ง และให้มนุษย์ตรวจอีกชั้น
Hursh พบว่า model ช่วยลงมือทำได้ แต่การเลือกแนวทางยังต้องอาศัยคนกำกับ เช่น เมื่อ agent บอกว่าโจทย์ทำไม่ได้ เขาอาจเสนออีกวิธีให้ลอง หน้าที่ของคนใน workflow นี้จึงรวมถึงตรวจการตัดสินใจและผลลัพธ์ด้วย
สำหรับงานพัฒนาระบบ Hursh แนะนำให้ agent เขียน test ก่อนสร้างฟีเจอร์ ตรวจ flow แบบ end-to-end แยก PR ให้อ่านง่าย จัดการ CI และให้ AI reviewer ตรวจซ้ำ สำหรับงานธุรกิจ รายการต่อไปนี้เป็นข้อเสนอเกณฑ์ตรวจที่ทีมเลือกใช้ได้ตามความเสี่ยง
- คำตอบอ้างอิงข้อมูลที่มีจริงหรือไม่
- มีข้อมูลส่วนบุคคลหรือข้อมูลลับหลุดออกมาหรือไม่
- ข้อเสนอขัดกับนโยบายราคา การคืนสินค้า หรือคำสัญญาแบรนด์หรือไม่
- มีเคสที่ AI ควรส่งต่อให้พนักงานตัดสินใจหรือไม่
- ผลลัพธ์ถูกทดสอบกับเคสจริงที่หลากหลายแล้วหรือไม่
Hursh ย้ำให้อ่านและตรวจโค้ดก่อนส่งต่อให้คนอื่นรีวิว เมื่อประยุกต์กับเอกสาร แผนแคมเปญ หรือคำตอบลูกค้า เจ้าของงานก็ควรตรวจผลลัพธ์ในส่วนที่ตนรับผิดชอบก่อนส่งต่อ
ใช้ feedback ปรับ AI feature แบบเป็นวงจร
วิธีที่ Hursh ใช้กับ AI feature คือเพิ่มปุ่ม feedback และช่องข้อความ แล้วเก็บแต่ละรอบพร้อม input, system prompt และคำวิจารณ์ เพื่อใช้ตั้งเกณฑ์ประเมินรอบต่อไป
เขายกตัวอย่างการรวบรวม feedback ประมาณ 10 ถึง 30 เคส แล้วให้ agent ช่วยสร้าง eval set และพูดคุยเพื่อออกแบบเกณฑ์คะแนน ตัวอย่างจำนวนนี้เป็นชุดเริ่มต้นใน workflow ที่เขาเล่า ไม่ได้พิสูจน์ว่าคุณภาพจะดีขึ้นหรือครอบคลุมผู้ใช้ทุกกลุ่ม
ตัวอย่างประยุกต์: ทีมขายที่ใช้ AI ร่างคำตอบลีดอาจเก็บ feedback ว่า “ถามข้อมูลซ้ำ” “ภาษาดูแข็ง” หรือ “เสนอสินค้าผิดกลุ่ม” พร้อมเหตุผลและตัวอย่าง แล้วใช้ข้อมูลนี้กำหนดเกณฑ์ตรวจ prompt รอบถัดไป แทนการดูเฉพาะคะแนนบนข้อมูลเดิม
Hursh กล่าวถึงความเสี่ยง overfitting เมื่อมีข้อมูลน้อย ข้อเสนอของบทความคือกันตัวอย่างบางส่วนไว้ตรวจผล และทดลองกับสถานการณ์ที่ไม่ได้ใช้ปรับ prompt การสั่งว่า “อย่า overfit” เพียงอย่างเดียวไม่ได้เป็นหลักฐานว่าปัญหานี้หมดไป
สร้างรั้วความปลอดภัยก่อนขยายขอบเขตงาน
Hursh ระบุว่าการทำงานข้ามคืนของเขาอาศัยระบบรองรับที่มีอยู่ เช่น AI code reviewer, คำแนะนำ agent ที่จัดระเบียบไว้, CI, feature flags และ prototype branch สำหรับพนักงาน เขายอมรับด้วยว่าโค้ดของตนเคยทำให้เกิด incident จึงไม่ควรอ่านแนวทางนี้เป็นการรับประกันความปลอดภัย
ข้อเสนอประยุกต์สำหรับทีมที่ยังไม่มีระบบรองรับครบคือเริ่มจากขอบเขตเล็ก แยกข้อมูลทดลอง กำหนดสิทธิ์ที่จำเป็น มีบัญชีทดสอบและผู้อนุมัติก่อนเผยแพร่ พร้อมทางย้อนกลับเมื่อผลผิดพลาด แล้วค่อยขยายงานตามผลที่ตรวจได้
อ้างอิง Prototyping as Leadership: How a CTO Ships with AI Agents — Hursh Agrawal, The Browser Company โดย Hursh Agrawal บนช่อง AI Engineer วิดีโอเผยแพร่วันที่ 20 สิงหาคม 2026 ข้อมูลวันที่นี้เป็นวันอัปโหลด ไม่ใช่วันจัดงาน คำบรรยายที่บันทึกไว้ครอบคลุมช่วง 00:13–17:56 จากวิดีโอความยาว 18:18 โดยไม่ใช้ตำแหน่งเวลาท้ายยืนยันว่ามีคำบรรยายครบทุกวินาที
