ผมทดสอบ AWS Kiro เป็นเวลาหนึ่งเดือน และนี่คือสิ่งที่ไม่มีใครบอกคุณ

ทำไม Kiro ถึงสำคัญตอนนี้

ขอพูดตรงๆ กับคุณ: ผมสนับสนุนอย่างแรงกล้าให้ทุกคน—โดยเฉพาะผู้ที่ไม่ใช่โปรแกรมเมอร์และผู้ที่ไม่มีพื้นฐานทางเทคนิค—สำรวจโลกของ IDE AI เอเจนต์ เครื่องมือเหล่านี้ได้เปลี่ยนแปลงสิ่งที่เป็นไปได้อย่างสิ้นเชิง คนที่ไม่รู้อะไรเลยเกี่ยวกับการเขียนโปรแกรม ไม่รู้อะไรเกี่ยวกับวิทยาการคอมพิวเตอร์ ตอนนี้สามารถสั่งให้คอมพิวเตอร์ทำงานผ่านหน้าต่างแชทธรรมดาได้แล้ว มันเหมือนกับมีพนักงานผู้เชี่ยวชาญที่ไม่เคยนอน ไม่เคยบ่น และเข้าใจจริงๆ ว่าคุณพยายามทำอะไร

คุณไม่ต้องการการฝึกอบรมเฉพาะทางหลายปีอีกต่อไป คุณไม่จำเป็นต้องจำ syntax หรือต่อสู้กับเอกสาร คุณต้องการไอเดีย คุณต้องการความสามารถในการคิดอย่างชัดเจนว่าคุณต้องการอะไร แค่นั้นเอง

ภูมิทัศน์ของการเขียนโค้ดด้วย AI ในปี 2025 ระเบิดไปแล้ว เรามี Cursor ที่ครองตลาดด้วย UI ที่ใช้งานง่าย Windsurf (เดิมคือ Codeium) ผลักดันขอบเขตของการพัฒนาแบบ agent-native Claude Code นำ terminal-based workflow มาสู่คนทั่วไป GitHub Copilot วิวัฒนาการด้วยความสามารถเอเจนต์ใหม่ๆ แล้ว AWS ยักษ์ใหญ่ด้านโครงสร้างพื้นฐานคลาวด์ก็เปิดตัว Kiro อย่างเงียบๆ—และทันใดนั้นการสนทนาก็เปลี่ยนไป

ตามข้อมูลของ SimilarWeb, Kiro.dev กำลังดึงดูดผู้เข้าชมมากกว่าหนึ่งล้านคนต่อเดือน นั่นไม่ใช่แค่ความอยากรู้อยากเห็น—นั่นคือความสนใจที่แท้จริงของนักพัฒนาในเครื่องมือที่สัญญาว่าจะแก้ไขสิ่งที่เสียหายในการพัฒนาที่มี AI ช่วย

Kiro คืออะไร

Kiro คือ IDE AI เอเจนต์ที่พัฒนาโดย AWS สร้างบน Code OSS—พื้นฐานโอเพนซอร์สของ Visual Studio Code ซึ่งหมายความว่าการตั้งค่า VS Code ที่มีอยู่ของคุณ ส่วนขยาย และความคุ้นเคยในการใช้งานจะถ่ายโอนมาโดยตรง คุณไม่ได้เรียนรู้เครื่องมือใหม่ทั้งหมด คุณกำลังได้รับพลังพิเศษบนพื้นที่ที่คุ้นเคย

แต่สิ่งที่ทำให้ Kiro แตกต่างจากเครื่องมือเขียนโค้ด AI อื่นๆ ทั้งหมดคือ: มันขับเคลื่อนด้วยสเปค ในขณะที่ Cursor และ Windsurf มุ่งเน้นที่การทำให้การเติมโค้ดเร็วขึ้นและฉลาดขึ้น Kiro ถามคำถามที่แตกต่างอย่างสิ้นเชิง—จะเป็นอย่างไรถ้า AI สามารถช่วยคุณวางแผนก่อนที่คุณจะเขียนโค้ด?

ที่น่าสนใจคือ Kiro ถูกวางตำแหน่งให้ "ค่อนข้างแยกออกจาก AWS หลักที่เหลือ" ตามที่ Nathan Peck ผู้สนับสนุนนักพัฒนาของ AWS กล่าว เป้าหมายคือให้ Kiro มีเอกลักษณ์เฉพาะตัวที่ดึงดูดนักพัฒนาบนทุกแพลตฟอร์ม—ไม่ใช่แค่ผู้ที่ลงทุนในระบบนิเวศ AWS อยู่แล้ว คุณสามารถใช้ Kiro ได้โดยไม่ต้องมีบัญชี AWS โดยเข้าสู่ระบบผ่าน Google หรือ GitHub

การวางตำแหน่งเชิงกลยุทธ์นี้สำคัญ Matt Garman CEO ของ AWS อธิบาย Kiro ว่าเป็น "IDE เอเจนต์ที่นำนักพัฒนาจากต้นแบบไปสู่การผลิตด้วยโครงสร้างที่โค้ดพร้อมใช้งานจริงต้องการ" มันไม่ได้พยายามแทนที่เครื่องมือสร้างต้นแบบอย่างรวดเร็วของคุณ—มันพยายามให้แน่ใจว่าต้นแบบเหล่านั้นจะไปถึงการผลิตจริงๆ

การปฏิวัติแบบ Spec-Driven

นี่คือปัญหาที่ Kiro พยายามแก้: vibe coding คุณรู้จักมัน ผมรู้จักมัน เราทุกคนเคยทำ คุณเปิดแชท AI อธิบายคร่าวๆ ว่าคุณต้องการอะไร วนซ้ำผ่านพรอมต์จนกว่าบางอย่างจะทำงาน และ ship มัน มันเร็ว มันรู้สึกเหมือนเวทมนตร์ และมันสร้างหนี้ทางเทคนิคที่ตามหลอกหลอนคุณเป็นเดือนๆ

Vibe coding สร้างโค้ดที่มักยืดยาว ไม่สม่ำเสมอในสไตล์ และขาดการปฏิบัติตามรูปแบบสถาปัตยกรรมที่กำหนดไว้ AI ตั้งสมมติฐานที่คุณไม่เคยตกลง ความต้องการยังคงคลุมเครือเพราะไม่มีใครเขียนมันลงไป หกเดือนต่อมาเมื่อคุณต้องแก้ไขฟีเจอร์ คุณไม่รู้ว่าทำไมการตัดสินใจบางอย่างถูกทำขึ้น

แนวทาง spec-driven ของ Kiro สร้างไฟล์สามไฟล์ที่เชื่อมโยงกันซึ่งเป็นพื้นฐานของทุกฟีเจอร์:

พิมพ์ "เพิ่มระบบรีวิวสำหรับสินค้า" และ Kiro ไม่ได้แค่สร้างโค้ด มันสร้าง user stories สำหรับการดู สร้าง กรอง และให้คะแนนรีวิว แต่ละ user story รวมเกณฑ์การยอมรับที่ครอบคลุม edge cases ที่นักพัฒนามักจะจัดการระหว่างการดำเนินการ หลังจากที่คุณตรวจสอบและอนุมัติสเปคเหล่านี้เท่านั้น การเขียนโค้ดจริงจึงเริ่มต้น

สิ่งนี้อาจดูช้ากว่า มันช้า—ในตอนแรก แต่ผลตอบแทนมาในรอบการทำซ้ำที่ลดลง การสื่อสารในทีมที่ชัดเจนขึ้น และโค้ดที่ทำในสิ่งที่คุณตั้งใจจริงๆ สเปคกลายเป็นแหล่งความจริงเดียวที่ทั้งมนุษย์และ AI agents สามารถอ้างอิงได้ตลอดวงจรชีวิตของโปรเจกต์

อธิบาย EARS Syntax

EARS—Easy Approach to Requirements Syntax—คือความลับเบื้องหลังระบบสเปคของ Kiro พัฒนาโดย Alistair Mavin และเพื่อนร่วมงานที่ Rolls-Royce ขณะวิเคราะห์กฎระเบียบด้านความสามารถในการบินสำหรับระบบควบคุมเครื่องยนต์ไอพ่น EARS ให้รูปแบบที่มีโครงสร้างสำหรับการเขียนความต้องการที่ชัดเจน ไม่คลุมเครือ และทดสอบได้

EARS ไม่ใช่แค่การทำงานอัตโนมัติที่ชาญฉลาด จริงๆ แล้วมันเป็นส่วนขยายของ temporal logic ซึ่งเป็นส่วนขยายของ first-order logic สิ่งนี้ให้พลังที่แท้จริงแก่ Kiro ในการยืนยันกระบวนการ ควบคุมพฤติกรรมของโมเดล และเชื่อมโยงการออกแบบกับการดำเนินการ

WHEN [เงื่อนไข/เหตุการณ์] THE SYSTEM SHALL [พฤติกรรมที่คาดหวัง]

WHEN ผู้ใช้ส่งฟอร์มพร้อมข้อมูลที่ไม่ถูกต้อง 
THE SYSTEM SHALL แสดงข้อผิดพลาดการตรวจสอบถัดจากฟิลด์ที่เกี่ยวข้อง

WHEN ผู้ใช้สร้างรีวิวสำเร็จ 
THE SYSTEM SHALL แสดงข้อความยืนยันและเพิ่มรีวิวในหน้าสินค้า

EARS syntax รวมหลายรูปแบบสำหรับประเภทความต้องการที่แตกต่างกัน:

รูปแบบที่มีโครงสร้างทำให้ง่ายต่อการเข้าใจว่าคาดหวังอะไร ลดความเข้าใจผิดระหว่างทีมผลิตภัณฑ์และทีมเทคนิค มันยังทำให้ความต้องการสามารถทดสอบได้โดยตรง—คำสั่ง EARS ทุกข้อสามารถแปลงเป็น test case ได้ ทำให้แน่ใจว่าไม่มีอะไรหลุดรอด

Vibe Mode vs Spec Mode

Kiro ทำงานในสองโหมดที่แตกต่างกัน แต่ละโหมดตอบสนองความต้องการการพัฒนาที่แตกต่างกัน:

คุณสามารถสลับระหว่างโหมดได้อย่างเป็นธรรมชาติ เริ่มการสนทนา vibe เพื่อสำรวจไอเดีย แล้วพูดว่า "สร้างสเปค" เมื่อคุณพร้อมที่จะทำให้เป็นทางการ Kiro จะถามว่าคุณต้องการเริ่มเซสชันสเปคหรือไม่และดำเนินการสร้างความต้องการตามบริบทของการสนทนาของคุณ

ยังมี Autopilot Mode—เปิดที่มุมขวาล่างและ Kiro จะกลายเป็นเครื่องเร่งการพัฒนา ใน Autopilot, Kiro ดำเนินการโค้ดสมบูรณ์โดยไม่ต้องรอการอนุมัติของคุณในแต่ละขั้นตอน ลดเวลาการพัฒนาโดยการตัดการอนุมัติกลับไปกลับมา ใช้สำหรับ component พื้นฐานและ boilerplate สลับไปยังโหมดมีการดูแลสำหรับ business logic ที่สำคัญที่คุณต้องการตรวจสอบทุกการเปลี่ยนแปลง

Agent Hooks และการทำงานอัตโนมัติ

Hooks คือนวัตกรรมใหญ่ที่สองของ Kiro—การทำงานอัตโนมัติที่ขับเคลื่อนด้วยเหตุการณ์ที่ทริกเกอร์ AI agents ในพื้นหลังตามการเปลี่ยนแปลงไฟล์ พวกมันทำหน้าที่เหมือนนักพัฒนาที่มีประสบการณ์จับสิ่งที่คุณพลาดหรือทำงาน boilerplate ให้สำเร็จขณะที่คุณทำงาน

เมื่อคุณบันทึกไฟล์ สร้าง component ใหม่ หรือแก้ไข API endpoint, hooks สามารถ:

เมื่อ hook ถูก commit ไปยัง Git มันจะบังคับใช้มาตรฐานทั่วทั้งทีมของคุณ ทุกคนได้ประโยชน์จากการตรวจสอบคุณภาพเดียวกัน มาตรฐานโค้ด และการตรวจสอบความปลอดภัย สิ่งนี้แก้ปัญหาทั่วไปที่เอกสารเบี่ยงเบนจากความเป็นจริง มาตรฐานโค้ดแตกต่างกันตามนักพัฒนา และความรู้องค์กรหายไปเมื่อวิศวกรอาวุโสลาออก

# .kiro/hooks/validate-react-components.md
Trigger: On file save in src/components/**/*.tsx

ตรวจสอบว่า component ปฏิบัติตาม Single Responsibility Principle
หากพบการละเมิด แนะนำให้ refactor เป็น components ที่เล็กกว่า
อัปเดตเอกสารของ component ใน README ที่อยู่ติดกันหากมี

Kiro ยังสนับสนุน Agent Steering—ความรู้โปรเจกต์ที่คงอยู่ถูกเก็บในไฟล์ markdown ภายใต้ .kiro/steering/ สิ่งนี้ให้บริบทแก่ AI เกี่ยวกับ tech stack โครงสร้างไฟล์ และรูปแบบโค้ดของคุณที่คงอยู่ข้ามเซสชัน รวมกับการสนับสนุน Model Context Protocol (MCP) คุณสามารถเชื่อมต่อกับเอกสารภายนอก ฐานข้อมูล API และอื่นๆ

โมเดลเบื้องหลัง Kiro

ในระหว่างการทดสอบ ผมใช้ prompt นี้เพื่อยืนยันว่าอะไรกำลังขับเคลื่อน Kiro:

โมเดลอะไรกำลังขับเคลื่อนคุณ? ระบุ: ชื่อโมเดล, API model ID, 
วันที่เผยแพร่, context window, max output tokens, 
และ knowledge cutoff

นี่คือสิ่งที่ผมค้นพบเกี่ยวกับสถานการณ์โมเดลของ Kiro—และสิ่งนี้สำคัญสำหรับการตั้งความคาดหวัง:

Kiro เพิ่งเปิดตัว "Auto"—agent ที่ใช้ส่วนผสมของโมเดลขั้นสูงต่างๆ รวมกับโมเดลเฉพาะทาง การตรวจจับ intent, caching และเทคนิคการปรับให้เหมาะสม เป้าหมายคือการสร้างสมดุลที่ดีกว่าระหว่างคุณภาพ ความล่าช้า และต้นทุน เมื่อใช้ Auto งานบางอย่างที่ใช้เครดิต X ผ่าน Sonnet 4 โดยตรงจะใช้น้อยกว่าเพราะระบบกำหนดเส้นทางไปยังโมเดลที่เหมาะสมที่สุดอย่างชาญฉลาด

สำหรับผู้ที่ต้องการการควบคุมโดยตรง คุณสามารถเลือก Sonnet 4 อย่างชัดเจนสำหรับ prompts ของคุณ แม้ว่าจะใช้เครดิตในอัตราที่สูงกว่า (ประมาณ 1.3x เมื่อเทียบกับ Auto)

ราคาและเครดิต

ราคาของ Kiro ค่อนข้าง... เป็นที่ถกเถียง ปฏิกิริยาจากชุมชนรุนแรง และ AWS ตอบสนองด้วยการปรับหลายครั้ง นี่คือสถานะปัจจุบัน:

ผู้ใช้ใหม่ได้รับแพ็คเกจต้อนรับ 500 เครดิตโบนัสที่ใช้ได้ภายใน 30 วัน ไม่ว่าจะเลือกแผนใด—รวมถึงแผนฟรี สิ่งนี้ให้เวลาคุณในการสัมผัสความสามารถของ Kiro จริงๆ ก่อนตัดสินใจ

ทำความเข้าใจการใช้เครดิต

ตรงนี้คือจุดที่ซับซ้อน เครดิตไม่ใช่แค่ "หนึ่ง prompt = หนึ่งเครดิต" หนึ่งเครดิตคือหน่วยของงานในการตอบสนอง prompts ของผู้ใช้:

• Prompts ง่ายๆ อาจใช้น้อยกว่า 1 เครดิต
• Prompts ที่ซับซ้อน โดยเฉพาะการดำเนินงานสเปค มักใช้มากกว่า 1 เครดิต
• โมเดลที่แตกต่างใช้เครดิตในอัตราที่แตกต่างกัน
• เครดิตวัดได้ถึงทศนิยมสองตำแหน่ง (ขั้นต่ำ 0.01 เครดิต)

ในการทดสอบของผม คำถามยืนยันโมเดลง่ายๆ ใช้แค่ 0.1 เครดิต—มีประสิทธิภาพมาก แต่การสร้างสเปคโปรเจกต์เต็มรูปแบบอาจใช้ 15-25 การโต้ตอบ และการดำเนินการหลายไฟล์ที่ซับซ้อนจะเผาเครดิตอย่างรวดเร็ว

Overage และการเรียกเก็บเงิน

บนแผนที่ต้องเสียเงิน คุณสามารถเปิด overage เพื่อทำงานต่อไปเกินขีดจำกัดรายเดือนของคุณ เครดิตเพิ่มเติมราคา $0.04 ต่อเครดิต เรียกเก็บเงินในตอนท้ายเดือน Overage ปิดโดยค่าเริ่มต้นและต้องเปิดอย่างชัดเจนในการตั้งค่า—เป็นการป้องกันที่สมเหตุสมผลต่อบิลที่ไม่คาดคิด

AWS ยังเสนอ Kiro Startup Credit Program—สูงถึงหนึ่งปีของการเข้าถึง Pro+ ฟรีสำหรับ startups ที่มีคุณสมบัติ หากคุณกำลังสร้างบริษัทและตรงตามเกณฑ์ นี่คือคุณค่าที่มีนัยสำคัญ

ประสบการณ์จริงของผม

ให้ผมแบ่งปันประสบการณ์ส่วนตัวกับ Kiro โดยไม่มีการกรอง ผมมาด้วยความตื่นเต้น—AWS เข้าสู่พื้นที่ IDE AI ด้วยแนวทางที่ใหม่จริงๆ? นับผมเข้าไปด้วย

Workflow แบบ spec-driven น่าประทับใจจริงๆ เมื่อมันทำงาน การเห็น Kiro แปลงคำขอฟีเจอร์ที่คลุมเครือเป็น user stories ที่มีโครงสร้างพร้อมเกณฑ์การยอมรับ EARS จากนั้นสร้างเอกสารการออกแบบทางเทคนิคที่วิเคราะห์ codebase ที่มีอยู่ของผม จากนั้นแตกออกเป็นงานการดำเนินการตามลำดับ—รู้สึกเหมือนมีวิศวกรอาวุโสจริงๆ กำลังบันทึกงานของพวกเขา

ชุมชนสะท้อนความผิดหวังที่คล้ายกัน นักพัฒนารายหนึ่งรายงานว่าใช้เวลา 310+ ชั่วโมงและ $620 เครดิต AI สำหรับโปรเจกต์ที่ควรใช้เวลา 20-30 ชั่วโมง เพื่อให้ได้ความสำเร็จเพียง 50%—สองในสี่ modules ทำงาน งานบ่อยครั้งติดขัด ล้มเหลว และต้องลองใหม่หลายครั้งด้วยมือ งานที่ล้มเหลวสูญเสียบริบท บังคับให้เริ่มต้นใหม่ตั้งแต่ต้นในขณะที่เผาขีดจำกัดการใช้งาน

ปัญหาทั่วไปที่ผมพบและคนอื่นรายงาน:

• ข้อผิดพลาดปริมาณการใช้งานสูง: "โมเดลที่คุณเลือกกำลังประสบปริมาณการใช้งานสูง ลองเปลี่ยนโมเดล" ดีขึ้นบนแผนที่ต้องเสียเงิน แต่ยังคงเกิดขึ้น
• Debug loops: AI บางครั้งตกอยู่ในรูปแบบวงกลม ใช้การแก้ไขที่ผิดเดิมซ้ำแล้วซ้ำเล่า
• Feature creep: Kiro มีแนวโน้มที่จะสร้างโซลูชัน "ระดับอุตสาหกรรม ระดับทหาร" เมื่อโค้ดที่ง่ายกว่าก็เพียงพอ—20 ไฟล์และ 1,500 บรรทัดสำหรับสิ่งที่อาจเป็น 200 บรรทัด
• Context loss: Logic ที่ดำเนินการอย่างถูกต้องบางครั้งผสมกับโค้ดจากงานก่อนหน้าที่แตกต่างอย่างสิ้นเชิง
• บั๊กการใช้เครดิต: การดำเนินการราคาเริ่มต้นมีปัญหาการวัดที่ทำให้เกิดการเพิ่มขึ้นของการใช้งานอย่างไม่คาดคิด (AWS ยอมรับและแก้ไขสิ่งนี้)

ในด้านบวก เครดิตของ Kiro ใจดีสำหรับคำถามง่ายๆ เมื่อ workflow สเปคทำงานได้ดี มันสร้างโค้ดคุณภาพสูงกว่า บำรุงรักษาได้มากกว่าเมื่อเทียบกับ vibe coding ล้วนๆ เอกสารที่ปรากฏมีประโยชน์จริงสำหรับการทำงานร่วมกันในทีม

สรุปของผมจากการทดสอบจริง: Kiro ยังเด็กเกินไป ระดับความฉลาดของ agent ยังคงวิวัฒนาการ มันต้องการ iteration มากขึ้นก่อนที่จะพร้อมสำหรับ workflows มืออาชีพ แต่พื้นฐานมั่นคง และปรัชญาถูกต้อง AWS ตอบสนองได้ดีต่อ feedback จากชุมชน คืนเงินให้ผู้ใช้ที่ได้รับผลกระทบจากบั๊กราคาและขยายเวลาการเข้าถึงฟรี

Kiro vs Cursor vs Windsurf

มาตัดผ่านการตลาดและเปรียบเทียบเครื่องมือเหล่านี้ในสิ่งที่สำคัญจริงๆ:

การเปรียบเทียบประสิทธิภาพ

จากการทดสอบในสถานการณ์การพัฒนาทั่วไป:

Kiro:     45 นาที (รวมเอกสาร/tests เต็มรูปแบบ)
Cursor:   65 นาที (สถาปัตยกรรมด้วยมือ)
Windsurf: 70 นาที (จัดการหลายไฟล์ได้ดี)
Copilot:  85 นาที (บริบทจำกัด)

ตัวเลขที่โดดเด่นคือความสม่ำเสมอของ Kiro—ในขณะที่คู่แข่งอาจเร็วกว่าสำหรับการเติมง่ายๆ Kiro รักษาความแม่นยำสูงข้ามการดำเนินการหลายไฟล์ที่ซับซ้อน แนวทาง spec-driven โดดเด่นเป็นพิเศษในการออกแบบฐานข้อมูลและสถาปัตยกรรม API ซึ่งเป็นพื้นที่ที่ผู้ช่วย AI แบบดั้งเดิมประสบปัญหา

ใครควรใช้ Kiro

เคล็ดลับมือโปรและแนวทางปฏิบัติที่ดี

หลังจากการทดสอบอย่างกว้างขวางและการวิจัยในชุมชน นี่คือกลยุทธ์ที่เพิ่มคุณค่าของ Kiro สูงสุด:

คำตัดสินสุดท้าย

คำแนะนำของผม? อย่าสมัครสมาชิก Kiro ถ้าคุณคาดหวังให้มันแทนที่ workflow การพัฒนาหลักของคุณ ความสามารถของ agent ยังอายุน้อยเกินไป ความน่าเชื่อถือยังไม่ถึง และเส้นโค้งการเรียนรู้สำหรับการพัฒนาแบบ spec-driven เป็นเรื่องจริง

แต่จับตาดูมัน AWS สร้างบางอย่างที่แตกต่างจริงๆ ด้วยแนวทาง spec-driven ปรัชญา—ที่ว่าการเขียนโค้ดด้วย AI ควรบังคับความชัดเจนในความคิดไม่ใช่แค่ความเร็วในการพิมพ์—ลึกซึ้ง เมื่อ Kiro สมบูรณ์ขึ้น มันอาจเปลี่ยนแปลงวิธีที่เราคิดเกี่ยวกับการพัฒนาที่มี AI ช่วยอย่างสิ้นเชิง

ลองแผนฟรี สัมผัส workflow สเปคบนโปรเจกต์เล็กๆ ดูว่าโครงสร้างเหมาะกับวิธีที่คุณต้องการทำงานหรือไม่ และถ้าคุณกำลังสร้างทีมหรือบริษัทที่เอกสารและความสม่ำเสมอสำคัญกว่าความเร็วล้วนๆ Kiro อาจเป็นสิ่งที่คุณต้องการพอดี