แชร์กรณีศึกษาการทำฟีเจอร์ขั้นสูงของ Ghostty ด้วย vibe coding

• เปิดเผยกระบวนการทั้งหมดในการพัฒนาฟีเจอร์ การแจ้งเตือนอัปเดตอัตโนมัติแบบไม่รบกวน ของ Ghostty บน macOS โดยอาศัยเครื่องมือเขียนโค้ดเชิงเอเจนต์ด้วย AI เป็นหลัก และสามารถทำฟีเจอร์ที่พร้อมนำไปใช้งานจริงได้ภายในราว 8 ชั่วโมง ด้วยค่าโทเคน $15.98 ตลอด 16 เซสชัน
• จากเหตุการณ์ที่พรอมป์ตอัปเดตของ Ghostty ไปรบกวนเดโมระหว่างคีย์โน้ตของ OpenAI จึงตัดสินใจเปลี่ยนเป็นแนวทางแบบ non-modal ที่แสดงสถานะการอัปเดตผ่าน องค์ประกอบ GUI ขนาดเล็กบนแถบชื่อหน้าต่างหรือด้านล่างของหน้าต่าง โดยไม่ขัดจังหวะการทำงาน
• ก่อนเริ่มใช้ AI ได้วางแผนคร่าว ๆ ของฝั่งแบ็กเอนด์/ฟรอนต์เอนด์ไว้ก่อน โดยใช้ โปรโตคอล custom UI ของเฟรมเวิร์ก Sparkle และ titlebar accessory controller แล้วจึงใช้ AI เป็นเครื่องมือทำต้นแบบ
• ใช้แนวทางทำงานเป็นขั้นตอน ทั้งการทำต้นแบบ UI, การเปลี่ยนทิศทางเมื่อแก้บั๊กไม่สำเร็จ, และ cleanup session แบบวนซ้ำ (เขียนเอกสาร, รีแฟกเตอร์) เพื่อเพิ่มประสิทธิภาพของเซสชัน AI ในอนาคต รวมถึงการสร้างโค้ดจำลอง
• เน้นย้ำคุณค่าของ รูปแบบการทำงานแบบอะซิงโครนัส ที่ทำให้สามารถไปทำอย่างอื่น เช่น เตรียมอาหารเช้าให้ครอบครัว ระหว่างที่ AI ทำงานได้ พร้อมยึดหลักว่าโค้ดที่ AI สร้างทั้งหมดต้องผ่านการรีวิวด้วยตนเองอย่างเข้มงวดก่อนปล่อยใช้งาน และจะไม่นำโค้ดที่ตนเองไม่เข้าใจขึ้นโปรดักชัน

---

ภาพรวมของฟีเจอร์

• ฟีเจอร์ที่ทำเสร็จคือ การแจ้งเตือนอัปเดตแบบไม่รบกวน บน macOS ที่ไม่บังหน้าต่าง
  • แสดงสถานะการอัปเดตภายในหน้าต่างเทอร์มินัลโดยไม่รบกวนการทำงาน เช่น การสร้างหน้าต่างใหม่หรือดึงโฟกัส
  • เหตุการณ์ที่ พรอมป์ตอัปเดต Ghostty โผล่ขึ้นมาระหว่างคีย์โน้ตของ OpenAI ทำให้เห็นชัดว่าจำเป็นต้องปรับปรุง UX
• ตัดสินใจให้การแจ้งเตือนอัปเดตเป็นแบบ ไม่ล่วงล้ำ
  • แทนที่จะใช้หน้าต่างป๊อปอัป ก็เลือกแสดงองค์ประกอบ GUI ขนาดเล็กแบบ non-modal ในตำแหน่งใดตำแหน่งหนึ่งที่ไม่รบกวนผู้ใช้
  • ตำแหน่งหลักของการแจ้งเตือนคือ ด้านขวาของแถบชื่อหน้าต่าง และมีทางเลือกอย่าง overlay ด้านล่างของหน้าต่าง สำหรับกรณีสไตล์ที่ซ่อนแถบชื่อหน้าต่าง เป็นต้น
• ใช้ AI agent ตลอดกระบวนการพัฒนา แต่ควบคู่กับ การแก้ไขเอง การขัดเกลา และการรีวิวขั้นสุดท้ายด้วยตนเอง ตามแนวทางใช้ AI เป็นเครื่องมือช่วยที่มนุษย์ยังเป็นผู้ขับเคลื่อนหลัก

วางแผนก่อนใช้ AI

• ก่อนหยิบเครื่องมือ AI มาใช้ ได้วาง แผนคร่าว ๆ ไว้ก่อน
  • ศึกษาเอกสารของ Sparkle (เฟรมเวิร์กอัปเดตสำหรับ macOS ที่ได้รับความนิยมมาก) ที่ Ghostty ใช้งาน
  • พบว่า รองรับ custom UI ผ่าน Obj-C protocol ซึ่งแม้ต้องเขียนอะไรขึ้นมาใหม่มากพอสมควร แต่ก็เป็นไปได้
• เมื่อได้ไอเดียคร่าว ๆ ของฝั่งแบ็กเอนด์แล้ว จึงออกแบบฝั่งฟรอนต์เอนด์ต่อ
  • มีแนวคิดคร่าว ๆ ว่าจะฝังปุ่มเล็ก ๆ ไว้ในแถบชื่อหน้าต่าง
  • รู้อยู่แล้วว่า macOS รองรับ custom UI บนแถบชื่อหน้าต่างผ่าน titlebar accessory controller แต่ยังไม่แน่ใจในรายละเอียดของหน้าตาและความรู้สึกการใช้งาน
• มีจุดเริ่มต้นมากพอที่จะลงมือได้
  • AI เป็นเครื่องมือทำต้นแบบที่ยอดเยี่ยมมาก ดังนั้นแค่รู้ว่าตนเองยังไม่รู้อะไร ก็เพียงพอสำหรับการเริ่มต้น
  • มีภาพรวมใหญ่ในหัวที่ชัดเจนมากพอแล้ว

เซสชันแรก: การทำต้นแบบ UI

• พรอมป์ตเริ่มต้นของ เซสชัน agentic coding แรก
  • ปรับแต่ง SPUUserDriver เพื่อทำการแจ้งเตือนอัปเดตแบบไม่ล่วงล้ำ และร้องขอให้เปิดใช้งานการติดตั้ง
  • จำกัดให้ทำเฉพาะงาน UI
  • ขอแผนสร้าง SwiftUI view ที่สามารถแสดงสถานะต่าง ๆ ที่ SPUUserDriver ต้องการได้
  • ขอแผนสำหรับการแสดงผลที่มุมขวาบนของแถบชื่อหน้าต่าง macOS
  • Oracle คืออะไร? - read-only sub-agent สำหรับ Amp โดยเฉพาะ ที่ใช้โมเดลซึ่งช้ากว่าและมีค่าใช้จ่ายสูงกว่า แต่โดยทั่วไปคิดวิเคราะห์ได้ดีกว่า
• ตัดสินใจโฟกัสที่ต้นแบบ UI ก่อน
  • ไม่ได้ส่งให้เอเจนต์ไปสร้างทั้งฟีเจอร์ในครั้งเดียว
  • อย่างแรกคือยังไม่รู้ว่า UI/UX ควรมีหน้าตาแบบไหน จึงไม่อาจคาดหวังให้ AI ทำสิ่งนี้ได้อย่างสม่ำเสมอท่ามกลางการเปลี่ยนแปลงอื่น ๆ
  • อย่างที่สองคือการแบ่งงานเป็นก้อนเล็ก ๆ ทำให้ตรวจทาน ทำความเข้าใจ และทำซ้ำได้ง่ายกว่า
• ขอให้เขียนเฉพาะแผน และสั่งไม่ให้เขียนโค้ด
  • เพราะเป็นคำขอที่ค่อนข้างคลุมเครือ จึงสำคัญที่จะต้องรีวิวแผนก่อนจะลงแรงมากเกินไป (และใช้โทเคนมากเกินไป)
  • เคล็ดลับ: การสร้างแผนแบบครอบคลุมร่วมกับเอเจนต์ผ่านการโต้ตอบ เป็นขั้นตอนแรกที่สำคัญสำหรับงานที่ไม่ตรงไปตรงมา
  • โดยทั่วไปสามารถบันทึกไว้เป็นไฟล์อย่าง spec.md แล้วในเซสชันถัดไปค่อยขอว่าให้อ้างอิง @spec.md แล้ว ทำงานบางอย่าง ได้
• เมื่อเอเจนต์เสนอแผนที่น่าเห็นด้วยมากพอ ก็อนุญาตให้ลงมือทำ
  • UI ที่สร้างออกมามีทิศทางที่ดีมาก
  • แม้ยังมีปัญหาเรื่องการขัดเกลาหลายจุด (เช่น ระยะห่าง สี ฯลฯ) แต่พอได้เห็น UI ก็เกิดประกายไอเดียว่าต้องการอะไร
  • เคล็ดลับ: ใช้ AI บ่อยมากเพื่อหาแรงบันดาลใจ ในกรณีนี้ยังคงเก็บโค้ด UI ที่สร้างไว้หลายส่วน (แม้ไม่ทั้งหมด) แต่ก็มีบ่อยมากเช่นกันที่เพียงแค่ป้อนพรอมป์ตให้เอเจนต์ แล้วสุดท้ายทิ้งทั้งหมดและกลับมาเขียนเองใหม่ด้วยมือ
  • ช่วง “จากศูนย์สู่หนึ่ง” ของงานสร้างสรรค์นั้นยากและใช้เวลามาก และ AI ก็ทำหน้าที่เป็นมิวส์ได้อย่างยอดเยี่ยม

ชนกำแพง

• ในช่วงแชต 11~14 ได้เข้าสู่ โซนความเละ
  • โค้ดที่เอเจนต์สร้างมีบั๊กร้ายแรง และแก้ยังไงก็ไม่สำเร็จเลย
  • ตัวผู้เขียนเองก็ไม่รู้จะแก้อย่างไร
• ลองเสี่ยงแบบเฮลแมรีอยู่หลายครั้งเพื่อแก้บั๊ก
  • ถ้าเอเจนต์แก้ได้ ก็สามารถศึกษาย้อนหลังและเรียนรู้ได้
  • ถ้าล้มเหลว ต้นทุนก็แทบไม่มี
  • ถ้าเอเจนต์แก้ได้แต่ยังไม่เข้าใจ ก็จะย้อนกลับ เพราะ จะไม่ปล่อยโค้ดที่ตัวเองไม่เข้าใจ
  • ระหว่างที่มันล้มเหลว ก็สลับแท็บไปค้นหาปัญหาและพยายามแก้ด้วยตัวเอง
• ณ จุดนี้จึงตระหนักว่าต้องถอยออกมาหนึ่งก้าว ทบทวนงานที่ทำไป และวางแผนด้วยตัวเอง
  • ต้องใช้เวลาเรียนรู้ด้วยตัวเองและคิดอย่างมีวิจารณญาณ
  • ตอนนั้น AI ไม่ใช่ทางออกอีกต่อไป แต่กลายเป็นภาระ

เซสชัน cleanup

• ใช้เวลาหลายเซสชันถัดมาไปกับการชี้นำเอเจนต์ให้ช่วยจัดระเบียบโค้ด
• เซสชันที่สอง: ย้ายบางเมธอดไปไว้ในตำแหน่งที่เหมาะสมกว่า
  • ย้ายฟังก์ชัน fill background, foreground และ badge จาก UpdateAccessoryView.swift ไปยัง UpdateViewModel.swift และทำให้มีความทั่วไปมากขึ้น
• เซสชันที่สาม: เพิ่มเอกสารให้โค้ด
  • อัปเดตเอกสารของ UpdateBadge.swift
  • เคล็ดลับ: การเพิ่มเอกสารช่วยยืนยันความเข้าใจของตนเองที่มีต่อโค้ดอีกครั้ง และช่วยสอนเอเจนต์ในอนาคตที่จะมาอ่านและแก้ไขโค้ดนี้
  • เอเจนต์ทำงานได้ดีกว่ามากเมื่อมีทั้งคำอธิบายภาษาธรรมชาติและตัวโค้ด
• เซสชันที่สี่: ย้าย view model ไปไว้ในตำแหน่งระดับแอปทั้งหมด
  • เพราะงานเดิมวางไว้ในขอบเขตระดับหน้าต่าง แต่ข้อมูลอัปเดตนั้นอยู่ในขอบเขตระดับแอป
  • ระหว่างทำขั้นตอนนี้ก็มักทำการแก้ไขเล็กน้อยด้วยตนเองควบคู่ไปด้วย
• ความสำคัญของช่วง cleanup
  • การจะจัดระเบียบได้อย่างมีประสิทธิภาพ ต้องมีความเข้าใจโค้ดค่อนข้างดี จึงเป็นการบังคับไม่ให้ยอมรับโค้ดที่ AI เขียนมาแบบไม่ลืมหูลืมตา
  • โค้ดที่มีโครงสร้างและเอกสารดีกว่าจะช่วยเพิ่มประสิทธิภาพของเซสชัน agentic ในอนาคต
• เจ้าตัวเรียกสิ่งนี้แบบขำ ๆ ว่า “anti-slop session”

เผชิญหน้ากับบั๊ก

• ย้อนกลับไปยังบั๊กที่พบในช่วงเซสชันแรก
  • ใช้เวลาไปอีกหลายเซสชันเพื่อทำให้เอเจนต์เข้าใจสิ่งนี้
  • เริ่มต้นอย่างคลุมเครือ แล้วค่อยๆ ทำให้แนวทางชัดเจนขึ้นเรื่อยๆ
• เซสชันแรกที่คลุมเครือ: สำหรับแท็บเนทีฟมาตรฐาน ไม่เห็น update accessory view ต้องทำให้มันแสดงอยู่ใน title bar ของหน้าต่างตลอดเวลา - ล้มเหลว
• ครั้งที่สองที่เจาะจงขึ้น: อัปเดตข้อจำกัดของ tab bar ใน TerminalTabsTitlebarTahoe.swift เพื่อจัดขอบขวาของ tab bar ให้ตรงกับขอบซ้ายของ update accessory view - ล้มเหลว
• ลอง แนวทางที่เจาะจงอีกแบบ ครั้งที่สาม: แก้ TitlebarTabsTahoeTerminalWindow.swift ให้ tab bar กลายเป็น top accessory view แทน bottom accessory view เพื่อเอาแท็บไปไว้ใน title bar จะเป็นอย่างไร - ล้มเหลว
• ความพยายามครั้งสุดท้าย: right accessory view และเลย์เอาต์ชนกับการตั้งค่า update accessory view ใน TerminalWindow.swift จะจำกัดให้ tab bar แสดงทางซ้ายของการแจ้งเตือนอัปเดตเสมอได้ไหม - ล้มเหลว
• ตลอดกระบวนการนี้ก็พยายามแก้เองด้วยการค้นคว้าแบบแมนนวลและแรงคน
  • พรอมป์ต์ที่เจาะจงขึ้นอิงจากสิ่งที่เรียนรู้ระหว่างทาง
  • โดยรวมแล้วเห็นได้ชัดว่าไม่เวิร์ก
• ตัดสินใจ เปลี่ยนทิศทาง เพราะมองว่าแก้คนเดียวไม่ไหว
  • สำหรับสไตล์ title bar ที่มีปัญหา ให้เอาการแจ้งเตือนอัปเดตไปไว้ที่มุมขวาล่างแบบ overlay เหนือ content view ของหน้าต่างแทนที่จะอยู่ใน title bar
  • Ghostty มีการตั้งค่าที่ซ่อน title bar ทั้งหมดได้ จึงจำเป็นต้องรองรับสิ่งนี้อยู่แล้ว
  • ต่อให้ภายหลังแก้ปัญหาสไตล์ title bar ได้ ก็ยังต้องรองรับโหมดอีกแบบนี้อยู่ดี
• เซสชันถัดไป เดินตามแผนนี้โดยใช้พรอมป์ต์ที่เจาะจงมาก
  • เสริมระบบ Update ให้รองรับแนวทาง overlay ใน TerminalView.swift ด้วย
  • การแจ้งเตือนอัปเดตต้องแสดงที่ด้านล่างของหน้าต่างและซ้อนอยู่เหนือข้อความ ดังนั้นจึงไม่ต้อง resize terminal view
  • พฤติกรรมการคลิกทั้งหมดเหมือนกับ accessory view
• ทำได้ดีมาก ภายหลังมีงานเก็บรายละเอียดเชิงนโยบายแบบแมนนวลอีกมาก (ย้าย เปลี่ยนชื่อ ฯลฯ) แต่แกนหลักแข็งแรง

เริ่มต้นฝั่งแบ็กเอนด์

• รู้สึกว่า UI ดีพอแล้ว
  • จดปัญหาเชิงนโยบายไว้หลายอย่างที่อยากจัดการทีหลัง แต่หลักๆ อยากย้ายไปทำแบ็กเอนด์เพื่อค้นหา unknown unknowns ที่อาจโยนประแจใส่แผนได้
• สร้างไฟล์ scaffold แบบแมนนวลที่มีฟังก์ชันไม่สมบูรณ์และคอมเมนต์ TODO หลายจุด จากนั้น เริ่มเซสชันใหม่
  • ขอให้เติม UpdateDriver.swift ให้เสร็จ และอ่านเอกสาร Sparkle เพื่อทำความเข้าใจฟีเจอร์
  • เคล็ดลับ: AI เก่งมากในการเติมช่องว่างหรือวาดส่วนที่เหลือของนกฮูก
  • แพตเทิร์นการทำ scaffold ด้วยชื่อฟังก์ชันเชิงอธิบาย พารามิเตอร์ คอมเมนต์ todo ฯลฯ เป็นวิธีที่ใช้กันบ่อยมากและได้ผลดี
• ในทางปฏิบัติแล้วมันทำงานได้ แย่มาก จนต้องทิ้งโค้ดทั้งหมดนี้ไป
  • โค้ดที่สร้างมาทำงานได้ แต่เป็นแนวทางที่ผิดอย่างชัดเจน
  • มันปะปนหลาย concern เข้าด้วยกัน และวิธีเก็บ state ไว้ใน driver ก็ผิดชัดเจน
• เมื่อศึกษาสิ่งที่มันทำ ก็พบว่า view model ถูกจัดโครงสร้างไว้ในแบบที่ไม่เหมาะนัก
  • เพื่อให้ AI (และมนุษย์ หากเลือกเขียนเอง) มี framework ที่ดีกว่า จึงเปลี่ยนเกียร์เข้าสู่โหมด cleanup

รีคลีนอัปครั้งใหญ่

• จากประสบการณ์ ความเรียบร้อยของ UI frontend และ business logic backend มักถูกกำหนดโดย คุณภาพของ view model ตรงกลาง
  • ใช้เวลาไปกับการปรับโครงสร้าง view model แบบแมนนวล
  • เปลี่ยนจาก struct ที่มี optional จำนวนมากไปเป็น tagged union พร้อมเปลี่ยนชื่อและย้ายบาง type
• จากประสบการณ์รู้ว่า งานแมนนวลเล็กๆ ตรงกลางนี้จะช่วยพาเอเจนต์ไปสู่ความสำเร็จในเซสชันทั้งฝั่ง frontend และ backend ต่อจากนี้
  • หลังรีสตรักเจอร์เสร็จ สิ่งแรกที่ทำคือให้เอเจนต์ช่วยวาดนกฮูกให้เสร็จอีกครั้ง
  • รอบนี้ให้มันตรวจดูการเปลี่ยนแปลง อัปเดตโค้ดที่พึ่งพาให้เข้ากับสไตล์ใหม่ และลบโค้ดเก่าออก
• เดินหน้าต่อด้วยชุด เซสชัน cleanup แบบมาราธอน
  • ขอให้ ลบ dead code เพิ่มเติม
  • หลังจากทำ build พังด้วยมือตัวเอง ก็ให้เอเจนต์แก้ระหว่างเข้าประชุม
  • เคล็ดลับ: “ฉันทำเละไปแล้ว ช่วยแก้ความผิดพลาดของฉันที” ก็เป็นอีก use case ที่ใช้กับเอเจนต์บ่อย
  • เริ่ม refactor จากบาง view
  • ทำ cleanup เพิ่มเติม

การจำลอง

• ในเซสชัน UI แรก ขอให้เอเจนต์สร้างโค้ดเดโมเพื่อให้เห็น UI จริงได้โดยไม่ต้องเช็กอัปเดตจริง
  • ฟลोอัปเดตมีหลายสถานการณ์ และถึงจุดนี้ได้ทดสอบแค่ happy path
• ใน เซสชันถัดไป แยกโค้ดจำลองออกเป็นไฟล์เฉพาะ แล้วขอให้เอเจนต์สร้างสถานการณ์เพิ่ม
  • ย้ายโค้ดจำลองการอัปเดตจาก AppDelegate.swift ไปยังไฟล์เฉพาะใน Features/Update
  • ใส่หลายสถานการณ์จำลอง (happy path, หาไม่พบ, error ฯลฯ) เพื่อให้ลองเดโมแบบต่างๆ ได้ง่าย
  • เคล็ดลับ: เอเจนต์เก่งในการสร้าง test และ simulation
  • โค้ดจำลองที่สร้างตรงนี้พูดตรงๆ ว่าค่อนข้างแย่ แต่ใช้งานได้ และไม่ได้เป็นส่วนหนึ่งของรีลีสไบนารี ดังนั้นคุณภาพจึงไม่สำคัญ
  • ไม่ได้แม้แต่จะเก็บกวาดเกินกว่าสิ่งพื้นฐานที่เห็นได้ในเซสชัน
• รันการจำลองหลายแบบแล้วพบจุดปรับปรุง UX หลายอย่าง
  • จัดระเบียบสถานะ “ไม่มีอัปเดต”
  • รีเซ็ตสถานะเมื่อเช็กแล้วเกิดข้อผิดพลาด
  • ปรับข้อความและสไตล์สำหรับสถานะขอสิทธิ์

ช่วงสุดท้าย

• ถึงจุดนี้มีทั้งแบ็กเอนด์และฟรอนต์เอนด์ที่ใช้งานได้แล้ว และทั้งหมดต้องเชื่อมเข้าด้วยกัน
• ใน เซสชันถัดไป ให้พรอมป์ต์กับเอเจนต์ว่า
  • สร้างคลาส UpdateController สำหรับชนิด updater ให้เหมือนกับ SPUStandardUpdaterController.m ของ Sparkle
  • ต้องมีการไปๆ มาๆ และเก็บรายละเอียดแบบแมนนวลเล็กน้อย แต่ก็ไปถึงจุดนั้นได้
• จากนั้นเพิ่มการปรับปรุงเล็กน้อย
  • สำหรับสถานะอัปเดตได้ที่มี appcast ให้ดูที่ SUAppcastItem และแสดง metadata ที่เกี่ยวข้องอื่นๆ ถ้ามีการตั้งค่าไว้
  • เช่น content length สำหรับขนาด

อย่างอื่นอีกไหม?

• สำหรับเอเจนต์ พรอมป์สุดท้ายคือถามเสมอว่ายังพลาดอะไรไปบ้าง
  • ทำสิ่งนี้ไม่ว่าจะได้เขียนโค้ดด้วยมือตรง ๆ หรือไม่ก็ตาม
  • ยังมีส่วนปรับปรุงอื่น ๆ ที่ทำได้ในฟีเจอร์ Features/Update หรือไม่, ห้ามเขียนโค้ด, ให้คำปรึกษาแบบ Oracle, พิจารณาส่วนของโค้ดที่สามารถเพิ่ม unit test ได้อีก
• เนื่องจากได้เน้นปัญหาจริงไว้แล้ว จึงขอให้ลงมือทำการ implement
  • พบว่าการบอกเอเจนต์ให้ "ทำทั้งหมด" ง่ายกว่าการถามว่ามีอะไรเฉพาะเจาะจงที่ควรทำ เพราะภายหลังสามารถเก็บกวาดได้ง่ายด้วย commit แบบเลือกเฉพาะ
• จุดที่น่าสนุกของเซสชันนี้คือเอเจนต์เริ่มมุดลงโพรงกระต่ายแบบหลุดโลกจริง ๆ จนต้องเข้าไปแทรกให้หยุด
  • "หยุด หยุด หยุด ยกเลิกรายการ main actor ทั้งหมด"
• นอกจากนี้ยังพบว่ามีวิธีที่ดีกว่า แต่สิ่งที่ทำไปนั้นค่อนข้างแย่
  • สำหรับข้อความ error น่าจะมีวิธีมาตรฐานของ SwiftUI แทนการตัดข้อความไหม จำเป็นต้องเพิ่ม UI element เพื่อให้ดูข้อความทั้งหมดได้

ค่าใช้จ่ายและเวลา

• งานนี้ใช้ไปทั้งหมด 16 เซสชันแยกกัน และใช้โทเคนใน Amp เป็นเงิน $15.98
  • ปกติจะไม่เดาว่านี่แพงหรือถูก แต่ส่วนตัวแล้วในช่วง 2 วันที่ใช้ไปกับฟีเจอร์นี้ ฉันจ่ายค่ากาแฟที่ร้านมากกว่านี้อีก
• เวลาจริงทั้งหมดที่ใช้กับฟีเจอร์นี้คาดว่าอยู่ที่ประมาณ 8 ชั่วโมง
  • แม้ commit แรกกับ commit สุดท้ายจะกินช่วงเวลา 3 วัน แต่ในแต่ละวันฉันทำงานหน้าคอมพิวเตอร์ประมาณ 4 ชั่วโมงเท่านั้น
  • ไม่ได้ใช้เวลาทั้งหมดไปกับฟีเจอร์นี้อย่างเดียว
  • ตัวอย่างเช่น ระหว่างทำฟีเจอร์นี้ก็ทำ การปล่อยอัปเดต Ghostty, ไปเป็นแขกรับเชิญ 1 ชั่วโมงให้ ThePrimeagen และไปนำเสนอในงานรวมพลประจำปีของ Zoo ด้วย
  • ที่บ้านมีเด็กเล็ก จึงมี "เวลาหน้าคอม" ที่ต้องวางแผนไว้ชัดเจนและจำกัดมาก
  • ดังนั้นตัวเลขประมาณ 8 ชั่วโมงนี้อาจจะนับแบบเผื่อ ๆ ด้วยซ้ำ
• มีคนจำนวนมากบนอินเทอร์เน็ตถกเถียงกันว่า AI ทำให้ทำงานได้เร็วขึ้นหรือไม่
  • สำหรับกรณีนี้ ฉันคิดว่าปล่อยได้เร็วกว่าแน่นอนเมื่อเทียบกับการทำเองทั้งหมด
  • โดยเฉพาะงานวนซ้ำเรื่องการจัดสไตล์ SwiftUI จุกจิกที่สำหรับฉันทั้งน่าเบื่อและกินเวลามาก ขณะที่ AI ทำเรื่องนี้ได้ดีมาก
• สิ่งที่ชอบที่สุด มากกว่าการถกเถียงว่าเร็วขึ้น/ช้าลง: AI สามารถทำงานแทนฉันได้ในตอนที่ฉันลุกไปทำอย่างอื่น
  • มีรูปหนึ่งจากเซสชันเก็บกวาด ขณะที่ฉันกำลังทำอาหารเช้าให้ครอบครัว
  • มีคนมองข้ามเรื่องนี้ได้หลายแบบ เช่น "ฉันไม่อยากเขียนโค้ดระหว่างทำอาหาร" หรือ "ควรอยู่กับปัจจุบันมากกว่านี้"
  • ถ้าคุณอยากทำแบบนั้นก็ไม่เป็นไร แต่ในกรณีของฉัน ตัวอย่างนี้คือฉันเป็นคนแรกที่ตื่นในบ้าน และกำลังเตรียมอาหารเช้าขณะที่คนอื่นยังหลับกันอยู่
  • ไม่ได้ทำแบบนี้ทุกช่วงเวลาที่ตื่นอยู่
• สรุปคือ: มันเวิร์กสำหรับฉัน
  • ไม่ได้พยายามจะโน้มน้าวคุณเลยแม้แต่น้อย
  • ไม่ได้มีความเกี่ยวข้องทางการเงินกับบริษัท AI ใด ๆ
  • ในฐานะคนที่ประสบความสำเร็จกับเครื่องมือ AI มาก และชอบพูดคุยเรื่องนี้ ผู้คนมักขอให้แชร์ตัวอย่างอยู่เสมอ
  • นั่นคือสิ่งที่ฉันกำลังทำอยู่ตรงนี้

บทสรุป

• ฟีเจอร์นี้สวยงาม ทำงานได้ยอดเยี่ยม และถูก merge หลังจากตรวจทานด้วยมือตอนท้าย
  • "การตรวจทานด้วยมือตอนท้าย" สำคัญมาก มาก มาก มาก อย่านำโค้ดที่ AI เขียนไป deploy โดยไม่ตรวจทานด้วยมืออย่างละเอียด
  • ถ้าเป็นผู้ใช้ Ghostty ที่ใช้ tip release ก็ใช้งานได้แล้วตอนนี้
  • ถ้าใช้ tagged release จะใช้งานได้ใน Ghostty 1.3
• ฉันเป็นคนที่สนับสนุนอย่างชัดเจนเรื่อง ความสำคัญของการแชร์เซสชัน agentic coding แบบเปิดเผยต่อสาธารณะ
  • เหตุผลหนึ่งคือมันเป็นวิธีที่ทรงพลังอย่างไม่น่าเชื่อในการช่วยให้คนอื่นเรียนรู้วิธีใช้เครื่องมือเหล่านี้อย่างมีประสิทธิภาพ
  • หวังว่าโพสต์นี้จะช่วยแสดงให้เห็นสิ่งนั้นได้

[GN⁺]

ความเห็นจาก Hacker News

• ฉันใช้ AI เป็นเครื่องมือหาแรงบันดาลใจบ่อยมาก ครั้งนี้ก็ยังคงโค้ด UI จำนวนมากที่ AI สร้างให้ไว้เหมือนเดิม แต่บางครั้งก็ให้เอเจนต์ทำแล้วสุดท้ายก็ทิ้งทั้งหมดก่อนจะเขียนใหม่เองทั้งหมด (ด้วยมือ!) ช่วงสร้างสรรค์แบบ "zero to one" นั้นยากและกินเวลามากเสมอ ดังนั้น AI จึงยอดเยี่ยมมากในบทบาทเหมือนเป็นมิวส์ของฉัน นี่แหละคือข้อดีที่ใหญ่ที่สุดของ code agent หลายคนกังวลเรื่องการบำรุงรักษาหรือความยุ่งเหยิงของโปรเจกต์ที่ขับเคลื่อนด้วย AI แต่ฉันไม่ค่อยสนใจ ถ้าแค่ไปให้ถึงจุดที่เริ่มจับต้องฟีเจอร์ของโปรเจกต์ได้จริงและแก้ไปต่อได้อย่างรวดเร็ว หลังจากนั้นทุกอย่างจะพุ่งเร็วมาก ฉันมองว่าเส้นทางไปถึง "ช่วงเวลาทอง" นี้คือ 80% ที่แพงที่สุดของการเขียนโปรแกรมสำหรับฉัน เลยพูดตามตรงว่าฉันไม่ค่อยเข้าใจเสียงคัดค้านต่อ code agent นัก ต่อให้สุดท้ายเหลือแค่โค้ดที่ต้องทิ้งทั้งหมด ฉันก็ยังรู้สึกว่ามันมีคุณค่าชัดเจนในตัวเอง ป.ล. เบคอนต้องชั่งน้ำหนักเสมอ

  • เพิ่งคุยกับใครบางคนเรื่องนี้มาไม่นาน และฉันก็เห็นด้วยเป็นส่วนใหญ่ เครื่องมือพวกนี้ยอดเยี่ยมมากตรงที่ช่วยสร้างต้นแบบสำหรับทดสอบไอเดียได้ง่าย โดยเราสามารถลองจับการโต้ตอบได้โดยตรง แต่มีปัญหาอยู่สองข้อ ข้อแรก การโน้มน้าวว่าต้นแบบที่ดูภายนอกเหมือนเกือบเสร็จแล้วนั้นยังห่างไกลจากความพร้อมสำหรับ production ก็ปวดหัวพออยู่แล้ว และโค้ดที่ใช้ LLM ก็ยิ่งห่างจาก production มากกว่าต้นแบบที่ฉันเคยทำแบบเดิมเสียอีก ข้อสอง ต้นแบบที่ฉันทำด้วยมือนั้นทำให้ได้เรียนรู้เทคโนโลยีสแตกหรือการลงมือทำจริงไปด้วย แม้เป้าหมายหลักคือทำให้เร็ว แต่ระหว่างทางก็มีบทเรียนเชิงเทคนิคมากมาย และบ่อยครั้งต้นแบบของฉันก็มักเป็นตัวกำหนดทิศทางเทคนิคด้วย ในทางกลับกัน ต้นแบบที่ใช้ LLM นั้นแทบไม่มีประโยชน์ที่ตัวโค้ดเองเลย และถ้าจะเริ่มทำอะไรจริง ก็มักต้องเริ่มใหม่แทบตั้งแต่ต้น มันเหมือนพิสูจน์ไอเดียได้แล้ว แต่ยังไม่ได้พิสูจน์ทั้งเทคโนโลยีหรือการออกแบบเลย ถึงอย่างนั้นฉันก็ยังคิดว่ามันมีประโยชน์ ฉันเชื่อในแนวคิดว่า "ต้นแบบต้องเร็ว" และด้วยการใช้ LLM ฉันสามารถประกอบระบบที่ค่อนข้างใหญ่ได้แทบจะทันที เพียงแต่ต้องเปลี่ยนกรอบความคิดเรื่องกระบวนการ ต้นแบบแบบไม่ใช้ LLM อาจอยู่ราวขั้น 4~5 จาก 10 แต่ต้นแบบแบบ LLM ใกล้เคียงขั้น 2 มากกว่า นี่ไม่ใช่เรื่องแย่ แต่ต้องปรับความคาดหวังว่าปริมาณงานที่เหลือหลังจากต้นแบบนั้นมากกว่าเมื่อก่อน

  • คุณค่าที่ว่า "ถ้าพาโปรเจกต์ไปถึงระดับที่เริ่มวิ่งได้เองสักหน่อย จากนั้นมันจะเดินหน้าอย่างรวดเร็ว" ของคุณนี่สำคัญมาก สำหรับฉันกลับกันเลย ช่วง "zero to one" คือช่วงที่คุ้มค่าและสนุกที่สุด เพราะเป็นช่วงที่ความเป็นไปได้นั้นเปิดกว้างมาก และสามารถสร้างสิ่งที่ไม่เคยมีมาก่อนได้ ถ้า AI มาชี้ทางไว้ล่วงหน้า ฉันรู้สึกว่าจะสูญเสียความสร้างสรรค์แบบนั้นไปไม่น้อย

  • จากความเห็นของคุณ ดูเหมือนความกลัวหน้ากระดาษเปล่าคือปัญหาใหญ่ และฉันก็เห็นด้วยว่าเครื่องมือที่ช่วยลบสิ่งนั้นออกไปได้ย่อมเพิ่มผลิตภาพอย่างมาก แต่ไม่ใช่ทุกคนจะมีปัญหาเดียวกัน การพัฒนาซอฟต์แวร์เป็นกิจกรรมที่มีความเป็นส่วนตัวมาก ดังนั้นเวิร์กโฟลว์และประสบการณ์ของแต่ละคนจึงต่างกัน ไม่ใช่ว่าวิธีของใครเหนือกว่าใคร แต่สำคัญตรงที่แต่ละคนมีเครื่องมือที่เหมาะกับตนเองต่างกัน และควรยอมรับกับเชื่อถือประสบการณ์ของกันและกันตามนั้น ในข้อถกเถียงเรื่อง LLM ทั้งสองฝั่งมักมีแนวโน้มจะสมมติว่าตัวเองกับอีกฝ่ายเหมือนกัน

  • สัปดาห์นี้ฉันเพิ่งดูบทสัมภาษณ์เกี่ยวกับชุดพัฒนาโปรแกรมของ Mitchell ตอนที่มีคนถามว่าทำไมถึงใช้ neovim เขาตอบว่า "ผมไม่ต้องการเครื่องมือที่เขียนโค้ดแทนผม" ซึ่งน่าประทับใจมาก ไม่ได้จะวิจารณ์นะ แต่ก็น่าสังเกตว่านักพัฒนาฝีมือเยี่ยมอย่าง Mitchell ก็ยังเห็นคุณค่าใน LLM แบบที่ต่างจาก intellisense สมัยก่อน

  • ฉันอธิบายเรื่องนี้กับเพื่อนร่วมงานว่าเป็นการ "ใช้กฎของ Cunningham กับตัวเอง" Cunningham's Law: 'วิธีที่เร็วที่สุดในการได้คำตอบที่ถูกต้องจากอินเทอร์เน็ต ไม่ใช่การถามคำถาม แต่คือการโพสต์คำตอบที่ผิด' ถ้าฉันจ้องหน้าจอว่าง ๆ โดยไม่มีอะไรอยู่ในหัว ฉันจะนั่งเหม่ออยู่นานมาก แต่ถ้ามีอะไรให้วิจารณ์ ฉันจะเปลี่ยนเป็นโหมดทำงานได้ทันที

• ฉันนับถือความเห็นของ Mitchell ต่อกรณี OpenAI อย่างจริงใจ แม้ว่าสุดท้ายจะเป็นทิศทางบวกต่อ ghostty ก็ตาม แทบไม่เคยเห็นบริษัทซอฟต์แวร์ไหนพยายามลดความไม่พอใจหรือความรำคาญของผู้ใช้อย่างเชิงรุกเลย โดยเฉพาะถ้านึกถึงอะไรอย่าง MS Auto Update ถือเป็นการเปลี่ยนแปลงที่น่ายินดีมาก อีกอย่าง บทความนี้แสดงให้เห็นการใช้ AI ในการเขียนโปรแกรมอย่างมีความรับผิดชอบ ซึ่งฉันคิดว่าไม่ตรงกับนิยามดั้งเดิมของ vibe coding เลยแม้แต่น้อย ที่มักถูกพูดถึงกันแบบเกินจริง

  • ฉันคิดว่าคำว่า "vibe coding" เองก็เป็นแนวคิดที่ไม่เข้ากับกรณีนี้เลย คำนี้ถูกใช้พร่ำเพรื่อไปทั่วมาก

  • เห็นด้วยกับความเห็นเรื่อง "การใช้ AI เขียนโปรแกรมอย่างมีความรับผิดชอบ" นี่ไม่ใช่ vibe coding แต่เป็น vibe engineering อย่างที่ simonw เสนอคำนี้ไว้ที่นี่เป็นคนแรก บทความที่เกี่ยวข้อง

• เผื่อใครยังไม่ทราบ ตอนนี้ Ghostty บังคับให้ต้องเปิดเผยเสมอเมื่อมีการใช้เครื่องมือ AI coding เมื่อเร็ว ๆ นี้ ลิงก์ PR ที่เกี่ยวข้อง

• บทความนี้แสดงให้เห็นว่าทำไม ai agent ถึงเก่งมากกับงานบน UI framework ฉันเองก็พัฒนาแอปด้วย Rust และ GTK และเวิร์กโฟลว์ก็คล้ายกันมาก ไม่ใช่ว่าฉันไม่รู้วิธีทำอะไรบางอย่าง แต่ AI ช่วยจัดการงานค้นหาซ้ำ ๆ ที่น่าเบื่อและการลองผิดลองถูกในงาน UI framework ไปได้เกือบทั้งหมด จึงช่วยได้มาก Mitchell เข้าใจโค้ดทั้งหมดตลอดกระบวนการทำงาน และเขารู้อยู่แล้วว่าตัวเองต้องทำอะไร ตรงนี้จึงต่างจากสิ่งที่เรียกว่า "vibe coding" โดยสิ้นเชิง ไม่มีทางลัดพิเศษในการจะกลายเป็นผู้เชี่ยวชาญได้ Ghostty ดีมากจริง ๆ

• LLM ทำให้การเขียนโค้ดกลับมาสนุกอีกครั้ง ในงานประจำ LLM ช่วยเรื่องที่ยากที่สุดคือการออกตัวช่วงแรก ทำให้เริ่มลงมือได้อย่างรวดเร็ว มันยังมีประโยชน์มากเวลาต้องทำความเข้าใจ codebase ใหม่หรือเขียนส่วนที่น่าเบื่อ แต่ความสนุกจริง ๆ เริ่มต้นใน side project เพราะมันทำให้ฉันลองทำไอเดียฉับพลันได้เร็วมาก ตอนนี้ไม่จำเป็นต้องเสียเวลาหลายชั่วโมงเขียน boilerplate code หรือสู้กับ tooling อีกแล้ว ส่วนไหนที่ฉันไม่คุ้นเคยก็โยนให้เอเจนต์จัดการ หรือสั่ง prompt ทีเดียวให้ดึงฟีเจอร์ออกมาก่อน ถ้าผลลัพธ์ไม่ถูกใจก็ย้อนกลับทันที

• ขอถามนอกเรื่องนิดหนึ่ง ทำไมจนถึงตอนนี้แอปแทบทั้งหมดถึงยังต้องมีเฟรมเวิร์กอัปเดตของตัวเองอยู่ ไม่สามารถรวมฟังก์ชันนี้เข้าไปใน app store หรือ package manager ได้หรือ?

  • ใน ecosystem ของ macOS เรื่องแบบนี้ทำได้ค่อนข้างยาก

  • อย่างใน Ubuntu เรื่องนี้ค่อนข้างสะดวก เช่นถ้าดาวน์โหลดเวอร์ชันล่าสุดมาติดตั้งเอง หลังจากนั้นก็จะได้รับการอัปเดตอัตโนมัติต่อเนื่อง

• ท้ายที่สุด ส่วนที่คุณยอมรับเองว่ายังทำได้ไม่ดีนัก—ก็คือช่วง zero to one—ถ้าคุณยกให้ AI ทำไปเสียหมด มันก็จะกลายเป็นพื้นที่ที่คุณไม่มีวันฝึกได้ด้วยตัวเอง ถ้าคุณยังอยากทำเองในอนาคต ก็ต้องฝึกส่วนนั้นด้วยตัวเอง

• Ghostty ดีมากจริง ๆ และฉันเกือบจะเลิกใช้ iTerm แล้ว แต่พอกด cmd-f แล้วไม่มีอะไรเกิดขึ้นเลยก็ต้องยอมแพ้ หน้า issue และ feedback

  • ถ้ามี cmd-f มาตั้งแต่แรก ฉันสงสัยจริง ๆ ว่าบทสนทนาใต้โพสต์เกี่ยวกับ ghostty จะเป็นอย่างไร เริ่มเบื่อเหมือนกันที่ทุกโพสต์ต้องได้ยินเรื่องนี้ ทั้งที่จริงน่าจะมีประเด็นน่าสนใจกว่านี้เกี่ยวกับเครื่องมือ LLM หรือแนวทางการเขียนโค้ดให้คุยกัน แต่สุดท้ายทุกคนก็มักวกกลับมาพูดเรื่อง cmd-f อีก

  • น่าขันดีเหมือนกัน เพราะสุดสัปดาห์ที่แล้วฉันใช้ Claude ทำฟีเจอร์ค้นหาให้ Ghostty จริง ๆ ส่วนการค้นหาจริงมีโค้ดที่ทำงานแบบงู ๆ ปลา ๆ อยู่ก่อนแล้ว ดังนั้นงานส่วนใหญ่คือเชื่อมกับ UI ภายในสองเซสชัน (รวมประมาณ 10 ชั่วโมง) ฉันก็ทำให้การค้นหาพื้นฐาน การไฮไลต์ และการเลื่อนไปยังผลลัพธ์ก่อนหน้า/ถัดไป ใช้งานได้บน Linux frontend ฟีเจอร์ค้นหานี้ยังชัดเจนว่าเป็น WIP จึงยังไม่พร้อมสำหรับผู้ใช้ทั่วไป ระหว่างทำงานฉันยิ่งตระหนักว่าฟีเจอร์ที่ดูเหมือน "พื้นฐาน" แบบนี้ พอจะให้ทำงานกับข้อความแบบสตรีมมิงแล้ว มันซับซ้อนแค่ไหน

  • ฉันก็รู้สึกเสียดายเหมือนกันที่ Ghostty มินิมัลเกินไป เลยกลับไปใช้ Warp อย่างรวดเร็ว อ้างอิงไว้ด้วยว่า scrollback buffer เริ่มต้นของ Ghostty อยู่ที่ราว 10MB และปรับได้ตามต้องการในการตั้งค่า

  • ฟีเจอร์ค้นหานี้มีแผนเป้าหมายไว้สำหรับ v1.3 ในเดือนมีนาคม 2026 ลิงก์ roadmap

• พอเห็นประโยคในบทความที่ว่า "มาดูว่าอะไรเป็นแรงผลักดันให้เพิ่มฟีเจอร์นี้" ก็ทำให้นึกขึ้นได้อีกครั้งว่าเราทนกับความไม่สะดวกใน OS กันมากแค่ไหน การพรีเซนต์หรือการแชร์หน้าจอก็เป็นเรื่องปกติมาหลายสิบปีแล้ว แต่ทำไมแม้แต่การตั้งค่าพื้นฐานที่บังคับให้แสดงเฉพาะหน้าต่างพรีเซนต์บนหน้าจอก็ยังทำได้ยากนัก

[xguru]

นี่คือ Ghostty เครื่องมือที่ช่วงนี้ Mitchell Hashimoto ผู้ร่วมก่อตั้ง HashiCorp ทุ่มเวลาให้เกือบทั้งหมด

เปิดตัว Ghostty 1.0 - เทอร์มินัลอีมูเลเตอร์ความเร็วสูงแบบข้ามแพลตฟอร์ม
libghostty กำลังมา

เขาสนับสนุน agentic coding และพูดว่าการแชร์เซสชันสำคัญมากจริงๆ
แต่ลิงก์ส่วนใหญ่เชื่อมไปยังเซสชันของ AMP นะ Amp - เครื่องมือ agentic coding