- Addy Osmani ผู้นำด้านวิศวกรรมที่ทำงานในทีม Google Chrome มา 13 ปี แนะนำ แนวทางการพัฒนาด้วย AI สำหรับวิศวกรซอฟต์แวร์มืออาชีพ
- Vibe coding มีประโยชน์สำหรับการทำต้นแบบอย่างรวดเร็ว แต่สำหรับการพัฒนา ซอฟต์แวร์ระดับพร้อมใช้งานจริงในโปรดักชัน ยังจำเป็นต้องมีหลักการทางวิศวกรรมและการกำกับดูแลโดยมนุษย์
- เมื่อนำเครื่องมือ AI มาใช้ ต้องรับประกันคุณภาพผ่าน การพัฒนาแบบอิงสเปก การเขียนเทสต์ และความเข้าใจโค้ด พร้อมทั้งตรวจสอบกระบวนการคิดของโมเดลเพื่อให้เข้าใจโค้ดที่สร้างขึ้นอย่างครบถ้วน
- LLM สามารถ สร้างแอปพลิเคชันได้อย่างรวดเร็วถึงราว 70% แต่สำหรับความสมบูรณ์ ความปลอดภัย และความสามารถในการบำรุงรักษาในอีก 30% ที่เหลือ ความเชี่ยวชาญของวิศวกรระดับซีเนียร์ ยิ่งมีความสำคัญมากขึ้น
- เวิร์กโฟลว์การพัฒนาแบบใหม่ เช่น เอเจนต์เบื้องหลังแบบอะซิงโครนัสและการเขียนโค้ดแบบขนาน กำลังเกิดขึ้น และวิศวกรต้องเป็น ผู้เรียนรู้ตลอดชีวิต ที่ใช้ AI ไปพร้อมกับการรักษาความสามารถในการคิดเชิงวิพากษ์และความเข้าใจโค้ด
ความต่างระหว่าง Vibe Coding กับ AI-assisted Engineering
- Vibe coding คือแนวทางที่ดื่มด่ำกับการไหลลื่นเชิงสร้างสรรค์ร่วมกับ AI อย่างเต็มที่ โดยโฟกัสกับการพรอมป์ตระดับสูงและแทบลืมโค้ดไปเลย
- รับข้อเสนอของ AI โดยไม่ตรวจทานเชิงลึก และมุ่งเน้นที่ การทดลองวนซ้ำอย่างรวดเร็ว
- เหมาะกับต้นแบบ, MVP และการเรียนรู้ โดยให้ความสำคัญกับ ความเร็วและการสำรวจ มากกว่าความถูกต้องและการบำรุงรักษา
- AI-assisted engineering คือแนวทางที่ใช้ AI เป็นผู้ร่วมงานที่ทรงพลัง แต่ไม่แทนที่หลักการวิศวกรรม
- AI ทำหน้าที่เป็น force multiplier ช่วยใน วงจรชีวิตการพัฒนาซอฟต์แวร์ทั้งหมด เช่น boilerplate, debugging และ deployment
- วิศวกรมนุษย์ยังคงรับผิดชอบการออกแบบสถาปัตยกรรม การตรวจทานโมเดล และ ความเข้าใจโค้ดที่สร้างขึ้นทั้งหมด
- การรับประกันความปลอดภัย ความสามารถในการขยายระบบ และการบำรุงรักษาของผลิตภัณฑ์สุดท้ายยังเป็นหน้าที่ของวิศวกร
- ยิ่งมีความเชี่ยวชาญด้านวิศวกรรมซอฟต์แวร์มากเท่าไร คุณภาพของผลลัพธ์จาก LLM ก็ยิ่งดีขึ้น
- สำหรับการเขียนโปรแกรมระดับพร้อมใช้งานจริง ควร commit เข้ารีโพซิทอรีเฉพาะ โค้ดที่สามารถอธิบายให้ผู้อื่นเข้าใจได้ทั้งหมด เท่านั้น
วิธีที่ Addy ใช้เครื่องมือ AI
- ใช้แนวทางที่ยึด การพัฒนาแบบอิงสเปก (Spec-driven development) เป็นศูนย์กลาง
- หัวใจสำคัญคือการวางแผนอย่างชัดเจนว่าจะสร้างอะไร
- ใช้ Vibe coding กับเครื่องมือส่วนตัว โปรเจกต์ใช้ครั้งเดียว และการทำภาพไอเดียให้เห็นชัด
- หลังใช้ต้นแบบเพื่อทำให้วิสัยทัศน์ชัดเจนแล้ว จึงจัดทำข้อกำหนดจริงเพื่อชี้นำให้ LLM สร้างผลลัพธ์คุณภาพสูง
- ลดความเสี่ยงด้วย การเขียนเทสต์
- แม้แต่โมเดลสมัยใหม่ก็ยังอาจสร้างโค้ดที่ซับซ้อนเกินไปหรือผิดพลาดได้ในบางครั้ง
- เทสต์ช่วยพิสูจน์ว่าใช้งานได้จริง และช่วย ระบุปัญหาได้อย่างชัดเจน เมื่อเกิดข้อผิดพลาด
- ใช้ Chrome DevTools MCP
- มอบ “สายตา” ต่อเบราว์เซอร์ให้กับ LLM เพื่อให้ตรวจจับการเรนเดอร์, console error และ warning ต่าง ๆ ได้
- นำเบราว์เซอร์เข้ามาอยู่ในลูปเพื่อ ปรับปรุง feedback loop
- ทำ การทดลองอย่างต่อเนื่อง กับโมเดล เครื่องมือ และแพลตฟอร์มใหม่ ๆ พร้อมแบ่งปันอินไซต์ภายในทีม
- สร้างวัฒนธรรมการเรียนรู้ร่วมกันด้วยความปลอดภัยทางจิตใจ
สิ่งที่สังเกตและเรียนรู้เกี่ยวกับเครื่องมือ AI ที่ Google
- หลักการวิศวกรรมซอฟต์แวร์ที่ผ่านการพิสูจน์แล้ว ของ Google ยังใช้ได้ในยุค AI
- ความใส่ใจต่อคุณภาพและการตรวจสอบอย่างรอบคอบ (due diligence) ยังสำคัญเหมือนเดิม
- ความสำคัญของ prompt engineering และ context engineering
- การจัดวาง “คาถา” ที่เหมาะสมเพื่อให้ได้ผลลัพธ์ที่ดีที่สุดจาก LLM
- การปรับ context window ให้เหมาะช่วยเพิ่มโอกาสได้ผลลัพธ์คุณภาพสูง
- ใส่ เนื้อหาที่ไม่มีอยู่ในข้อมูลฝึกของ LLM เช่น คำอธิบายเฉพาะโปรเจกต์ รายละเอียด ไฟล์ และตัวอย่าง
- เร่งการเปลี่ยนผ่านสู่ วิศวกรแบบ AI native
- ฝึกวิธีคิดให้ลองให้ AI ลงมือก่อนเสมอก่อนจะแก้ปัญหาด้วยตัวเอง
- สร้างความเชี่ยวชาญด้าน AI เช่น evaluation benchmark, RAG vs. fine-tuning
- ความสำคัญของการกำกับดูแลโดยมนุษย์
- หาก AI ทั้งเขียนโค้ดและรีวิวโค้ดเอง ก็จะเกิดความ ไม่แน่ชัด ว่าจริง ๆ แล้วมีอะไรถูก deploy ออกไป
- เมื่อความเร็วของ PR เพิ่มขึ้น การรีวิวโดยมนุษย์จึงกลายเป็นคอขวด
- best practice ของ code review ยังอยู่ระหว่างการพัฒนา
เครื่องมือที่ Addy ชอบใช้
- ใช้ Klein in VS Code เป็นหลัก
- Cursor และ GitHub Copilot ก็มีฟีเจอร์มากมายเช่นกัน
- ตรวจสอบ กระบวนการคิด (thinking log) ที่เครื่องมือแสดง
- เพื่อตรวจดูการตัดสินใจของโมเดลและโค้ดที่ถูกสร้างขึ้นระหว่างการสร้างโซลูชัน
- รีวิวโค้ดก่อน PR เพื่อให้มั่นใจว่า จะบำรุงรักษาได้ในอนาคต
- รักษาความสามารถในการ debug ด้วยตัวเอง เมื่อ LLM แก้ปัญหาไม่สำเร็จ
- หากไม่เข้าใจว่าโค้ดทำงานอย่างไร จะรู้สึกเหมือนถูกโยนเข้าไปในป่า
- ความต่างระหว่างวิศวกรมืออาชีพกับคนทั่วไป
- ใคร ๆ ก็พิมพ์พรอมป์ตได้
- สิ่งที่ทำให้ต่างคือ ความเข้าใจหลักการทำงานของโค้ด ความสามารถในการแก้ไขเมื่อโมเดลล้มเหลว และการอธิบายได้อย่างชัดเจนในที่ประชุม
แก่นของปัญหา 70%
- LLM สามารถสร้างแอปพลิเคชันที่ใช้งานได้จริงประมาณ 70% ได้อย่างรวดเร็วมาก แต่จะเริ่มลำบากกับอีก 30% ที่เหลือ
- องค์ประกอบของ 30% สุดท้าย
- แพตเทิร์น “Two steps back”: พรอมป์ตหนึ่งอันอาจพาไปผิดทาง เช่น เขียน UI หรือฟังก์ชันใหม่ทั้งหมดอีกครั้ง
- ต้นทุนการบำรุงรักษาที่ซ่อนอยู่: หากมอบความรับผิดชอบให้ LLM ด้วยสเปกที่ไม่ชัดเจน อาจทำให้ผลตอบแทนลดลง
- ช่องโหว่ด้านความปลอดภัย: ปัญหาอย่างการเปิดเผย API key หรือ XSS ซึ่งเกิดจากการขาดมุมมองภาพรวม
- PoC ที่สร้างด้วย Vibe coding จำเป็นต้องเขียนใหม่ก่อนนำไป deploy ในโปรดักชัน
- ในโค้ดเบสที่รองรับผู้ใช้จริง ความปลอดภัยและคุณภาพเป็นสิ่งจำเป็น
- วิศวกรที่มีประสบการณ์ จะจัดการกับ 30% สุดท้ายได้ง่ายกว่ามาก
- วิศวกรจูเนียร์มักไม่รู้ก้าวถัดไปนอกจากพรอมป์ตใหม่ให้ LLM ไปเรื่อย ๆ
- ทำให้เห็นความสำคัญของ การคิดเชิงวิพากษ์และแนวคิดการแก้ปัญหา
- ความขยันในการอ่านโค้ด ทำความเข้าใจระบบ และมองว่าทุกส่วนเชื่อมกันอย่างไร ยังจำเป็นเสมอ
กลยุทธ์เพื่อใช้ LLM อย่างมีประสิทธิภาพ
- ใช้ แนวคิดแบบผู้จัดการโครงการ
- แบ่งงานออกเป็นหน่วยเล็ก ๆ ที่ตรวจสอบได้
- การโยนทุก requirement เข้าไปพร้อมกันไม่ใช่วิธีที่มีประสิทธิภาพ
- ต้องตั้งความคาดหวังให้ชัดและเตรียมพร้อมสำหรับ การทำงานแบบวนซ้ำร่วมกับ AI
- เขียน โค้ดที่เป็นโมดูลและทดสอบได้
- แนวปฏิบัติที่ดีของวิศวกรรมซอฟต์แวร์ เช่น code review ยังใช้ได้ในยุค AI
- คำนึงถึง ข้อจำกัดของ input/output และให้ context อย่างเพียงพอ
- เป็นนิสัยใหม่ แต่ช่วยให้ได้ผลลัพธ์ที่ดี
- กุญแจสู่ความสำเร็จคือการรักษา ความรอบคอบในการให้มนุษย์อยู่ในลูป
- ยิ่งโยนความรับผิดชอบให้ LLM มากเท่าไร ความเสี่ยงของปัญหาก็ยิ่งเพิ่มขึ้น
เอเจนต์อัตโนมัติและเวิร์กโฟลว์แบบใหม่
- การมาของ เอเจนต์เขียนโค้ดเบื้องหลังแบบอะซิงโครนัส
- เครื่องมืออย่าง Jewels, Devin, Codex และการทดลองของ GitHub
- แนวคิดคือมอบหมายบางส่วนของ backlog ให้ไป ลงมือทำแบบอะซิงโครนัส
- สถานะปัจจุบัน
- ใช้ได้ผลแล้วกับ การเขียน/อัปเดตเทสต์ และการย้ายเวอร์ชันไลบรารี
- เหมาะกับการมอบหมาย การเปลี่ยนแปลงเล็ก ๆ เช่น เพิ่ม dark mode
- โจทย์ด้านการบริหารจัดการ
- ต้องมีอินเทอร์เฟซที่เหมาะสมเพื่อบริหารทุกงานเหมือนวาทยกรคุมวงออร์เคสตรา
- ต้องคำนึงถึง จำนวนงานที่ดูแลพร้อมกันได้จริง
- เนื่องจากความสนใจของมนุษย์มีจำกัด จึงทำหลายงานพร้อมกันได้เพียง ไม่กี่งาน หากยังต้องการรีวิวโค้ดอย่างรอบคอบ
- วิวัฒนาการของ Vibe designing
- การทำงานร่วมกันของนักออกแบบและนักพัฒนาดีขึ้นผ่าน MCP ของ Figma
- นักออกแบบสามารถเปลี่ยนวิสัยทัศน์ให้เป็น functional prototype และเข้าใกล้ โค้ดที่พร้อมทำเป็นโปรดักชัน มากขึ้น
การเปลี่ยนแปลงของบทบาท EM และ PM
- บทบาท PM
- ใช้เวลากับการกำหนดกรอบปัญหา เมตริก และนโยบายของเอเจนต์มากขึ้น
- บทบาท EM
- ดูแลเรื่อง evaluation, การตรวจสอบความปลอดภัย และช่วยให้ทีมใช้ AI ได้อย่างมั่นใจ
- ความรับผิดชอบต่อผลลัพธ์ ไม่ได้เปลี่ยนไป
- ความสำคัญของรสนิยม (taste) ใน product engineering
- เพราะทุกคนสามารถสร้างฟีเจอร์คล้ายกันได้ด้วยพรอมป์ต สิ่งที่สร้างความแตกต่างคือรสนิยม
- จูเนียร์ vs. ซีเนียร์
- AI ยกระดับเส้นฐานขั้นต่ำ แต่ เพดานสูงสุดก็สูงขึ้นด้วย
- จูเนียร์เริ่มต้นได้เร็วขึ้น
- ซีเนียร์ที่มีความสามารถด้าน การเขียนสเปก การแยกงาน ความเข้าใจสถาปัตยกรรมระบบ และการรีวิวอย่างมีประสิทธิภาพ จะยิ่งมีคุณค่ามากขึ้น
- 30% สุดท้ายไม่ใช่งานจุกจิก แต่คือ จุดที่สร้าง leverage
บทบาทใหม่และการเปลี่ยนแปลงในการฝึกนักพัฒนา
- บทบาทใหม่อย่าง Forward deployed engineers กำลังเกิดขึ้น
- ทำงานใกล้ชิดกับลูกค้ามากขึ้น ใช้ AI สร้างฟีเจอร์ได้รวดเร็ว และรับฟัง feedback เรื่อง requirement
- อาจทำให้ เส้นแบ่งระหว่างบทบาทนักพัฒนา PM และดีไซเนอร์พร่าเลือนลง
- การศึกษา AI engineering
- มีความจำเป็นต้องสอน best practice ของ prompt และ context engineering ในระดับมัธยมและมหาวิทยาลัย
- พร้อมหาวิธีรักษาวิธีคิดแบบ system design และ engineering เอาไว้
- trio programming
- ให้จูเนียร์ ซีเนียร์ และ AI ทำงานร่วมกัน
- ให้ซีเนียร์อธิบายโค้ดที่ AI สร้างขึ้น หรืออธิบายว่าโค้ดนั้น เชื่อมกับส่วนอื่นของระบบอย่างไร
ความสำคัญของการคิดเชิงวิพากษ์เมื่อทำงานกับ AI
- การใช้เครื่องมือ AI มีความเสี่ยงที่ทำให้ความสามารถในการคิดเชิงวิพากษ์ลดลง เพราะ ยอมรับสิ่งต่าง ๆ ได้ง่ายเกินไป
- มีแนวโน้มจะกด Tab/Accept รับทุกอย่างในงานที่ดูไม่สำคัญมาก
- เมื่อความเชื่อใจสะสมมากขึ้น การตรวจทานเชิงวิพากษ์ก็ลดลง
- คอขวดของ code review
- เมื่อโค้ดที่สร้างโดย AI เพิ่มความเร็วขึ้น การรีวิวโดยมนุษย์จึงกลายเป็นคอขวด
- มีความเสี่ยงที่จะใช้ LGTM (Looks Good To Me) แบบพร่ำเพรื่อ
- กลยุทธ์รับมือ
- ตั้งใจเลือกบางฟีเจอร์หรือบางวันเพื่อ ทำงานโดยไม่ใช้ AI เพื่อรักษาความสามารถในการคิดเชิงวิพากษ์
- คิดไว้ด้วยว่าถ้าผู้ให้บริการ LLM รายใหญ่ทั้งหมดล่มจะทำอย่างไร
- การเขียนโค้ด vs. การอ่านโค้ด
- การพิมพ์โค้ดเองทำให้เกิดการตรวจทานด้วยตนเอง และคนอื่นก็รู้ว่าใครเป็นผู้เขียนเมื่อต้องรีวิว
- ในยุค AI การอ่านและการรีวิว จะมีสัดส่วนมากขึ้น
- การใช้ AI ใน code review
- “การอนุมัติ” จาก AI เป็นเพียงสัญญาณหนึ่งเท่านั้น
- เช่นเดียวกับการผ่าน CI/CD หรือเทสต์ที่สำเร็จ ยังจำเป็นต้องมี มุมมองส่วนบุคคลต่อคุณภาพ
- ยังควรทำงาน 20-30% โดยไม่ใช้ AI เพื่อให้สมองยังได้ใช้งานต่อเนื่อง
LLM ในฐานะเครื่องมือการเรียนรู้
- เป็นเครื่องมือทรงพลังสำหรับ ทำความเข้าใจโค้ดเบสใหม่
- งานแรกไม่ควรเป็นการพรอมป์ตฟีเจอร์ใหม่เพื่อส่งมอบคุณค่า แต่ควรเป็น การเรียนรู้ว่าโค้ดเบสทำงานอย่างไร
- มีประโยชน์ต่อการทำความเข้าใจ แนวคิดการเขียนโปรแกรม เฟรมเวิร์ก และแพตเทิร์นสถาปัตยกรรม
- จำเป็นอย่างยิ่งเมื่อต้องย้ายฟีเจอร์ระหว่าง โค้ดเบสที่เขียนด้วยภาษาต่างกัน
- การสร้างวัฒนธรรมทีม
- ทำให้เกิดการยอมรับว่าการใช้ AI เป็นเครื่องมือเรียนรู้นั้นเป็นเรื่องปกติ
- ส่งเสริมการทดลองและการแบ่งปัน best practice อย่างสม่ำเสมอ
- ช่วยให้พนักงานใหม่ onboard ได้เร็วขึ้น
- เครื่องมือ AI ทำหน้าที่เป็นเมนเทอร์ที่เชื่อถือได้ตลอด 24/7
- เรียนรู้ได้สบายใจกว่าการต้องถามวิศวกรซีเนียร์ทั้งวัน
- learning mode ของ Claude Code
- มีทั้งโหมดอธิบายและโหมดเรียนรู้
- สามารถหยุดชั่วคราวและขอให้ผู้ใช้ลองทำบางส่วนด้วยตนเอง
วิวัฒนาการของเครื่องมือ AI และการตั้งความคาดหวัง
- ประวัติของวิวัฒนาการเครื่องมือ
- จากการดาวน์โหลดเทมเพลต → CLI และ scaffolding → การ bootstrap ด้วย AI
- ในแต่ละขั้น ประสบการณ์นักพัฒนาก็ดีขึ้นทีละน้อย
- การรับรู้ข้อจำกัดของข้อมูลฝึก
- อิงจากโค้ดใน GitHub ที่ใช้ permissive license หรือแพตเทิร์นจาก open web
- อาจสะท้อนแพตเทิร์นแบบ lowest common denominator
- ไม่ได้รับประกันว่าจะได้ความปลอดภัย ประสิทธิภาพ หรือ accessibility ระดับสูงสุด
- ความคล้ายกับการคัดลอก-วางจาก Stack Overflow
- ในอดีต: คัดลอกสิ่งอย่าง regex สำหรับตรวจอีเมลจาก Stack Overflow
- ปัจจุบัน: LLM สร้างแพตเทิร์นคล้ายกัน แต่ก็ยังอาจมี edge case หรือปัญหาด้านความปลอดภัย
- ไลบรารีจากบุคคลที่สาม vs. เขียนเอง
- ใช้ LLM เขียนเวอร์ชันเล็ก ๆ เองได้ แต่ต้องแบกรับ ภาระการบำรุงรักษา
- ไลบรารีสามารถมี การแก้ไขแบบรวมศูนย์ สำหรับปัญหาด้านความปลอดภัยและเรื่องอื่น ๆ
- ต้องพิจารณา trade-off ของแต่ละทางเลือก
- กุญแจสำคัญคือ ตั้งความคาดหวังให้ต่ำและคงการควบคุมไว้ให้สูง
นิยามของวิศวกรซอฟต์แวร์ที่ยอดเยี่ยมกำลังเปลี่ยนไป
- ความสำคัญของ ผู้เรียนรู้ตลอดชีวิต (Lifelong learner) ไม่เคยเปลี่ยน
- ไม่ว่าเฟรมเวิร์ก เครื่องมือ หรืออุตสาหกรรมจะพัฒนาไปอย่างไร การเปิดรับการเรียนรู้สิ่งใหม่ยังจำเป็นเสมอ
- Growth mindset
- พร้อมลองโมเดล เครื่องมือ และแพลตฟอร์มใหม่ ๆ
- เรียนรู้จากความล้มเหลวและเข้าใจข้อจำกัด
- บทบาทของผู้นำ
- หากผู้นำแสดงให้เห็นว่าเปิดรับการเรียนรู้ ก็จะช่วยสร้าง ความปลอดภัยทางจิตใจ ให้ทีม
- Addy เขียน จดหมายข่าวภายในทีม ทุกวันจันทร์
- แชร์โปรเจกต์ส่วนตัว บทความ และความคิด
- คัดสรรอัปเดตสำคัญด้าน AI และ AI engineering
- ผู้บริหารคนอื่น ๆ ก็ใช้ประโยชน์ได้เช่นกัน
- การคัดกรองข้อมูลในยุคข้อมูลล้นเกิน
- ในโซเชียลเน็ตเวิร์ก รู้สึกราวกับว่ามีการเปลี่ยนแปลงครั้งใหญ่ทุกชั่วโมง
- ผู้นำต้องคัดเลือก สิ่งที่สำคัญจริง ๆ แล้วชี้แนะแก่ทีม
- การรักษาความสามารถทางเทคนิค
- อ่านและดู paper, whitepaper, blog, video และ lecture อย่างต่อเนื่อง
- ช่วยชี้ทางว่าทีมควรลงทุนเวลาไว้ตรงไหน
- การเชื่อมโยงกับการพัฒนาผลิตภัณฑ์
- งานที่ช่วยปรับปรุงเวิร์กโฟลว์การเขียนโค้ดก็มีส่วนช่วย ยกระดับประสบการณ์ลูกค้าของผลิตภัณฑ์ ด้วย
เครื่องมือโปรดและคำแนะนำ
- ภาษาโปรแกรมที่ชอบที่สุด: JavaScript
- ไม่ใช่เพียงเพราะความชอบส่วนตัว แต่เพราะความเปิดกว้างที่ ทุกคนสามารถสร้างและ deploy บนเว็บได้
- มอบความรู้สึกเป็นอิสระโดยไม่ต้องมี gatekeeper
- เครื่องมือที่ชอบที่สุดตอนนี้: Bolt
- เครื่องมือ scaffolding สำหรับ Vibe coding
- เพิ่งเพิ่มการรองรับ custom agent (เช่น Claude Code)
- ให้ผลลัพธ์คุณภาพสูงและมีดีไซน์ยอดเยี่ยม
- มีความสามารถด้าน การทำ automation การเชื่อมต่อ กับ Supabase, ผู้ให้บริการยืนยันตัวตน และอื่น ๆ
- มุ่งลดแรงเสียดทานในการตั้งค่า
- หนังสือแนะนำ
- "The Software Engineer's Guidebook"
- "AI Engineering" by Chip Huyen - หนังสือสำหรับเรียนรู้ แง่มุมพื้นฐาน ของ AI engineering
ยังไม่มีความคิดเห็น