ทุกสิ่งที่ประกาศใน Code w/ Claude

xguru · 2026-05-14T11:50:02+09:00

การประชุมนักพัฒนาของ Anthropic: จัดขึ้นทั้งแบบออนไลน์และออฟไลน์ โดยงานออฟไลน์จะจัดที่ ซานฟรานซิสโก 5/6, ลอนดอน 5/19, โตเกียว 6/10 และมีการเผยแพร่วิดีโอ 19 เซสชัน จากงานที่ซานฟรานซิสโก Claude กำลังพัฒนาไปในทิศทางของ การทำงานที่ยาวนานขึ้น, หน่วยความจำระยะยาว, การใช้เครื่องมือมากขึ้น, การตรวจสอบที่ดีขึ้น การเปลี่ยนแปลงสำคัญคือสิ่งที่นักพัฒนาเคยต้องสร้างเองอย่าง การรันซ้ำ, การเลือกเครื่องมือ, การตรวจสอบ, หน่วยความจำ, การจัดการบริบท กำลังถูกนำเข้าไปอยู่ในผลิตภัณฑ์และแพลตฟอร์มของ Claude ความแตกต่างของผลิตภัณฑ์และองค์กรกำลังย้ายจากเรื่องวิธีเรียกใช้โมเดล ไปสู่การเปิดให้โมเดลเข้าถึง เครื่องมือ, ข้อมูล, สิทธิ์, บริบท แบบใด คอขวดใหม่กำลังขยับจากการเขียนโค้ดเอง ไปเป็นเรื่อง การตรวจสอบ, ความปลอดภัย, การจัดการสิทธิ์, การสังเกตการณ์ระบบ, ระบบประเมินผล, การดำเนินงานระดับองค์กร พื้นที่สำคัญต่อจากนี้คือ เครื่องมือแบบปรับแต่งเอง, หน่วยความจำที่เชื่อถือได้, การประเมินผล, ขอบเขตความปลอดภัย, context engineering, agent experience เซสชัน 1 - คีย์โน้ต เน้นการปรับปรุงผลิตภัณฑ์เพื่อให้ Claude Code และ Claude Platform ทำงานกับนักพัฒนาได้ดีขึ้น ผู้ใช้ส่วนใหญ่ไม่ได้ใช้ Claude API หรือเทอร์มินัลโดยตรง แต่ใช้ Claude ผ่านผลิตภัณฑ์ที่นักพัฒนาสร้างขึ้น ปริมาณการใช้งาน Claude Platform API เพิ่มขึ้นเกือบ 17 เท่า เมื่อเทียบกับปีก่อน นักพัฒนาโดยเฉลี่ยของ Claude Code ใช้งาน Claude 20 ชั่วโมงต่อสัปดาห์ ขีดจำกัดการใช้งาน 5 ชั่วโมง ของ Claude Code ถูกเพิ่มเป็น 2 เท่า สำหรับ Pro, Max, Team และ seat-based Enterprise plans ขีดจำกัด API ของ Claude Opus ก็เพิ่มขึ้นมากเช่นกัน มีแผนใช้ความจุของ ศูนย์ข้อมูล Colossus One ของ SpaceX เพื่อมอบทรัพยากรประมวลผลเพิ่มให้แก่นักพัฒนารายบุคคลและทีมขนาดเล็ก Opus 4.7 ช่วยเพิ่มประสิทธิภาพเอเจนต์เขียนโค้ด คุณภาพของการวางแผน และอัตราการแก้งานวิศวกรรมจริงได้ดีขึ้นที่ Amp, Rakuten และ Intuit Claude ในอนาคตกำลังมุ่งไปสู่ การตัดสินใจที่ดีขึ้น, บริบทและหน่วยความจำที่ใหญ่ขึ้น, การทำงานร่วมกันของหลายเอเจนต์ เซสชัน 2 - What's new in Claude Code ฟีเจอร์ใหม่ของ Claude Code แบ่งได้เป็นสองแกนคือ การใช้งานที่ดีขึ้นสำหรับนักพัฒนา และ การเพิ่มความสามารถในการทำงานอัตโนมัติ Remote Control ช่วยให้รับช่วงเซสชันที่เริ่มจากเทอร์มินัลต่อบนเว็บหรือมือถือได้ Full screen terminal UI ใช้ virtual scrollback เพื่อให้การเรนเดอร์ไม่กะพริบ และมีหน้าจอเรียกใช้เครื่องมือที่คลิกได้ GUI ของ Claude Code ถูกปรับให้จัดการหลายเซสชันได้ด้วยการปักหมุด กรอง จัดกลุ่ม และแบ่งหน้าจอ ใน plan view, diff view และ files view สามารถใส่คอมเมนต์ระดับบรรทัดไว้ได้ และ Claude จะรวบรวมไปจัดการภายหลัง Auto Mode จะจัดประเภทก่อนว่าการเรียกใช้เครื่องมือเป็นแบบทำลายล้างหรือดูคล้าย prompt injection หรือไม่ แล้วถ้าปลอดภัยก็รันได้โดยไม่ต้องยืนยันสิทธิ์ worktree ช่วยให้หลายเซสชันของ Claude ทำงานขนานกันได้บน branch ที่แยกจากกันและสำเนาไฟล์ของตัวเอง auto memory ให้ Claude จัดการ memory.md และไฟล์ที่เกี่ยวข้องแยกตามโปรเจ็กต์ พร้อมนำคำสั่ง build, เบาะแสการดีบัก และค่าความชอบของโปรเจ็กต์กลับมาใช้ในเซสชันถัดไป Routines และ /loop ทำให้สามารถรันเซสชัน Claude Code อัตโนมัติผ่าน cron, GitHub webhook และ API trigger ได้ เซสชัน 3 - Memory and dreaming for self-learning agents Memory ถูกวางให้เป็นองค์ประกอบพื้นฐานลำดับถัดไปจาก MCP, Claude Code, Agent SDK และ Skills หน่วยความจำของ Claude Managed Agents ถูกจัดโครงสร้าง เหมือนระบบไฟล์ เพื่อให้ Claude จัดระเบียบและอัปเดตได้เองผ่าน Bash และ Grep Opus 4.7 ตัดสินใจได้ดีขึ้นว่าควรเก็บอะไร แบ่งไฟล์อย่างไร และรักษาโครงสร้างหน่วยความจำอย่างไร สามารถแยก หน่วยความจำองค์กรแบบอ่านอย่างเดียว และ หน่วยความจำงานแบบอ่าน-เขียน เพื่อให้หลายเอเจนต์อ่านและเขียนที่เก็บหน่วยความจำเดียวกันได้ ใช้ การควบคุมการทำงานพร้อมกันแบบ optimistic บนพื้นฐาน content hash เพื่อป้องกันการเขียนทับ แม้มีเอเจนต์หลายร้อยตัวแก้ไขหน่วยความจำพร้อมกัน มีการบันทึก ประวัติการเปลี่ยนแปลง, ผู้สร้าง, เซสชัน, ช่วงเวลา เพื่อให้จัดการเป็นหน่วยความจำที่ตรวจสอบย้อนหลังได้ในสภาพแวดล้อมองค์กร Dreaming จะวิเคราะห์เซสชันและ transcript ล่าสุดของเอเจนต์แบบอะซิงโครนัส เพื่อค้นหาและจัดการข้อผิดพลาดที่เกิดซ้ำ กลยุทธ์ที่สำเร็จ หน่วยความจำซ้ำซ้อน และหน่วยความจำที่ล้าสมัย Harvey นำ Dreaming ไปใช้กับเกณฑ์ทดสอบด้านกฎหมาย และเพิ่ม อัตราการทำงานสำเร็จได้ 6 เท่า ในสถานการณ์กฎหมายหนึ่งแบบ ในเดโม SRE นั้น Dreaming ตรวจพบแพตเทิร์นการ retry ทุก 60 วินาทีที่หลายเอเจนต์มองแยกกันแล้วพลาด และนำสิ่งนั้นไปสะท้อนในหน่วยความจำ เป้าหมายคือการสร้าง โครงสร้างการเรียนรู้อย่างต่อเนื่อง ที่ทำให้งานของเอเจนต์ในวันนี้ช่วยทำให้เอเจนต์ของวันพรุ่งนี้ดีขึ้นโดยอัตโนมัติ เซสชัน 4 - Caching, harnesses, and advisors: Building on Claude at GitHub scale ในระดับของ GitHub Copilot นั้น prompt caching กลายเป็นวิธีหลักในการลดต้นทุนและเวลาแฝง เป้าหมายของอัตรา cache hit คือ 94-96% และถ้าอยู่แถว 70% จะถูกมองว่าเป็นสัญญาณว่ามีปัญหาในการประกอบพรอมป์ต์หรือการออกแบบแคช ส่วนต้นของ system prompt และรายการเครื่องมือควรถูกทำให้คงที่มากที่สุดเท่าที่ทำได้ หากมี UUID, เวลา หรือการโหลดเครื่องมือแบบไดนามิกอยู่ในส่วนต้น แคชจะแตกได้ง่าย แม้ใน harness ที่สลับไปมาระหว่างหลายโมเดล ก็ควรรักษาความเป็นมิตรต่อแคช เพื่อให้การเรียก Opus ใช้แคชเดิมซ้ำได้ GitHub หมุนเวียนโมเดลใหม่ตามลำดับ ออฟไลน์เบนช์มาร์ก, ใช้งานภายใน, A/B testing, online eval, การปรับแต่งหลังเปิดตัว กลยุทธ์ Advisor คือให้โมเดลรันงานราคาถูกทำงานส่วนใหญ่ และเรียก Opus มาเป็นที่ปรึกษาเฉพาะเวลาที่ต้องการการตัดสินใจสำคัญ สิ่งที่กำหนดคุณภาพและต้นทุนไม่ใช่แค่ตัวโมเดล แต่คือชั้นการปฏิบัติการที่รวม พรอมป์ต์, เครื่องมือ, แคช, การเลือกโมเดล, การประเมินผล, ฟีดแบ็กออนไลน์ เข้าด้วยกัน เซสชัน 5 - The expanding toolkit โค้ดส่วนเสริม ที่เมื่อปีก่อนยังต้องทำเอง ตอนนี้กำลังถูกรวมเข้าไปในโมเดลและ API แล้ว ในการใช้เครื่องมือนั้น คุณค่าของ manual router หรือ retry decorator กำลังลดลง Claude สามารถค้นหาเครื่องมือเอง ดูการเรียกใช้เครื่องมือที่ล้มเหลว กู้คืน แล้วเรียกใช้อีกครั้งได้ ในคำอธิบายเครื่องมือ ควรระบุไม่ใช่แค่ input แต่รวมถึง output schema ด้วย เมื่อรู้โครงสร้างผลลัพธ์ล่วงหน้า Claude จะใช้ผลลัพธ์ได้ดีขึ้นโดยไม่ต้องเรียกกลับไปกลับมาโดยไม่จำเป็น pre/post tool hook ของ Claude Code สามารถใช้บล็อกการเรียกบางประเภท หรือบันทึกและวิเคราะห์ผลลัพธ์โดยอัตโนมัติได้ บริบท 1 ล้านโทเค็น, การบีบอัดฝั่งเซิร์ฟเวอร์, การแก้ไขบริบท ทำให้การจัดการบริบทสำหรับงานยาว ๆ ง่ายขึ้น สกรีนช็อตเก่า ผลการค้นหาเก่า และผลการอ่านไฟล์เก่าสามารถลบออกเป็นระยะได้ โดยยังคงเก็บการตัดสินใจที่เกิดจากสิ่งเหล่านั้นไว้ Opus 4.7 สามารถคืนค่า พิกัดพิกเซลแบบ 1:1 จากสกรีนช็อตความละเอียดจริงได้สูงสุด 1440p ช่วยลดภาระการปรับเทียบพิกัดในงานอัตโนมัติบนหน้าจอ โค้ดที่ใช้ชดเชยข้อจำกัดของโมเดลมีอายุสั้น ขณะที่โค้ดที่เชื่อมต่อ เครื่องมือ, ข้อมูล, การยืนยันตัวตน, บริบทโดเมน ที่ Claude มองไม่เห็นจะอยู่ได้นานกว่า เซสชัน 6 - How to get to production faster with Claude Managed Agents Claude Managed Agents คือแพลตฟอร์มที่รวม การจัดการบริบท, การจัดการข้อมูลรับรอง, ความปลอดภัย, การควบคุมการเข้าถึง, การตรวจทานโดยมนุษย์, การสังเกตการณ์ ที่จำเป็นสำหรับเอเจนต์งานปฏิบัติการที่ทำงานเป็นเวลานาน องค์ประกอบพื้นฐานคือ agent configuration, environment และ session ใน session events สามารถดู user event, agent event, session event และ span event ได้ Console รวบรวมการตั้งค่า, environment, execution trace ทั้งหมด, คอขวด, มาตรการที่แนะนำ ไว้ในหน้าจอเดียว outcomes คือฟีเจอร์ที่ทำให้ Claude วนทำซ้ำจนกว่าจะผ่านเกณฑ์การสิ้นสุดและเกณฑ์การให้คะแนนที่กำหนดไว้ล่วงหน้า ยังมีการพูดถึงฟีเจอร์ขั้นสูงอย่างการประสานงานหลายเอเจนต์, memory และ Dreaming ร่วมด้วย ในเดโมแดชบอร์ด เอเจนต์ค้นพบการทำงานแบบขนาน, fast mode และการปรับแต่งพรอมป์ต์ จน ลดเวลาเรนเดอร์จากประมาณ 37 วินาทีเหลือ 10 วินาที เอเจนต์สำหรับงานปฏิบัติการไม่ใช่แค่ลูปการเรียกโมเดลซ้ำ ๆ แต่ต้องมี การติดตาม, การวิเคราะห์คอขวด, สิทธิ์, การตรวจสอบความถูกต้อง ร่วมด้วย เซสชัน 7 - A conversation with Dario Amodei & Daniela Amodei Anthropic มี การเติบโตของการใช้งานและรายได้ เร็วกว่าที่คาด จนทรัพยากรคอมพิวต์เริ่มไม่พอ บริษัทกำลังพยายามจัดหา ขีดความสามารถด้านคอมพิวต์เพิ่มเติม เพื่อส่งมอบให้แก่นักพัฒนาและผู้ใช้ได้มากขึ้น นักพัฒนาถูกมองว่าเป็นผู้ใช้หลักของ Claude และเป็นกลุ่มที่แสดงให้เห็นก่อนว่า AI กำลังกระจายไปทั่วเศรษฐกิจอย่างไร การเปลี่ยนแปลงถัดไปของ Claude Code คือการขยับจาก ผลิตภาพส่วนบุคคล ไปสู่ ผลิตภาพของทีมและองค์กร ยิ่งการเขียนโค้ดเร็วขึ้นเท่าไร ความปลอดภัย, การตรวจสอบความถูกต้อง, ความน่าเชื่อถือ, การบำรุงรักษา ก็ยิ่งกลายเป็นคอขวดใหม่ เมื่อความสามารถของโมเดลเปลี่ยนเร็ว ผลิตภัณฑ์ที่เมื่อไม่กี่เดือนก่อนยังเป็นไปไม่ได้ก็อาจกลายเป็นไปได้ขึ้นมาทันที ตลาด API จะยังคงสำคัญต่อไป Claude ในอนาคตจะก้าวข้ามจากการช่วยงานของคนคนเดียว ไปสู่การขยายงานของ หลายคนและหลายเอเจนต์ทั้งองค์กร เซสชัน 8 - Live coding session with Boris Cherny and Jarred Sumner Robobun ของ Bun จะรีโปรดิวซ์ GitHub issue โดยอัตโนมัติและสร้าง PR ที่มีการทดสอบรวมอยู่ด้วย ใช้ เงื่อนไขที่เวอร์ชันก่อนหน้าล้มเหลว แต่ผ่านได้ในสาขาที่แก้ไขแล้ว เป็นเกณฑ์ในการส่ง PR CLAUDE.md กลายเป็นเอกสารปฏิบัติการของเอเจนต์ที่บรรจุคำสั่ง build, คำสั่ง test, ตำแหน่งของ test, แพตเทิร์นความล้มเหลวในอดีต, โครงสร้างโฟลเดอร์ และวิธีอ่าน CI log ใช้ CodeRabbit, Claude Code Review และ Robobun ร่วมกันเพื่อทำให้งานด้านสไตล์, การปฏิบัติตาม CLAUDE.md และการตรวจสอบเงื่อนไขขอบเขตนอก diff เป็นอัตโนมัติ Claude Code และ Opus 4.7 เหมาะกับงานที่ค่อย ๆ ยกระดับประสิทธิภาพเมื่อ เป้าหมาย, วิธีวัดผล และรอบการตรวจสอบ ชัดเจน คอขวดกำลังย้ายจาก การเขียนโค้ด ไปสู่ การวางแผนและการตรวจสอบความถูกต้อง PR ที่เอเจนต์สร้างอาจไม่จำเป็นต้องเป็นผลลัพธ์ที่ต้อง merge เสมอไป แต่อาจถูกมองเป็นข้อเสนอที่นำมาตรวจทานได้ แม้ PR จากเอเจนต์จะเพิ่มขึ้น เกณฑ์การ merge ของมนุษย์ก็ไม่ได้ลดลง แต่อาจยิ่งสูงขึ้นด้วยซ้ำ เซสชัน 9 - Building with Claude Managed Agents and Asana AI teammates AI teammates ของ Asana ตั้งเป้าเป็นเอเจนต์ที่ทำงานเหมือนเพื่อนร่วมงานจริงภายในองค์กร เอเจนต์จะทำหน้าที่เป็น actor เพื่อจัดการการอนุมัติ, เวิร์กโฟลว์ และงานหลายขั้นตอนร่วมกับมนุษย์ การใช้เอเจนต์ในหลายองค์กรยังคงหยุดอยู่ที่โฟลว์แบบผู้ใช้คนเดียว ซึ่งคนหนึ่งรับผลลัพธ์แล้วส่งต่อให้คนถัดไป Asana มุ่งไปสู่โฟลว์การทำงานร่วมกันที่หลายคนโต้ตอบกับเอเจนต์ตัวเดียวกัน และมีการสะสมความรู้กับ memory อย่างต่อเนื่อง Asana work graph เชื่อมโยงเป้าหมาย, portfolio, project, task, approval และการตัดสินใจในอดีต เพื่อนำมาใช้เป็นบริบทของเอเจนต์ AI teammate จะเข้าสู่ระบบเหมือนเพื่อนร่วมงานที่เป็นมนุษย์ พร้อม การตั้งค่าที่ใช้ร่วมกัน, การควบคุมการเข้าถึงตามบทบาท, ความสามารถในการตรวจสอบย้อนหลัง Claude Managed Agents รองรับงานหลายขั้นตอนอย่าง การเขียนเอกสารแผนแคมเปญ และ การสร้าง mockup หน้า landing page แบบ HTML Asana มุ่งเน้นที่อินเทอร์เฟซสำหรับมนุษย์, บริบทระดับองค์กร, ความปลอดภัย และความสามารถในการตรวจสอบย้อนหลัง ส่วน Claude Managed Agents รับผิดชอบเรื่องรอบการตรวจสอบความถูกต้อง, grader, outcomes และการรันหลายเอเจนต์ มี AI teammates ที่สร้างไว้ล่วงหน้ามากกว่า 21 ตัว สำหรับงานด้าน PMO, การตลาด, IT, HR และ R&D ฟีดแบ็กจะถูกเก็บไว้ใน memory ของเอเจนต์ เพื่อไม่ให้ผู้ใช้คนถัดไปต้องเจอความผิดพลาดเดิมซ้ำอีก เซสชัน 10 - Running an AI-native engineering org ใน องค์กรวิศวกรรมแบบ AI-native ปริมาณงานการเขียนโค้ดจะไม่ใช่คอขวดที่แพงที่สุดอีกต่อไป การตรวจสอบความถูกต้อง, การรีวิว, ความปลอดภัย, การบำรุงรักษา, การประสานงานข้ามสายงาน จะกลายเป็นคอขวดใหม่ที่ใหญ่ขึ้น สำหรับทีม Claude Code แนวทางที่เหมาะกว่าการทำโรดแมป 6 เดือนหรือเอกสารออกแบบครบทุกงานล่วงหน้า คือการวางแผนในจังหวะที่เหมาะสมและสร้างต้นแบบอย่างรวดเร็ว การถกเถียงทางเทคนิคกำลังเปลี่ยนจากการคุยหน้าไวท์บอร์ดยาว ๆ ไปเป็นการสร้าง PR ของหลายแนวทางการพัฒนา เพื่อเปรียบเทียบผลกระทบจริงและรูปแบบ API เมื่อการสร้างโค้ดกลายเป็นเรื่องง่ายขึ้น การทดสอบ, ระบบอัตโนมัติ และการตรวจสอบที่เร็วขึ้นก็ยิ่งสำคัญกว่าเดิม สิ่งที่สำคัญกว่าคำถามว่า “ใครเป็นคนเขียนโค้ดนี้” คือการแยกแยะสาเหตุของ regression, การต้องการคำตอบจากผู้เชี่ยวชาญหรือไม่ และจุดประสงค์ของการจัดหาบริบท ทีม Claude Code มอบหมายให้ Claude จัดการเรื่องสไตล์, lint, ฟีดแบ็กใน PR, การแก้บั๊กบางส่วน และการเพิ่ม test การตรวจทานด้านกฎหมาย, โค้ดที่อ่อนไหวด้านความปลอดภัย, trust boundary, product sense ยังเป็นสิ่งที่ผู้เชี่ยวชาญมนุษย์ต้องดูต่อไป ในการจ้างงาน จะให้ความสำคัญกับ นักสร้างสรรค์ที่มี product sense และ ความเชี่ยวชาญเชิงลึกด้านระบบ มากกว่าปริมาณงานล้วน ๆ ตัวชี้วัดความสำเร็จอาจดูได้จาก เวลาการ onboarding ที่สั้นลง, รอบ PR ที่สั้นลง, จำนวน commit ที่ได้รับความช่วยเหลือจาก Claude ที่เพิ่มขึ้น เซสชัน 11 - Building AI-native: Inside the stacks powering Cognition, Gamma, and Harvey Gamma นำการปรับปรุงด้าน tool calling และการประสานงานเอเจนต์เข้าสู่ผลิตภัณฑ์อย่างรวดเร็ว เพื่อเสริมเวิร์กโฟลว์การแก้ไขแบบเอเจนต์ Gamma ใช้ MCP connector ไม่ใช่แค่เป็นฟีเจอร์เชื่อมต่อ แต่ยังเป็นช่องทางดึงลูกค้าและจุดเริ่มต้นของเวิร์กโฟลว์ด้วย Cognition ลดบางส่วนของระบบวางแผนและ memory ภายในที่สร้างเองลง เมื่อโมเดลทำงานด้านการแก้ไขโค้ด, การใช้ระบบไฟล์ และการวางแผนระยะยาวได้ดีขึ้น Harvey ออกแบบโครงสร้างผลิตภัณฑ์ใหม่ทุกครั้งที่เกิดจุดเปลี่ยนของ foundation model, reasoning model และ coding agent ความสามารถของแพลตฟอร์มปัจจุบันของ Harvey คงเกิดขึ้นได้ยากหากไม่ได้ใช้สถาปัตยกรรมแบบ agent-native ผลิตภัณฑ์ AI-native ต้องตั้งสมมติฐานว่าโครงสร้างเดิมอาจล้าสมัยได้ภายใน 6-12 เดือน การบันทึก, การสังเกตการณ์, การเล่นซ้ำ, การประเมินผล กลายเป็นกลไกจำเป็นเพื่อรับมือกับการเปลี่ยนแปลงโครงสร้างอย่างรวดเร็ว ในโดเมนที่อ่อนไหวอย่างกฎหมาย จำเป็นต้องมีขอบเขตข้อมูลที่แข็งแรงระหว่างข้อมูลสาธารณะ, ข้อมูลส่วนตัว, memory และโฟลว์ของเอเจนต์ สิ่งที่สำคัญขึ้นคือโครงสร้างที่ดูดซับการก้าวกระโดดของความสามารถครั้งถัดไปได้อย่างรวดเร็ว มากกว่าโครงสร้างที่ออกแบบมาให้เข้ากับข้อจำกัดของโมเดลเฉพาะตัวใดตัวหนึ่ง เซสชัน 12 - Architecting for model step-changes: A fireside with Vercel's Guillermo Rauch Vercel มองว่าโครงสร้างพื้นฐานแบบเอเจนต์เป็นทิศทางหลัก คลาวด์สามารถขยายไปเป็นโครงสร้างพื้นฐานที่ซ่อมแซมตัวเอง ปรับแต่งให้เหมาะสมเอง และเปลี่ยนการตั้งค่าเองได้ AI Gateway ถูกมองเหมือน CDN สำหรับโทเคน มันกลายเป็นชั้นที่ดูแลหลายผู้ให้บริการและหลายโมเดล พร้อมรับหน้าที่ routing, การรับมือเหตุขัดข้อง และการควบคุมต้นทุน Opus tokens มีสัดส่วนค่าใช้จ่ายสูงกว่าสัดส่วนการใช้งานมาก ดังนั้นเมื่อนำโมเดลอัจฉริยะสูงมาใส่ในผลิตภัณฑ์ ต้องมองโครงสร้างต้นทุนให้ชัดเจน หลังนำ Opus 4.5 มาใช้ V0 สามารถทำให้ตัวตรวจไวยากรณ์ การแก้อัตโนมัติ และบางขั้นตอนการประมวลผลที่เคยมีไว้เพื่อชดเชยโมเดลก่อนหน้า เรียบง่ายลงได้ การก้าวกระโดดของความสามารถโมเดลไม่ได้หมายถึงแค่การเพิ่มฟีเจอร์ใหม่ แต่ยังนำไปสู่การเปลี่ยนแปลงด้วยการลบโค้ดชดเชยเดิมออก หลังจากขยายการใช้ Opus ใน V0 ค่าใช้จ่ายเครดิตผลิตภัณฑ์เพิ่มขึ้น 2 เท่า ต่อจากนี้ ไม่ใช่แค่การพัฒนาด้วย CLI และ UI เท่านั้น แต่เอเจนต์แบบ asynchronous ที่มีการกำกับดูแลจากมนุษย์น้อยกว่านี้ก็อาจเติบโตมากขึ้น เซสชัน 13 - The thinking lever test-time compute คือแกนที่ Claude ใช้โทเคนและเวลามากขึ้นระหว่างการให้เหตุผลเพื่อแก้ปัญหาที่ยาก แม้จะเป็น Opus 4.7 ตัวเดียวกัน คุณภาพของการจำลองการจราจรก็แตกต่างกันมากตามระดับ effort แบบ low, high และ max ยิ่งใช้เวลาและโทเคนมากขึ้น กราฟิก การไหลของการจราจร และการเคลื่อนที่ของรถก็ยิ่งสมจริงมากขึ้น โทเคนที่ Claude ใช้แบ่งได้เป็นโทเคนการคิด โทเคนเรียกใช้เครื่องมือ และโทเคนข้อความ โทเคนการคิดใช้กับการให้เหตุผลภายใน โทเคนเรียกใช้เครื่องมือใช้กับการโต้ตอบกับโลกภายนอก และโทเคนข้อความใช้สื่อสารกับผู้ใช้ effort คือกลไกปรับสมดุลระหว่างเวลา ต้นทุน และคุณภาพ Task Budgets ช่วยให้กำหนดเพดานของโทเคน เวลา และต้นทุนที่ Claude ใช้กับงานเฉพาะได้ adaptive thinking คือการที่ Claude เลือกลำดับได้อย่างอิสระว่าจะคิด ใช้เครื่องมือ และตอบผู้ใช้เมื่อถึงจังหวะที่จำเป็น ใน use case แบบ coding และ agentic ค่าเริ่มต้นที่ดีมักถูกมองว่าเป็น extra high สำหรับงานจัดหมวดหมู่หรือดึงข้อมูลจำนวนมากแบบง่าย ๆ โมเดลขนาดเล็กจะได้เปรียบกว่า และหากต้องการให้งานที่ต้องใช้ความฉลาดจบเร็ว โมเดลใหญ่ที่ใช้ effort ต่ำอาจดีกว่า เซสชัน 14 - How Datadog built a universal machine tool for Claude Code ประมาณ 90% ของวิศวกร Datadog ใช้เครื่องมือเขียนโค้ด AI กับโค้ดที่ใช้งานจริง ในจำนวนนั้น อย่างน้อย 2/3 ใช้ Claude Code ขอบเขตการใช้เครื่องมือเขียนโค้ด AI ขยายจากฟังก์ชันเดี่ยว การทดสอบ และโค้ดเชื่อมต่อ ไปสู่การทำงานระดับระบบ คอขวดได้ย้ายจากการเขียนโค้ดไปอยู่ที่การวนลูป feedback และการตรวจสอบในสภาพแวดล้อมใช้งานจริง ใน Helix experiment Claude Code สามารถสร้างบริการสตรีมมิงที่คล้าย Kafka ได้ภายในไม่กี่วัน แต่หากจะนำไปสู่สภาพแวดล้อม production ต้องมี shadowing, validation ladder และ system mileage Tempor ทำให้เอเจนต์ไม่สร้างเครื่องมือแบบด้นสด แต่ให้สร้างพิมพ์เขียวที่บรรจุ state, transition, effect และ invariant ก่อน ตาราง transition, เอกสารนโยบาย, effect ที่มี type, validator และ property test ทำให้ซอฟต์แวร์ที่เอเจนต์สร้างสามารถตรวจสอบได้ หากต้องการให้อิสระกับ agent ก็ต้องทำให้ invariant และขั้นตอนการตรวจสอบของระบบ production อยู่ในรูปแบบที่เครื่องอ่านได้ เซสชัน 15 - Building with Claude on Google Cloud วิธีที่ง่ายที่สุดในการตั้งค่า Claude Code บน Google Cloud คือใช้ ตัวช่วยตั้งค่าที่อิงกับ Application Default Credentials ตัวช่วยตั้งค่าสามารถตรวจหาและตรึงค่า project, region และ model ที่ใช้งานได้ เมื่อใช้ Claude model บน Google Cloud จะใช้ประโยชน์จาก การคิดค่าบริการตามโทเคน, provisioned throughput, ภาระการสลับ API key ที่ลดลง, การบังคับใช้นโยบายระดับ project, การเก็บข้อมูลไว้ภายใน project และ regional/global endpoint ได้ เดโมดำเนินไปในรูปแบบที่บทบาท 5 แบบ ได้แก่ PM, UI/UX designer, software engineer, security engineer และ data/growth marketer ร่วมกันสร้างแอป feedback หนึ่งตัวจนจบ PM ใส่ wireframe ที่วาดด้วยมือลงใน Claude Code เพื่อทำต้นแบบอย่างรวดเร็ว ในขั้น UI/UX ใช้ plan mode เพื่อให้ Claude เสนอแผนก่อนลงมือพัฒนา Google Cloud developer knowledge API และ MCP server เชื่อม Claude Code เข้ากับเอกสารล่าสุดและคำแนะนำด้านสถาปัตยกรรม Google Cloud Skills ถูกใช้เพื่อช่วยทำบล็อกย่อยแต่ละส่วน เช่น การ deploy API บน Cloud Run และการเชื่อม Cloud Run กับ Firestore ใช้ sub-agent เพื่อทำ implementation ของ API, ingestion pipeline และ dashboard แบบขนานกัน security review prompt จะตรวจปัญหา OWASP หรือสิทธิ์ของ service account แก้ไขปัญหาที่พบ แล้วจึง deploy ไปยัง Cloud Run เซสชัน 16 - Getting more out of the Claude Platform ลำดับความสำคัญในการเพิ่มประสิทธิภาพเอเจนต์สำหรับ production คือ prompt caching, context engineering และ Advisor strategy prompt caching ช่วยลดต้นทุน input token ลดเวลาจนถึงโทเคนแรก และลดภาระเพดานการใช้งานของโทเคนที่ถูกแคช เป้าหมายของอัตรา cache hit ถูกมองว่าอยู่ในระดับ 90% ขึ้นไป ความเสถียรของพรอมป์ต์ช่วงต้น ตำแหน่งของนิยามเครื่องมือ และตำแหน่งที่แทรกค่าที่เปลี่ยนแปลงได้ ล้วนมีผลต่อแคช tool search tool จะดึงเฉพาะนิยามเครื่องมือที่จำเป็นเข้ามาในเวลาที่เหมาะสมเพื่อประหยัด context หากใส่ทุกเครื่องมือตั้งแต่แรก จะเป็นภาระทั้งกับ context และแคช programmatic tool calling จะไม่ใส่ผลลัพธ์จากเครื่องมือจำนวนมากเข้ามาตรง ๆ แต่เลือกเฉพาะส่วนที่จำเป็นมาใส่ใน context compaction ช่วยย่อบทสนทนาเก่าและผลลัพธ์จากเครื่องมือเพื่อให้งานที่ยาวสามารถดำเนินต่อได้ Advisor strategy คือให้ Sonnet หรือ Haiku ทำงานส่วนใหญ่ และเรียก Opus มาเป็นที่ปรึกษาเฉพาะตอนที่ต้องการการตัดสินใจสำคัญ หัวใจสำคัญไม่ใช่การเรียกใช้โมเดลให้มากขึ้น แต่คือการออกแบบว่าโมเดลจะทำงานภายใต้ context, เครื่องมือ และโครงสร้างแคชแบบใด เซสชัน 17 - Evaluating and improving Replit Agent at scale ผู้ใช้ Replit Agent คาดหวังแอปที่ทำงานได้จากเพียงภาษาธรรมชาติ โดยไม่ต้องระบุ framework หรือ test หากดูแค่ว่าแพตช์ผ่านการทดสอบหรือไม่เหมือนใน coding benchmark ทั่วไป ก็วัดคุณภาพของ Replit Agent ได้ยาก การประเมินต้องดูว่าแอปทำงานตามที่ผู้ใช้ขอจริงหรือไม่ Replit ใช้ทั้ง offline evaluation และ online evaluation ควบคู่กัน offline evaluation ทำหน้าที่เป็นด่านก่อนปล่อย agent release ใหม่ ส่วน online evaluation ใช้เพื่อรับมืออย่างรวดเร็วหลังมีการใช้งานจริง VibeBench คือ benchmark แบบเปิดที่ใช้ PRD จริง 20 ชุด เป็นอินพุต ให้สร้างแอปจาก repository ว่าง และมีผู้ประเมินอัตโนมัติทดสอบแอปในเบราว์เซอร์ โมเดลส่วนใหญ่มักยากกว่าเมื่อต้องขยายโค้ดที่ตัวเองสร้างไว้แล้วต่อไป ควรมีขั้นตอนการทดสอบและตรวจสอบคั่นระหว่างฟังก์ชัน เพื่อลดการสร้างต่อบนฐานที่สั่นคลอน Telescope คือระบบภายในที่จัดกลุ่ม execution trace จาก production ตามความหมาย เพื่อค้นหาความล้มเหลวแบบ long tail, จัดประเภทปัญหา, ให้ agent สร้าง PR และตรวจสอบด้วย VibeBench หรือการทดสอบ A/B การประเมินไม่ใช่เช็กลิสต์ยืนยันก่อนปล่อยเวอร์ชันขั้นสุดท้ายอีกต่อไป แต่กลายเป็น เอนจิน ที่ช่วยปรับปรุงเอเจนต์ทุกวัน เซสชัน 18 - The capability curve ผู้ใช้ Claude Code มี ความเชื่อมั่นที่มากขึ้น และ deploy ได้เร็วขึ้นกว่าปีก่อน ในการโหวตระหว่างการประกาศ มีผู้เข้าร่วมจำนวนมากตอบว่ารู้สึกว่า Claude ช่วยให้ เร็วขึ้น 10 เท่า, 5 เท่า, 2 เท่า บน SWE-bench Verified นั้น Sonnet 3.7 ทำได้ราว 62% และ Opus 4.7 ทำได้ 87% Opus 4.7 มีโอกาสสูงกว่า 3 เท่า ที่จะทำ PR ยาก ๆ ซึ่ง Sonnet 3.7 เคยทำไม่สำเร็จให้สำเร็จได้ ในเดโมที่ให้จำลอง Claude.ai ด้วยพรอมป์ต์เดียวกัน โมเดลก่อนหน้านี้สร้าง UI แชตทั่วไปและเกิดข้อผิดพลาด แต่ Opus 4.7 สามารถทำสีของ Claude, การตอบกลับจาก API, ประวัติแชต, กราฟิกแบบอินไลน์ และ dark mode ได้ ด้านที่พัฒนาขึ้นคือ การวางแผน, การกู้คืนจากข้อผิดพลาด, การรักษาสมาธิระหว่างการรันที่ยาวนาน โมเดลใหม่จะวางแผนก่อน หากล้มเหลวจะย้อนกลับ และยังคงรักษา system prompt กับเป้าหมายได้ดีกว่าเดิมแม้ในบริบทยาว ๆ ต้องสร้างการประเมินที่มีการกระจายใกล้เคียงกับการใช้งานจริงของผลิตภัณฑ์ จึงจะเห็นการพัฒนาที่เกิดขึ้นจริง ยิ่งโมเดลดีขึ้น การประเมินแบบเดิมก็ยิ่งอิ่มตัวได้ง่าย ดังนั้นการประเมินก็ต้องยากขึ้นอย่างต่อเนื่องเช่นกัน เมื่อมี frontier model ใหม่ออกมา ก็ควรลองลดขั้นตอนการปรับจูนและพรอมป์ต์เดิมลงอีกครั้ง เซสชัน 19 - Giving coding agents their own computers: How Cursor built cloud agents Cursor มองว่าคอขวดไม่ได้อยู่ที่ความฉลาดของโมเดล แต่เป็นเพราะมนุษย์ยังให้เครื่องมือ บริบท และเป้าหมายขนาดใหญ่แก่โมเดลได้ไม่เพียงพอ เช่นเดียวกับการ onboarding นักพัฒนาที่เป็นมนุษย์ เอเจนต์ก็ควรได้รับคอมพิวเตอร์ สภาพแวดล้อมการพัฒนา และเอกสาร onboarding agent ของ Cursor จะสำรวจ repository และทำความเข้าใจวิธีรันแอป, services, environment variables และสิทธิ์ต่าง ๆ AnyDev CLI เป็นเครื่องมือที่ช่วยให้เอเจนต์เริ่ม services, รอจนพร้อมใช้งาน, ตรวจสอบสถานะ และจัดการได้ตั้งแต่การสร้างบัญชีทดสอบไปจนถึงการล็อกอิน ยิ่งสภาพแวดล้อมการพัฒนาสำหรับเอเจนต์ดีขึ้น นักพัฒนาก็ยิ่งรัน cloud agent ได้มากขึ้นและมอบหมายงานที่ใหญ่ขึ้น หลักการพื้นฐานของ autonomy คือการให้นัยน์ตา เครื่องมือ และบริบทที่ดีแก่เอเจนต์ เอเจนต์ควรมองเห็นสถานะของแอป บทสนทนาของเอเจนต์ตัวอื่น และสถานะของ services ได้เหมือนมนุษย์ Cursor มองว่า computer use เป็นองค์ประกอบพื้นฐานสำคัญถัดจากการเขียนโค้ด Claude 4.7 ช่วยให้ agent อัดเดโมแบบ end-to-end ได้ด้วยตัวเองเพื่อตรวจสอบฟีเจอร์ และช่วยให้มนุษย์เข้าใจผลลัพธ์ได้อย่างรวดเร็วก่อนเริ่ม code review Cursor มอง agent experience เป็นงานออกแบบแยกต่างหาก และหากเอเจนต์เจอ flow ที่น่ารำคาญ พัง หรือชวนสับสน ก็จะให้บันทึกเป็น issue แบบ work on the factory เป้าหมายสุดท้ายไม่ใช่ให้มนุษย์คอยพาจาก A ไป D ด้วยมือ แต่คือการสร้าง ระบบที่แก้ปัญหาได้ตั้งแต่ A ถึง Z

(claude.com)

9 คะแนน โดย xguru 4 시간 전 | ยังไม่มีความคิดเห็น | แชร์ทาง WhatsApp

การประชุมนักพัฒนาของ Anthropic: จัดขึ้นทั้งแบบออนไลน์และออฟไลน์ โดยงานออฟไลน์จะจัดที่ ซานฟรานซิสโก 5/6, ลอนดอน 5/19, โตเกียว 6/10 และมีการเผยแพร่วิดีโอ 19 เซสชัน จากงานที่ซานฟรานซิสโก
Claude กำลังพัฒนาไปในทิศทางของ การทำงานที่ยาวนานขึ้น, หน่วยความจำระยะยาว, การใช้เครื่องมือมากขึ้น, การตรวจสอบที่ดีขึ้น
การเปลี่ยนแปลงสำคัญคือสิ่งที่นักพัฒนาเคยต้องสร้างเองอย่าง การรันซ้ำ, การเลือกเครื่องมือ, การตรวจสอบ, หน่วยความจำ, การจัดการบริบท กำลังถูกนำเข้าไปอยู่ในผลิตภัณฑ์และแพลตฟอร์มของ Claude
ความแตกต่างของผลิตภัณฑ์และองค์กรกำลังย้ายจากเรื่องวิธีเรียกใช้โมเดล ไปสู่การเปิดให้โมเดลเข้าถึง เครื่องมือ, ข้อมูล, สิทธิ์, บริบท แบบใด
คอขวดใหม่กำลังขยับจากการเขียนโค้ดเอง ไปเป็นเรื่อง การตรวจสอบ, ความปลอดภัย, การจัดการสิทธิ์, การสังเกตการณ์ระบบ, ระบบประเมินผล, การดำเนินงานระดับองค์กร
พื้นที่สำคัญต่อจากนี้คือ เครื่องมือแบบปรับแต่งเอง, หน่วยความจำที่เชื่อถือได้, การประเมินผล, ขอบเขตความปลอดภัย, context engineering, agent experience

เซสชัน 1 - คีย์โน้ต

เน้นการปรับปรุงผลิตภัณฑ์เพื่อให้ Claude Code และ Claude Platform ทำงานกับนักพัฒนาได้ดีขึ้น
ผู้ใช้ส่วนใหญ่ไม่ได้ใช้ Claude API หรือเทอร์มินัลโดยตรง แต่ใช้ Claude ผ่านผลิตภัณฑ์ที่นักพัฒนาสร้างขึ้น
ปริมาณการใช้งาน Claude Platform API เพิ่มขึ้นเกือบ 17 เท่า เมื่อเทียบกับปีก่อน
นักพัฒนาโดยเฉลี่ยของ Claude Code ใช้งาน Claude 20 ชั่วโมงต่อสัปดาห์
ขีดจำกัดการใช้งาน 5 ชั่วโมง ของ Claude Code ถูกเพิ่มเป็น 2 เท่า สำหรับ Pro, Max, Team และ seat-based Enterprise plans
ขีดจำกัด API ของ Claude Opus ก็เพิ่มขึ้นมากเช่นกัน
มีแผนใช้ความจุของ ศูนย์ข้อมูล Colossus One ของ SpaceX เพื่อมอบทรัพยากรประมวลผลเพิ่มให้แก่นักพัฒนารายบุคคลและทีมขนาดเล็ก
Opus 4.7 ช่วยเพิ่มประสิทธิภาพเอเจนต์เขียนโค้ด คุณภาพของการวางแผน และอัตราการแก้งานวิศวกรรมจริงได้ดีขึ้นที่ Amp, Rakuten และ Intuit
Claude ในอนาคตกำลังมุ่งไปสู่ การตัดสินใจที่ดีขึ้น, บริบทและหน่วยความจำที่ใหญ่ขึ้น, การทำงานร่วมกันของหลายเอเจนต์

เซสชัน 2 - What's new in Claude Code

ฟีเจอร์ใหม่ของ Claude Code แบ่งได้เป็นสองแกนคือ การใช้งานที่ดีขึ้นสำหรับนักพัฒนา และ การเพิ่มความสามารถในการทำงานอัตโนมัติ
Remote Control ช่วยให้รับช่วงเซสชันที่เริ่มจากเทอร์มินัลต่อบนเว็บหรือมือถือได้
Full screen terminal UI ใช้ virtual scrollback เพื่อให้การเรนเดอร์ไม่กะพริบ และมีหน้าจอเรียกใช้เครื่องมือที่คลิกได้
GUI ของ Claude Code ถูกปรับให้จัดการหลายเซสชันได้ด้วยการปักหมุด กรอง จัดกลุ่ม และแบ่งหน้าจอ
ใน plan view, diff view และ files view สามารถใส่คอมเมนต์ระดับบรรทัดไว้ได้ และ Claude จะรวบรวมไปจัดการภายหลัง
Auto Mode จะจัดประเภทก่อนว่าการเรียกใช้เครื่องมือเป็นแบบทำลายล้างหรือดูคล้าย prompt injection หรือไม่ แล้วถ้าปลอดภัยก็รันได้โดยไม่ต้องยืนยันสิทธิ์
worktree ช่วยให้หลายเซสชันของ Claude ทำงานขนานกันได้บน branch ที่แยกจากกันและสำเนาไฟล์ของตัวเอง
auto memory ให้ Claude จัดการ memory.md และไฟล์ที่เกี่ยวข้องแยกตามโปรเจ็กต์ พร้อมนำคำสั่ง build, เบาะแสการดีบัก และค่าความชอบของโปรเจ็กต์กลับมาใช้ในเซสชันถัดไป
Routines และ /loop ทำให้สามารถรันเซสชัน Claude Code อัตโนมัติผ่าน cron, GitHub webhook และ API trigger ได้

เซสชัน 3 - Memory and dreaming for self-learning agents

Memory ถูกวางให้เป็นองค์ประกอบพื้นฐานลำดับถัดไปจาก MCP, Claude Code, Agent SDK และ Skills
หน่วยความจำของ Claude Managed Agents ถูกจัดโครงสร้าง เหมือนระบบไฟล์ เพื่อให้ Claude จัดระเบียบและอัปเดตได้เองผ่าน Bash และ Grep
Opus 4.7 ตัดสินใจได้ดีขึ้นว่าควรเก็บอะไร แบ่งไฟล์อย่างไร และรักษาโครงสร้างหน่วยความจำอย่างไร
สามารถแยก หน่วยความจำองค์กรแบบอ่านอย่างเดียว และ หน่วยความจำงานแบบอ่าน-เขียน เพื่อให้หลายเอเจนต์อ่านและเขียนที่เก็บหน่วยความจำเดียวกันได้
ใช้ การควบคุมการทำงานพร้อมกันแบบ optimistic บนพื้นฐาน content hash เพื่อป้องกันการเขียนทับ แม้มีเอเจนต์หลายร้อยตัวแก้ไขหน่วยความจำพร้อมกัน
มีการบันทึก ประวัติการเปลี่ยนแปลง, ผู้สร้าง, เซสชัน, ช่วงเวลา เพื่อให้จัดการเป็นหน่วยความจำที่ตรวจสอบย้อนหลังได้ในสภาพแวดล้อมองค์กร
Dreaming จะวิเคราะห์เซสชันและ transcript ล่าสุดของเอเจนต์แบบอะซิงโครนัส เพื่อค้นหาและจัดการข้อผิดพลาดที่เกิดซ้ำ กลยุทธ์ที่สำเร็จ หน่วยความจำซ้ำซ้อน และหน่วยความจำที่ล้าสมัย
Harvey นำ Dreaming ไปใช้กับเกณฑ์ทดสอบด้านกฎหมาย และเพิ่ม อัตราการทำงานสำเร็จได้ 6 เท่า ในสถานการณ์กฎหมายหนึ่งแบบ
ในเดโม SRE นั้น Dreaming ตรวจพบแพตเทิร์นการ retry ทุก 60 วินาทีที่หลายเอเจนต์มองแยกกันแล้วพลาด และนำสิ่งนั้นไปสะท้อนในหน่วยความจำ
เป้าหมายคือการสร้าง โครงสร้างการเรียนรู้อย่างต่อเนื่อง ที่ทำให้งานของเอเจนต์ในวันนี้ช่วยทำให้เอเจนต์ของวันพรุ่งนี้ดีขึ้นโดยอัตโนมัติ

เซสชัน 4 - Caching, harnesses, and advisors: Building on Claude at GitHub scale

ในระดับของ GitHub Copilot นั้น prompt caching กลายเป็นวิธีหลักในการลดต้นทุนและเวลาแฝง
เป้าหมายของอัตรา cache hit คือ 94-96% และถ้าอยู่แถว 70% จะถูกมองว่าเป็นสัญญาณว่ามีปัญหาในการประกอบพรอมป์ต์หรือการออกแบบแคช
ส่วนต้นของ system prompt และรายการเครื่องมือควรถูกทำให้คงที่มากที่สุดเท่าที่ทำได้
หากมี UUID, เวลา หรือการโหลดเครื่องมือแบบไดนามิกอยู่ในส่วนต้น แคชจะแตกได้ง่าย
แม้ใน harness ที่สลับไปมาระหว่างหลายโมเดล ก็ควรรักษาความเป็นมิตรต่อแคช เพื่อให้การเรียก Opus ใช้แคชเดิมซ้ำได้
GitHub หมุนเวียนโมเดลใหม่ตามลำดับ ออฟไลน์เบนช์มาร์ก, ใช้งานภายใน, A/B testing, online eval, การปรับแต่งหลังเปิดตัว
กลยุทธ์ Advisor คือให้โมเดลรันงานราคาถูกทำงานส่วนใหญ่ และเรียก Opus มาเป็นที่ปรึกษาเฉพาะเวลาที่ต้องการการตัดสินใจสำคัญ
สิ่งที่กำหนดคุณภาพและต้นทุนไม่ใช่แค่ตัวโมเดล แต่คือชั้นการปฏิบัติการที่รวม พรอมป์ต์, เครื่องมือ, แคช, การเลือกโมเดล, การประเมินผล, ฟีดแบ็กออนไลน์ เข้าด้วยกัน

เซสชัน 5 - The expanding toolkit

โค้ดส่วนเสริม ที่เมื่อปีก่อนยังต้องทำเอง ตอนนี้กำลังถูกรวมเข้าไปในโมเดลและ API แล้ว
ในการใช้เครื่องมือนั้น คุณค่าของ manual router หรือ retry decorator กำลังลดลง
Claude สามารถค้นหาเครื่องมือเอง ดูการเรียกใช้เครื่องมือที่ล้มเหลว กู้คืน แล้วเรียกใช้อีกครั้งได้
ในคำอธิบายเครื่องมือ ควรระบุไม่ใช่แค่ input แต่รวมถึง output schema ด้วย
เมื่อรู้โครงสร้างผลลัพธ์ล่วงหน้า Claude จะใช้ผลลัพธ์ได้ดีขึ้นโดยไม่ต้องเรียกกลับไปกลับมาโดยไม่จำเป็น
pre/post tool hook ของ Claude Code สามารถใช้บล็อกการเรียกบางประเภท หรือบันทึกและวิเคราะห์ผลลัพธ์โดยอัตโนมัติได้
บริบท 1 ล้านโทเค็น, การบีบอัดฝั่งเซิร์ฟเวอร์, การแก้ไขบริบท ทำให้การจัดการบริบทสำหรับงานยาว ๆ ง่ายขึ้น
สกรีนช็อตเก่า ผลการค้นหาเก่า และผลการอ่านไฟล์เก่าสามารถลบออกเป็นระยะได้ โดยยังคงเก็บการตัดสินใจที่เกิดจากสิ่งเหล่านั้นไว้
Opus 4.7 สามารถคืนค่า พิกัดพิกเซลแบบ 1:1 จากสกรีนช็อตความละเอียดจริงได้สูงสุด 1440p ช่วยลดภาระการปรับเทียบพิกัดในงานอัตโนมัติบนหน้าจอ
โค้ดที่ใช้ชดเชยข้อจำกัดของโมเดลมีอายุสั้น ขณะที่โค้ดที่เชื่อมต่อ เครื่องมือ, ข้อมูล, การยืนยันตัวตน, บริบทโดเมน ที่ Claude มองไม่เห็นจะอยู่ได้นานกว่า

เซสชัน 6 - How to get to production faster with Claude Managed Agents

Claude Managed Agents คือแพลตฟอร์มที่รวม การจัดการบริบท, การจัดการข้อมูลรับรอง, ความปลอดภัย, การควบคุมการเข้าถึง, การตรวจทานโดยมนุษย์, การสังเกตการณ์ ที่จำเป็นสำหรับเอเจนต์งานปฏิบัติการที่ทำงานเป็นเวลานาน
องค์ประกอบพื้นฐานคือ agent configuration, environment และ session
ใน session events สามารถดู user event, agent event, session event และ span event ได้
Console รวบรวมการตั้งค่า, environment, execution trace ทั้งหมด, คอขวด, มาตรการที่แนะนำ ไว้ในหน้าจอเดียว
outcomes คือฟีเจอร์ที่ทำให้ Claude วนทำซ้ำจนกว่าจะผ่านเกณฑ์การสิ้นสุดและเกณฑ์การให้คะแนนที่กำหนดไว้ล่วงหน้า
ยังมีการพูดถึงฟีเจอร์ขั้นสูงอย่างการประสานงานหลายเอเจนต์, memory และ Dreaming ร่วมด้วย
ในเดโมแดชบอร์ด เอเจนต์ค้นพบการทำงานแบบขนาน, fast mode และการปรับแต่งพรอมป์ต์ จน ลดเวลาเรนเดอร์จากประมาณ 37 วินาทีเหลือ 10 วินาที
เอเจนต์สำหรับงานปฏิบัติการไม่ใช่แค่ลูปการเรียกโมเดลซ้ำ ๆ แต่ต้องมี การติดตาม, การวิเคราะห์คอขวด, สิทธิ์, การตรวจสอบความถูกต้อง ร่วมด้วย

เซสชัน 7 - A conversation with Dario Amodei & Daniela Amodei

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

เซสชัน 8 - Live coding session with Boris Cherny and Jarred Sumner

Robobun ของ Bun จะรีโปรดิวซ์ GitHub issue โดยอัตโนมัติและสร้าง PR ที่มีการทดสอบรวมอยู่ด้วย
ใช้ เงื่อนไขที่เวอร์ชันก่อนหน้าล้มเหลว แต่ผ่านได้ในสาขาที่แก้ไขแล้ว เป็นเกณฑ์ในการส่ง PR
CLAUDE.md กลายเป็นเอกสารปฏิบัติการของเอเจนต์ที่บรรจุคำสั่ง build, คำสั่ง test, ตำแหน่งของ test, แพตเทิร์นความล้มเหลวในอดีต, โครงสร้างโฟลเดอร์ และวิธีอ่าน CI log
ใช้ CodeRabbit, Claude Code Review และ Robobun ร่วมกันเพื่อทำให้งานด้านสไตล์, การปฏิบัติตาม CLAUDE.md และการตรวจสอบเงื่อนไขขอบเขตนอก diff เป็นอัตโนมัติ
Claude Code และ Opus 4.7 เหมาะกับงานที่ค่อย ๆ ยกระดับประสิทธิภาพเมื่อ เป้าหมาย, วิธีวัดผล และรอบการตรวจสอบ ชัดเจน
คอขวดกำลังย้ายจาก การเขียนโค้ด ไปสู่ การวางแผนและการตรวจสอบความถูกต้อง
PR ที่เอเจนต์สร้างอาจไม่จำเป็นต้องเป็นผลลัพธ์ที่ต้อง merge เสมอไป แต่อาจถูกมองเป็นข้อเสนอที่นำมาตรวจทานได้
แม้ PR จากเอเจนต์จะเพิ่มขึ้น เกณฑ์การ merge ของมนุษย์ก็ไม่ได้ลดลง แต่อาจยิ่งสูงขึ้นด้วยซ้ำ

เซสชัน 9 - Building with Claude Managed Agents and Asana AI teammates

AI teammates ของ Asana ตั้งเป้าเป็นเอเจนต์ที่ทำงานเหมือนเพื่อนร่วมงานจริงภายในองค์กร
เอเจนต์จะทำหน้าที่เป็น actor เพื่อจัดการการอนุมัติ, เวิร์กโฟลว์ และงานหลายขั้นตอนร่วมกับมนุษย์
การใช้เอเจนต์ในหลายองค์กรยังคงหยุดอยู่ที่โฟลว์แบบผู้ใช้คนเดียว ซึ่งคนหนึ่งรับผลลัพธ์แล้วส่งต่อให้คนถัดไป
Asana มุ่งไปสู่โฟลว์การทำงานร่วมกันที่หลายคนโต้ตอบกับเอเจนต์ตัวเดียวกัน และมีการสะสมความรู้กับ memory อย่างต่อเนื่อง
Asana work graph เชื่อมโยงเป้าหมาย, portfolio, project, task, approval และการตัดสินใจในอดีต เพื่อนำมาใช้เป็นบริบทของเอเจนต์
AI teammate จะเข้าสู่ระบบเหมือนเพื่อนร่วมงานที่เป็นมนุษย์ พร้อม การตั้งค่าที่ใช้ร่วมกัน, การควบคุมการเข้าถึงตามบทบาท, ความสามารถในการตรวจสอบย้อนหลัง
Claude Managed Agents รองรับงานหลายขั้นตอนอย่าง การเขียนเอกสารแผนแคมเปญ และ การสร้าง mockup หน้า landing page แบบ HTML
Asana มุ่งเน้นที่อินเทอร์เฟซสำหรับมนุษย์, บริบทระดับองค์กร, ความปลอดภัย และความสามารถในการตรวจสอบย้อนหลัง ส่วน Claude Managed Agents รับผิดชอบเรื่องรอบการตรวจสอบความถูกต้อง, grader, outcomes และการรันหลายเอเจนต์
มี AI teammates ที่สร้างไว้ล่วงหน้ามากกว่า 21 ตัว สำหรับงานด้าน PMO, การตลาด, IT, HR และ R&D
ฟีดแบ็กจะถูกเก็บไว้ใน memory ของเอเจนต์ เพื่อไม่ให้ผู้ใช้คนถัดไปต้องเจอความผิดพลาดเดิมซ้ำอีก

เซสชัน 10 - Running an AI-native engineering org

ใน องค์กรวิศวกรรมแบบ AI-native ปริมาณงานการเขียนโค้ดจะไม่ใช่คอขวดที่แพงที่สุดอีกต่อไป
การตรวจสอบความถูกต้อง, การรีวิว, ความปลอดภัย, การบำรุงรักษา, การประสานงานข้ามสายงาน จะกลายเป็นคอขวดใหม่ที่ใหญ่ขึ้น
สำหรับทีม Claude Code แนวทางที่เหมาะกว่าการทำโรดแมป 6 เดือนหรือเอกสารออกแบบครบทุกงานล่วงหน้า คือการวางแผนในจังหวะที่เหมาะสมและสร้างต้นแบบอย่างรวดเร็ว
การถกเถียงทางเทคนิคกำลังเปลี่ยนจากการคุยหน้าไวท์บอร์ดยาว ๆ ไปเป็นการสร้าง PR ของหลายแนวทางการพัฒนา เพื่อเปรียบเทียบผลกระทบจริงและรูปแบบ API
เมื่อการสร้างโค้ดกลายเป็นเรื่องง่ายขึ้น การทดสอบ, ระบบอัตโนมัติ และการตรวจสอบที่เร็วขึ้นก็ยิ่งสำคัญกว่าเดิม
สิ่งที่สำคัญกว่าคำถามว่า “ใครเป็นคนเขียนโค้ดนี้” คือการแยกแยะสาเหตุของ regression, การต้องการคำตอบจากผู้เชี่ยวชาญหรือไม่ และจุดประสงค์ของการจัดหาบริบท
ทีม Claude Code มอบหมายให้ Claude จัดการเรื่องสไตล์, lint, ฟีดแบ็กใน PR, การแก้บั๊กบางส่วน และการเพิ่ม test
การตรวจทานด้านกฎหมาย, โค้ดที่อ่อนไหวด้านความปลอดภัย, trust boundary, product sense ยังเป็นสิ่งที่ผู้เชี่ยวชาญมนุษย์ต้องดูต่อไป
ในการจ้างงาน จะให้ความสำคัญกับ นักสร้างสรรค์ที่มี product sense และ ความเชี่ยวชาญเชิงลึกด้านระบบ มากกว่าปริมาณงานล้วน ๆ
ตัวชี้วัดความสำเร็จอาจดูได้จาก เวลาการ onboarding ที่สั้นลง, รอบ PR ที่สั้นลง, จำนวน commit ที่ได้รับความช่วยเหลือจาก Claude ที่เพิ่มขึ้น

เซสชัน 11 - Building AI-native: Inside the stacks powering Cognition, Gamma, and Harvey

Gamma นำการปรับปรุงด้าน tool calling และการประสานงานเอเจนต์เข้าสู่ผลิตภัณฑ์อย่างรวดเร็ว เพื่อเสริมเวิร์กโฟลว์การแก้ไขแบบเอเจนต์
Gamma ใช้ MCP connector ไม่ใช่แค่เป็นฟีเจอร์เชื่อมต่อ แต่ยังเป็นช่องทางดึงลูกค้าและจุดเริ่มต้นของเวิร์กโฟลว์ด้วย
Cognition ลดบางส่วนของระบบวางแผนและ memory ภายในที่สร้างเองลง เมื่อโมเดลทำงานด้านการแก้ไขโค้ด, การใช้ระบบไฟล์ และการวางแผนระยะยาวได้ดีขึ้น
Harvey ออกแบบโครงสร้างผลิตภัณฑ์ใหม่ทุกครั้งที่เกิดจุดเปลี่ยนของ foundation model, reasoning model และ coding agent
ความสามารถของแพลตฟอร์มปัจจุบันของ Harvey คงเกิดขึ้นได้ยากหากไม่ได้ใช้สถาปัตยกรรมแบบ agent-native
ผลิตภัณฑ์ AI-native ต้องตั้งสมมติฐานว่าโครงสร้างเดิมอาจล้าสมัยได้ภายใน 6-12 เดือน
การบันทึก, การสังเกตการณ์, การเล่นซ้ำ, การประเมินผล กลายเป็นกลไกจำเป็นเพื่อรับมือกับการเปลี่ยนแปลงโครงสร้างอย่างรวดเร็ว
ในโดเมนที่อ่อนไหวอย่างกฎหมาย จำเป็นต้องมีขอบเขตข้อมูลที่แข็งแรงระหว่างข้อมูลสาธารณะ, ข้อมูลส่วนตัว, memory และโฟลว์ของเอเจนต์
สิ่งที่สำคัญขึ้นคือโครงสร้างที่ดูดซับการก้าวกระโดดของความสามารถครั้งถัดไปได้อย่างรวดเร็ว มากกว่าโครงสร้างที่ออกแบบมาให้เข้ากับข้อจำกัดของโมเดลเฉพาะตัวใดตัวหนึ่ง

เซสชัน 12 - Architecting for model step-changes: A fireside with Vercel's Guillermo Rauch

Vercel มองว่าโครงสร้างพื้นฐานแบบเอเจนต์เป็นทิศทางหลัก
คลาวด์สามารถขยายไปเป็นโครงสร้างพื้นฐานที่ซ่อมแซมตัวเอง ปรับแต่งให้เหมาะสมเอง และเปลี่ยนการตั้งค่าเองได้
AI Gateway ถูกมองเหมือน CDN สำหรับโทเคน
มันกลายเป็นชั้นที่ดูแลหลายผู้ให้บริการและหลายโมเดล พร้อมรับหน้าที่ routing, การรับมือเหตุขัดข้อง และการควบคุมต้นทุน
Opus tokens มีสัดส่วนค่าใช้จ่ายสูงกว่าสัดส่วนการใช้งานมาก ดังนั้นเมื่อนำโมเดลอัจฉริยะสูงมาใส่ในผลิตภัณฑ์ ต้องมองโครงสร้างต้นทุนให้ชัดเจน
หลังนำ Opus 4.5 มาใช้ V0 สามารถทำให้ตัวตรวจไวยากรณ์ การแก้อัตโนมัติ และบางขั้นตอนการประมวลผลที่เคยมีไว้เพื่อชดเชยโมเดลก่อนหน้า เรียบง่ายลงได้
การก้าวกระโดดของความสามารถโมเดลไม่ได้หมายถึงแค่การเพิ่มฟีเจอร์ใหม่ แต่ยังนำไปสู่การเปลี่ยนแปลงด้วยการลบโค้ดชดเชยเดิมออก
หลังจากขยายการใช้ Opus ใน V0 ค่าใช้จ่ายเครดิตผลิตภัณฑ์เพิ่มขึ้น 2 เท่า
ต่อจากนี้ ไม่ใช่แค่การพัฒนาด้วย CLI และ UI เท่านั้น แต่เอเจนต์แบบ asynchronous ที่มีการกำกับดูแลจากมนุษย์น้อยกว่านี้ก็อาจเติบโตมากขึ้น

เซสชัน 13 - The thinking lever

test-time compute คือแกนที่ Claude ใช้โทเคนและเวลามากขึ้นระหว่างการให้เหตุผลเพื่อแก้ปัญหาที่ยาก
แม้จะเป็น Opus 4.7 ตัวเดียวกัน คุณภาพของการจำลองการจราจรก็แตกต่างกันมากตามระดับ effort แบบ low, high และ max
ยิ่งใช้เวลาและโทเคนมากขึ้น กราฟิก การไหลของการจราจร และการเคลื่อนที่ของรถก็ยิ่งสมจริงมากขึ้น
โทเคนที่ Claude ใช้แบ่งได้เป็นโทเคนการคิด โทเคนเรียกใช้เครื่องมือ และโทเคนข้อความ
โทเคนการคิดใช้กับการให้เหตุผลภายใน โทเคนเรียกใช้เครื่องมือใช้กับการโต้ตอบกับโลกภายนอก และโทเคนข้อความใช้สื่อสารกับผู้ใช้
effort คือกลไกปรับสมดุลระหว่างเวลา ต้นทุน และคุณภาพ
Task Budgets ช่วยให้กำหนดเพดานของโทเคน เวลา และต้นทุนที่ Claude ใช้กับงานเฉพาะได้
adaptive thinking คือการที่ Claude เลือกลำดับได้อย่างอิสระว่าจะคิด ใช้เครื่องมือ และตอบผู้ใช้เมื่อถึงจังหวะที่จำเป็น
ใน use case แบบ coding และ agentic ค่าเริ่มต้นที่ดีมักถูกมองว่าเป็น extra high
สำหรับงานจัดหมวดหมู่หรือดึงข้อมูลจำนวนมากแบบง่าย ๆ โมเดลขนาดเล็กจะได้เปรียบกว่า และหากต้องการให้งานที่ต้องใช้ความฉลาดจบเร็ว โมเดลใหญ่ที่ใช้ effort ต่ำอาจดีกว่า

เซสชัน 14 - How Datadog built a universal machine tool for Claude Code

ประมาณ 90% ของวิศวกร Datadog ใช้เครื่องมือเขียนโค้ด AI กับโค้ดที่ใช้งานจริง
ในจำนวนนั้น อย่างน้อย 2/3 ใช้ Claude Code
ขอบเขตการใช้เครื่องมือเขียนโค้ด AI ขยายจากฟังก์ชันเดี่ยว การทดสอบ และโค้ดเชื่อมต่อ ไปสู่การทำงานระดับระบบ
คอขวดได้ย้ายจากการเขียนโค้ดไปอยู่ที่การวนลูป feedback และการตรวจสอบในสภาพแวดล้อมใช้งานจริง
ใน Helix experiment Claude Code สามารถสร้างบริการสตรีมมิงที่คล้าย Kafka ได้ภายในไม่กี่วัน
แต่หากจะนำไปสู่สภาพแวดล้อม production ต้องมี shadowing, validation ladder และ system mileage
Tempor ทำให้เอเจนต์ไม่สร้างเครื่องมือแบบด้นสด แต่ให้สร้างพิมพ์เขียวที่บรรจุ state, transition, effect และ invariant ก่อน
ตาราง transition, เอกสารนโยบาย, effect ที่มี type, validator และ property test ทำให้ซอฟต์แวร์ที่เอเจนต์สร้างสามารถตรวจสอบได้
หากต้องการให้อิสระกับ agent ก็ต้องทำให้ invariant และขั้นตอนการตรวจสอบของระบบ production อยู่ในรูปแบบที่เครื่องอ่านได้

เซสชัน 15 - Building with Claude on Google Cloud

วิธีที่ง่ายที่สุดในการตั้งค่า Claude Code บน Google Cloud คือใช้ ตัวช่วยตั้งค่าที่อิงกับ Application Default Credentials
ตัวช่วยตั้งค่าสามารถตรวจหาและตรึงค่า project, region และ model ที่ใช้งานได้
เมื่อใช้ Claude model บน Google Cloud จะใช้ประโยชน์จาก การคิดค่าบริการตามโทเคน, provisioned throughput, ภาระการสลับ API key ที่ลดลง, การบังคับใช้นโยบายระดับ project, การเก็บข้อมูลไว้ภายใน project และ regional/global endpoint ได้
เดโมดำเนินไปในรูปแบบที่บทบาท 5 แบบ ได้แก่ PM, UI/UX designer, software engineer, security engineer และ data/growth marketer ร่วมกันสร้างแอป feedback หนึ่งตัวจนจบ
PM ใส่ wireframe ที่วาดด้วยมือลงใน Claude Code เพื่อทำต้นแบบอย่างรวดเร็ว
ในขั้น UI/UX ใช้ plan mode เพื่อให้ Claude เสนอแผนก่อนลงมือพัฒนา
Google Cloud developer knowledge API และ MCP server เชื่อม Claude Code เข้ากับเอกสารล่าสุดและคำแนะนำด้านสถาปัตยกรรม
Google Cloud Skills ถูกใช้เพื่อช่วยทำบล็อกย่อยแต่ละส่วน เช่น การ deploy API บน Cloud Run และการเชื่อม Cloud Run กับ Firestore
ใช้ sub-agent เพื่อทำ implementation ของ API, ingestion pipeline และ dashboard แบบขนานกัน
security review prompt จะตรวจปัญหา OWASP หรือสิทธิ์ของ service account แก้ไขปัญหาที่พบ แล้วจึง deploy ไปยัง Cloud Run

เซสชัน 16 - Getting more out of the Claude Platform

ลำดับความสำคัญในการเพิ่มประสิทธิภาพเอเจนต์สำหรับ production คือ prompt caching, context engineering และ Advisor strategy
prompt caching ช่วยลดต้นทุน input token ลดเวลาจนถึงโทเคนแรก และลดภาระเพดานการใช้งานของโทเคนที่ถูกแคช
เป้าหมายของอัตรา cache hit ถูกมองว่าอยู่ในระดับ 90% ขึ้นไป
ความเสถียรของพรอมป์ต์ช่วงต้น ตำแหน่งของนิยามเครื่องมือ และตำแหน่งที่แทรกค่าที่เปลี่ยนแปลงได้ ล้วนมีผลต่อแคช
tool search tool จะดึงเฉพาะนิยามเครื่องมือที่จำเป็นเข้ามาในเวลาที่เหมาะสมเพื่อประหยัด context
หากใส่ทุกเครื่องมือตั้งแต่แรก จะเป็นภาระทั้งกับ context และแคช
programmatic tool calling จะไม่ใส่ผลลัพธ์จากเครื่องมือจำนวนมากเข้ามาตรง ๆ แต่เลือกเฉพาะส่วนที่จำเป็นมาใส่ใน context
compaction ช่วยย่อบทสนทนาเก่าและผลลัพธ์จากเครื่องมือเพื่อให้งานที่ยาวสามารถดำเนินต่อได้
Advisor strategy คือให้ Sonnet หรือ Haiku ทำงานส่วนใหญ่ และเรียก Opus มาเป็นที่ปรึกษาเฉพาะตอนที่ต้องการการตัดสินใจสำคัญ
หัวใจสำคัญไม่ใช่การเรียกใช้โมเดลให้มากขึ้น แต่คือการออกแบบว่าโมเดลจะทำงานภายใต้ context, เครื่องมือ และโครงสร้างแคชแบบใด

เซสชัน 17 - Evaluating and improving Replit Agent at scale

ผู้ใช้ Replit Agent คาดหวังแอปที่ทำงานได้จากเพียงภาษาธรรมชาติ โดยไม่ต้องระบุ framework หรือ test
หากดูแค่ว่าแพตช์ผ่านการทดสอบหรือไม่เหมือนใน coding benchmark ทั่วไป ก็วัดคุณภาพของ Replit Agent ได้ยาก
การประเมินต้องดูว่าแอปทำงานตามที่ผู้ใช้ขอจริงหรือไม่
Replit ใช้ทั้ง offline evaluation และ online evaluation ควบคู่กัน
offline evaluation ทำหน้าที่เป็นด่านก่อนปล่อย agent release ใหม่ ส่วน online evaluation ใช้เพื่อรับมืออย่างรวดเร็วหลังมีการใช้งานจริง
VibeBench คือ benchmark แบบเปิดที่ใช้ PRD จริง 20 ชุด เป็นอินพุต ให้สร้างแอปจาก repository ว่าง และมีผู้ประเมินอัตโนมัติทดสอบแอปในเบราว์เซอร์
โมเดลส่วนใหญ่มักยากกว่าเมื่อต้องขยายโค้ดที่ตัวเองสร้างไว้แล้วต่อไป
ควรมีขั้นตอนการทดสอบและตรวจสอบคั่นระหว่างฟังก์ชัน เพื่อลดการสร้างต่อบนฐานที่สั่นคลอน
Telescope คือระบบภายในที่จัดกลุ่ม execution trace จาก production ตามความหมาย เพื่อค้นหาความล้มเหลวแบบ long tail, จัดประเภทปัญหา, ให้ agent สร้าง PR และตรวจสอบด้วย VibeBench หรือการทดสอบ A/B
การประเมินไม่ใช่เช็กลิสต์ยืนยันก่อนปล่อยเวอร์ชันขั้นสุดท้ายอีกต่อไป แต่กลายเป็น เอนจิน ที่ช่วยปรับปรุงเอเจนต์ทุกวัน

เซสชัน 18 - The capability curve

ผู้ใช้ Claude Code มี ความเชื่อมั่นที่มากขึ้น และ deploy ได้เร็วขึ้นกว่าปีก่อน
ในการโหวตระหว่างการประกาศ มีผู้เข้าร่วมจำนวนมากตอบว่ารู้สึกว่า Claude ช่วยให้ เร็วขึ้น 10 เท่า, 5 เท่า, 2 เท่า
บน SWE-bench Verified นั้น Sonnet 3.7 ทำได้ราว 62% และ Opus 4.7 ทำได้ 87%
Opus 4.7 มีโอกาสสูงกว่า 3 เท่า ที่จะทำ PR ยาก ๆ ซึ่ง Sonnet 3.7 เคยทำไม่สำเร็จให้สำเร็จได้
ในเดโมที่ให้จำลอง Claude.ai ด้วยพรอมป์ต์เดียวกัน โมเดลก่อนหน้านี้สร้าง UI แชตทั่วไปและเกิดข้อผิดพลาด แต่ Opus 4.7 สามารถทำสีของ Claude, การตอบกลับจาก API, ประวัติแชต, กราฟิกแบบอินไลน์ และ dark mode ได้
ด้านที่พัฒนาขึ้นคือ การวางแผน, การกู้คืนจากข้อผิดพลาด, การรักษาสมาธิระหว่างการรันที่ยาวนาน
โมเดลใหม่จะวางแผนก่อน หากล้มเหลวจะย้อนกลับ และยังคงรักษา system prompt กับเป้าหมายได้ดีกว่าเดิมแม้ในบริบทยาว ๆ
ต้องสร้างการประเมินที่มีการกระจายใกล้เคียงกับการใช้งานจริงของผลิตภัณฑ์ จึงจะเห็นการพัฒนาที่เกิดขึ้นจริง
ยิ่งโมเดลดีขึ้น การประเมินแบบเดิมก็ยิ่งอิ่มตัวได้ง่าย ดังนั้นการประเมินก็ต้องยากขึ้นอย่างต่อเนื่องเช่นกัน
เมื่อมี frontier model ใหม่ออกมา ก็ควรลองลดขั้นตอนการปรับจูนและพรอมป์ต์เดิมลงอีกครั้ง

เซสชัน 19 - Giving coding agents their own computers: How Cursor built cloud agents

Cursor มองว่าคอขวดไม่ได้อยู่ที่ความฉลาดของโมเดล แต่เป็นเพราะมนุษย์ยังให้เครื่องมือ บริบท และเป้าหมายขนาดใหญ่แก่โมเดลได้ไม่เพียงพอ
เช่นเดียวกับการ onboarding นักพัฒนาที่เป็นมนุษย์ เอเจนต์ก็ควรได้รับคอมพิวเตอร์ สภาพแวดล้อมการพัฒนา และเอกสาร
onboarding agent ของ Cursor จะสำรวจ repository และทำความเข้าใจวิธีรันแอป, services, environment variables และสิทธิ์ต่าง ๆ
AnyDev CLI เป็นเครื่องมือที่ช่วยให้เอเจนต์เริ่ม services, รอจนพร้อมใช้งาน, ตรวจสอบสถานะ และจัดการได้ตั้งแต่การสร้างบัญชีทดสอบไปจนถึงการล็อกอิน
ยิ่งสภาพแวดล้อมการพัฒนาสำหรับเอเจนต์ดีขึ้น นักพัฒนาก็ยิ่งรัน cloud agent ได้มากขึ้นและมอบหมายงานที่ใหญ่ขึ้น
หลักการพื้นฐานของ autonomy คือการให้นัยน์ตา เครื่องมือ และบริบทที่ดีแก่เอเจนต์
เอเจนต์ควรมองเห็นสถานะของแอป บทสนทนาของเอเจนต์ตัวอื่น และสถานะของ services ได้เหมือนมนุษย์
Cursor มองว่า computer use เป็นองค์ประกอบพื้นฐานสำคัญถัดจากการเขียนโค้ด
Claude 4.7 ช่วยให้ agent อัดเดโมแบบ end-to-end ได้ด้วยตัวเองเพื่อตรวจสอบฟีเจอร์ และช่วยให้มนุษย์เข้าใจผลลัพธ์ได้อย่างรวดเร็วก่อนเริ่ม code review
Cursor มอง agent experience เป็นงานออกแบบแยกต่างหาก และหากเอเจนต์เจอ flow ที่น่ารำคาญ พัง หรือชวนสับสน ก็จะให้บันทึกเป็น issue แบบ work on the factory
เป้าหมายสุดท้ายไม่ใช่ให้มนุษย์คอยพาจาก A ไป D ด้วยมือ แต่คือการสร้าง ระบบที่แก้ปัญหาได้ตั้งแต่ A ถึง Z