คอขวดไม่เคยเป็นโค้ดเลย

 (thetypicalset.com)
1 คะแนน โดย GN⁺ 1 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Codex สร้างเวอร์ชันแรกที่ใช้งานได้ของการทดลองอัลกอริทึมการสร้างแบบมีโครงสร้างที่ .txt เลื่อนมานานกว่าหนึ่งปีได้ภายในไม่กี่ชั่วโมง แต่การเปลี่ยนแปลงสำคัญคือการเผยให้เห็น คอขวดของการทำงานร่วมกัน มากกว่าความเร็วการเขียนโค้ดส่วนบุคคล
  • เมื่อเอเจนต์รับหน้าที่ลงมือพัฒนา สิ่งที่ทำให้ทีมช้าลงจะไม่ใช่ผู้เขียนโค้ดอีกต่อไป แต่เป็นการสร้าง สเปกที่แม่นยำ ซึ่งเอเจนต์สามารถหยิบไปทำงานต่อได้ทันที เช่น โรดแมป เกณฑ์การยอมรับ และเอกสารออกแบบ
  • เมื่อค่าใช้จ่ายในการเขียนโค้ดลดลง ก็จะมีต้นแบบและเครื่องมือภายในที่เมื่อก่อนคงไม่ทำเพิ่มขึ้น ขณะที่ความเร็วที่ผู้ใช้จะรับสิ่งเหล่านี้ได้ยังเท่าเดิม ทำให้วินัยของการ โฟกัส ว่าจะไม่สร้างอะไรมีความสำคัญยิ่งขึ้น
  • เอเจนต์สามารถดึงการตัดสินใจโดยนัยและธรรมเนียมปฏิบัติจาก Slack, PR, issue, commit และเอกสารออกแบบมาสร้างเป็น ฐานความรู้ ได้ แต่ก็ยังไม่อาจสร้างบริบทที่มีร่วมกันจากการสั่งสมโดยมนุษย์ขึ้นมาใหม่ได้อย่างสมบูรณ์
  • ความได้เปรียบในอีก 10 ปีข้างหน้าอาจอยู่กับบริษัทที่รักษา ความสอดคล้องระดับองค์กร ให้ยังสอดรับกับชุดการตัดสินใจที่แคบลงได้ แม้ขยายสเกลเป็น 50, 200 หรือ 2,000 คน มากกว่าจะอยู่กับบริษัทที่มีโมเดลดีที่สุด

คอขวดที่เอเจนต์เขียนโค้ดเปลี่ยนไป

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

โรดแมปกลายเป็นข้อจำกัด

  • ในทีมที่ให้เอเจนต์ลงมือพัฒนา สิ่งที่ทำให้ช้าลงคือการสร้างสเปกที่แม่นยำพอให้เอเจนต์หยิบไปทำงานต่อได้ทันที
  • โรดแมป เกณฑ์การยอมรับ และ “สิ่งที่เราอยากได้จริง ๆ” ต้องถูกเขียนไว้อย่างชัดเจนในรูปแบบอย่าง test suite, ticket และเอกสารออกแบบ
  • ฟีเจอร์ต่าง ๆ ถูกพัฒนาได้อย่างรวดเร็วมาก และแทนที่วิศวกรจะต้องรอวิศวกรคนอื่น ก็กลายเป็นการรอสเปกที่เขียนถูกต้องซึ่งจะมาถัดไป
  • คอขวดจึงย้ายจากคนที่เขียนโค้ด ไปสู่คนที่ตัดสินใจว่าโค้ดแบบใดควรมีอยู่ ซึ่งท้ายที่สุดคือปัญหาเรื่อง การบริหารจัดการ

โค้ดที่ถูกลงต้องการฉันทามติมากขึ้น

  • เมื่อค่าใช้จ่ายในการเขียนโค้ดลดลง ความหมายไม่ได้มีแค่ว่าใช้ความพยายามเพียง 10% เพื่อให้ได้ผลลัพธ์เดิม แต่หมายถึงการทุ่มความพยายามเท่าเดิมให้กับผลลัพธ์ที่ก่อนหน้านี้ไม่คุ้มค่าจะทำ
  • ต้นแบบที่เมื่อ 3 เดือนก่อนยังถูกมองว่า “เสียเวลา” อาจถูกสร้างขึ้นได้ภายในบ่ายเดียว และเครื่องมือภายในที่ยังไม่มีความต้องการชัดเจนก็อาจถูกสร้างขึ้นแล้วถูกลืมไป
  • ความเร็วที่ผู้ใช้จะรับฟีเจอร์ได้ยังคงใกล้เคียงเดิม ไม่ว่าทีมจะปล่อยออกมา 10 ฟีเจอร์หรือ 50 ฟีเจอร์ก็ตาม
  • อย่างที่ Steve Jobs เคยพูดไว้ในปี 1997 ว่า “การโฟกัสคือการปฏิเสธ” และ Apple ก็ได้ตัดทอนสายผลิตภัณฑ์ไปราว 70% ในปีนั้น
  • เมื่อมีเอเจนต์ ความรู้สึกของการปล่อยฟีเจอร์ใหม่จะง่ายขึ้น จึงยิ่งทำให้วินัยในการตัดสินใจไม่ใช่แค่ว่าจะสร้างอะไร แต่รวมถึงจะไม่สร้างอะไรด้วย เป็นเรื่องที่ยากขึ้น

บริบทกลายเป็นทรัพยากรหลัก

  • การเจรจาและการตกลงกันดำเนินไปบนพื้นฐานของ บริบทร่วมกัน ภายในองค์กร
  • บริบทนี้รวมถึงสิ่งที่กำลังสร้างอยู่ เหตุใดมันจึงสำคัญ อะไรที่เคยลองไปแล้ว ใครตัดสินใจอะไร อะไรคือแก่นสำคัญ และอะไรเป็นเพียงร่องรอยที่หลงเหลืออยู่
  • มนุษย์ในทีมสะสมบริบทนี้อย่างเป็นธรรมชาติจากการอยู่ห้องเดียวกัน อ่านช่อง Slack เดียวกัน และดีบักเหตุขัดข้องเดียวกันตอนตี 2
  • บริบทส่วนใหญ่ไม่ได้ถูกบันทึกเป็นเอกสาร และแม้แต่เวลาที่วิศวกรอาวุโสพูดใน PR review ว่า “อันนี้จะทำให้ migration พัง” ก็อาจกำลังใช้บริบทที่ไม่เคยถูกเขียนไว้
  • เอเจนต์ไม่สามารถดูดซึมบริบทแบบนั้นได้ ไม่ได้อยู่ในห้อง ไม่ได้ฟังบทสนทนาเรื่องแผนงานแบบผ่าน ๆ และไม่ได้มีความทรงจำร่วมจากเหตุขัดข้องครั้งก่อน
  • บริบทที่ไม่ได้ถูกใส่ไว้ในพรอมป์ต์ โครงสร้างไฟล์ เครื่องมือ หรือคำสั่งที่ชัดเจน คือบริบทที่เอเจนต์จะไม่มีไว้ใช้อย่างมั่นคง
  • เมื่อไม่มีบริบท เอเจนต์ก็อาจสร้างคำตอบที่ฟังดูน่าเชื่อสำหรับคำถามที่ผิดไปเพียงเล็กน้อย
  • แม้เวลาที่เอเจนต์ทำงานที่มีประโยชน์ที่ .txt เบื้องหลังจริง ๆ ก็คือมีมนุษย์ทำงานด้านบริบทไว้แล้ว และไม่ได้แปลว่าวิศวกรอีก 10 คนถัดไปจะมีภาพนั้นอยู่โดยอัตโนมัติ
  • บริบทที่องค์กรพึ่งพาแบบโดยนัยมาโดยตลอด บัดนี้ได้กลายเป็นอินพุตที่จำกัดความเร็ว และมนุษย์ก็มักทิ้งมันไว้ในรูปโดยนัยเพราะไม่มีผู้รับที่จะอ่านเวอร์ชันที่ชัดแจ้งนั้น

วงจรที่เอเจนต์สร้างบริบท

  • การสร้างบริบทที่มนุษย์บริโภคได้ง่ายเป็นงานที่ผู้คนไม่ชอบทำ
  • เอเจนต์มีจุดแข็งในการอ่าน PR comment, issue ที่ปิดแล้ว, commit message, เอกสารออกแบบเก่า และคลังเก็บ Slack อย่างไม่ตกหล่น แล้วดึงรูปแบบที่ไม่เคยมีใครบันทึกไว้เป็นเอกสารออกมา
  • ที่ .txt ได้เริ่มสร้างเอเจนต์ที่ crawl codebase, issue, PR และ thread เพื่อเปลี่ยนการตัดสินใจโดยนัย ธรรมเนียมปฏิบัติ และ “ทำไมถึงทำแบบนี้” ให้กลายเป็นฐานความรู้
  • ฐานความรู้นี้ไม่ได้มีแค่ “โมดูลนี้มีอยู่” แต่ยังมีบริบทอย่าง “โมดูลนี้ดูแปลกเพราะ migration ต้องรักษาพฤติกรรมเดิมไว้” หรือ “benchmark นี้สำคัญเพราะการปรับแต่งครั้งก่อนเคยเปลี่ยน distribution อย่างเงียบ ๆ”
  • เมื่อเอเจนต์ตัวอื่นต้องลงมือทำงานกับ codebase ก็จะใช้ฐานความรู้นี้
  • การดูดซึมแบบไม่เป็นทางการที่มนุษย์เคยทำกัน จึงถูกทำให้เป็นสิ่งภายนอกในรูปแบบที่ทั้งเอเจนต์และมนุษย์อ่านได้
  • เอเจนต์ที่ใช้บริบทจำเป็นต้องมีเอเจนต์ที่สร้างบริบท และเมื่อวงจรนี้หมุนได้ องค์กรก็จะมีฐานเอกสารที่ตัวเองคงไม่เคยสร้างขึ้นมาเอง
  • อย่างไรก็ดี สิ่งที่วงจรนี้สร้างขึ้นย่อมเป็นภาพที่ไม่สมบูรณ์เสมอ
  • อย่างที่ Michael Polanyi กล่าวว่า “เรารู้มากกว่าสิ่งที่เราพูดออกมาได้” และบริบทสำคัญบางอย่างมีอยู่ได้ก็เพราะมันไม่เคยถูกเขียนเป็นคำพูด และอาจเปลี่ยนไปทันทีเมื่อถูกเขียนลงไป
  • ชั้นของการดูดซึมที่มนุษย์สร้างร่วมกันแบบพบหน้ากัน ไม่สามารถสร้างกลับมาได้อย่างสมบูรณ์จากเพียงผลพลอยได้ที่เป็นเอกสาร
  • ผลลัพธ์จึงใกล้เคียงกับจุดตั้งต้นที่มีประโยชน์ มากกว่าจะเป็นการสร้างกลับอย่างสมบูรณ์ และคำถามว่านั่นเพียงพอจะก่อให้เกิดผลสะสมหรือไม่ ก็ยังคงเป็นคำถามเชิงทดลอง

คูเมืองใหม่อยู่ที่องค์กร มากกว่าเทคโนโลยี

  • ผู้ชนะในอีก 10 ปีข้างหน้าอาจไม่ใช่บริษัทที่มีโมเดลดีที่สุดหรือมีโครงสร้างพื้นฐานเอเจนต์ดีที่สุด แต่เป็นบริษัทที่ยังสร้างผลงานต่อคนได้มากขึ้น พร้อมรักษาการจัดแนวกับชุดการตัดสินใจที่แคบลงไว้ได้ แม้จะเติบโตเป็น 50, 200 หรือ 2,000 คน
  • บริษัทแบบนี้คือองค์กรที่รู้มาตั้งแต่ก่อนเอเจนต์จะมาถึงแล้วว่าโจทย์ที่ยากที่สุดคือ ความสอดคล้อง
  • นี่เป็นปัญหาเรื่องวัฒนธรรมและการจัดการ และก็เป็นเช่นนั้นมาโดยตลอด
  • เครื่องมือในยุคก่อนอย่าง IDE, version control, CI, microservices และ DevOps เคยสัญญาว่าจะใช้เครื่องมือที่ดีกว่าเพื่อแก้ปัญหาการประสานงาน แต่ในความเป็นจริง พวกมันทำหน้าที่ขยายความสอดคล้องระดับองค์กรที่มีอยู่แล้ว
  • ทีมขนาดเล็กได้ความสอดคล้องแทบจะฟรีอยู่แล้ว ดังนั้นผลของการขยายจึงมักออกมาในทางบวก และนี่ก็เป็นเหตุผลว่าทำไมเสียงสนับสนุนเอเจนต์อย่างมากจึงมักมาจากทีมเล็ก เพราะในบริบทของพวกเขา มันถูกต้องเป็นส่วนใหญ่
  • เมื่อเกินขนาดหนึ่งไปแล้ว ความสอดคล้องต้องถูกสร้างและบำรุงรักษา และผลของการขยายก็จะคมในทั้งสองทิศทาง
  • องค์กรที่ดีจะยิ่งดีขึ้น ขณะที่องค์กรที่แย่จะพังเร็วขึ้น
  • เอเจนต์เป็นตัวขยายที่ทรงพลังกว่าเครื่องมือยุคก่อนมาก และถูกประเมินค่าสูงเกินไปในฐานะเครื่องมือให้แต่ละคนเขียนโค้ดได้เร็วขึ้น แต่กลับถูกประเมินค่าต่ำเกินไปในฐานะเครื่องมือที่ทำให้องค์กรทำให้สิ่งที่ตนรู้ออกมาอยู่ภายนอกได้

เอเจนต์ในฐานะส่วนขยายของวัฒนธรรมบริษัท

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

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

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

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

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

    • คุณกำลังพูดถึงผู้เขียนบางคนหรือคนรู้จักบางคนอยู่หรือเปล่า? ถ้าเป็นการเหมารวมถึงกลุ่มคนออนไลน์ทั้งหมด คุณอาจกำลังตกอยู่ใน ความผิดพลาดจากการยกคุณลักษณะของกลุ่มมาสรุปเป็นคุณลักษณะของแต่ละคน
      ไม่ว่าอย่างไร ทั้งสองอย่างก็อาจจริงพร้อมกันได้: การเขียนโค้ดไม่ใช่คอขวดจนสามารถพัฒนาฟีเจอร์ได้เร็วกว่าอัตราที่ปล่อยใช้งานได้ และการถูกรบกวนเวลาทำงานที่ต้องใช้สมาธิลึก ๆ ก็ยังน่าหงุดหงิดและทำให้เสียจังหวะ
      https://en.wikipedia.org/wiki/Group_attribution_error
    • นี่คือ การตั้งให้เลือกแค่สองทางแบบผิด ๆ การพัฒนาซอฟต์แวร์เป็นเรื่องของการทำให้ทุกคนตั้งแต่ลูกค้าจนถึงคนเขียนโค้ด รวมถึงทุกคนระหว่างทาง เข้าใจตรงกันมาโดยตลอด และยิ่งมีคนคั่นกลางน้อยยิ่งดี
      การประชุมที่ช่วยให้ลูกค้ากับคนเขียนโค้ดซิงก์กันมากขึ้นนั้นหาได้ยากและมีค่า ในองค์กรใหญ่ การประชุมเชิงพิธีการมักเพิ่มขึ้นด้วยเหตุผลที่ผิด คนพยายามสอดตัวเองเข้าไประหว่างลูกค้ากับคนเขียนโค้ดเพื่อแสดงว่าตัวเองมีความสำคัญ
      ส่วนตัวผมชอบประชุมกับลูกค้า ผู้ใช้ปลายทาง นักออกแบบ UX และผู้มีส่วนได้ส่วนเสียตัวจริง แต่เกลียดการประชุมกับพวกคนยุ่งเชิงการเมืองในบริษัทที่กินแบนด์วิดท์ไปเพื่อแย่งอิทธิพลในองค์กร ผมไม่ต้องการผู้จัดการชั้นกลางอีกคนมาคั่นระหว่างผมกับผู้ใช้ของผม
    • ทำไมถึงเรียกว่าหน้าซื่อใจคด? ถ้าในโลกเดิม กระบวนการที่สำคัญมากคือการเขียนโค้ดจริง ๆ ใช้เวลามาก และได้ประโยชน์มหาศาลจากการไม่ถูกรบกวน การถูกตัดจังหวะด้วยพิธีกรรมสารพัดที่มีคุณค่าแค่จำกัดเพื่อทำรายงานความคืบหน้าให้ผู้บริหาร ก็ย่อมรู้สึกว่าเป็นการเสียเวลา
      กลับกัน ในโลกใหม่ที่การเขียนโค้ดเร็วขึ้นมาก และส่วนที่ยากกลายเป็นการทำความเข้าใจ ข้อกำหนดทางธุรกิจและทางเทคนิค ที่ต้องบรรลุ คนคนเดิมก็อาจให้ความสำคัญกับพิธีกรรมเหล่านั้นมากขึ้น และยอมรับการถูกรบกวนได้ในขณะที่ AI agent กำลังเขียนโค้ด
      การเปลี่ยนความคิดเมื่อข้อเท็จจริงของสถานการณ์เปลี่ยนไป ไม่ใช่ความหน้าซื่อใจคด
    • พิธีกรรมกับ ticket ไม่ได้มีประสิทธิภาพเป็นพิเศษต่อ การทำงานร่วมกัน จริง ๆ หน้าที่หลักคือทำให้งานอยู่ในรูปแบบที่ผู้บริหารอ่านง่ายและควบคุมได้
      ถ้าคุณจะทำโปรเจกต์สร้างสรรค์กับใครสักคนนอกบริษัท มีหลายเหตุผลที่ Scrum ritual หรือ Jira จะไม่ใช่สิ่งแรกที่คุณนึกถึง การให้คุณค่ากับการร่วมมือกันแต่ยังวิจารณ์สิ่งเหล่านี้ ก็สอดคล้องกันดีอยู่แล้ว
    • นี่คือ การปฏิเสธความจริงกับศักดิ์ศรีล้วน ๆ ผมทำงานสัญญาจ้างมานานแบบไม่ได้ตั้งใจ และทุกครั้งที่เข้าทีมใหม่ก็เห็นปฏิกิริยาเดิม ๆ
      ทีมจะบ่นว่างานล้นจนทำอะไรไม่ทัน แล้วผู้จัดการก็ส่งผมเข้าไป แต่พอผมมาถึง จู่ ๆ ก็ไม่มีใครอยากส่งงานต่อให้เลย ตอนนี้ผมก็อยู่กลางสถานการณ์แบบนั้นพอดี
      ทีมบอกว่า “ยุ่งจนจม” แต่ก็ยังมีแรงพอจะยืนกรานว่างานแทบทุกอย่างที่ผมช่วยได้ พวกเขาทำเองดีที่สุดและไม่ต้องการความช่วยเหลือ ผมก็ไม่เป็นไร นั่งรับเงินไปได้ แต่กลิ่นมันเหมือนเดิม
      A: พวกเขาไม่อยากยอมรับว่าตัวเองแทนที่ได้ และงานไม่ได้พิเศษขนาดนั้น B: พวกเขาไม่อยากยอมรับว่าคอขวดไม่ใช่กระบวนการหรือปริมาณงาน แต่คือตัวพวกเขาเอง

  • ดูเหมือนว่าวิศวกรรุ่นเก๋าจะรู้กันมานานแล้วว่าต้นเหตุแท้จริงของปัญหาเรื่องความเร็วอยู่ที่ องค์กร มากกว่าเทคโนโลยีเสมอ
    การที่ธุรกิจไม่สามารถกำหนด roadmap ที่มีประสิทธิผลและมีจุดโฟกัสได้ เป็นปัญหาเรื้อรังของ software engineering มานาน ธุรกิจกระโดดไปหาเรื่องใหม่ที่ดูวิบวับถัดไปตลอดทั้งที่ ROI แทบไม่มี และยังไม่ยอมจัดการ technical debt เชิงระบบ ซึ่งทำลายหลายบริษัทที่ผมเคยทำงานด้วยในระยะยาว

    • อาจจริงสำหรับวิศวกรรุ่นเก๋า แต่สำหรับวิศวกรจูเนียร์ก่อนยุค AI ความเร็วเป็นปัญหา ทางเทคนิค มาโดยตลอด
      ผมรู้จักวิศวกรจูเนียร์ที่ใช้ C++ มาทั้งปีแล้วยังไม่เข้าใจ std::unique_ptr และคนแบบนี้ก็มักจะช้าที่สุดในทีมเสมอ
      เมื่อก่อนตอนต้องเขียนประเมินผลงานให้วิศวกรจูเนียร์ ผลงานถูกขับเคลื่อนด้วยความเร็วอย่างชัดเจน และวัดแบบคร่าว ๆ จากจำนวนบรรทัดโค้ดที่ไม่มีบั๊กซึ่งเขียนได้ในช่วงเวลาหนึ่ง จูเนียร์ที่ดีจะรับฟีเจอร์ที่นิยามชัดเจนมาแล้วเขียนโค้ดดี ๆ ได้เร็ว ส่วนคนที่ไม่ดีก็จะทำงานเดียวกันช้ากว่า หรือเขียนเร็วแต่มีบั๊กเยอะ จนสร้างงาน debug และเขียนใหม่เพิ่มขึ้นมาก
    • เห็นด้วยว่าปัญหาคือการนิยาม roadmap ที่มีประสิทธิผลและโฟกัสทางธุรกิจ และเห็นด้วยด้วยว่านักพัฒนาส่วนใหญ่จะตระหนักเรื่องนี้เมื่อเวลาผ่านไปและมีประสบการณ์มากขึ้น
      ถ้าเข้าใจ เหตุผลทางธุรกิจ ขอบเขต input และผลลัพธ์ที่ต้องการอย่างชัดเจน data model, system design และโค้ดก็มักจะตามมาแทบจะเอง หรืออย่างน้อยก็ชัดเจนขึ้นมาก
    • “องค์กรใดก็ตามที่ออกแบบระบบในความหมายกว้าง จะเลี่ยงไม่ได้ที่จะสร้างแบบออกแบบที่เป็นสำเนาของ โครงสร้างการสื่อสาร ขององค์กรนั้น”
      — Melvin E. Conway, 1967
    • ตอนนี้ technical debt เชิงระบบ สามารถรับมือในวงกว้างด้วย LLM ได้แล้ว โมเดลต่อจากนี้จะดีพอที่จะทำต่อเนื่องได้ และถ้าใครไม่เชื่อ ผมอยากให้ลองอธิบายว่าทำไมถึงไม่
      ก่อนอื่นคงต้องถามตัวเองก่อนว่าเข้าใจ scaling law แบบ Chinchilla และเข้าใจพื้นฐานของ reinforcement learning ที่มีการตรวจสอบอย่างไรบ้าง
      ผมเห็นด้วยเต็มที่ว่าข้อจำกัดเชิงรากฐานอยู่ที่ว่าธุรกิจสามารถอธิบายตัวเองและกลยุทธ์ของตัวเองได้อย่างสม่ำเสมอหรือไม่
      แต่ข้อได้เปรียบตอนนี้คือเราสร้าง prototype ได้แทบฟรี สมัยก่อนต้องระวังอย่างยิ่งกับการลงทุนแรงงานวิศวกร แต่ตอนนี้เราลองอะไรได้มากขึ้นมากภายใต้ข้อจำกัดด้านเวลาเท่าเดิม
    • ถ้าเป็นวิศวกรที่มีความสามารถ ก็ควรเข้าใจว่างานวิศวกรรมอยู่ฝั่ง สายการประกอบ ของการพัฒนาผลิตภัณฑ์
      ความท้าทายที่แท้จริงมาตลอดคือจะปล่อยฟีเจอร์กับ bug fix อะไร เมื่อไร และจะพัฒนาและบริหารผลิตภัณฑ์โดยรวมอย่างไร ซึ่งกลยุทธ์ส่วนใหญ่นี้พึ่งพา feedback loop ที่ AI ยังทำให้เร็วขึ้นไม่ได้
      ขณะเดียวกันก็รู้สึกว่าผู้นำฝั่งธุรกิจจำนวนมากใช้ความเร็วของวิศวกรเป็นแพะรับบาป แทนที่จะรับผิดชอบต่อการตัดสินใจแย่ ๆ ของฝั่งตัวเอง

  • ปกติคอขวดก็คือโค้ดจริง แต่ไม่ใช่ การเขียนโค้ด เป็นตัวโค้ดต่างหาก ตลอดอาชีพผมมีความล่าช้าจากแอปช้า ๆ นับไม่ถ้วน
    ต้องใช้ editor ที่อิง Eclipse ซึ่งช้าและค้างหรือ crash เป็นระยะ งาน build ใช้เวลา 15–20 นาที และยังเจอเว็บแอปที่ใช้เวลานานชั่วกัปชั่วกัลป์กับงานที่ควรจบในไม่เกิน 50ms อยู่บ่อย ๆ
    รายการพวกนี้ยาวไม่รู้จบ ทุกความล่าช้าคือสิ่งรบกวนที่ทำลายสมาธิผมเป็นชิ้น ๆ ทุกวันนี้ผมอยู่สายบริหาร ดูแลคนหลายสิบคนและสิ่งรบกวนเชิงธุรการ แต่ก็ยังเขียนโค้ดในบริษัทอยู่
    ถ้าซอฟต์แวร์ช้า มันจะกลายเป็นสิ่งสำคัญลำดับต่ำสุดของผม ผมไม่สนว่ามันจะกระทบใคร ถ้ามันสำคัญจริง เราคงไม่ถูกจับเป็นตัวประกันโดยกากน้ำเชื่อมซอฟต์แวร์เชื่องช้านี่ที่ฉุดทุกคนลง

    • editor อะไร แล้วทำไมต้อง Eclipse?

  • โค้ดคือหนี้
    มองโค้ดเป็นสินทรัพย์ได้ง่าย แต่โดยพื้นฐานแล้วมันคือหนี้ คอขวดบางส่วนในการเพิ่มโค้ดใหม่มีไว้เพื่อให้มั่นใจว่าผลลัพธ์ที่ได้มากกว่าหนี้ที่เพิ่มขึ้น การมี agent ที่สร้างโค้ดได้มากขึ้นเร็วขึ้น ก็คือการสร้างหนี้ได้มากขึ้นเร็วขึ้น
    ความตื่นเต้นและความกังขาส่วนใหญ่ต่อ coding agent คือคำถามว่าผลผลิตระยะสั้นที่เพิ่มขึ้นทันที เช่น ฟีเจอร์ใหม่ ผลิตภัณฑ์ใหม่ รายได้ใหม่ จะชดเชยหนี้ระยะยาวที่เพิ่มขึ้นได้หรือไม่ คำตอบคงต้องรออีก 1–3 ปี และคงแตกต่างกันไปตามสาขา
    ถ้ามองจากมุมนี้ ความพยายามจะใส่คอขวดแบบนี้เข้าไปใน workflow แบบ agent โดยตรงก็พอฟังขึ้น การให้ coding agent มีบริบทเพิ่มขึ้นที่เน้นวิสัยทัศน์ของโปรเจกต์อย่างสม่ำเสมอ และช่วยคัดค้านฟีเจอร์ใหม่หรือกระบวนการที่ไร้ข้อจำกัด มีคุณค่าอยู่
    นี่คือสิ่งที่บทความพยายามจะสื่อหรือเปล่า? คือความพยายามให้ agent บางตัวรับบท product management แล้วสังเคราะห์ทุกอย่างที่ทำได้ให้เป็นวิสัยทัศน์ผลิตภัณฑ์ที่เกาะกันเป็นเนื้อเดียว และย้ำวิสัยทัศน์นั้นกับ coding agent อย่างเข้มงวดที่สุด?
    agent แบบนี้ควรตรวจข้อเสนอใหม่และ pull request ใหม่ในมุมของ “ความสอดคล้องกับภาพรวม” หรือไม่? จะเรียกสิ่งนี้ว่าบริบท วิสัยทัศน์ หรือชื่ออื่นก็ได้
    agent แบบนี้อาจเก่งมากในการสังเคราะห์บริบทและเสนอ roadmap ที่ดูสอดคล้องกับคุณค่าและวิสัยทัศน์ของทีมในเชิงภาษา แต่ผมยังสงสัยว่ามันจะมีวิจารณญาณแบบผู้จัดการหรือทีมที่ดีได้ไหม การอนุมัติ roadmap บางอย่างได้อย่างรวดเร็วและน่าเชื่อ อาจให้โทษมากกว่าประโยชน์

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

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

  • “เป้าหมายคือการทดสอบอัลกอริทึมการสร้างแบบมีโครงสร้างของเราและตัวเทียบเคียงโอเพนซอร์สของมัน โดยแทนที่คำถามแบบไร้เดียงสาว่า ‘มันยอมรับสตริงนี้หรือไม่?’ ด้วยคำถามที่ใกล้โลกจริงกว่าว่า ‘มันสร้าง การกระจายของโทเคน ที่ถูกต้องหรือไม่?’ … เมื่อเดือนที่แล้วผมอธิบายวิธีการให้ Codex ฟัง 30 นาที ไม่กี่ชั่วโมงต่อมาก็ได้เวอร์ชันแรกที่ใช้งานได้ แค่นั้นเอง”
    นี่พิสูจน์ว่าคอขวดจริง ๆ คือโค้ด เพียงแต่ตอนนี้ AI เป็นคนเขียนแทน
    คนที่คิดว่า “คอขวดไม่ใช่โค้ด” นั้น ได้ถกเรื่องเป้าหมายและจัดระเบียบมันในหัวไว้อย่างสอดคล้องแล้ว
    การบอกว่าโค้ดคือคอขวด ไม่จำเป็นต้องหมายถึง “ผมอยากได้ฟีเจอร์นี้ แต่ใช้เวลาหลายเดือนกว่าจะโค้ดเสร็จ” อาจหมายถึง “ผมอยากได้ฟีเจอร์นี้มาสองปีแล้ว แต่ผัดไว้เพราะแรงเสียดทานจากการต้องนั่งแปลงมันเป็นโค้ดและใช้เวลา 5–10 วัน” ก็ได้
    ถ้าโค้ดไม่ใช่คอขวด ก็น่าจะนั่งเขียนเองไปแล้ว แต่เจ้าตัวไม่อยากลงแรงและเวลาเขียนเอง และก็รู้ว่ามันไม่ได้ใช้เวลาน้อยเท่า LLM
    แม้ในกรณีที่สเปกสุดท้ายยังไม่ชัด การลองเขียนโค้ด ตรวจสอบ ทิ้ง แล้วลองแบบใหม่ ก็เร็วขึ้นเมื่อใช้ LLM เพราะส่วนที่เป็น “โค้ด” เร็วขึ้นนั่นเอง
    พูดอีกอย่างคือ คอขวดก็คือโค้ด
    ตัวบทความนี้เองก็ดูเหมือน ข้อความที่ AI สร้าง พร้อมคำสั่งให้หลีกเลี่ยงสำนวนซ้ำซาก จึงยังอ่านได้น่าเบื่ออยู่ดี

  • ในบทความบอกว่า “Jevons Paradox: เมื่อบางสิ่งถูกลง เราไม่ได้ใช้น้อยลง แต่กลับใช้มากขึ้น” ซึ่งเป็นการอธิบายที่ทำให้ Jevons paradox เพี้ยนไป
    ประโยคนั้นไม่ใช่ความย้อนแย้งอะไรเลย แต่เป็นผลที่ธรรมดามาก เมื่อของถูกลง การใช้งานเพิ่มขึ้นก็เป็นเรื่องปกติ
    สิ่งที่ Jevons paradox อธิบายจริง ๆ คือสถานการณ์ที่การใช้ทรัพยากรบางอย่างมีประสิทธิภาพมากขึ้นจนปริมาณที่ต้องใช้ต่อหนึ่งงานลดลง แต่การใช้ทรัพยากรนั้นโดยรวมกลับเพิ่มขึ้น

    • แล้วทำไมถึงเรียกว่าย้อนแย้ง? เหตุผลง่าย ๆ อย่างหนึ่งคือ ตอนนี้ใช้ทรัพยากรน้อยลงจึงถูกลง และทำให้งานแบบเดิมถูกทำมากขึ้นกว่าเดิม
    • แน่นอนว่าเมื่อบางอย่างถูกลง การใช้งานก็ย่อมเพิ่มขึ้น
      แต่เมื่อการใช้ทรัพยากรมีประสิทธิภาพมากขึ้น ราคาของ “การใช้งาน” นั้นก็ย่อมถูกลงด้วยไม่ใช่หรือ?
      เพราะฉะนั้นเมื่อประสิทธิภาพเพิ่ม การใช้งานก็เพิ่มขึ้นเป็นเรื่องธรรมดา ที่เรียกว่าย้อนแย้งก็เพราะบางคนคิดอย่างไร้เดียงสาว่าการเพิ่มประสิทธิภาพเป็นวิธีที่ดีในการลดการบริโภค
      เกือบทุกอย่างที่ถูกเรียกว่า “paradox” ก็ชัดเจนแบบนี้แหละ
    • ความย้อนแย้งน่าจะอยู่ที่เรากลับจ่ายเงินให้มันมากขึ้นหรือเปล่า?
      หรืออาจเป็นว่าเมื่อกระบวนการใดมีประสิทธิภาพขึ้น คือใช้เวลาน้อยลง เรากลับใช้เวลากับกระบวนการนั้นมากขึ้น

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

    • ในธุรกิจ แอปพลิเคชันซอฟต์แวร์เป็นเครื่องมือที่ช่วย “งานนั้น” ซึ่งเป็นตัวทำเงินจริง ๆ คนในโลกซอฟต์แวร์อย่างพวกเรามักคิดว่างานนั้นคือซอฟต์แวร์และฟีเจอร์ซอฟต์แวร์ แต่ข้างนอกนั้นมักมี “งาน” อื่นอยู่
      คอขวดในการทำให้แอปซอฟต์แวร์ที่ธุรกิจนอกสายซอฟต์แวร์ใช้ดีขึ้น คือการทำให้มั่นใจว่าซอฟต์แวร์ได้ทำงานด้านซอฟต์แวร์ทั้งหมดที่เป็นประโยชน์ต่อธุรกิจจริง ๆ
      ไม่ว่าจะเป็นการประหยัดเวลา ทำให้คนมีประสิทธิผลขึ้น ลดความผิดพลาดของมนุษย์ ทำให้ธุรกิจมีประสิทธิภาพขึ้น และเพิ่มกำไร
      ทั้งหมดนี้คาดการณ์และวัดเชิงปริมาณได้ค่อนข้างยาก คุณอาจเริ่มจากไอเดียที่น่าจะเป็นประโยชน์ต่อธุรกิจ แล้วออกแบบ สร้าง prototype และทดสอบ สุดท้ายสร้างหรือปรับปรุงแอปซอฟต์แวร์ แล้วพยายามวัดว่ามันทำให้ธุรกิจดีขึ้นแค่ไหน
      ตลอดกระบวนการนี้ การทำให้แน่ใจว่าซอฟต์แวร์กำลังจัดการปัญหาที่ถูกต้องด้วยวิธีที่ถูกต้อง และท้ายที่สุดทำให้ธุรกิจดีขึ้น เป็นปัญหาที่ยาก ไม่ว่าการสร้างซอฟต์แวร์จะเร็วและง่ายขึ้นแค่ไหนก็ตาม
      ถึงอย่างนั้น ความเร็วก็ช่วยได้มากจริง ๆ คุณสามารถสร้าง prototype ทดสอบ และทำให้ feedback loop ดีขึ้นได้
    • ไม่ใช่แค่ “ฟีเจอร์ที่มากขึ้น?” แต่คือ การเปลี่ยนแปลงโค้ด ไม่ว่าจะเป็นฟีเจอร์ การแก้บั๊ก การบำรุงรักษาทั่วไป หรือการรีแฟกเตอร์เพื่อให้ทดสอบได้ดีขึ้น
      เมื่อใช้ผู้ช่วยเขียนโค้ด AI สิ่งที่เมื่อก่อนถือเป็นงานของนักพัฒนาจูเนียร์ ตอนนี้ทำได้ด้วย prompt สั้น ๆ และ agent ที่รันอยู่เบื้องหลัง
      งานของนักพัฒนาจูเนียร์แบบนี้ ตอนนี้ผู้ช่วยเขียนโค้ดส่งมอบได้แทบไม่ต้องมีคนเข้าไปยุ่ง backlog ถูกเคลียร์เร็วกว่าอัตราที่มีรายการใหม่ถูกเพิ่มเข้ามา และเมื่อ throughput ไม่ใช่ปัญหาอีกต่อไป รายการใหม่ก็ยิ่งถูกเพิ่มเข้ามามากขึ้น
      ตอนนี้โจทย์คือการตามให้ทันปริมาณการเปลี่ยนแปลง เราเห็นสิ่งนี้โดยตรงในองค์กรของเรา
      การที่คุณนึกถึงคอขวดอื่นได้ ไม่ได้แปลว่าการสร้างโค้ดไม่เคยเป็นคอขวด หรือไม่ใช่คอขวดในตอนนี้ แนวคิดเรื่อง backlog เองก็ชี้ชัดว่ามันคือคอขวด

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

  • ตกลงคุณทำโปรเจกต์แบบไหนกันแน่ ที่ส่วนยากมีแค่การทำความเข้าใจฟีเจอร์ที่ผู้บริหารต้องการ แล้วที่เหลือก็แค่ “พิมพ์ออกมา” หรือเดี๋ยวนี้ก็โยนให้ LLM ทำ?
    ถ้านั่นคืองานที่ทำ ก็ไม่แปลกเลยที่คนจำนวนมากใน HN จะคิดว่า LLM มาแทนตัวเองได้

    • การถกเรื่องนี้ดูเหมือนตั้งสมมติฐานเสมอว่าทุกคนเขียนโค้ดแบบเดียวกันและเพื่อฟังก์ชันแบบเดียวกัน แล้วก็พยายามยัดโลกที่เหลือทั้งหมดให้เข้ากับกรอบนั้น
      แล้วเราก็วนกลับมาคุยเรื่องเดิม ๆ แสดงความกังวล คุยกันคนละเรื่อง และรออีก 30 นาทีเพื่อหาโอกาสคอมเมนต์รอบถัดไป
    • ยิ่งอาวุโสมากขึ้น โค้ดก็ดู ทดแทนได้ มากขึ้น และกระบวนการก็ดูสำคัญและยากขึ้น
    • ประมาณ 80% ของแอป CRUD ก็เป็นแบบนี้ มีปัญหาน่าสนใจบ้างเป็นครั้งคราว แต่ไม่ใช่อะไรระดับ 20% บนสุด
      ส่วนใหญ่คุณภาพโค้ดแย่มากเหมือนกองขยะร้อน ๆ เพราะวงจร offshore กับ layoff
    • สะท้อนกลับเลย คุณต้องมีประสบการณ์โปรเจกต์ที่จำกัดแค่ไหน ถึงคิดว่าในพื้นที่การพัฒนาซอฟต์แวร์ไม่มีสเปกตรัมกว้างใหญ่ระหว่าง ความยากของโค้ดกับปัญหาเชิงองค์กร?