วิธีที่ฉันใช้ LLM เหมือน Staff Engineer

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

การเขียนโค้ดโปรดักชัน

• ใช้ฟีเจอร์ Copilot autocomplete ระหว่างเขียนโค้ดอยู่เสมอ
  • ข้อเสนอ autocomplete ส่วนใหญ่เป็นงาน boilerplate ซ้ำ ๆ เช่น การใส่ฟังก์ชันอาร์กิวเมนต์หรือ type
  • ในโดเมนงานหลักของตนเอง (เช่น Ruby on Rails) ผู้เขียนเห็นว่าโค้ดที่ตนเขียนเองยังดีกว่า
• ใน พื้นที่ที่มีความเชี่ยวชาญด้านงานต่ำกว่า จะยอมรับ logic ที่ Copilot เสนอมากขึ้น
  • เช่น เวลาต้องแก้ไขเชิงยุทธวิธีเล็ก ๆ ในภาษาอย่าง Golang หรือ C
  • อาศัย Copilot เพื่อทำความเข้าใจ syntax และสไตล์โค้ดแบบ idiomatic ของภาษาที่ไม่คุ้นเคยได้อย่างรวดเร็ว
  • เพราะขาดความเชี่ยวชาญเชิงลึก จึงมักให้ผู้เชี่ยวชาญในด้านนั้นรีวิวเสมอ
  • วิธีนี้ทำให้ทำงานได้ในระดับ “เด็กฝึกงานที่ฉลาด” ได้พอสมควร แต่กระบวนการตรวจสอบยังเป็นสิ่งจำเป็น

การเขียนโค้ดใช้ครั้งเดียว

• เวลาเขียน โค้ดใช้ครั้งเดียว ที่จะไม่ deploy ขึ้นโปรดักชัน จะใช้ LLM อย่างเชิงรุกมากกว่าเดิม
  • หากเป็นโค้ดที่รันครั้งเดียวเพื่อการวิจัยแล้วทิ้ง ก็แทบไม่ต้องคำนึงถึงการบำรุงรักษา
  • เช่น ดึงข้อมูลสาธารณะจาก API มาจัดหมวดหมู่ แล้วใช้ regex ตรวจสอบแบบง่าย ๆ
• ในกรณีนี้ ผู้เขียนบอกว่าสามารถทำงานได้เร็วขึ้นราว 2–4 เท่าเมื่อใช้ LLM
• LLM มีประสิทธิภาพมากสำหรับการเขียนโค้ดที่ใช้ครั้งเดียวแล้วทิ้ง

การเรียนรู้พื้นที่ใหม่

• ผู้เขียนยกให้เป็น กรณีใช้งานที่คุ้มค่าที่สุด โดยใช้ LLM เสมือนครูสอนพิเศษแบบ on-demand
  • เช่น ตอนเริ่มเรียน Unity ครั้งแรก ก็ถามโมเดลอย่าง ChatGPT-4o ต่อเนื่องไปเรื่อย ๆ
  • ไม่ได้ถามแค่ “X ทำงานอย่างไร?” แต่ยังถามต่อได้ว่า “X เกี่ยวข้องกับ Y อย่างไร?”
  • ยังใช้เพื่อตรวจสอบความเข้าใจ เช่น “สิ่งที่ฉันเข้าใจถูกต้องไหม?”
• ระหว่างเรียนรู้ ผู้เขียนยังใช้วิธีคัดลอกโน้ตที่เขียนไว้ไปวางตรง ๆ เพื่อให้ช่วยตรวจทาน
• ความกังวลเรื่อง hallucination
  • ผู้เขียนรู้สึกว่านับตั้งแต่ GPT-3.5 เป็นต้นมา ปัญหา hallucination ไม่ได้เด่นชัดมากนัก
  • เพราะหลายโดเมนที่เรียนรู้ในชีวิตประจำวันเป็นสาขาที่มีการวางรากฐานไว้ดีอยู่แล้ว จึงมีความเสี่ยงคำตอบผิดต่ำ
  • จนถึงตอนนี้ยังไม่เคยเรียนรู้ข้อมูลผิดจาก LLM

การแก้บั๊กด่านสุดท้าย

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

การแก้คำผิดและข้อผิดพลาดเชิงตรรกะ

• ผู้เขียนไม่ได้ให้ LLM เขียนแทนทั้งหมด สำหรับงานเขียนอย่าง ADRs, technical summary, เอกสารภายใน ฯลฯ
  • ผู้เขียนคิดว่าตนเองเขียนได้ชัดเจนกว่า และไม่ได้ชอบสไตล์การเขียนเฉพาะตัวของ LLM
• บางครั้งจะป้อนร่างแรกให้ LLM เพื่อรับ feedback สำหรับ ตรวจไวยากรณ์หรือแก้คำผิด
  • LLM จับข้อผิดพลาดด้านการสะกดได้ดี และบางครั้งก็เสนอแง่มุมที่น่าสนใจ
• แทนที่จะให้เสนอการแก้ไขซ้ำไปซ้ำมา ผู้เขียนมักขอฟีดแบ็กเพียงครั้งเดียวในระดับ “ภาพรวม”

สรุป

• ขอบเขตการใช้ LLM
  • “smart autocomplete” ด้วย Copilot
  • การแก้ไขเชิงยุทธวิธีระยะสั้นในพื้นที่ที่ไม่คุ้นเคย (ต้องมีผู้เชี่ยวชาญรีวิว)
  • การเขียนโค้ดเพื่อการวิจัยที่ใช้ครั้งเดียวแล้วทิ้ง
  • การถามอย่างต่อเนื่องเมื่อเรียนรู้เทคโนโลยีหรือโดเมนใหม่
  • การลองใช้เป็นทางเลือกสุดท้ายเพื่อแก้บั๊กเมื่อไปต่อไม่ไหว
  • การตรวจคำสะกด/คำผิดและข้อผิดพลาดเชิงตรรกะของร่างเอกสารภาษาอังกฤษในภาพรวม
• สิ่งที่ยังไม่ใช้ LLM ทำ
  • ให้ช่วยเขียน Pull Request ทั้งฉบับในพื้นที่ที่ตนเชี่ยวชาญดีอยู่แล้ว
  • เขียนเอกสารเทคนิคทั้งฉบับอย่าง ADR
  • ทำความเข้าใจสถาปัตยกรรมที่ซับซ้อนภายใน codebase ขนาดใหญ่

[fortune]

นี่คือ.. สตาฟฟ์เอนจิเนียร์..?

[smallzoo]

เป็นสตาฟฟ์เอนจิเนียร์ของ GitHub จริง ๆ นั่นแหละ

[vwjdalsgkv]

ผมก็ยังไม่คิดว่านี่จะดูถึงระดับ Staff Engineer นะครับ... รู้สึกว่าเรียกระดับ Assistant น่าจะเหมาะกว่า

[flaps3]

หัวข้อมีการแปลผิดนะครับ/ค่ะ ไม่ใช่ "เหมือน staff engineer" แต่เป็น "ในฐานะ staff engineer"

[fortune]

👍!!

[GN⁺]

ความคิดเห็นบน Hacker News

• ในฐานะ "staff engineer" นั้น LLMs อ่อนมากทั้งในการเขียนโค้ดแบบเป็นสำนวนธรรมชาติและการสอน แถมยังทำให้ต้องเสียเวลากับการรีวิวโค้ดมากขึ้น การใช้ LLMs เขียนโค้ดมีความเสี่ยงที่จะทำให้เรียนรู้แนวปฏิบัติที่ไม่ดี และพึ่งพาปริมาณโค้ด, boilerplate และผลลัพธ์ที่ไม่แน่นอนมากเกินไป LLMs อาจมีประโยชน์สำหรับการระดมไอเดียหรือสำรวจข้อมูลที่ยังไม่น่าเชื่อถือ แต่การพึ่งมันในการสร้างโค้ดนั้นถือว่าบ้าบอมาก

• เวลาจะแก้บั๊ก มีวิธีใช้ Copilot โดยแนบทั้งไฟล์และวางข้อความ error เพื่อขอความช่วยเหลือ โมเดลแบบ "reasoning" ให้ผลลัพธ์ที่ดีกว่านี้มาก และถ้าใส่ทั้ง codebase พร้อมอธิบายข้อความ error ลงไป ก็มักจะหาต้นตอของปัญหาเจอ

• LLMs มีประโยชน์กับโค้ด boilerplate หรือการเติมโค้ดอัตโนมัติ แต่มีข้อจำกัดในงานที่ซับซ้อน เพราะมันไม่เข้าใจ business logic อย่างไรก็ดี มันมีประโยชน์มากในการเขียนเอกสารภายในองค์กรได้อย่างรวดเร็ว

• ทำงานอยู่ที่ GitHub และเคยมีประสบการณ์มีส่วนร่วมกับ Copilot โดยตรง

• หากใช้ภาษาแบบ static type และ IDE ที่ดี ฟีเจอร์ "smart auto complete" อาจมีประโยชน์น้อยลง การเติมโค้ดอัตโนมัติของ Intellij ให้ความรู้สึกเหมือนอ่านใจได้ในแทบทุกกรณี

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

• วิธีใช้ AI ในการดูแลรักษาโปรเจกต์ Python มันช่วยแปลงวิธีการจากภาษาอื่นมาเป็น Python ได้

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

• หลังจากย้ายจาก VSCode ไปใช้ Cursor แล้ว โหมด agent กับ Sonnet น่าประทับใจมาก หากมีนักพัฒนาที่มีประสบการณ์คอยกำกับ ก็สามารถช่วยเพิ่มผลิตภาพได้อย่างมาก

• ใช้ LLMs ช่วยแก้คำสะกดผิดและข้อผิดพลาดเชิงตรรกะในเอกสาร และปรับ Graphite Reviewer ให้โฟกัสกับบั๊กและความผิดพลาดจริง AI ไม่ได้สมบูรณ์แบบ แต่มีประโยชน์ในฐานะเครื่องมือช่วยตรวจแก้โค้ด