WU Web Camp 2026
โมเดลพูดได้อย่างเดียว สิ่งที่ทำให้มันอ่านโค้ด แก้ไฟล์ และรันคำสั่งได้จริงคือชั้นที่ห่อมันอยู่ — deck นี้เปิดกล่องนั้นดู แล้วลงมือใช้
Section 01
เปิดกล่องดูว่าข้างในมีอะไร ก่อนจะไปเถียงกันว่าตัวไหนดีกว่าตัวไหน
recap
โมเดลทำได้อย่างเดียวคือรับข้อความเข้าไป แล้วส่งข้อความออกมา นอกจากนั้นไม่มีอะไรเลย
อ่านไฟล์
เปิดไฟล์ในเครื่องเราเองไม่ได้ ต้องมีคนหยิบมาวางให้
รันคำสั่ง
พิมพ์คำสั่งลงเทอร์มินัลไม่ได้ ได้แค่บอกว่าอยากรันอะไร
ความจำ
จบรอบแล้วลืมหมด สิ่งที่จำได้คือสิ่งที่มีคนป้อนกลับเข้าไปใหม่
ทุกอย่างที่ agent ทำได้ — เปิดไฟล์ แก้โค้ด รันเทสต์ — ไม่มีอันไหนที่โมเดลทำเอง
Everything that isn’t the model itself.
anatomy
Loop
วนซ้ำจนกว่างานจะจบ
Tools
มือที่ลงมือทำจริง
Context
เลือกว่าอะไรถูกส่งเข้าโมเดล
Permissions
ด่านตรวจก่อนแตะของจริง
Memory
สิ่งที่ยังอยู่เมื่อขึ้นรอบใหม่
the loop
คำว่า agent ต่างจาก chatbot ตรงนี้ที่เดียว — มันเห็นผลของสิ่งที่ตัวเองทำ แล้ววนกลับไปคิดต่อได้
รอบเดียวไม่จบ
งานจริงหนึ่งงานกินหลายสิบรอบ เราเห็นแค่ผลสุดท้าย
มันแก้ตัวเองได้
รันเทสต์ไม่ผ่าน มันอ่าน error แล้ววนกลับไปแก้ต่อ
คำถามที่ยากที่สุด
“พอหรือยัง” — จุดที่ harness แต่ละตัวตัดสินใจไม่เหมือนกัน
who does what
เวลามันจะแก้ไฟล์ สิ่งที่โมเดลส่งออกมาคือ “คำขอ” ไม่ใช่การลงมือ harness เป็นคนรับคำขอนั้นไปตรวจ แล้วค่อยทำ
โมเดลไม่ได้ลบไฟล์ของคุณ มันแค่ขอให้ลบ — คนที่ตัดสินคือ harness และกล่องขออนุญาตที่โผล่มาหาคุณ
context
context window ไม่ได้ทำงานแบบ “ยังไม่เต็มก็ยังดีอยู่” — งานวิจัยปี 2026 วัดได้ว่าความแม่นยำตกลงตามความยาว ทั้งที่ข้อมูลที่ต้องใช้ยังอยู่ครบทุกตัว
13–85%
ช่วงที่ความแม่นยำตกลง เมื่อ context ยาวขึ้น (วัดข้ามหลายโมเดล)
อาการนี้มีชื่อว่า context rot — และมันคือเหตุผลว่าทำไม “คุยยาว ๆ ในห้องเดิม” ถึงได้ผลแย่ลงเรื่อย ๆ
Section 02
ของที่มีให้ใช้ตอนนี้ ต่างกันตรงไหนจริง ๆ — และเลือกยังไงไม่ให้ต้องเลือกใหม่ทุกไตรมาส
the harness effect
เวลาเราเถียงกันว่า “ตัวไหนเก่งกว่า” เรามักคิดว่ากำลังเทียบโมเดล — ทั้งที่จริงกำลังเทียบชั้นที่ห่อมันอยู่ งานวิจัยปี 2026 วัดเรื่องนี้ด้วยการล็อกโมเดลไว้ตัวเดียว แล้วเปลี่ยนแค่ harness
10–20
จุด — ช่วงคะแนนที่ต่างกันบน benchmark ชุดเดียวกัน
โมเดลตัวเดียวกัน โจทย์ชุดเดียวกัน เปลี่ยนแค่ชั้นที่ห่อมันอยู่
1
ตัวแปรเดียวที่เปลี่ยน
จนมีงานวิจัยเรียกร้องว่า อย่าเอา agent มาเทียบกัน ถ้าไม่บอกว่าใช้ harness อะไร
the landscape
อยู่ในเทอร์มินัล
เปิดในโฟลเดอร์โปรเจกต์แล้วคุยกันตรงนั้น เห็น diff ทุกไฟล์ก่อนรับ
ฝังอยู่ในโปรแกรมเขียนโค้ด
อยู่ข้างไฟล์ที่เรากำลังเปิด เห็นโค้ดกับผลลัพธ์พร้อมกันในจอเดียว
รันบนคลาวด์ ส่งงานทิ้งไว้
มอบงานแล้วปิดจอไปทำอย่างอื่น กลับมาอ่านผลทีหลัง — เหมาะกับงานที่นิยามชัดแล้วเท่านั้น
September 2026
เจ็ดตัวนี้ใช้ห้าชิ้นส่วนเดียวกันหมด — ต่างกันที่ว่าใครประกอบมาให้แล้ว และใครปล่อยให้เราประกอบเอง
ตัวที่ประกอบมาให้ครบที่สุด แลกกับการผูกอยู่กับโมเดลเจ้าเดียว
จุดเด่น
จุดด้อย
เหมาะกับคนที่อยากได้ของที่ใช้ได้ทันทีและมีด่านกันพลาดครบ — รวมถึงห้องเรียนนี้
ตัว client เปิดโค้ด แต่โมเดลล็อกอยู่กับ GPT — เร็วและตั้งค่าน้อย
จุดเด่น
จุดด้อย
เหมาะกับคนที่อยากเริ่มเร็วโดยไม่ต้องเลือกอะไรเยอะ และอยู่กับ ecosystem ของ OpenAI อยู่แล้ว
ขั้วตรงข้ามของสองตัวแรก — เปิดทั้งระบบ และไม่ผูกกับโมเดลเจ้าไหนเลย
จุดเด่น
จุดด้อย
เหมาะกับคนที่ต้องการอิสระเรื่องโมเดล ความเป็นส่วนตัว หรืออยากแก้ตัว harness เอง
harness ที่บางที่สุดในห้า — system prompt ~200 โทเคน เทียบกับ ~10,000 ของ Claude Code
จุดเด่น
จุดด้อย
เหมาะกับคนที่อยากเห็นเครื่องยนต์เปล่า ๆ และคุมทุกอย่างเอง — ไม่ใช่มือใหม่
เอา Pi มาใส่ทุกอย่างกลับเข้าไป — เหมือนต่อสาย IDE เข้ากับ agent ทั้งชุด
จุดเด่น
จุดด้อย
เหมาะกับคนที่ใช้ agent จนชนเพดานของตัวสำเร็จรูปแล้ว และรับความไม่นิ่งได้
คนละทรงกับห้าตัวก่อนหน้า — ไม่ได้อยู่ในเทอร์มินัล แต่เป็นโปรแกรมเขียนโค้ดที่มี agent อยู่ข้าง ๆ ตลอด
จุดเด่น
จุดด้อย
เหมาะกับคนที่ต้องรีแฟกเตอร์ข้ามหลายสิบไฟล์ หรืออ่านโค้ดที่ไม่คุ้นเป็นงานประจำ
ตัวที่เข้าไปอยู่ใน editor ที่คุณใช้อยู่แล้ว — เริ่มง่ายที่สุดในเจ็ดตัว
จุดเด่น
จุดด้อย
เหมาะกับคนที่เขียนโค้ดใหม่และแก้บั๊กเป็นหลัก และอยู่กับ GitHub อยู่แล้ว
how to choose
มันเห็นโปรเจกต์จริงของเราไหม
ถ้ามันอ่านโค้ดเดิมไม่ได้ มันก็เขียนของใหม่ที่ไม่เข้ากับของเดิม
เราเห็นทุกอย่างที่มันแก้ก่อนรับไหม
ไม่มี diff ให้ดู = เรารับผิดชอบโค้ดที่เราไม่เคยอ่าน
โค้ดอยู่ในเครื่องเราและใน git ของเราไหม
ถ้าย้ายออกมาไม่ได้ อย่าเอามาทำงานที่ต้องดูแลยาว
Section 03
ตั้งแต่ยังไม่ได้พิมพ์อะไรเลย จนถึงรับงานชิ้นแรกเข้า git
getting started
01
ติดตั้ง
ลงตัวที่เลือกไว้ตามเอกสารของมัน ขั้นนี้ไม่มีอะไรให้คิด
02
ล็อกอิน
ผูกกับบัญชีที่มีสิทธิ์ใช้โมเดล ยังไม่ต้องจ่ายก็เริ่มได้
03
เปิดในโฟลเดอร์โปรเจกต์
cd เข้าไปในโปรเจกต์ก่อนเปิดเสมอ — มันเห็นได้แค่ที่ที่เราเปิดมันขึ้นมา
ข้อสามคือข้อที่คนพลาดบ่อยที่สุด — เปิดผิดที่ มันจะมองไม่เห็นโค้ดของคุณเลยสักไฟล์
read the screen
คำสั่งที่เราพิมพ์
สิ่งเดียวในจอที่เราคุมได้ร้อยเปอร์เซ็นต์
เครื่องมือที่มันเรียก
อ่านไฟล์ไหน รันคำสั่งอะไร — บรรทัดนี้บอกว่ามันกำลังทำอะไรอยู่จริง
diff
บรรทัดที่เพิ่ม บรรทัดที่หาย คือของที่เรากำลังจะรับเข้าโปรเจกต์
กล่องขออนุญาต
จุดเดียวที่เราหยุดมันได้ก่อนมันแตะของจริง — อ่านก่อนกด
permissions
ทุก harness มีสเกลเดียวกัน ต่างกันแค่ชื่อเรียก เลือกให้ตรงกับความเสียหายที่ยอมรับได้ของงานตรงหน้า
วางแผนอย่างเดียว
ห้ามแก้อะไรทั้งสิ้น ใช้ตอนอยากให้มันสำรวจโค้ดและเสนอแผนก่อน
ถามทุกครั้ง
ช้าที่สุดและปลอดภัยที่สุด ใช้ตอนเริ่ม และตอนทำงานกับโค้ดที่มีคนอื่นใช้อยู่
ให้แก้ไฟล์เองได้
เร็วขึ้นมาก ใช้ได้เมื่ออยู่บน branch ที่ทิ้งทั้ง branch ได้โดยไม่เสียใจ
โหมด “ไม่ต้องถามเลย” มีอยู่จริง — คำแนะนำด้านความปลอดภัยปี 2026 ตรงกันว่าให้ใช้ใน sandbox ที่แยกออกมาเท่านั้น ไม่ใช่บนเครื่องที่มีของจริงอยู่
your first task
งานแรกที่ควรสั่ง
“อ่านโปรเจกต์นี้แล้วอธิบายให้ฟังว่า หน้า login ทำงานยังไง ไฟล์ไหนเกี่ยวบ้าง — ยังไม่ต้องแก้อะไร”
สองนาทีนี้ราคาถูกที่สุดใน session ทั้งหมด
สิ่งที่เราได้จากมัน
safety net
agent แก้ไฟล์เป็นสิบไฟล์ในนาทีเดียวได้ ปุ่ม undo ของ editor เอาไม่อยู่ — สิ่งที่เอาอยู่คือ git
ก่อนเริ่ม
แยก branch ใหม่เสมอ ให้ main เป็นที่ที่ปลอดภัยไว้ก่อน
ระหว่างทาง
ได้ของที่ใช้ได้เมื่อไหร่ commit ทันที นั่นคือจุดที่เราย้อนกลับมาได้
ก่อน commit
อ่าน diff ทุกครั้ง ถ้ามีบรรทัดที่อธิบายไม่ได้ อย่าเพิ่งรับ
อย่าปล่อยให้ agent commit รวดเดียวจบ — checkpoint ที่เราวางเอง คือสิ่งที่ทำให้ย้อนได้ตรงจุดที่พัง
when it drifts
หยุดมันทันทีที่เห็นว่าไปผิดทาง
อย่ารอดูให้จบรอบ ทุกรอบที่ปล่อยคือขยะที่เพิ่มลง context
ย้อนด้วย git ให้กลับไปจุดที่ยังดีอยู่
อย่าให้มันแก้ของที่มันทำพังเอง — ล้างแล้วเริ่มใหม่ถูกกว่า
แก้คำสั่ง แล้วค่อยสั่งใหม่
ถ้าคำสั่งเดิมทำให้มันหลง สั่งเดิมซ้ำก็หลงเหมือนเดิม
Section 04
ทักษะจริงของการใช้ harness ไม่ได้อยู่ที่รู้ปุ่มไหนอยู่ตรงไหน แต่อยู่ที่ป้อนอะไรเข้าไป
prompting
คำสั่งที่ได้ผลลัพธ์เดา ๆ
“แก้บั๊กหน้า login ให้หน่อย”
มันไม่รู้ว่าบั๊กคืออะไร ไม่รู้ว่าไฟล์ไหน ไม่รู้ว่าเสร็จแล้วหน้าตายังไง — สิ่งที่มันทำได้คือเดา
คำสั่งที่เป็นสเปก
“ที่ src/app/login/page.tsx ตอนกรอกรหัสผิดแล้วกดปุ่ม ไม่มีข้อความอะไรขึ้นเลย ให้ขึ้นข้อความใต้ช่องรหัสผ่าน ใช้รูปแบบเดียวกับหน้า register แล้วรัน pnpm test ให้ผ่าน”
ที่ไหน · อาการ · สิ่งที่อยากได้ · ของเดิมที่ให้ยึด · เกณฑ์ว่าเสร็จ
give it the map
ชี้ไฟล์
บอกพาธไปเลย ประหยัดกว่าปล่อยให้มันไล่เปิดไฟล์ทั้งโปรเจกต์หา
ชี้ของเดิมที่ทำถูกแล้ว
“ทำแบบเดียวกับหน้า register” ให้ผลดีกว่าอธิบายสไตล์เป็นย่อหน้า
บอกว่าห้ามแตะอะไร
ไฟล์ config, migration, โค้ดที่มีคนอื่นใช้อยู่ — ระบุไปตรง ๆ
define done
ถ้าไม่บอกเกณฑ์ มันจะตัดสินเองว่าเสร็จแล้ว — และเกณฑ์ของมันคือ “เขียนโค้ดจบ” ไม่ใช่ “ใช้งานได้”
คำสั่งที่ต้องรันผ่าน
บอกคำสั่งจริงไปเลย เช่น build หรือ lint ที่โปรเจกต์นี้ใช้
เทสต์ที่ต้องเขียว
ให้มันรันเองแล้วรายงานผล ไม่ใช่บอกว่า “น่าจะผ่าน”
สิ่งที่ควรเห็นบนจอ
อธิบายผลลัพธ์ที่ตาเราจะเห็น เพื่อให้มันตรวจตัวเองได้
และต้องบอกให้ชัดว่า ห้ามแก้เทสต์เพื่อให้ผ่าน — ถ้าไม่บอก มันจะเลือกทางที่ง่ายกว่าเสมอ
project rules
ข้างในเขียนอะไร
เป็นไฟล์ Markdown ธรรมดาวางที่รากโปรเจกต์ ไม่ต้องลงอะไรเพิ่ม
ทำไมถึงคุ้ม
60,000+
โปรเจกต์ที่ใช้ไฟล์นี้อยู่ และเครื่องมือกว่า 20 ตัวอ่านไฟล์เดียวกัน
เขียนครั้งเดียว ใช้ได้ข้ามเครื่องมือ — เปลี่ยน harness ปีหน้าก็ไม่ต้องเขียนใหม่
the working loop
วงจรนี้เป็นสิ่งที่เอกสารของทุกเจ้าแนะนำตรงกัน และมันคือวงจรของเรา ไม่ใช่ของ agent
Plan
ให้มันเล่าแผนก่อนแตะโค้ด อ่านแผนแล้วแก้ตรงนั้น
Execute
ปล่อยให้ทำตามแผนที่ตกลงกันแล้ว ทีละก้อนที่รีวิวไหว
Verify
รันเอง เปิดดูเอง แล้วค่อย commit ด้วยมือเรา
จับผิดตอนที่มันยังเป็นแผน ถูกกว่าจับผิดตอนที่มันเป็นโค้ดไปแล้วสิบไฟล์
scope
งานที่ขนาดกำลังดี
งานที่อธิบายจบในสองสามประโยค รีวิว diff ไหวในครั้งเดียว และ commit ได้เป็นก้อนเดียว
งานใหญ่ให้แตกเป็นชิ้นแบบนี้หลาย ๆ ชิ้น ไม่ใช่สั่งทีเดียวแล้วหวัง
เมื่อไหร่ควรเริ่มบทสนทนาใหม่
บทสนทนาที่สะอาดราคาถูกกว่าบทสนทนาที่ยาว — ดูสไลด์ context rot อีกที
Section 05
ส่วนที่แยกคนที่ใช้เป็น ออกจากคนที่กด yes ไปเรื่อย ๆ
going further
ไฟล์กฎประจำโปรเจกต์
สิ่งที่ต้องรู้ทุกครั้ง เขียนไว้ที่เดียว
คำสั่งลัดที่ใช้ซ้ำ
prompt ยาว ๆ ที่ใช้บ่อย เก็บไว้เรียกด้วยคำสั้น ๆ
ผู้ช่วยที่แยก context
ให้ตัวอื่นไปค้นของหรือรีวิวแทน เพื่อไม่ให้ context หลักบวม
ต่อกับของนอกผ่าน MCP
ฐานข้อมูล ระบบ ticket บริการที่เราใช้อยู่ — ให้มันเห็นของจริง
verify
มันรายงานว่าเสร็จด้วยน้ำเสียงมั่นใจเท่ากันทุกครั้ง ทั้งตอนที่ถูกและตอนที่ผิด น้ำเสียงจึงไม่ใช่หลักฐาน
รันเอง
อย่าอ่านแค่ที่มันบอกว่าเทสต์ผ่าน รันด้วยมือเราอีกรอบ
เปิดดูเอง
เปิดหน้าจอจริง กดปุ่มจริง โดยเฉพาะเคสที่ผู้ใช้จะเจอ
อ่าน diff
มองหาบรรทัดที่ไม่ได้ขอ ไฟล์ที่ไม่ควรถูกแตะ และเทสต์ที่ถูกแก้
คำถามที่ควรถามตัวเองก่อนกดรับทุกครั้ง — “ถ้าอันนี้พังตอนใช้จริง ฉันอธิบายได้ไหมว่าโค้ดนี้ทำอะไร”
security
agent แยกไม่ออกระหว่าง “ข้อมูลที่ให้อ่าน” กับ “คำสั่งที่ให้ทำ” ใครฝากข้อความไว้ในของที่มันจะอ่าน ก็สั่งงานมันได้
ซ่อนมาได้จากไหน
README ของ library, issue บน GitHub, หน้าเว็บที่มันเปิดอ่าน, ผลลัพธ์จาก tool
เกิดขึ้นจริงแล้ว
ปี 2026 มีเคสที่หัวข้อ issue อันเดียวนำไปสู่การยึด package และเคสที่ prompt เดียวรันคำสั่งบนเครื่องได้
ป้องกันยังไง
อย่าปิดกล่องขออนุญาต อ่านคำสั่งก่อนกด และอย่าเก็บรหัสผ่านไว้ในที่ที่ agent เห็น
ปี 2026 นี่คือความเสี่ยงอันดับหนึ่งของ coding agent — และเป็นเหตุผลจริงที่ห้ามปิดกล่องขออนุญาต
common traps
กด yes รัว ๆ
อนุมัติเร็วกว่าที่อ่านทัน สุดท้ายไม่รู้ว่าโปรเจกต์เปลี่ยนไปตรงไหนบ้าง
สั่งงานใหญ่เกินไป
“ทำระบบ login ให้ที” แล้วได้ของที่รีวิวไม่ไหว และย้อนไม่ได้
ไม่มี git
แก้พังแล้วกลับไม่ได้ นี่คือกับดักที่แพงที่สุดในหกอัน
ปล่อยให้มันแก้เทสต์
เทสต์เขียวเพราะเทสต์ถูกแก้ ไม่ใช่เพราะโค้ดถูก
คุยยาวในห้องเดิม
context บวมจนมันลืมสิ่งที่ตกลงกันไว้ตั้งแต่ต้น
พิมพ์รหัสผ่านลงไป
ทั้ง key ทั้ง token — ถือว่าหลุดทันทีที่พิมพ์ ต้องไปเปลี่ยนใหม่
ห้าในหกข้อนี้แก้ได้ด้วยนิสัยเดียว — ทำงานทีละก้อนเล็ก ๆ บน branch ของตัวเอง แล้วอ่านก่อนรับ
ปีหน้าเครื่องมือที่คุณใช้อาจไม่ใช่ตัวเดิม แต่มันก็ยังมี loop, tools, context, สิทธิ์ และความจำอยู่ห้าอย่างเดิม — เข้าใจห้าอย่างนี้แล้วย้ายเครื่องมือเมื่อไหร่ก็ได้ และงานของเราก็ย้ายจากคนพิมพ์โค้ด มาเป็นคนที่ตัดสินว่าอะไรถูก
The Harness