Anthropic จ่ายเงินให้วิศวกรของพวกเขาเดือนละ 80,000 ดอลลาร์ วิศวกรเหล่านั้นในปัจจุบันรวมโค้ด (merge code) ได้มากกว่าเมื่อปีก่อนถึง 8 เท่า ไม่ใช่เพราะโมเดลฉลาดขึ้น แต่เป็นเพราะพวกเขาเลิกเขียน Prompt ให้ Claude แล้วหันมาสร้างระบบที่เขียน Prompt ให้ Claude แทน
Brian Cherny หัวหน้าฝ่าย Claude Code ที่ Anthropic กล่าวว่า: "ผมไม่เขียน Prompt ให้ Claude อีกต่อไปแล้ว ผมมีลูป (loop) ที่คอยรันเพื่อเขียน Prompt ให้ Claude และตัดสินใจว่าจะต้องทำอะไร งานของผมคือการเขียนลูปพวกนี้"
นักพัฒนาส่วนใหญ่ที่อ่านประโยคนี้อาจไม่เข้าใจว่าในทางปฏิบัติมันหมายถึงอะไร แต่เมื่อจบจากบทความนี้ คุณจะเข้าใจ และคุณจะมีทุกอย่างที่จำเป็นสำหรับการสร้างลูปแรกของคุณในสุดสัปดาห์นี้
ลูปคืออะไรกันแน่
Prompt คือคำสั่งเดียว แต่ลูปคือเป้าหมายที่ AI จะทำงานต่อไปเรื่อยๆ จนกว่าจะสำเร็จ
ความแตกต่างอยู่ที่ว่าใครเป็นคนขับเคลื่อน หากใช้ Prompt คุณจะต้องคอยผลักดัน Claude ไปทีละขั้นตอนด้วยตัวเอง แต่หากใช้ลูป คุณเพียงแค่กำหนดเป้าหมายไว้ครั้งเดียว แล้วระบบจะรันวงจรทั้งหมดด้วยตัวเอง ทั้งการค้นหางานที่ต้องทำ การลงมือทำ การตรวจสอบผลลัพธ์ และการตัดสินใจว่าจะทำอะไรต่อ ทั้งหมดนี้โดยที่คุณไม่ต้องเข้ามานั่งคุมเอง
1Prompt | คุณพิมพ์, Claude ตอบ, คุณพิมพ์อีกครั้ง2ลูป | ระบบหางาน, Claude ทำงาน,3 | ระบบตรวจสอบผล, ทำซ้ำจนกว่าจะเสร็จ
ลูปที่ใช้งานได้จริงทุกอันจะมี 5 ขั้นตอน:
1ค้นพบ (Discover) | หางานที่ต้องทำ2วางแผน (Plan) | ตัดสินใจว่าจะทำอย่างไร3ลงมือทำ (Execute) | ทำงานนั้น4ตรวจสอบ (Verify) | เช็คเทียบกับเป้าหมาย5ทำซ้ำ (Iterate) | ยังไม่เสร็จ? ส่งผลลัพธ์กลับเข้าไปแล้วเริ่มใหม่
สามขั้นตอนหลังนี้คือส่วนที่ทำงานจริงทั้งหมด
การตรวจสอบ (Verify) คือหัวใจสำคัญ หากไม่มีการตรวจสอบผลลัพธ์ที่แท้จริง คุณก็ไม่ได้มีลูป แต่คุณแค่มีเอเจนต์ที่เห็นด้วยกับตัวเองไปเรื่อยๆ การตรวจสอบต้องเป็นกลาง เช่น การทดสอบที่ผ่านหรือตก การ build ที่สำเร็จหรือไม่สำเร็จ หรือ linter ที่คืนค่าศูนย์หรือไม่ใช่ศูนย์ ไม่ใช่การให้เอเจนต์ตัวที่สองมา "รีวิว" เพราะการให้เอเจนต์สองตัวที่มองโลกในแง่ดีมาเห็นพ้องต้องกันไม่ใช่การตรวจสอบ
สถานะ (State) คือสิ่งที่ทำให้ลูปเรียนรู้ได้ ในแต่ละรอบ AI ต้องจำสิ่งที่เคยลองทำไปแล้ว ไม่อย่างนั้นมันจะทำผิดซ้ำเดิมตลอดไป ลูปที่แท้จริงจะเก็บข้อมูลไว้นอกเหนือจากการสนทนา ทั้งสิ่งที่ทำเสร็จแล้ว สิ่งที่ล้มเหลว และสิ่งที่ต้องทำต่อไป เอเจนต์อาจลืมสิ่งที่เกิดขึ้นระหว่างเซสชัน แต่ไฟล์สถานะไม่ลืม
เงื่อนไขการหยุด (Stop condition) คือสิ่งที่ทำให้ระบบไม่เพี้ยน ลูปที่ไม่มีทางออกจะรันไปเรื่อยๆ จนกว่าจะสำเร็จ พัง หรือเงินในงบประมาณของคุณหมด ลูปที่จริงจังทุกอันจะมีวิธีหยุด 2 แบบ คือ เมื่อสำเร็จ และเมื่อถึงขีดจำกัดที่กำหนดไว้ หากไม่มีสิ่งนี้ คุณก็แค่สร้างเครื่องจักรที่คอยเรียกเก็บเงินคุณเงียบๆ เท่านั้น
บททดสอบ 4 ข้อก่อนที่คุณจะสร้างอะไรก็ตาม
ลูปจะคุ้มค่าก็ต่อเมื่อเข้าเงื่อนไขทั้ง 4 ข้อนี้ หากขาดข้อใดข้อหนึ่งไป ให้ใช้การเขียน Prompt แบบปกติแทน
1เงื่อนไข 1 | งานนั้นต้องทำซ้ำอย่างน้อยสัปดาห์ละครั้ง2 | ถ้าน้อยกว่านั้น ค่าติดตั้งจะไม่คุ้มทุน34เงื่อนไข 2 | มีระบบที่ปฏิเสธผลลัพธ์ที่แย่ได้โดยอัตโนมัติ5 | เช่น การทดสอบ, build, linter, type check6 | ถ้าไม่มีเกตอัตโนมัติ คุณก็ต้องกลับมานั่งรีวิวทุก diff อยู่ดี78เงื่อนไข 3 | เอเจนต์สามารถทำงานนั้นได้ตั้งแต่ต้นจนจบ9 | ไม่ใช่ทำไปครึ่งทางแล้วโยนกลับมาให้คุณ1011เงื่อนไข 4 | คำว่า "เสร็จ" ต้องวัดผลได้ ไม่ใช่เรื่องของรสนิยม12 | ถ้าคุณภาพเป็นเรื่องของความชอบ มนุษย์ยังคงทำได้ดีกว่า
ลูปแรกที่ควรลองทำ:
1คัดกรอง CI ที่ล้มเหลว | ทำทุกคืน, จำแนกความผิดพลาด, ร่างวิธีแก้2อัปเดต Dependency | ทำรายสัปดาห์, สแกนอัปเดต, เปิด PR3Lint-and-fix | ทำทุก PR, แก้ไขสไตล์โค้ดอัตโนมัติ4ร่าง Issue-to-PR | สำหรับ codebase ที่มีการทดสอบครอบคลุม
ลูปที่ไม่ควรทำเป็นอันดับแรก - ควรให้มนุษย์คุมเอง:
1เขียน Architecture ใหม่ | ต้องใช้การตัดสินใจ, ลูปจะออกทะเล2โค้ดระบบ Auth หรือจ่ายเงิน | ความผิดพลาดที่ย้อนกลับไม่ได้มีราคาแพงเกินไป3Deploy ขึ้น Production | ต้องมีมนุษย์อนุมัติ4งาน Product ที่คลุมเครือ | คำว่า "เสร็จ" ไม่ชัดเจน
องค์ประกอบ 5 อย่างในการสร้างลูป
ลูปที่ใช้งานได้จริงทุกอันประกอบขึ้นจาก 5 ส่วน ซึ่ง Claude Code มีครบทั้ง 5 ส่วนนี้
1 - ระบบอัตโนมัติ (หัวใจสำคัญ)
นี่คือสิ่งที่ทำให้ลูปเป็นลูปจริงๆ ไม่ใช่แค่การรันครั้งเดียวจบ ตัวกระตุ้น (trigger) จะทำงานตามเวลาหรือเหตุการณ์ที่กำหนด ส่งงานให้ Claude และนำผลลัพธ์กลับมาโดยที่คุณไม่ต้องไปคอยเช็ค
1/loop | รัน Prompt ซ้ำตามจังหวะเวลา2/goal | ทำงานต่อไปจนกว่าเงื่อนไขที่คุณเขียนจะเป็นจริง3hooks | สั่งงาน ณ จุดต่างๆ ในวงจรชีวิตของเอเจนต์4cron | รันหลังจากคุณปิดคอมพิวเตอร์ผ่าน GitHub Actions
สิ่งที่สำคัญที่สุดคือ /goal โดยจะมีโมเดลขนาดเล็กแยกต่างหากคอยตรวจสอบว่าเงื่อนไขนั้นสำเร็จหรือไม่ ดังนั้นเอเจนต์ที่เขียนโค้ดจะไม่ใช่ตัวเดียวกับที่ให้คะแนน
1/loop 30m /goal "การทดสอบทั้งหมดใน test/auth ผ่านและ lint สะอาด"2สแกน src/auth เพื่อหาข้อผิดพลาด, ร่างวิธีแก้, เปิด PR เมื่อเป้าหมายสำเร็จ
2 - ทักษะ (เขียนความรู้โปรเจกต์ไว้ครั้งเดียว)
ทักษะ (Skill) คือวิธีที่คุณไม่ต้องอธิบายบริบทของโปรเจกต์ซ้ำๆ ในทุกเซสชัน ไฟล์ SKILL.md จะเก็บคำสั่ง ข้อตกลง และกฎต่างๆ ที่ลูปจะอ่านในทุกครั้งที่รัน
หากไม่มีทักษะ ลูปจะเริ่มทำความเข้าใจโปรเจกต์ของคุณใหม่จากศูนย์ในทุกรอบ แต่เมื่อมีทักษะ ความตั้งใจจะถูกสั่งสม ทั้งข้อตกลง ขั้นตอนการ build และสิ่งที่เคยผิดพลาดมาก่อน ทั้งหมดนี้เขียนครั้งเดียวและอ่านตลอดไป
1skills/2 ci-triage.md - กฎการจำแนก, รูปแบบการแก้, เกณฑ์การยกระดับ3 frontend.md - กฎของ Tailwind, Next.js, SEO, accessibility4 security.md - รูปแบบ auth, การตรวจสอบข้อมูล, สิ่งที่ห้ามแตะ5 deps.md - กฎการอัปเดต, การเช็คความเข้ากันได้, รูปแบบการย้อนกลับ
ระบบอัตโนมัติจะเรียกใช้ทักษะตามชื่อ งานที่ทำซ้ำจะยังคงดูแลรักษาได้ง่าย แทนที่จะปล่อยให้มันเน่าเสียไปตามกาลเวลา
3 - เอเจนต์ย่อย (แยกคนทำออกจากคนตรวจ)
นี่คือโครงสร้างที่มีประโยชน์ที่สุดในลูป ให้แยกเอเจนต์ที่เขียนโค้ดออกจากเอเจนต์ที่ตรวจสอบ
โมเดลที่เขียนโค้ดมักจะใจดีเกินไปเมื่อต้องให้คะแนนงานตัวเอง การมีเอเจนต์ตัวที่สองที่มีคำสั่งต่างออกไป และบางครั้งใช้โมเดลที่เก่งกว่า จะช่วยจับข้อผิดพลาดที่ตัวแรกมองข้ามไปได้
1เอเจนต์ผู้สร้าง (Maker) | โมเดลเร็วและถูก - สำรวจ, ลงมือทำ, ร่างงาน2เอเจนต์ผู้ตรวจ (Checker) | โมเดลเก่ง, ใช้ความพยายามสูง - รีวิว, ตรวจสอบ, ปฏิเสธ
1.claude/agents/2 explorer.md | อ่านอย่างเดียว, โมเดลเร็ว, หางานที่ต้องทำ3 implementer.md | เขียนวิธีแก้, รันการทดสอบ4 reviewer.md | ตรวจสอบความปลอดภัย, คุณภาพโค้ด, เกตที่เป็นกลาง
หนึ่งโมเดล สามผู้เชี่ยวชาญ ลูปจะรันไปในขณะที่คุณไม่ได้เฝ้าดู และตัวตรวจสอบคือเหตุผลเดียวที่คุณจะเดินจากไปได้อย่างสบายใจ
4 - ตัวเชื่อมต่อ (เพื่อให้มันลงมือทำ ไม่ใช่แค่แนะนำ)
ความแตกต่างระหว่างลูปที่บอกว่า "นี่คือวิธีแก้" กับลูปที่เปิด PR, เชื่อมโยง Ticket และแจ้งเตือน Slack เมื่อ CI ผ่านแล้ว
1GitHub | อ่าน repo, สร้าง branch, เปิด PR, ตอบสนองต่อ webhook2Linear | อัปเดต Ticket, เชื่อมโยง PR, ปิดงานเมื่อตรวจสอบผ่าน3Slack | โพสต์ผลการคัดกรอง, แจ้งเตือนมนุษย์เมื่อต้องยกระดับงาน4Sentry | ตรวจสอบการแจ้งเตือนสด, ร่างวิธีแก้สำหรับปัญหาที่พบบ่อย
หากไม่มีตัวเชื่อมต่อ ลูปก็จะทำได้แค่บรรยายว่ามันจะทำอะไร แต่ถ้ามีตัวเชื่อมต่อ มันจะลงมือทำจริง
5 - ไฟล์สถานะ (เอเจนต์ลืม แต่ไฟล์ไม่ลืม)
ส่วนที่ฟังดูเรียบง่ายจนเหมือนไม่มีอะไร แต่กลับเป็นกระดูกสันหลังของลูปที่ใช้งานได้จริงทุกอัน มันคือไฟล์ Markdown ที่อยู่นอกเหนือการสนทนา ซึ่งบันทึกสิ่งที่ทำไปแล้ว สิ่งที่ล้มเหลว และสิ่งที่ต้องทำต่อไป
1# สถานะลูป - ci-triage23## รันครั้งล่าสุด42026-06-09 03:30 UTC - จำแนกข้อผิดพลาด 7 รายการ, ร่างวิธีแก้ 3 รายการ, ยกระดับ 4 รายการ56## กำลังดำเนินการ7- claude/fix-auth-token-refresh - ทดสอบผ่านในเครื่อง, รอ CI89## ทำเสร็จวันนี้10- claude/bump-axios-1.7.4 - รวมโค้ดแล้ว, CI ผ่าน1112## ยกระดับให้มนุษย์13- src/billing/refund.ts - ทดสอบไม่ผ่าน 3 รูปแบบ, ยังหาสาเหตุหลักไม่พบ1415## บทเรียนที่ได้รับ16- 2026-06-08: PowerShell ติดปัญหา TLS บน Windows runner ให้ใช้ bash แทน17- 2026-06-07: tests/e2e/checkout ต้องการ Stripe webhook secret ให้ข้ามถ้าไม่มี
การรันในวันพรุ่งนี้จะอ่านไฟล์นี้และทำงานต่อจากเดิม หากไม่มีไฟล์นี้ ทุกการรันจะเริ่มจากศูนย์เสมอ
ลูปที่ใช้งานจริงหน้าตาเป็นอย่างไร
การคัดกรอง CI ที่ล้มเหลวเป็นหนึ่งในลูปแรกๆ ที่ดีที่สุด เพราะการตรวจสอบเป็นไปโดยอัตโนมัติและความเสี่ยงจากผลลัพธ์ที่ผิดพลาดนั้นต่ำ
1ตัวกระตุ้น (Trigger) | รันทุกคืนตอนตี 3 หรือเมื่อ CI ล้มเหลว2ทักษะ (Skill) | ci-triage.md3อ่านสถานะ | STATE.md - อะไรพังเมื่อวาน, อะไรแก้ไปแล้ว
ลูปจะทำงานดังนี้:
1ขั้นตอน 1 | อ่าน CI ที่ล้มเหลวจาก GitHub ผ่านตัวเชื่อมต่อ2ขั้นตอน 2 | จำแนกแต่ละรายการ: env / flake / bug / dependency / infra3ขั้นตอน 3 | สำหรับข้อผิดพลาดที่แก้ได้ - เปิด worktree, ส่งเอเจนต์ผู้ลงมือทำไปจัดการ4ขั้นตอน 4 | เอเจนต์ผู้ตรวจเช็ควิธีแก้เทียบกับการทดสอบและกฎความปลอดภัย5ขั้นตอน 5 | ถ้าผ่านเกต - เปิด PR และเชื่อมโยง Linear ticket6ขั้นตอน 6 | ถ้าไม่ผ่านเกต - ยกระดับไปที่กล่องข้อความคัดกรองของมนุษย์7ขั้นตอน 7 | อัปเดต STATE.md8ขั้นตอน 8 | โพสต์สรุปผลข้ามคืนลง Slack
ในตอนเช้า คุณจะตื่นมาพบข้อความใน Slack, กล่องข้อความคัดกรองที่มีเฉพาะปัญหาที่ยากจริงๆ และชุด PR ที่ผ่านการรีวิวอัตโนมัติมาแล้ว โดยที่คุณไม่ต้องเขียน Prompt แม้แต่ขั้นตอนเดียว
ลูปที่สร้างผลลัพธ์ทวีคูณทั่วทั้งธุรกิจ
เวอร์ชันที่ทรงพลังที่สุดไม่ใช่ลูปเดียว แต่เป็นหลายลูปที่เขียนข้อมูลลงในระบบบันทึกที่ใช้ร่วมกัน เพื่อให้พวกมันเรียนรู้จากกันและกัน
ที่ SuperDesign ลูปของพวกเขาครอบคลุมทั้งฝ่ายสนับสนุน, SEO, การเติบโตของผลิตภัณฑ์ และโฆษณา แต่ละลูปมีตัวกระตุ้นและเวิร์กโฟลว์ของตัวเอง แต่ทั้งหมดเขียนข้อมูลลงในคลังสัญญาณ (signal store) เดียวกัน
ลูปฝ่ายสนับสนุนสังเกตเห็นผู้ใช้ 5 คนถามวิธีส่งออกข้อมูล มันจึงสร้างสัญญาณขึ้นมา:
1ชนิด: สัญญาณ2หัวข้อ: หาปุ่มส่งออกยากเกินไป3ความถี่: 54หมวดหมู่: อุปสรรค (friction)5แท็ก: [feedback, pricing, conversion]
ลูป SEO สังเกตเห็นหน้าเว็บที่มีทราฟฟิกสูงแต่มีอัตราการเปลี่ยนเป็นลูกค้าต่ำ จึงสร้างสัญญาณอีกอันขึ้นมา ลูปการเติบโตของผลิตภัณฑ์อ่านสัญญาณทั้งสองควบคู่ไปกับข้อมูลวิเคราะห์ และระบุว่าอุปสรรคเรื่องการส่งออกข้อมูลนั้นใหญ่กว่าที่ข้อมูลดิบแสดงไว้ เพราะตอนนี้มีแหล่งข้อมูลอิสระสองแหล่งยืนยันปัญหาเดียวกัน ลูปโฆษณาพบช่องว่างของคีย์เวิร์ดและป้อนข้อมูลนั้นเข้าสู่ลูป SEO โดยตรง
1ลูปสนับสนุน | พบอุปสรรค, เขียนสัญญาณ2ลูป SEO | พบช่องว่างเนื้อหา, เขียนสัญญาณ3ลูปผลิตภัณฑ์ | อ่านสัญญาณทั้งสอง, ระบุความสำคัญ4ลูปโฆษณา | พบช่องว่างคีย์เวิร์ด, ป้อนให้ลูป SEO
ลูปเหล่านี้ไม่ใช่ระบบอัตโนมัติที่แยกส่วนกัน แต่ทำงานจากฐานความรู้ที่ใช้ร่วมกันว่าธุรกิจกำลังเรียนรู้อะไรอยู่ แต่ละลูปทำให้ลูปอื่นฉลาดขึ้น นี่คือการเติบโตแบบทวีคูณ
ความล้มเหลวที่ไม่มีใครเตือนคุณ
ลูปแบบ Ralph Wiggum: เอเจนต์ที่ควรส่งสัญญาณว่าเสร็จสิ้นเฉพาะตอนที่งานเสร็จจริงๆ กลับส่งสัญญาณว่าเสร็จตั้งแต่งานยังไม่เรียบร้อย ลูปจึงหยุดทำงานทั้งที่งานเสร็จแค่ครึ่งเดียว แต่ยังคงรันและเรียกเก็บเงินต่อไปโดยไม่ได้ผลลัพธ์อะไร วิธีแก้: ต้องมีเกตที่เข้มงวดซึ่งสามารถตัดสินว่างานนั้น "สอบตก" ได้จริงๆ ไม่ใช่แค่เกตแบบนิ่มๆ ที่บอกว่า "ดูดีนะ"
เป้าหมายเพี้ยน (Goal drift) ในเซสชันยาวๆ: ข้อจำกัดต่างๆ จะหายไปในรอบที่ 47 เพราะบริบทถูกสรุปย่อลงเรื่อยๆ วิธีแก้: มีไฟล์ AGENTS.md ที่เอเจนต์จะกลับมาอ่านใหม่ทุกครั้งที่เริ่มรันรอบใหม่
หนี้ความเข้าใจ (Comprehension debt): ยิ่งลูปส่งโค้ดที่คุณไม่ได้เขียนเร็วเท่าไหร่ ช่องว่างระหว่างสิ่งที่มีอยู่กับสิ่งที่คุณเข้าใจก็จะยิ่งกว้างขึ้น ค่าใช้จ่ายที่เจ็บปวดไม่ใช่ค่า Token แต่เป็นวันที่คุณต้องมานั่ง Debug ระบบที่ไม่มีใครในทีมเคยอ่าน วิธีแก้: อ่านทุก diff ที่ลูปเปิดขึ้นมา
การยอมจำนนทางความคิด (Cognitive surrender): แรงดึงดูดที่ทำให้คุณเลิกคิดและยอมรับทุกอย่างที่ลูปส่งกลับมา การออกแบบลูปคือวิธีรักษาเมื่อคุณทำด้วยวิจารณญาณ แต่จะเป็นตัวเร่งความพินาศเมื่อคุณทำเพื่อหลีกเลี่ยงการใช้ความคิด การกระทำเดียวกัน แต่ผลลัพธ์ตรงกันข้าม
ค่า Token ที่เพิ่มขึ้น: การรันลูปแต่ละรอบจะอ่านบริบททั้งหมดใหม่ และกองข้อมูลจะใหญ่ขึ้นเรื่อยๆ ในแต่ละรอบ ให้ติดตามต้นทุนต่อการเปลี่ยนแปลงที่ยอมรับได้ หากอัตราการยอมรับต่ำกว่า 50% ลูปนั้นจะมีต้นทุนสูงกว่าสิ่งที่มันช่วยประหยัดไว้
ลำดับการสร้างที่ใช้งานได้จริง
ทุกคนที่สร้างลูปที่อยู่รอดใน Production ทำแบบเดียวกันนี้:
1ขั้นตอน 1 | ทำให้การรันด้วยมือ 1 ครั้งเชื่อถือได้ก่อน2ขั้นตอน 2 | เปลี่ยนมันเป็นทักษะ - บันทึกคำสั่งไว้ใน SKILL.md3ขั้นตอน 3 | หุ้มทักษะด้วยลูป - เพิ่มเกตและเงื่อนไขการหยุด4ขั้นตอน 4 | จากนั้นค่อยตั้งเวลาให้มันรันอัตโนมัติ
การตั้งเวลาให้สิ่งที่ยังทำด้วยมือไม่สำเร็จคือวิธีที่ทำให้ลูปพังพินาศในขณะที่คุณหลับ พิสูจน์ให้ได้ก่อน ทำให้มันแข็งแกร่ง แล้วค่อยทำให้เป็นอัตโนมัติ
ตัวชี้วัดที่สำคัญไม่ใช่จำนวน Token ที่ใช้หรือจำนวนงานที่พยายามทำ แต่คือต้นทุนต่อการเปลี่ยนแปลงที่ยอมรับได้ หากลูปให้ผลลัพธ์คุณ 10 อย่างแล้วคุณปฏิเสธไป 6 คุณก็แค่กำลังทำงานรีวิวที่ลูปควรจะช่วยคุณประหยัดเวลาไปนั่นเอง
การเปลี่ยนแปลงที่เกิดขึ้นแล้ว
ในปี 2024 พลังอำนาจอยู่ที่ Prompt ยิ่ง Prompt ดี ผลลัพธ์ก็ดี นักพัฒนาก็เก่งขึ้น ในปี 2026 พลังอำนาจอยู่สูงขึ้นไปอีกหนึ่งชั้น นั่นคือระบบที่ตัดสินใจว่า Claude ควรทำงานอะไร เมื่อไหร่ ด้วยเกตแบบไหน และสถานะอะไรที่ควรคงอยู่ระหว่างการรัน
วิศวกรของ Anthropic รวมโค้ดได้มากกว่าวันละ 8 เท่า ไม่ใช่เพราะพวกเขาหาวิธีถามคำถาม Claude ได้ดีขึ้น แต่เพราะพวกเขาเลิกถามคำถามแล้วหันมาสร้างระบบที่ถามคำถาม Claude แทนพวกเขาอย่างต่อเนื่อง ตลอดทั้งคืน ในขณะที่พวกเขานอนหลับ
ลูปไม่ได้ทำให้งานง่ายขึ้น แต่มันเปลี่ยนจุดที่งานเกิดขึ้น จากการพิมพ์ Prompt เป็นการออกแบบระบบที่พิมพ์ Prompt จากการถือเครื่องมือ เป็นการสร้างโรงงาน
นักพัฒนาส่วนใหญ่จะยังคงเขียน Prompt ด้วยมือและสงสัยว่าทำไมช่องว่างระหว่างพวกเขากับคนอื่นถึงกว้างขึ้นเรื่อยๆ แต่จะมีคนกลุ่มหนึ่งที่ใช้เวลาสุดสัปดาห์สร้างลูปแรกของพวกเขาขึ้นมา ทั้งระบบอัตโนมัติ ทักษะ ไฟล์สถานะ และเกตตรวจสอบ แล้วพวกเขาจะไม่มีวันกลับไปใช้วิธีเดิมอีกเลย
