8 ปีแห่งความโหยหา 3 เดือนแห่งการลงมือทำจริง - สูตรของไซด์โปรเจกต์ที่ AI เปลี่ยนไป

 (lalitm.com)
27 คะแนน โดย GN⁺ 24 일 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • สร้าง เครื่องมือพัฒนาคุณภาพสูงสำหรับ SQLite ที่ขาดแคลนมานานให้เสร็จได้ในเวลาอันสั้นด้วยความช่วยเหลือของ AI
  • อุปสรรคใหญ่ที่สุดคือการสร้าง parser เนื่องจาก ไม่มีข้อกำหนดไวยากรณ์อย่างเป็นทางการและมีโค้ดเบส C ที่ซับซ้อน
  • ใช้ AI coding agent อย่าง Claude Code เพื่อเร่งการพัฒนาในช่วงแรก แต่เพราะปัญหาโค้ดสปาเกตตีจึงตัดสินใจ เขียนใหม่บนพื้นฐาน Rust
  • AI แสดงประสิทธิภาพสูงในด้าน การสร้างโค้ด การรีแฟกเตอร์ การช่วยเรียนรู้ และการปรับปรุง UX แต่ก็มีผลข้างเคียงอย่าง การเลื่อนการตัดสินใจด้านการออกแบบ การขาดความต่อเนื่องของโค้ด และการเสพติดการพึ่งพา
  • โดยสรุป AI เป็นเพียง เครื่องมือที่ช่วยเพิ่มความเร็วในการลงมือทำ ขณะที่ การออกแบบและทิศทางของซอฟต์แวร์ยังต้องเป็นความรับผิดชอบของมนุษย์

บันทึก 3 เดือนของการสร้างเครื่องมือพัฒนา SQLite ด้วย AI

  • ต้องการ เครื่องมือพัฒนาคุณภาพสูงสำหรับ SQLite มานาน แต่เครื่องมือโอเพนซอร์สที่มีอยู่ยังขาดทั้งความน่าเชื่อถือ ความเร็ว และความยืดหยุ่น
    • ระหว่างดูแล PerfettoSQL มีความต้องการฟีเจอร์อย่าง formatter, linter และ editor extension แต่ไม่มีเครื่องมือที่เหมาะสม
    • แม้อยากสร้างเครื่องมือใหม่เป็นโปรเจกต์ส่วนตัว แต่เพราะความยากและภาระงานซ้ำ ๆ จึงเลื่อนมาเป็นเวลาหลายปี

ความยากของโปรเจกต์

  • SQLite ไม่มีข้อกำหนดไวยากรณ์อย่างเป็นทางการหรือ parser API ที่เสถียร
    • ภายในไม่ได้สร้าง parse tree จึงต้องดึงตรรกะของ parser ออกจากซอร์สโค้ดโดยตรง
    • ต้องแมปกฎไวยากรณ์มากกว่า 400 ข้อทีละข้อ และการเขียนเทสต์กับดีบักก็เป็นงานที่ซ้ำซากและเหนื่อยล้ามาก
  • โค้ดเบสภาษา C ของ SQLite ซับซ้อนและหนาแน่นมาก จึงทำความเข้าใจได้ยาก
    • แค่ทำความเข้าใจ virtual table API และตัว implementation ก็ใช้เวลาหลายวันเพราะโครงสร้างซับซ้อนมาก

กระบวนการพัฒนาร่วมกับ AI

  • ตั้งแต่ปลายปี 2025 เริ่มใช้งาน Claude Code และ AI coding agent อื่น ๆ อย่างจริงจัง
    • ช่วงแรกมอบหมายทั้งการออกแบบและการพัฒนาให้ AI เป็นส่วนใหญ่ โดยทำงานในแบบ “vibe-coding”
    • แม้ผลลัพธ์จะใช้งานได้ แต่ โค้ดเบสกลายเป็นสปาเกตตี จนซับซ้อนเกินกว่าจะดูแลรักษาได้
  • หลังจากนั้นจึง เขียนใหม่ทั้งหมดด้วย Rust เพื่อจัดโครงสร้างใหม่
    • ใช้ Rust แทน C เพื่อให้พัฒนาองค์ประกอบระดับบน เช่น validator และ language server ได้ง่ายขึ้น
    • จำกัด AI ให้เป็นเพียง “เครื่องมือเสริม autocomplete” และเป็นผู้ขับเคลื่อนการออกแบบ การรีวิว และการทดสอบด้วยตนเอง
    • สร้าง scaffolding สำหรับตรวจสอบผลลัพธ์จาก AI เช่น linting, validation และระบบทดสอบอัตโนมัติ

สิ่งที่ AI ทำให้เป็นไปได้

  • เอาชนะแรงเฉื่อย

    • AI ช่วย แยกงานออกเป็นปัญหาย่อยที่เป็นรูปธรรม ทำให้เริ่มต้นได้ง่ายขึ้น
    • จากเดิมที่คิดว่า “ต้องเข้าใจการ parsing ของ SQLite” เปลี่ยนเป็น “ตรวจสอบแนวทางที่ AI เสนอ” ทำให้ลงมือทำได้เร็วขึ้น

  • ความเร็วในการสร้างโค้ดและรีแฟกเตอร์

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

  • บทบาทผู้ช่วยการเรียนรู้

    • AI สามารถอธิบายแนวคิดใหม่แบบเรียลไทม์ เช่น อัลกอริทึมการจัดรูปแบบของ Wadler-Lindig
    • ช่วยให้เริ่มต้นได้เร็วในพื้นที่ที่ไม่คุ้นเคย เช่น Rust หรือ extension ของ VS Code
    • เมื่อหลุดจากบริบทของโปรเจกต์ ก็สามารถกู้บริบทกลับมาได้ทันทีด้วยคำถามอย่าง “อธิบายคอมโพเนนต์นี้ให้หน่อย”

  • การยกระดับความสมบูรณ์ของงาน

    • ลดต้นทุนการพัฒนาฟีเจอร์เสริมอย่าง editor extension, Python binding, WASM playground และไซต์เอกสาร
    • เมื่อภาระการ implement ลดลง จึงโฟกัสกับ การปรับปรุง UX ได้มากขึ้น เช่น ข้อความแสดงข้อผิดพลาดและการออกแบบ CLI

ผลข้างเคียงของการใช้ AI

  • การเสพติด

    • มีโครงสร้างรางวัลแบบสล็อตแมชชีนจากการวนซ้ำ “ลอง prompt อีกครั้ง”
    • ยิ่งเหนื่อย คุณภาพของ prompt ก็ยิ่งตก ทำให้ผลลัพธ์แย่ลงและเกิดวงจรเลวร้าย

  • การขาดความต่อเนื่องกับโค้ดเบส

    • ยิ่งมีโค้ดที่ AI สร้างมากขึ้น ก็ยิ่ง สูญเสียความรู้สึกต่อรายละเอียดของโครงสร้าง
    • เมื่อหลุดจากบริบท การสนทนากับ AI ก็ยาวขึ้นและไร้ประสิทธิภาพ
    • ทางแก้คือสร้างนิสัยอ่านโค้ดด้วยตัวเองทันทีหลัง生成 และตรวจดูว่า “มีส่วนไหนที่ถ้าเป็นเราจะเขียนต่างออกไป”

  • การเลื่อนและการผุกร่อนของการออกแบบ

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

  • การขาดมุมมองเรื่องเวลา

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

ความเป็นสัมพัทธ์ของการใช้ AI

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

บทสรุป

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

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

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

 
GN⁺ 24 일 전
ความคิดเห็นจาก Hacker News

  • รู้สึกสดใหม่ที่ได้เห็น มุมมองที่สมดุล ต่อ AI coding
    ถ้าเป็นนักพัฒนาที่จริงจัง ส่วนใหญ่คงเคยเจอประสบการณ์แบบนี้ — ตอนแรกตกใจกับความเก่งของ AI ที่เขียนโค้ดได้ดี แต่พอมาดูทีหลัง codebase ก็เละเป็น spaghetti code ไปแล้ว
    บางคนไม่แม้แต่จะทำ code review แล้วก็พูดว่า “ยุคการเขียนโค้ดด้วยมือจบแล้ว” ขณะที่อีกบางคนก็ฟันธงว่า “AI coding ใช้ไม่ได้”
    แต่ความจริงอยู่ตรงกลาง somewhere. AI สามารถเป็น ตัวเร่งผลิตภาพ ที่ทรงพลังได้ แต่ต้องผสานเข้ากับ workflow อย่างถูกต้องและยังต้องมีคนคอยมีส่วนร่วมต่อเนื่อง

    • ช่วง 3 เดือนที่ผ่านมา ฉันก็ใช้ Claude เป็นอินเทอร์เฟซหลักในการเขียนโค้ด
      ตอนแรกเป็นแค่ prototype แต่ไม่นานก็พัฒนาเป็นบริการจริง หลังจากนั้นต้องเหนื่อยกับการ refactor เพื่อล้างโค้ดไร้ประโยชน์ออกไป
      ถึงอย่างนั้น prototype ที่ทำได้รวดเร็วนั้นก็เป็นเหตุผลที่ทำให้วันนี้มีผลิตภัณฑ์นี้อยู่จริง Claude มีประโยชน์กับการจัดระเบียบโค้ดเหมือน เลื่อยยนต์
      ไม่นานมานี้ฉันเพิ่ม type checker ผ่าน pre-commit hook แล้วแก้ error 90 จุดได้ภายใน 2 ชั่วโมง
      AI coding น่าทึ่งก็จริง แต่ใน production code ก็ยังจำเป็นต้องมีการ review และการตัดสินใจจากมนุษย์
    • สิ่งที่ชอบเป็นพิเศษในบทความนี้คือ มุมมองที่สมดุล
      แต่กรณีนี้เป็น greenfield project ส่วนบุคคล เลยเอาไปใช้กับการพัฒนาแบบทีมทั่วไปได้ยากในทันที
      ถึงอย่างนั้น ถ้าทำ prototype โดยตั้งใจไว้ตั้งแต่แรกว่าจะ “ทิ้ง” ทีหลัง spaghetti code ก็ถือว่าโอเค
      ปัญหาคือผู้เขียนเข้าใจผิดว่ามันจะต่อยอดเป็นผลิตภัณฑ์จริงได้เลย
      แต่ก็มองว่าความล้มเหลวนั้นน่าจะทำให้ได้เรียนรู้การออกแบบที่ดีกว่าเดิม
    • จริง ๆ แล้วคิดว่าปฏิกิริยาแบบสุดโต่งสองฝั่งนี้คือ ทุกคนที่เพิ่งเจอ AI coding ครั้งแรกต้องผ่าน
      ตอนแรกทึ่ง ต่อมาผิดหวัง และสุดท้ายค่อยหาสมดุลเจอ
      มันดูเหมือน Kübler-Ross model ฉบับ AI
    • กลับกัน ฉันมองว่าการ หมกมุ่นกับคุณภาพโค้ด เป็นจุดบอดในยุค AI
      แน่นอนว่าคุณภาพสำคัญ แต่ตอนนี้ความสำคัญของคุณภาพโค้ดในตัวมันเองกำลังลดลง
      โค้ดที่ไม่ต้องบำรุงรักษามากอย่างแอปส่วนตัวมีมากขึ้น และความสามารถด้านการออกแบบของ AI ก็พัฒนาเร็วมาก
      สุดท้ายแล้ว “ความจริงของ AI coding” กำลังเปลี่ยนไปเรื่อย ๆ และกระแสนี้คงไม่หยุด
    • คิดว่าที่บทความแนวสมจริงแบบนี้หาได้ยากมีอยู่สองเหตุผล
      อย่างแรก นักพัฒนาส่วนใหญ่แค่เงียบ ๆ รับ ผลิตภาพที่เพิ่มขึ้น 2~50% โดยไม่ได้รู้สึกว่าต้องออกมาพูด
      อย่างที่สอง AI coding ของจริงนั้น น่าเบื่อและไม่ค่อยมีภาพให้โชว์
      สุดท้าย LLM ก็เป็นแค่ ‘เครื่องมือที่ช่วยให้ไม่ต้องท่อง boilerplate’ ส่วนแก่นของการเขียนโค้ดยังเหมือนเดิม

  • ฉันก็เจอปัญหาเดียวกันกับการสร้างเทสต์ด้วย AI
    พอมีเทสต์เยอะก็อุ่นใจ แต่ในความเป็นจริงมันรับมือ edge case ได้ไม่ครบ
    โดยเฉพาะตอน refactor legacy code ที่ไม่มีเทสต์ เทสต์ที่ AI สร้างขึ้นแค่ยืนยันว่าโค้ดทำงานได้ แต่ไม่ได้รับประกัน ความสม่ำเสมอของพฤติกรรม
    ปัญหานี้ยิ่งหนักในแอป React เลยกำลังคิดแนวทางผสาน BDD + การพัฒนาแบบอิงสเปก เข้ากับ AI

    • รู้สึกว่าการเขียนเทสต์ที่ดี ยากกว่าการเขียนโค้ดจริง 10 เท่า
      unit test ต้องอาศัยการออกแบบ mock อย่างสร้างสรรค์, integration test ต้องจัดการข้อมูลได้ดี, และ e2e test หัวใจสำคัญคือ ความเสถียรของ selector
      การตัดสินใจเชิงสร้างสรรค์แบบนี้ AI ยังตามไม่ทัน
    • อย่าหลงเชื่อตัวเลข coverage
      ต่อให้ coverage 97% ก็ยังมีรูโหว่เยอะใน logical input space
      ช่วงหลังฉันใช้ AI agent ทำ automation ให้กับเทคนิคคลาสสิกอย่าง equivalence partitioning แล้วนำไปใช้กับ 60 โมเดล
    • แนะนำแนวทางใช้ TLA+ เพื่อระบุสเปกการทำงานของระบบ แล้วเชื่อมโค้ดกับสเปกเข้าด้วยกัน
      หัวใจคือการแยก pure function ออกมาให้มากที่สุด เพื่อให้ทดสอบ mapping ระหว่าง input-output ได้ครบถ้วน

  • ในระยะยาว คิดว่าคุณค่าที่แท้จริงของ AI คือการเป็น เครื่องมือขยายความเข้าใจ
    เช่น ใช้วิเคราะห์กฎในโค้ด C ที่ซับซ้อนแล้วทำเอกสารโครงสร้างออกมา
    ถ้าทำ การสกัดความรู้ แบบนี้ได้ ก็จะต่อยอดไปสู่อัตโนมัติในงานอย่างเอกสาร API, การแมปกฎ, การวิเคราะห์บั๊ก, ไปจนถึงการปรับแต่งสถาปัตยกรรมได้
    สุดท้ายแล้ว ความสามารถในการ จัดโครงสร้างบริบท จะสำคัญกว่าการสร้างโค้ดเสียอีก

    • วิธีใช้ AI ของแต่ละคนแตกต่างกันสุดขั้ว
      ① แบบ oracle ผู้รู้ทุกสิ่ง ที่โยนแค่ requirement แล้วให้สร้างทั้งแอป
      ② แบบ เครื่องมือช่วย ที่ใช้ใน IDE และตรวจทีละบรรทัด
      ถ้าจะสร้างบริการที่ยั่งยืน แนวทางแบบ ② สมจริงกว่ามาก

  • ประโยคที่ว่า “สถาปัตยกรรมเกิดขึ้นเมื่อชิ้นส่วนระดับ local มีปฏิสัมพันธ์กัน” น่าประทับใจมาก
    AI เก่งกับงานระดับ local แต่ยังอ่อนกับ ขั้นตอนการออกแบบที่คลุมเครือ
    จริง ๆ มนุษย์นักพัฒนาก็เป็นเหมือนกัน เพราะการออกแบบคือชุดของ trade-off ที่ไม่มีคำตอบตายตัว

    • ฉันเองก็เคยได้ข้อสรุปด้านการออกแบบจากการคุยยาว ๆ กับ AI
      โดยเฉพาะการออกแบบ ClickHouse SQL ที่ช่วยได้มาก
      ด้วยวิธี รวม SQL แบบอิงเทมเพลต ที่ AI เสนอ ทำให้ลดความซ้ำซ้อนและปรับปรุงประสิทธิภาพได้ด้วย
      วิธีแบบนี้อาจมีอยู่ก่อนแล้วก็ได้ แต่ถ้าไม่มี AI ก็คงหาไม่เจอง่าย ๆ

  • เหตุผลที่บทความนี้น่าเชื่อคือมี ความพยายามจริง 250 ชั่วโมง อยู่เบื้องหลัง
    คิดว่าโปรเจ็กต์ขนาดนี้คือโมเดลที่สมจริงของ system programming ที่มี AI ช่วย

  • คำว่า “AI coding เหมือนสล็อตแมชชีน” นี่โดนใจมาก
    ฉันเองก็ได้ สิทธิ์เข้าถึง AI agent แบบไม่จำกัด จากที่บริษัท และพอเริ่มคิดว่า “ขอลอง prompt อีกครั้งเดียว”
    รู้ตัวอีกทีก็ผ่านไป 12 ชั่วโมงแล้ว มันมี ความเสพติดแบบดึงให้จมอยู่กับมัน สูงมาก

  • ตอนนี้น่าจะเป็นช่วงที่ AI coding ยากที่สุด
    สิ่งที่เมื่อ 6 เดือนก่อนยังนึกไม่ถึง ตอนนี้ทำได้แล้ว
    ฉันกำลังทำโปรเจ็กต์หลายภาษา และ AI ก็สร้างโค้ดได้เร็วเกินไป
    จนตอนนี้ ความเร็วในการ review กลายเป็นคอขวด
    พอเทสต์ผ่านได้ระดับหนึ่งก็เริ่มคิดว่า “แค่นี้พอหรือยัง?”
    ฉันจะระบุคุณสมบัติด้านคุณภาพอย่าง หลักการ SOLID, coupling, cohesion ไว้ใน prompt
    ถาม AI ขอไอเดีย refactor แล้วถ้าเข้าท่าก็บอกว่า “โอเค ทำเลย”
    สุดท้ายสิ่งสำคัญคือ ศิลปะของการออกแบบ prompt
    แต่ก็คิดว่าอีกไม่นาน AI จะทำ quality guardrail พวกนี้ให้เป็นพื้นฐานได้เอง

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

  • ทำให้นึกถึงปรัชญา “สร้างหนึ่งอันเพื่อทิ้ง” ของ Fred Brooks
    AI เหมาะมากกับการสร้างเวอร์ชันแรกแบบ throwaway นั้นให้เร็ว
    การคาดหวังคุณภาพระดับ production ตั้งแต่แรกเป็น แนวทางที่ไม่ฉลาด
    วิธีที่ถูกต้องคือต้องทำให้เร็ว เรียนรู้ แล้วค่อย refactor ต่อ
    และก็เห็นด้วยว่าพอเหนื่อย prompt จะคลุมเครือขึ้น ผลลัพธ์ก็แย่ลงตาม

    • แต่ก็น่าสนใจเหมือนกันที่ต่อมา Brooks เปลี่ยนมุมมองไปทาง iterative refinement มากขึ้น

  • น่าแปลกใจที่ SQL parser ของ SQLite ไม่ได้สร้างด้วย lemon
    ตอนพอร์ต pikchr ไปเป็น Go ฉันย้าย lemon ก่อน แต่ SQLite ไม่ได้สร้างแม้แต่ parser tree
    พออ่าน เอกสาร lemon แล้ว รู้สึกว่านี่ดูเป็นปัญหาแบบ นิยามปัญหาไม่ชัดตั้งแต่ขั้นออกแบบ

  • ฉันเองก็เห็นด้วยกับข้อสรุปของบทความนี้ทั้งหมด
    นี่เป็นกรณีศึกษาที่ดีที่แสดงความจริงของ AI coding แบบ ตรงไปตรงมาโดยไม่โอ้อวด