ซอฟต์แวร์ถูกสร้างขึ้นระหว่างคอมมิต

 (zed.dev)
1 คะแนน โดย GN⁺ 4 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • DeltaDB คือระบบควบคุมเวอร์ชันรูปแบบใหม่ที่จัดการเวอร์ชันทั้งบทสนทนากับเอเจนต์และ worktree ที่เอเจนต์แก้ไขร่วมกัน
  • Git ถูกออกแบบมาโดยยึด commit แต่ละรายการเป็นศูนย์กลาง จึงไม่ได้ออกแบบมาเพื่อจัดการทั้งบทสนทนาที่ดำเนินต่อเนื่องและการเปลี่ยนแปลงโค้ดที่เกิดขึ้นระหว่างที่โค้ดยังเปลี่ยนอยู่ตลอด
  • DeltaDB บันทึกไม่ใช่แค่คอมมิต แต่บันทึกการดำเนินการทั้งหมดที่เกิดขึ้นระหว่างทำงานเป็นสตรีม delta แบบละเอียด และกำหนดตัวระบุที่เสถียรให้กับแต่ละเดลตา
  • ข้อความและการแก้ไขที่ข้อความนั้นก่อให้เกิดจะถูกบันทึกเคียงกัน และหลายคนกับเอเจนต์หลายตัวสามารถแก้ไขไฟล์เดียวกันพร้อมกันได้บนคนละเครื่อง
  • การทำงานร่วมกันสามารถเกิดขึ้นได้โดยตรงมากกว่าเดิมภายใน บทสนทนา และใน worktree ระหว่างที่โค้ดกำลังก่อตัว แทนที่จะรอขั้นตอนรีวิวหลังคอมมิตและ push

ที่มาและปัญหาที่ต้องการแก้

  • ทีม Zed ไม่คุ้นกับวิธีทำงานแบบ pull request และได้สร้างความเชื่อใจรวมถึงความเข้าใจร่วมกันผ่านการทำงานร่วมกันใน worktree เดียวกัน พร้อมพูดคุยกันระหว่างเขียนโค้ด
  • GitHub ทำให้การพูดคุยเกี่ยวกับโค้ดเกิดขึ้นได้ก็ต่อเมื่อคอมมิตและ push แล้ว แต่สำหรับทีม Zed บทสนทนาสำคัญมักจบไปก่อนถึงจุดนั้น
  • Zed เริ่มต้นขึ้นในปี 2021 เพื่อก้าวข้ามข้อจำกัดของคอมมิต โดยตั้งใจจะสร้างเอดิเตอร์ที่เหมาะกับนักพัฒนาระดับโลกก่อน แล้วจึงมอบวิธีการทำงานร่วมกันที่ดีกว่าภายในนั้น
  • ปัญหาที่ครุ่นคิดมายาวนานในบริบทการทำงานร่วมกันระหว่างมนุษย์ ยิ่งมีความสำคัญมากขึ้นเมื่อทำงานร่วมกับเอเจนต์
  • บทสนทนา ที่สร้างโค้ดกำลังกลายเป็นแหล่งกำเนิดที่แท้จริงของซอฟต์แวร์มากขึ้นเรื่อย ๆ และบทสนทนานั้นจำเป็นต้องอ้างอิงถึงโค้ดที่เปลี่ยนแปลงและพัฒนาอยู่ตลอดได้
  • Git ถูกสร้างขึ้นโดยมีคอมมิตเดี่ยว ๆ เป็นศูนย์กลาง จึงไม่ได้ออกแบบมาเพื่อรองรับการเชื่อมโยงระหว่างบทสนทนาต่อเนื่องเช่นนี้กับการเปลี่ยนแปลงของโค้ด

DeltaDB และก้าวถัดไป

  • ไม่ใช่ทุกคอมมิต แต่คือทุกการดำเนินการ

    • DeltaDB แบ่งงานออกเป็นสตรีม delta แบบละเอียด และต่างจาก Git ที่เก็บ snapshot ต่อหนึ่งคอมมิต มันจะบันทึกทุกการดำเนินการที่เกิดขึ้นระหว่างคอมมิต
    • แต่ละเดลตามีตัวระบุที่เสถียร จึงสามารถชี้ไปยังช่วงเวลาหนึ่งของกระบวนการวิวัฒนาการได้ แม้โค้ดยังคงเปลี่ยนอยู่ตลอด
    • worktree จะถูกจัดการเวอร์ชันในฐานะกระบวนการของการเปลี่ยนแปลงเอง และถูกจัดการร่วมกับบทสนทนาที่ขับเคลื่อนการเปลี่ยนแปลงนั้น
    • ข้อความและการแก้ไขที่ข้อความนั้นก่อให้เกิดจะถูกบันทึกเคียงกันโดยไม่แยกออกจากกัน
    • DeltaDB มี worktree แบบ replicated ที่ไม่มี conflict ในตัว ทำให้หลายคนและหลายเอเจนต์สามารถแก้ไขไฟล์เดียวกันพร้อมกันได้บนคนละเครื่อง
    • ไฟล์ยังคงเป็นไฟล์จริง เอเจนต์สามารถทำงานกับไฟล์ผ่านเทอร์มินัล และผู้ใช้สามารถ mount worktree ทั้งหมดลงดิสก์เพื่อใช้เครื่องมือของตนเองได้เมื่อจำเป็น

  • ซอร์สโค้ดตอนนี้คือบทสนทนาต้นทาง

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

  • การทำงานร่วมกันไม่ควรต้องคอมมิตก่อน

    • เป้าหมายคือให้บทสนทนากับเอเจนต์กลายเป็นบทสนทนาเดียวที่จำเป็นต่อการทำงานร่วมกัน
    • สมาชิกทีมสามารถเข้าร่วมได้ตั้งแต่งานยังดำเนินอยู่ พูดคุยกับเอเจนต์ที่ทำงานนั้น และใส่ความเห็นได้ระหว่างที่งานกำลังคืบหน้า
    • สมาชิกทีมไม่จำเป็นต้องรอให้มีคอมมิตและ push ก่อนจึงจะเข้าร่วมได้
    • pull request, review thread และ inline comment เป็นเพียงขั้นตอนที่ใช้แนบการสนทนากลับเข้ากับโค้ดในภายหลัง เพราะก่อนหน้านี้โค้ดกับการพูดคุยอยู่กันคนละที่
    • เมื่อโค้ดกับการพูดคุยอยู่ในที่เดียวกัน ขั้นตอนเหล่านั้นก็หายไป
    • Git และ CI จะยังคงมีบทบาทในการรันการตรวจสอบและเชื่อมต่อกับโลกภายนอก โดยไม่เป็นสถานที่ที่การทำงานร่วมกันถูกบังคับให้เกิดขึ้น

  • ก้าวถัดไป

    • ตอนนี้ซอฟต์แวร์ไม่ได้ก่อตัวขึ้นจากคอมมิตอีกต่อไป แต่ก่อตัวขึ้นภายใน บทสนทนา
    • DeltaDB คือระบบควบคุมเวอร์ชันสำหรับสิ่งนี้ และจะเปิดให้ผู้ใช้กลุ่มแรกได้ใช้งานภายในไม่กี่สัปดาห์
    • หากอยากลองใช้ก่อน สามารถลงชื่อในรายชื่อรอได้

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 4 시간 전
ความคิดเห็นจาก Hacker News

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

    • จากคอมเมนต์ที่นี่และเครือข่ายอาชีพของผม คนส่วนใหญ่ดูจะแบ่งเป็นสองฝั่ง ฝั่งหนึ่งใช้ Git เหมือน autosave แบบหยาบ ๆ แล้วค่อยรวมตอน merge อีกฝั่งชอบ คอมมิตแบบอะตอมิก ที่จัดระเบียบเรียบร้อยและทำงานได้สมบูรณ์
      จากประสบการณ์ของผม แบบแรกพบได้บ่อยกว่า อาจเพราะ GitHub รองรับวิธีนั้นได้เป็นธรรมชาติกว่า และ cumulative commits ก็ช่วยแก้ปัญหาบางส่วนของแบบที่สองได้ ถ้าต้องเลือก ผมว่าแบบแรกสมเหตุสมผลกว่ามาก
    • นี่ไม่ใช่ปัญหาของเครื่องมืออย่าง Phabricator หรือ Gerrit แต่เป็น ปัญหาของ GitHub ล้วน ๆ ไม่ใช่หรือ?
    • จะเป็นซุปเละเทะหรือไม่ก็ตาม ถ้าพื้นที่ดิสก์หรือค่าใช้จ่ายไม่ใช่ปัญหา การที่ใครสักคน—อาจเป็นเอเจนต์—จะมาดูว่าผมทำอะไรไปบ้างก็คงไม่เป็นไร
      ผมไม่ได้มั่นใจมากนัก แต่คิดว่าเอเจนต์น่าจะชอบ ข้อมูลเพิ่มเติม แม้บางคนจะมองว่ามันเป็นสัญญาณรบกวนก็ตาม
    • คาดอยู่แล้วว่าจะมีปฏิกิริยาแบบนี้ ตอนอ่านบทความก็จำได้ว่ารู้สึกผิดหวังทุกครั้งที่เห็นอารมณ์แบบเดียวกันในประเด็นเรื่อง version control
      มีคนมากเกินไปที่ทิ้งบันทึกทิ้งอย่างง่ายดายเพียงเพื่อให้มันดู “สะอาด” มันไม่สมเหตุสมผล แต่กลับเข้ากับตรรกะแบบโปรแกรมเมอร์บางประเภทที่พบได้บ่อยจนน่าแปลก
      วิธีของผมคือคอมมิตบ่อยมาก วันหนึ่งเป็นสิบ ๆ ครั้ง คอมมิตคือบันทึกของสิ่งที่เกิดขึ้น และผมอยากเก็บบันทึกนั้นไว้ให้มากที่สุดเท่าที่จะทำได้ หลายครั้ง git bisect ชี้ไปที่คอมมิตเล็ก ๆ แค่บรรทัดเดียวที่ดูไม่มีปัญหาอะไร แต่กลับช่วยหาบั๊กละเอียดอ่อนที่เพิ่งถูกพบในภายหลังได้
      สำหรับผม source control มีไว้เพื่อค้นหาเรื่องแบบนั้น ถ้าต้องไล่ทุกบรรทัดในคอมมิตใหญ่ ๆ ปัญหาแบบนี้จะเจ็บปวดกว่านี้มาก
      เพราะงั้นเวลาที่เห็นคนตั้งใจจับคอมมิตทั้งก้อนในระดับ PR มารวมกัน แล้วโยนทิ้งส่วนเดียวของ version control ที่มีประโยชน์จริง ๆ ไป ผมจึงไม่เข้าใจเลย และเมื่อมีคนจำนวนมากอยู่ฝั่งเดียวกับคอมเมนต์แม่ แผนของผู้เขียนที่จะเก็บบันทึกอย่างละเอียดก็คงเป็นศึกที่ไม่ง่าย
    • วิธีที่คุณใช้คอมมิตฟังดูคล้ายกับวิธีที่ผมใช้ stacked PRs ในบริษัท
      สุขอนามัยของคอมมิตที่ดีนั้นบังคับใช้ในระดับทีมได้ยาก แต่แปลกดีที่พอเป็นระดับ PR ผู้คนกลับค่อนข้างร่วมมือในการเขียนคำอธิบายดี ๆ และรักษากลุ่มการเปลี่ยนแปลงให้สะอาดเรียบร้อย

  • มันฟังดูเหมือน การ autosave แบบคอมมิตถี่ ที่เชื่อใจ Git น้อยไปหน่อย ซึ่งจริง ๆ แล้ว Git จัดการกับการ autosave แบบคอมมิตถี่ได้ดีพออยู่แล้ว
    ถ้าคุณอยากคง “บทสนทนา” ของคอมมิต autosave ตามช่วงเวลาไว้ พร้อมกับม้วนมันขึ้นไปเป็นคอมมิตระดับบนที่ “สะอาด” กว่า ก็ใช้ git merge --no-ff เป็นครั้งคราว แล้วใช้เครื่องมืออย่าง --first-parent เพื่อโฟกัสที่คอมมิตระดับบนมากกว่าคอมมิต “บทสนทนา” ได้
    ฝั่งแบ็กเอนด์ของ Git มี การปรับแต่ง Delta DB อยู่มากแล้วทั้งใน Git pack และเครื่องมืออื่น ๆ จุดที่ควรขยับจริง ๆ คือฟรอนต์เอนด์ของ Git—โดยเฉพาะ --first-parent—รวมถึง UI Git จำนวนมากที่เน้นหรือใช้แต่ “แผนที่เส้นรถไฟใต้ดิน” หลายคนมองแผนที่แบบนั้นว่าน่าเกลียด ชวนสับสน และชวนหงุดหงิด ดังนั้นจึงควรมี UI แบบเจาะลึก ที่สอดคล้องกับ --first-parent มากกว่านี้

    • ผมก็ทำแบบนั้นเหมือนกัน ปกติจะไม่ดูคอมมิตในกิ่ง แต่ถ้าจำเป็นมันก็ยังอยู่ตรงนั้น git blame ก็สามารถตั้งค่าให้ใช้ --first-parent ได้เหมือนกัน

  • ผมเห็นด้วยกับประโยคที่ว่า “ซอฟต์แวร์ถูกสร้างขึ้นระหว่างคอมมิต” แต่ไม่เห็นด้วยกับประโยคที่ว่า “DeltaDB จับงานทั้งหมดระหว่างแต่ละคอมมิตได้”
    อย่างแรกเลย มันให้ความรู้สึก ล่วงล้ำ ผมก็ไม่อยากได้ตัวบันทึกหน้าจอที่เปิดตลอด 24 ชั่วโมงระหว่างทำงานเหมือนกัน การที่ความผิดพลาดของผมถูกเปิดเผยอาจไม่ใช่เรื่องผิดอะไร แต่ถ้าผมทำงานได้ดี คุณค่าที่ผมสร้างก็ควรอยู่ในคอมมิต และวิธีนั้นก็ให้ความรู้สึกล่วงล้ำน้อยกว่ามาก
    อย่างที่สอง ผมใช้หลายเครื่องมือ และไม่อยากรวมทั้งหมดเข้าไปไว้ใน DB แปลก ๆ ก้อนหนึ่ง ถ้าในบางจุดสุดท้ายแล้วมันกลายเป็นแค่ “มีกระบวนการภายนอกทำอะไรบางอย่าง” การพยายามจับทุกอย่างไว้จะมีความหมายอะไร? เป็นเรื่องดีที่ Zed รวมอะไรได้หลายอย่าง แต่ไม่ได้แปลว่าผมจะใช้ทุกอย่างที่รวมอยู่ใน Zed และเท่าที่ผมเช็กล่าสุด ถ้าใช้ Claude Code ผ่าน ACP ใน Zed ก็ยังย้อนกลับไปแก้ข้อความก่อนหน้าไม่ได้ด้วยซ้ำ
    สุดท้าย ในมุมมองส่วนตัว ผมคิดว่าเราพลาดแก่นแท้ของคอมมิตไปแล้ว ส่วนใหญ่ผู้คนสร้างก้อนการเปลี่ยนแปลงแบบตามใจขนาดไม่จำกัดขึ้นมา จากนั้นค่อยรัน git commit แล้วก้อนการเปลี่ยนแปลงนั้นก็ถูกรีวิวเป็นก้อนใหญ่ก่อนที่คอมมิตจะถูกรวม มันไม่ใช่จุดจบของโลก แต่คอมมิตที่ปั้นขึ้นอย่างประณีตด้วยมือนั้นยอดเยี่ยมจริง ๆ ลองรัน git blame ในโปรเจกต์ที่บังคับแนวทางแบบนี้ดู แล้วจะเข้าใจทันทีว่าผมหมายถึงอะไร
    สิ่งอย่าง DeltaDB มีแต่จะยิ่งเสริมและทำให้พฤติกรรมการจับคอมมิตแบบลวก ๆ เป็นก้อนแข็งตัวมากขึ้น ถ้าอยากรู้ว่าเกิดอะไรขึ้น ตอนนี้ก็แค่ไปแอบดูการสนทนาระหว่างผู้ใช้กับ LLM แบบถ้ำมองแล้วเปิดย้อนดูเอา
    ประเด็นสุดท้ายน่าสนใจ แต่ก็น่ารำคาญด้วย ผมไม่เคยโน้มน้าวให้คนบันทึกการเปลี่ยนแปลงและแรงจูงใจเพราะมันเป็นแนวปฏิบัติทางวิศวกรรมที่ดีและช่วยทีมได้ แต่ทุกคนกลับเต็มใจอธิบายให้ LLM ฟัง เพราะมันจำเป็นถ้าอยากให้ LLM ทำงานให้ เลยยิ่งน่าสนใจว่าผู้คนยอมทำสิ่งที่เมื่อก่อนไม่เคยทำมากแค่ไหนเพียงเพื่อ เอาใจ LLM อยู่ ๆ สิ่งที่ก่อนหน้านี้ไม่เคยถูกบันทึกไว้ก็ไปโผล่อยู่ใน CLAUDE.md

  • โค้ดที่เขียนระหว่างแต่ละ commit คือกระบวนการคิดของฉันเอง ฉันคิดไปพร้อมกับลองเขียนโค้ด ลบ แล้วเขียนใหม่
    ส่วนโค้ดที่ถูกส่งออกไปพร้อม commit นั้นถูกเขียนให้คนอื่นเข้าใจ และเป็นผลลัพธ์ของกระบวนการที่เขียนขึ้นเพื่อใช้คิด ฉันไม่ต้องการให้ความคิดของตัวเองถูกทำให้เป็นอนุกรม ถูกจัดการเวอร์ชัน และเข้าถึงได้แบบสาธารณะ
    https://www.nature.com/articles/s44222-025-00323-4

    • เรื่องนี้มีปัญหาแบบเดียวกันกับ JJ ด้วย ฉันไม่ต้องการให้ทุกอย่างระหว่างแต่ละ commit ถูกจัดการเวอร์ชัน
      และก็ไม่แน่ใจด้วยว่าสถานะกลางทั้งหมดระหว่าง commit นั้นเกี่ยวข้องหรือมีประโยชน์จริงไหม แต่เหมือนฉันจะเป็นเสียงส่วนน้อย
    • เพราะแบบนี้ฉันเลยใช้ rebase ก่อนเปิด PR และไม่ชอบ squash ผ่านไปอีก 2 ปีคุณจะจำไม่ได้แล้วว่าทำไมถึงเขียนโค้ดแบบนั้น และในการทำความเข้าใจบั๊กกับระบุสถานการณ์แบบ รั้วของเชสเตอร์ตัน สิ่งที่มีอยู่ก็มีแค่ delta กับประวัติ commit
      ถ้าคุณ squash มันไป สิ่งที่เหลือเป็นบริบทก็มีแค่โค้ด 400 บรรทัดที่คุณเขียน “รวดเดียว” กับ feature request ที่โค้ดนั้นถูกผูกไว้ด้วย ซึ่งไม่ช่วยอะไรเลย
      คนที่แย่ที่สุดที่ฉันเคยเจอคือคนที่เขียนโมดูลใหม่ทั้งก้อนแล้วไม่ check in อะไรเลยจนกว่าจะพอใช้งานได้ มันน่าจะเชื่อมโยงกับอีโก้ที่เปราะบางแบบที่แอบแก้บั๊กในโค้ดตัวเองโดยไม่ยอมพูดถึงก่อนด้วย เขาเขียนโค้ดเข้าใจยากที่สะท้อนกฎของ Kernighan ทั้งที่มีประสบการณ์มากพออีกอย่างน้อย 10 ปีจนไม่ควรทำแบบนั้นแล้ว เขาชอบอวดว่าโค้ดของตัวเอง “ทรงพลัง” ซึ่งไม่ใช่คำชม แต่เป็นลางบอกเหตุ ฉันเจอบั๊กในโค้ดจาก commit แรกของเขาหลายครั้ง ขอแค่ทิ้งอะไรไว้บ้างเถอะ
      คุณไม่จำเป็นต้องสารภาพว่าลองมั่วทุกอย่างไปเรื่อยจนกว่าจะเจอปัญหา หลังจากรู้แล้วว่าไปถึงจุด B ได้ คุณก็แค่สร้างเรื่องเล่าที่ต้องการจาก A ไป B แล้วจัดเรียง commit ใหม่ให้เป็นแบบที่คุณคงจะเขียน ถ้ารู้ตั้งแต่แรกว่าต้องทำอะไร ส่วน 90% ของโค้ดที่เขียนแล้วลบทันที หรืออะไรที่ไม่ช่วยพยุงเรื่องเล่านั้น ก็ทิ้งไปได้
      ในวงการบังคับใช้กฎหมายมีสิ่งที่เรียกว่า parallel construction คือคุณอาจรู้ว่าผู้ต้องสงสัยมีความผิดจากข้อเท็จจริงที่ใช้ในศาลไม่ได้ แต่ก็ต้องค้นพบข้อเท็จจริงเดียวกันนั้นใหม่ตามกระบวนการ เช่น ไปเก็บขยะในวันรถมาเก็บ สัมภาษณ์เพื่อนบ้าน รวบรวมพยานแวดล้อมให้พอขอหมายค้น แล้วค่อยหาหลักฐานนั้นเจออีกครั้ง
    • ดูเหมือนจะนึกถึง AI agent เป็นหลัก เป็นไอเดียที่น่าสนใจที่ฉันเคยเห็นมาก่อน และก็ตลกดีที่ตอนนี้ทุกคนดูเหมือนจะพยายามประดิษฐ์อะไรใหม่เพื่อ AI กันหมด
      แต่ฉันก็ยังสงสัยอยู่ว่าจะไม่แค่สร้างไฟล์ข้อความขึ้นมาแล้วใส่อ้างอิง commit ลงไปไม่ได้หรือไง และก็ไม่เข้าใจด้วยว่าทำไมถึงใช้ Fossil ไม่ได้ มันเป็นฐานข้อมูล SQLite อยู่แล้ว เลยยัดสิ่งที่ต้องการรวมเข้าไปได้ และยังมีฟีเจอร์สารพัดแบบที่อ้างอิง commit ได้ในตัว
    • ฉันยังสงสัยกับส่วนของการทำงานร่วมกัน แต่ก็เข้าใจเจตนาเพราะมันฟังดูเหมือนฟีเจอร์สำหรับลูกค้าองค์กร
    • เห็นด้วยเต็มที่ ความรู้สึกแบบ การเฝ้าระวัง น่าขยะแขยงมาก โดยเฉพาะตรงที่บอกว่า “DeltaDB แยกงานออกเป็นสตรีมของ delta แบบละเอียด ขณะที่ Git จับ snapshot ของแต่ละ commit, DeltaDB จะจับทุกการทำงานระหว่างนั้นและให้ตัวระบุที่เสถียรกับแต่ละรายการ”
      ตอนแรกได้ยินมาว่า Zed มี emacs keymap แล้วเลยคิดว่าจะลองใช้ดู แต่ตอนนี้ไม่เอาแล้ว ฟีเจอร์นี้ล่วงล้ำเกินไปอย่างน่ากลัว และฉันไม่ต้องการเลยให้เพื่อนร่วมงานมาตรวจดูการแก้ไขระหว่างทางทั้งหมดจนถึง commit ที่ฉันเปิดให้รีวิว ในระดับทีละการกดแป้นพิมพ์
      ก่อนเปิด PR บางครั้งฉันจะเกลาประวัติ commit ใน magit เล็กน้อยให้เป็นเส้นตรงและอ่านง่ายขึ้น เช่น แก้คำอธิบายหรือรวม commit ที่อยู่ติดกัน แต่ฟีเจอร์นี้เท่ากับโยนงานส่วนนั้นทิ้งทั้งก้อน แล้วพูดว่า “เพื่อนร่วมงานเอ๋ย เชิญสูบสายฉีดดับเพลิงของ delta นี้ให้อิ่มใจไปเลย”
      ประโยคที่ว่า “สิ่งที่เราต้องการจริง ๆ นั้นง่ายมาก เราอยากให้การสนทนากับ agent กลายเป็นการสนทนาเดียวที่คุณต้องมี” นี่มันหมายความว่าอะไรกันแน่ ไม่เอานะ ผิดแล้ว

  • แค่คิดว่า Anthropic หรือ OpenAI จะ เข้าซื้อ Zed อย่างหลีกเลี่ยงไม่ได้ก็ชวนให้รู้สึกไม่สบายใจแล้ว ไอเดียมันดีเกินไปและซอฟต์แวร์ก็ดีเกินไป

    • coding harness ของ Zed ดีกว่า Claude Code มาก แต่เพราะมันใช้ Claude API โดยตรง เลยแพงกว่ามาก ถ้ามันเข้าไปอยู่ในสายผลิตภัณฑ์เดียวกัน ก็อาจกลายเป็นของที่นิยามหมวดหมู่ผลิตภัณฑ์ได้เลย
    • แล้วทำไมต้องหยุดแค่ Zed? เงินลงทุน 1 ล้านล้านดอลลาร์ ที่บริษัท AI ระดมมา เดิมทีตั้งใจไว้สำหรับดาต้าเซ็นเตอร์ก็จริง แต่ถ้าต้นทุนพุ่งขึ้นและกำหนดสร้างเสร็จยืดยาวเกินกรอบแผนธุรกิจปกติ เอาเงินนั้นไปใช้ที่อื่นอาจคุ้มกว่า 1 ล้านล้านดอลลาร์ซื้ออะไรก็ได้ที่ต้องการ
    • ที่ที่ Anthropic หรือ OpenAI กำลังจะไป ดูเหมือนจะไม่มี editor เหลืออยู่อีกต่อไปแล้ว ส่วนตัวฉันอยากได้เครื่องมืออ่านโค้ดแบบอ่านอย่างเดียวที่ดีกว่านี้ ไม่ก็การกลับมาของ UML

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

    • ถ้าผู้จัดการคนไหนใช้เวลาหมดไปกับการเฝ้าดูทุกการกดแป้นพิมพ์ของนักพัฒนาทุกคนใต้บังคับบัญชา แปลว่าเขาคงไม่มีงานจริงหรือปัญหาธุรกิจที่ควรใส่ใจเหลืออยู่แล้ว

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

  • Google น่าจะทำเรื่องนี้มากับ citc มาราว 10 ปีแล้ว ฉันไม่รู้ว่า Gemini จะเอาสิ่งนี้มาใช้จริงเมื่อไร แต่ Google มีบันทึกของนักพัฒนาแทบทุกคนแบบแทบครบถ้วนในระดับ Ctrl-S ทุกครั้ง มาอย่างน้อย 10 ปีแล้ว
    ถ้าตอนนี้ Gemini ยังดูทึ่ม ๆ นั่นก็แค่เพราะพวกเขายังประหยัดการจัดสรรคอมพิวต์อยู่เท่านั้น
    0 - https://en.wikipedia.org/wiki/Piper_(source_control_system)

  • ตรงนี้ฉันไม่เข้าใจว่า ข้อเสนอคุณค่า คืออะไร เห็นหลายบริษัทเสนอฟีเจอร์ประมาณนี้ แต่ยังไม่เคยเห็นที่ไหนอธิบายเหตุผลที่น่าโน้มน้าวได้เลยว่าทำไมเทคโนโลยีนี้ต้องมีอยู่

    • น่าสนใจที่ประสบการณ์และเวิร์กโฟลว์ของคุณต่างจากของฉันมากขนาดนี้ นี่คือฟีเจอร์ที่อ้างว่าแก้ปัญหาจริงที่ฉอเจอทุกวัน
      บริษัทของเราทำงานรีโมตเต็มรูปแบบ และเพื่อนร่วมงานส่วนใหญ่ก็ไม่ได้อาศัยอยู่ใกล้ฉัน เราคุยกันผ่านวิดีโอคอลวันละไม่กี่ครั้ง แต่สื่อสารกันหลัก ๆ ผ่าน Slack
      เราถือว่าอยู่ค่อนข้างล้ำหน้าบนเส้นโค้งของการนำ LLM agent มาใช้เพื่อเขียนโค้ดที่ดี ทุกวันนี้ LLM เขียนโค้ดส่วนใหญ่ของเรา เพราะมีทั้งโมเดลที่ดีและระบบป้องกันที่ดีมากของ coding harness บางตัว
      โดยปกติหนึ่งวันฉันจะหยิบตั๋วงานหนึ่งใบ ชี้ให้ LLM ดู แล้วเริ่มแก้ปัญหาไปด้วยกัน ตัดสินใจด้านสถาปัตยกรรม วางแผน และลงมือทำ ฟีเจอร์ล่าสุดที่ฉัน deploy มีค่าใช้จ่ายด้านโทเค็น 19 ดอลลาร์ และช่วงที่กำลังทำงานเข้มข้น LLM ทำงานต่อเนื่องเองได้ราว 30 นาทีโดยไม่มีอินพุตจากฉัน
      ฉันอาจโพสต์คำถามในแชตทีมเพื่อขอความเห็นจากเพื่อนร่วมงานได้เช่นกัน แต่จะทำก็ต่อเมื่อไม่แน่ใจว่าทิศทางไหนดีกว่า อย่างไรก็ตาม หลายตั๋วงานก็เสร็จได้แบบอัตโนมัติทั้งหมด
      จากนั้นฉันก็เปิด PR แล้วโพสต์ลิงก์ PR ลงใน Slack เพื่อขอรีวิว และเพื่อนร่วมงานก็จะได้เห็น implementation เป็นครั้งแรกตอนนั้น บางครั้งเพื่อนร่วมงานก็มีคำถาม GitHub comment ไม่ค่อยเหมาะกับบทสนทนาแบบเรียลไทม์เร็ว ๆ เลยทำให้หลายครั้งพวกเขาไปถามกันในเธรด Slack มากกว่าในคอมเมนต์ของ PR
      คำตอบของคำถามเหล่านั้นมีอยู่ในล็อกแชตกับ LLM บนแล็ปท็อปของฉัน แต่ไม่มีวิธีแสดงให้เพื่อนร่วมงานดูได้ง่าย ๆ เลยต้องเล่น เกมส่งสาร ด้วยการคัดลอกคำถามของเพื่อนร่วมงานจาก Slack ไปใส่ในแชตกับ LLM แล้วคัดลอกคำตอบกลับมาแปะอีกที
      ไอเดียที่ว่าเพื่อนร่วมงาน, LLM และฉันจะเข้าร่วมอยู่ในบทสนทนาเดียวกันได้ง่ายขึ้นนั้นน่าดึงดูดมาก
      ไม่ได้แปลว่าสิ่งที่ทีม Zed กำลังทำคือทิศทางที่ถูกต้อง และก็เป็นไปได้ว่าถ้าทีมเราทำงานอีกแบบอาจจะดีกว่า แต่แนวทางปัจจุบัน “ประสบความสำเร็จ” มากเกินไปจนแทบไม่มีแรงกดดันในระดับองค์กรให้เปลี่ยน

  • งานของทีมซอฟต์แวร์คือการร่วมกันเรียนรู้โมเดลที่ทำงานได้อย่างมีประสิทธิภาพในโดเมนใดโดเมนหนึ่ง แล้วแสดงโมเดลและสิ่งที่เรียนรู้นั้นออกมาเป็นโค้ด เทสต์ และเอกสารที่เกี่ยวข้อง
    เพราะฉะนั้นในด้านหนึ่งฉันเห็นด้วยอย่างเต็มที่ว่า pull request และ code review บั่นทอนกระบวนการนี้อย่างร้ายแรง แต่ในอีกด้านก็สะดุ้งกับความคิดที่จะสร้างขั้นตอนและผลลัพธ์รองอื่น ๆ เพิ่มขึ้นมาอีกจนทำให้เราเสียสมาธิ ทั้งหมดนี้ควรแสดงออกอยู่ใน codebase
    ไม่ใช่เป็นอย่างอื่นแยกต่างหาก ไม่ใช่ชุดของ commit message หรือ ADR ถ้า codebase ไม่สามารถอธิบายได้อย่างครบถ้วนด้วยตัวเองต่อทั้งมนุษย์และ AI ว่ามีอะไรและทำไม ก็ถือว่าล้มเหลว และเราจะใช้เวลาทั้งชีวิตสร้างขั้นตอนเพิ่มขึ้นมาเพื่อจัดการกับความล้มเหลวนั้น

    • การแตก branch ที่ต้นทุนต่ำสำหรับฟีเจอร์และการทดลอง ความสามารถในการย้อนคืน commit ใด commit หนึ่งได้อย่างรวดเร็ว และการอ่านข้อความของ commit ที่เปลี่ยนโค้ดบรรทัดหนึ่งเป็นครั้งล่าสุด ล้วนสำคัญอย่างมหาศาล และทั้งหมดนี้คือสิ่งที่ระบบควบคุมเวอร์ชันแบบกระจายทำให้เป็นไปได้
      สถานะปัจจุบันของโค้ดเพียงอย่างเดียวไม่เพียงพอสำหรับการพัฒนาซอฟต์แวร์สมัยใหม่