การออกแบบฮาร์เนสสำหรับพัฒนาแอปพลิเคชันที่รันระยะยาว

• Anthropic ได้พัฒนาโครงสร้างแบบมัลติเอเจนต์ที่ได้แรงบันดาลใจจาก GAN เพื่อแก้สองปัญหาพร้อมกันคือ การยกระดับคุณภาพงานออกแบบฝั่งฟรอนต์เอนด์ และ การเขียนโค้ดอัตโนมัติระยะยาว
• ด้วยโครงสร้างที่แยก generator และ evaluator ออกจากกัน จึงทำให้สามารถให้คะแนนคุณภาพงานออกแบบเชิงอัตวิสัยตามเกณฑ์ที่เป็นรูปธรรมได้ และแก้ปัญหาอคติจากการประเมินตนเองของเอเจนต์
• สถาปัตยกรรม 3 เอเจนต์ แบบ planner-generator-evaluator สามารถสร้างแอปพลิเคชันแบบฟูลสแตกจนเสร็จได้ในการเขียนโค้ดอัตโนมัติหลายช่วงเวลา โดยมีทั้งการเจรจา sprint contract และ QA ที่อิงกับ Playwright
• เมื่อเปลี่ยนจาก Opus 4.5 ไปเป็น Opus 4.6 ก็สามารถ เขียนโค้ดต่อเนื่องได้เกิน 2 ชั่วโมงโดยไม่ต้องแบ่งสปรินต์ ทำให้ลดความซับซ้อนของฮาร์เนสลงได้โดยยังคงประสิทธิภาพไว้
• แม้ประสิทธิภาพของโมเดลจะดีขึ้น แต่ พื้นที่ของการผสมผสานฮาร์เนสที่น่าสนใจไม่ได้ลดลง เพียงแค่ย้ายตำแหน่งไป และภารกิจหลักของวิศวกร AI คือการค้นหาการผสมผสานใหม่เหล่านั้น

---

ทำไมการอิมพลีเมนต์แบบตรงไปตรงมาจึงชนเพดาน

• ในการทดลองก่อนหน้า ใช้วิธีให้เอเจนต์เริ่มต้นแยกสเปกของผลิตภัณฑ์ออกเป็นรายการงาน และให้เอเจนต์เขียนโค้ดอิมพลีเมนต์ทีละฟีเจอร์ โดย ส่งต่อคอนเท็กซ์ข้ามเซสชันผ่านอาร์ติแฟกต์
  • ในคอมมูนิตี้นักพัฒนาก็เริ่มมีแนวทางคล้ายกัน เช่น วิธีแบบ "Ralph Wiggum" ที่ใช้ hook หรือสคริปต์เพื่อให้เอเจนต์อยู่ในลูปทำงานซ้ำอย่างต่อเนื่อง
• กับงานที่ซับซ้อน ยังคงพบปัญหาว่าเอเจนต์ค่อย ๆ หลุดออกจากเส้นทางเมื่อเวลาผ่านไป และสังเกตเห็นรูปแบบความล้มเหลวร่วมกัน 2 แบบ
• รูปแบบความล้มเหลวแบบแรก: เมื่อ context window เต็ม โมเดลจะสูญเสียความสม่ำเสมอ และบางโมเดลมีแนวโน้มเกิดอาการ "context anxiety" คือเมื่อคิดว่าตนเองใกล้ถึงขีดจำกัดของคอนเท็กซ์ ก็จะพยายามปิดงานก่อนเวลา
  • context reset (ล้าง context window ทั้งหมด แล้วเริ่มเอเจนต์ใหม่ด้วย structured handoff ที่มีสถานะของเอเจนต์ก่อนหน้าและขั้นตอนถัดไป) แก้ปัญหาทั้งสองอย่างได้
  • วิธีนี้ต่างจาก compaction ที่ให้เอเจนต์ตัวเดิมทำงานต่อโดยสรุปช่วงก่อนหน้าของบทสนทนา แม้ compaction จะรักษาความต่อเนื่องได้ แต่ไม่ได้ให้สภาวะเริ่มใหม่แบบ clean slate จึงอาจทำให้ context anxiety ยังคงอยู่
  • ใน Claude Sonnet 4.5 ปัญหา context anxiety รุนแรงมากจน compaction เพียงอย่างเดียวไม่สามารถรับประกันประสิทธิภาพของงานระยะยาวได้ ทำให้ context reset กลายเป็นองค์ประกอบสำคัญของการออกแบบฮาร์เนส
• รูปแบบความล้มเหลวแบบที่สอง: ปัญหา self-evaluation คือเมื่อเอเจนต์ประเมินผลงานที่ตนเองสร้างขึ้น มักจะชื่นชมอย่างมั่นใจแม้ว่าคุณภาพจริงจะธรรมดาอย่างชัดเจน
  • ปัญหานี้ยิ่งรุนแรงในงานเชิงอัตวิสัยอย่างงานออกแบบ เพราะไม่มีการตรวจแบบไบนารีเหมือนซอฟต์แวร์เทสต์ที่ตรวจสอบได้
  • การแยกเอเจนต์ที่ทำงานออกจากเอเจนต์ที่ประเมินเป็นคันโยกที่ทรงพลัง และการปรับจูน evaluator อิสระให้มีความสงสัยในเชิงวิพากษ์ นั้นจัดการได้ง่ายกว่าการทำให้ generator วิจารณ์ตัวเองอย่างเข้มงวดมาก

งานออกแบบฟรอนต์เอนด์: ทำให้คุณภาพเชิงอัตวิสัยกลายเป็นสิ่งที่ให้คะแนนได้

• หากไม่มีการแทรกแซง Claude มักสร้าง เลย์เอาต์ที่ปลอดภัยและคาดเดาได้ ซึ่งใช้งานได้ในเชิงเทคนิค แต่ดูธรรมดาในเชิงภาพ
• มี 2 ข้อค้นพบสำคัญที่กำหนดทิศทางการออกแบบฮาร์เนส
  • แม้จะไม่สามารถให้คะแนนความงามได้อย่างสมบูรณ์ แต่สามารถปรับปรุงได้ด้วย เกณฑ์การให้คะแนนที่เข้ารหัสหลักการและความชอบด้านการออกแบบ — คำถามว่า "ดีไซน์นี้สวยหรือไม่?" ให้คะแนนได้สม่ำเสมอน้อยกว่าคำถามว่า "สิ่งนี้ทำตามหลักการออกแบบที่ดีหรือไม่?"
  • การแยก การสร้าง ออกจาก การให้คะแนน ในงานฟรอนต์เอนด์ ช่วยสร้าง feedback loop ที่ผลักดันให้ generator สร้างผลงานที่แข็งแรงขึ้น
• เกณฑ์การให้คะแนน 4 ข้อ ที่ให้ทั้งกับ generator และ evaluator:
  • Design quality: สี ตัวอักษร เลย์เอาต์ รูปภาพ ฯลฯ รวมกันเป็นภาพรวมที่สอดคล้องกันและสร้างบรรยากาศกับอัตลักษณ์ที่ชัดเจนหรือไม่
  • Originality: มีหลักฐานของการตัดสินใจที่ออกแบบเองหรือไม่ หรือเป็นแค่เลย์เอาต์จากเทมเพลต ค่าเริ่มต้นของไลบรารี หรือแพตเทิร์นที่ AI ชอบสร้าง — ถ้ามีสัญญาณแบบ AI-generated เช่นการ์ดสีขาวบนพื้นหลังไล่เฉดสีม่วงถือว่าล้มเหลว
  • Craft: คุณภาพเชิงเทคนิคของการลงมือทำ เช่น ลำดับชั้นของตัวอักษร ความสม่ำเสมอของระยะห่าง ความกลมกลืนของสี อัตราส่วนคอนทราสต์ — เป็นการตรวจความชำนาญ ไม่ใช่ความคิดสร้างสรรค์
  • Functionality: ความใช้งานได้ที่แยกจากความงาม — ผู้ใช้เข้าใจหรือไม่ว่าอินเทอร์เฟซนี้ทำอะไร และหาการกระทำหลักเจอหรือไม่
• มีการ ให้น้ำหนักกับ design quality และ originality สูงกว่า craft และ functionality — เพราะ Claude ได้คะแนน craft และ functionality สูงอยู่แล้วโดยธรรมชาติ แต่ยังให้ผลลัพธ์ที่ธรรมดาในด้านดีไซน์และความแปลกใหม่
  • เกณฑ์ยัง หักคะแนนแพตเทิร์น "AI slop" ที่พบบ่อยอย่างชัดเจน เพื่อกระตุ้นให้โมเดลกล้าเสี่ยงด้านสุนทรียะมากขึ้น
• สร้าง orchestration ด้วย Claude Agent SDK โดยให้ generator สร้างฟรอนต์เอนด์ด้วย HTML/CSS/JS ส่วน evaluator ใช้ Playwright MCP โต้ตอบกับเพจจริง ถ่ายสกรีนช็อต ตรวจงานละเอียด แล้วให้คะแนนพร้อมคำวิจารณ์แบบละเอียด
  • ทำซ้ำ 5–15 รอบต่อหนึ่งการสร้าง โดยในแต่ละรอบ generator จะตอบสนองต่อคำวิจารณ์ของ evaluator และค่อย ๆ ขยับไปในทิศทางที่มีเอกลักษณ์มากขึ้น
  • การรันทั้งหมดอาจใช้เวลาสูงสุด 4 ชั่วโมง
  • สั่งให้ generator ตัดสินใจเชิงกลยุทธ์หลังการประเมินแต่ละครั้ง: ถ้าแนวโน้มคะแนนดีให้ปรับปรุงทิศทางเดิม แต่ถ้าวิธีนั้นไม่เวิร์กก็ให้เปลี่ยนไปสู่สุนทรียะแบบใหม่ทั้งหมด
• ถ้อยคำในเกณฑ์มีผลต่อ generator ในแบบที่ไม่คาดคิด — วลีอย่าง "งานออกแบบที่ดีที่สุดมีคุณภาพระดับพิพิธภัณฑ์" ทำให้ผลลัพธ์คอนเวิร์จไปในทิศทางภาพแบบเฉพาะเจาะจง แสดงว่าการพรอมป์ตที่ผูกกับเกณฑ์มีผลต่อบุคลิกของเอาต์พุตโดยตรง
• คะแนนโดยทั่วไปดีขึ้นเมื่อทำซ้ำ แต่ไม่ได้เป็นเส้นตรงเสมอไป และบ่อยครั้งก็ ชอบเวอร์ชันกลางทางมากกว่าเวอร์ชันสุดท้าย
  • ความซับซ้อนในการอิมพลีเมนต์มักเพิ่มขึ้นตามจำนวนรอบ เพราะตัวระบบพยายามหาทางออกที่ทะเยอทะยานขึ้นเพื่อตอบสนองต่อ feedback จาก evaluator
  • ตั้งแต่รอบแรกก็ได้ผลลัพธ์ที่ดีกว่า baseline แบบไม่ต้องพรอมป์ตอย่างเห็นได้ชัด เพราะตัวเกณฑ์และภาษาที่เกี่ยวข้องก็ช่วยดันโมเดลให้ออกจากค่าเริ่มต้นแบบทั่วไป แม้ก่อนจะได้รับ feedback จาก evaluator ก็ตาม
• กรณีเว็บไซต์พิพิธภัณฑ์ศิลปะดัตช์: จนถึงรอบที่ 9 ระบบสร้างหน้า landing page ธีมมืดที่สะอาดตา แต่ในรอบที่ 10 กลับทิ้งแนวทางเดิมทั้งหมดแล้ว ออกแบบใหม่เป็นประสบการณ์เชิงพื้นที่ด้วยห้อง 3D ที่เรนเดอร์ด้วย CSS perspective มีพื้นลายตาราง งานศิลป์แขวนผนังอย่างอิสระ และมีการนำทางระหว่างแกลเลอรีผ่านประตู — เป็นการกระโดดเชิงความคิดสร้างสรรค์ที่ไม่เคยเห็นจากการสร้างแบบ single pass

ขยายไปสู่การเขียนโค้ดฟูลสแตก

สถาปัตยกรรม

• ใน ฮาร์เนสแบบรันระยะยาว ก่อนหน้านี้ ระบบแก้ปัญหาการเขียนโค้ดหลายเซสชันอย่างสม่ำเสมอด้วยเอเจนต์เริ่มต้น เอเจนต์เขียนโค้ดตามฟีเจอร์ และการทำ context reset ระหว่างเซสชัน
  • สำหรับ Sonnet 4.5 การทำ context reset เป็นเรื่องสำคัญเพราะมี context anxiety แต่ใน Opus 4.5 พฤติกรรมนี้ถูกกำจัดออกไปเป็นส่วนใหญ่ จึงสามารถทำทั้งการบิลด์ในเซสชันต่อเนื่องเดียวได้โดยไม่ต้องทำ context reset
  • automatic compaction ของ Claude Agent SDK จัดการกับคอนเท็กซ์ที่ขยายใหญ่ขึ้น
• สร้างระบบ 3 เอเจนต์ ดังนี้:
  • Planner: ขยายพรอมป์ตสั้น ๆ 1–4 ประโยคให้กลายเป็น สเปกผลิตภัณฑ์ฉบับเต็ม — พรอมป์ตให้โฟกัสที่คอนเท็กซ์ของผลิตภัณฑ์และการออกแบบเชิงเทคนิคระดับสูง มากกว่ารายละเอียดเชิงอิมพลีเมนต์ เพราะหากกำหนดรายละเอียดทางเทคนิคไว้ล่วงหน้ามากเกินไป ความผิดพลาดอาจไหลต่อไปยังขั้นตอนถัดไป
    • ยังสั่งให้มองหาโอกาสในการ สอดแทรก ฟีเจอร์ AI เข้าไปในสเปกผลิตภัณฑ์ด้วย
  • Generator: หยิบฟีเจอร์จากสเปกมาทำทีละส่วนในระดับสปรินต์ อิมพลีเมนต์ด้วยสแตก React/Vite/FastAPI/SQLite (ภายหลังเปลี่ยนเป็น PostgreSQL) ทำ self-evaluation เมื่อจบแต่ละสปรินต์ก่อนส่งต่อให้ QA และ จัดการเวอร์ชันด้วย git
  • Evaluator: ใช้ Playwright MCP คลิกใช้งานแอปที่กำลังรันเหมือนผู้ใช้จริง เพื่อทดสอบการทำงานของ UI, API endpoint และสถานะฐานข้อมูล — ให้คะแนนตามเกณฑ์ด้านความลึกของผลิตภัณฑ์ ความสามารถใช้งานได้ งานออกแบบภาพ และคุณภาพโค้ด โดยหากไม่ผ่าน hard threshold ของเกณฑ์ใดเกณฑ์หนึ่ง สปรินต์นั้นจะถือว่าล้มเหลว
• ก่อนแต่ละสปรินต์ generator และ evaluator จะ เจรจา sprint contract กันก่อน — ตกลงร่วมกันให้ได้ว่าอะไรคือคำจำกัดความของคำว่า "เสร็จ" สำหรับชิ้นงานนั้น ก่อนจะเริ่มเขียนโค้ด
  • เพราะตัวสเปกผลิตภัณฑ์ถูกตั้งใจทำให้เป็นระดับสูง ขั้นตอนนี้จึงช่วยอุดช่องว่างระหว่าง user story กับการอิมพลีเมนต์ที่ทดสอบได้จริง
  • การสื่อสารถูกจัดการแบบ อิงไฟล์ — เอเจนต์หนึ่งเขียนไฟล์ อีกเอเจนต์อ่านแล้วตอบกลับ

ผลลัพธ์การรันฮาร์เนส: เครื่องมือสร้างเกมเรโทร

• ทดสอบด้วยพรอมป์ตว่า "สร้าง เครื่องมือสร้างเกมเรโทร 2D ที่มี level editor, sprite editor, พฤติกรรมของเอนทิตี และโหมดทดสอบที่เล่นได้"
• เอเจนต์เดี่ยว: 20 นาที / $9 เทียบกับ ฮาร์เนสเต็มรูปแบบ: 6 ชั่วโมง / $200 — ฮาร์เนสแพงกว่ากว่า 20 เท่า แต่ความต่างด้านคุณภาพของผลลัพธ์เห็นได้ชัดทันที
• ผลลัพธ์จากการรันแบบเดี่ยว: หน้าจอแรกดูตรงตามความคาดหวัง แต่เมื่อคลิกใช้งานก็เริ่มเห็นปัญหา — เลย์เอาต์ใช้พื้นที่เปลือง เวิร์กโฟลว์แข็งทื่อ ต้องสร้างสไปรต์กับเอนทิตีก่อนแต่ UI ไม่ได้ชี้นำ และที่สำคัญคือ ตัวเกมจริงเล่นไม่ได้ (เอนทิตีแสดงบนหน้าจอแต่ไม่ตอบสนองต่ออินพุต เพราะการเชื่อมต่อระหว่างนิยามเอนทิตีกับ runtime ของเกมขาดหาย)
• ผลลัพธ์จากฮาร์เนส: planner ขยายพรอมป์ตเพียงประโยคเดียวเป็น สเปกฟีเจอร์ 16 รายการตลอด 10 สปรินต์ — มีทั้งระบบแอนิเมชันสไปรต์ เทมเพลตพฤติกรรม ซาวด์เอฟเฟกต์และดนตรี ตัวสร้างสไปรต์และตัวออกแบบเลเวลแบบ AI-assisted รวมถึงการส่งออกเกมเป็นลิงก์แชร์ได้
  • ระบบอ่านทักษะด้านการออกแบบฟรอนต์เอนด์แล้วสร้าง ภาษาการออกแบบเชิงภาพ ของแอปเป็นส่วนหนึ่งของสเปก
  • แคนวาสใช้พื้นที่ทั้ง viewport ขนาดพาเนลสมเหตุสมผล และมีอัตลักษณ์ทางภาพที่สอดคล้องกับทิศทางการออกแบบในสเปก
  • sprite editor มีฟีเจอร์ครบและลึกกว่าเดิม มี tool palette ที่สะอาดกว่า color picker ที่ดีกว่า และการควบคุมการซูมที่ใช้งานได้มากกว่า
  • มีการผสาน AI เพื่อเร่งเวิร์กโฟลว์ โดยสร้างส่วนต่าง ๆ ของเกมผ่านการพรอมป์ต
• ความต่างสำคัญในโหมดเล่น: การรันแบบเดี่ยวทำให้เกมเล่นไม่ได้ แต่การรันผ่านฮาร์เนส สามารถขยับเอนทิตีและเล่นเกมได้จริง — แม้จะยังมีความหยาบของฟิสิกส์อยู่บ้าง (แพลตฟอร์มกับตัวละครซ้อนกัน) และข้อจำกัดของการจัดองค์ประกอบเลเวลโดย AI (มีกำแพงสูงที่กระโดดข้ามไม่ได้) แต่ฟังก์ชันหลักทำงาน
• evaluator มีบทบาทคอยตรึงการอิมพลีเมนต์ให้อยู่ตามสเปก — แค่ Sprint 3 สำหรับ level editor ก็มีสัญญาที่ละเอียดมาก ครอบคลุม 27 เกณฑ์
  • ตัวอย่างปัญหาที่พบ: เครื่องมือเติมสี่เหลี่ยมวางไทล์แค่จุดเริ่มและจุดสิ้นสุดของการลาก, เงื่อนไขผิดพลาดใน key handler สำหรับลบเอนทิตี, ปัญหาลำดับ route ของ FastAPI ทำให้ reorder ถูก parse เป็นจำนวนเต็มและส่ง 422 error กลับมา
• การปรับจูน evaluator ต้องใช้แรงมากพอสมควร — ในสภาพตั้งต้น Claude เป็น QA agent ที่ไม่ดีนัก มักเจอปัญหาที่ชอบธรรมแล้วกลับโน้มน้าวตัวเองว่า "ไม่ใช่ปัญหาใหญ่" จึงปล่อยผ่าน และยังพลาดบั๊กละเอียดจากการทดสอบผิวเผิน
  • ต้อง วนลูปพัฒนา อยู่หลายรอบด้วยการอ่านล็อกของ evaluator หาเคสที่การตัดสิน diverge แล้วอัปเดตพรอมป์ตของ QA จึงจะได้การให้คะแนนที่สมเหตุสมผล

การปรับปรุงฮาร์เนสแบบวนซ้ำ

• แม้ผลลัพธ์แรกเริ่มจะน่าประทับใจ แต่ระบบก็ ใหญ่ ช้า และแพง ดังนั้นขั้นต่อไปคือทำฮาร์เนสให้เรียบง่ายลงโดยไม่ให้ประสิทธิภาพลดลง
  • ทุกองค์ประกอบของฮาร์เนสคือการเข้ารหัสสมมติฐานเกี่ยวกับสิ่งที่โมเดลยังทำเองไม่ได้ และสมมติฐานเหล่านี้ ควรค่าแก่การ stress test — เพราะเมื่อโมเดลดีขึ้น มันอาจล้าสมัยอย่างรวดเร็ว
  • ยึดหลักว่า "หาวิธีแก้ที่เรียบง่ายที่สุดเท่าที่จะเป็นไปได้ และค่อยเพิ่มความซับซ้อนเมื่อจำเป็นเท่านั้น"
• ความพยายามลดความซับซ้อนแบบสุดโต่งไม่สามารถทำซ้ำประสิทธิภาพเดิมได้ และเพราะยากจะรู้ว่าชิ้นส่วนไหนเป็นตัวรับภาระจริง จึงเปลี่ยนมาใช้แนวทางเป็นระบบด้วยการ ถอดองค์ประกอบออกทีละอย่าง
• การเปิดตัว Opus 4.6 เป็นแรงผลักดันเพิ่มเติมให้ลดความซับซ้อนของฮาร์เนส — มันวางแผนอย่างรอบคอบขึ้น รักษางานแบบ agentic ได้นานขึ้น ทำงานกับโค้ดเบสขนาดใหญ่ได้เสถียรกว่า เดบักและรีวิวโค้ดเพื่อจับความผิดพลาดของตัวเองได้ดีขึ้น และ การค้นหาในคอนเท็กซ์ยาวก็ดีขึ้นอย่างมาก

การถอดโครงสร้างสปรินต์ออก

• ถอดโครงสร้างสปรินต์ออกทั้งหมด — ด้วยความสามารถที่ดีขึ้นของ Opus 4.6 โมเดลสามารถรับมือกับงานได้อย่างสม่ำเสมอโดยไม่ต้องแยกย่อย
• ยังคงเก็บ planner และ evaluator ไว้ — หากไม่มี planner, generator จะ ขาดขอบเขตงาน และเริ่มบิลด์จาก raw prompt โดยไม่มีสเปก ทำให้ได้แอปพลิเคชันที่มีฟีเจอร์น้อย
• ปรับ evaluator จากการให้คะแนนรายสปรินต์เป็น single pass เดียวเมื่อจบการรัน
  • หากงานอยู่ในขอบเขตความสามารถที่โมเดลทำคนเดียวได้ evaluator จะกลายเป็น overhead ที่ไม่จำเป็น แต่สำหรับ งานที่อยู่ตรงขอบเขตความสามารถของโมเดล มันยังช่วยยกระดับได้จริง
  • ดังนั้น evaluator จึงไม่ใช่คำตอบแบบตายตัวว่าใช้หรือไม่ใช้ แต่คุ้มค่าต้นทุนเมื่อเราพยายามก้าวเลยขอบเขตที่โมเดลรุ่นปัจจุบันยังทำได้ไม่เสถียรด้วยตัวเอง
• ยังเพิ่มการพรอมป์ตเพื่อปรับปรุงการบิลด์ฟีเจอร์ AI — ต้องทำซ้ำอยู่มากกว่าจะทำให้ generator สร้างเอเจนต์ที่เหมาะสมซึ่งขับเคลื่อนฟีเจอร์ของแอปเองผ่านเครื่องมือ ได้ เพราะความรู้ในเรื่องนี้ค่อนข้างใหม่และชุดข้อมูลการฝึกของ Claude ครอบคลุมบาง

ผลลัพธ์จากฮาร์เนสเวอร์ชันอัปเดต: DAW บนเบราว์เซอร์

• ทดสอบด้วยพรอมป์ตว่า "สร้าง DAW ที่มีฟังก์ชันครบในเบราว์เซอร์โดยใช้ Web Audio API"
• ใช้เวลารวม ประมาณ 4 ชั่วโมง, $124.70
  • planner 4.7 นาที/$0.46, build round1 2 ชั่วโมง 7 นาที/$71.08, QA round1 8.8 นาที/$3.24, build round2 1 ชั่วโมง 2 นาที/$36.89, QA round2 6.8 นาที/$3.09, build round3 10.9 นาที/$5.88, QA round3 9.6 นาที/$4.06
• ตัว builder ทำงานได้อย่างสม่ำเสมอ นานเกิน 2 ชั่วโมงโดยไม่ต้องแตกเป็นสปรินต์
• feedback รอบแรกจาก QA agent: ความสมบูรณ์ของดีไซน์, AI agent และ backend ทำได้ดี แต่ ความครบถ้วนของฟังก์ชันคือจุดล้มเหลวหลัก — ลากหรือย้ายคลิปบนไทม์ไลน์ไม่ได้, ไม่มีแผง UI สำหรับเครื่องดนตรี (ปุ่ม synth, drum pad), ไม่มีตัวแก้ไขเอฟเฟกต์แบบภาพ (EQ curve, compressor meter)
• feedback รอบสองจาก QA: การบันทึกเสียงยังเป็น stub, ยังไม่มีการ resize และ split คลิป, การแสดงผลเอฟเฟกต์ยังเป็นสไลเดอร์ตัวเลขแทนกราฟิก
• แอปสุดท้าย: ยังไม่ถึงระดับโปรแกรมทำเพลงระดับมืออาชีพ และความสามารถในการแต่งเพลงของเอเจนต์ยังต้องพัฒนา เพราะ Claude ฟังเสียงจริงไม่ได้ ทำให้ feedback loop ของ QA มีประสิทธิภาพน้อยลงในเรื่องรสนิยมทางดนตรี
  • อย่างไรก็ตาม มันมีองค์ประกอบหลักของโปรแกรมทำเพลงที่ใช้งานได้จริง เช่น arrangement view, mixer, transport ที่ทำงานได้
  • สามารถสร้างท่อนเพลงสั้น ๆ ได้ด้วยการพรอมป์ตเพียงอย่างเดียว — เอเจนต์สามารถตั้ง tempo และ key, วางเมโลดี, สร้างแทร็กกลอง, ปรับระดับใน mixer และเพิ่ม reverb

มุมมองต่อจากนี้

• เมื่อโมเดลดีขึ้น ก็คาดว่าจะทำงานที่ยาวขึ้นและซับซ้อนขึ้นได้ และในบางกรณี ความสำคัญของ scaffold รอบโมเดลอาจลดลง หมายความว่าหากรอโมเดลรุ่นถัดไป ปัญหาบางอย่างอาจหายไปเองตามธรรมชาติ
• ในอีกด้านหนึ่ง ยิ่งโมเดลดีขึ้น พื้นที่สำหรับพัฒนาฮาร์เนสที่ทำงานได้เหนือกว่า baseline ก็ยิ่งกว้างขึ้น
• บทเรียนสำคัญ:
  • การทดลองกับโมเดลที่ต้องการใช้สร้างของจริง, อ่าน trace จากปัญหาในโลกจริง และปรับจูนประสิทธิภาพให้เข้ากับผลลัพธ์ที่ต้องการ เป็นแนวปฏิบัติที่ดีเสมอ
  • กับงานที่ซับซ้อนขึ้น การแยกงานออกและใช้ เอเจนต์ที่เชี่ยวชาญเฉพาะด้าน กับแต่ละแง่มุม จะช่วยเปิดพื้นที่ความสามารถเพิ่มได้
  • เมื่อมีโมเดลใหม่ออกมา ก็ควรกลับมาทบทวนฮาร์เนส เพื่อตัดส่วนที่ ไม่ได้ช่วยรับภาระด้านประสิทธิภาพอีกต่อไป ออก และเพิ่มส่วนใหม่เพื่อไปให้ถึงความสามารถที่ใหญ่ขึ้นซึ่งก่อนหน้านี้ทำไม่ได้
• แม้โมเดลจะดีขึ้น พื้นที่ของการผสมผสานฮาร์เนสที่น่าสนใจก็ไม่ได้ลดลง แต่ ย้ายตำแหน่งไป และงานของวิศวกร AI คือการค้นหาการผสมผสานใหม่ถัดไปอย่างต่อเนื่อง