ชุบชีวิตโปรเจกต์ที่คงทำไม่เสร็จด้วยเครื่องมือช่วยเขียนโค้ด

• โปรเจกต์ส่วนตัว ที่ค้างมานานเหมาะกับการลองใช้ เครื่องมือช่วยเขียนโค้ด เพราะเป้าหมายคือทำให้การพัฒนาเสร็จ ไม่ใช่เรียนรู้สิ่งใหม่
• มีการเขียน shim ที่เปิดให้ YouTube Music ใช้งานผ่าน OpenSubsonic API ใหม่ เพื่อให้ Subsonic client ต่าง ๆ เชื่อมต่อได้ด้วยวิธีเดียวกัน
• เริ่มจากล็อกโครงสร้างขั้นต่ำและกติกาการพัฒนาให้ชัดก่อน จากนั้นทำงานเป็นรอบสั้น ๆ พร้อมรันการสร้าง stub จากสเปก OpenAPI และทดสอบการเชื่อมต่อกับ client จริงไปด้วย
• เวอร์ชันแรกที่อิงแค่สเปกพังทันทีเมื่อลองเชื่อมต่อจริง จึงต้องวนดู request log และเพิ่ม unit test ซ้ำ ๆ จนดันไปถึงระดับที่ค้นหาและเล่นเพลงได้
• ถ้าไม่ใช่ stretch project เพื่อการเรียนรู้ แต่เป็น โปรเจกต์ที่อยากให้มีอยู่จริง เครื่องมือช่วยเขียนโค้ดช่วยเปลี่ยนงานที่ผัดไว้มานานให้กลายเป็นบริการที่ใช้งานได้จริงอย่างมาก

---

ที่มาของโปรเจกต์และแนวทางที่ใช้

• โปรเจกต์ส่วนตัว ที่เคยเริ่มไว้นานแล้วแต่ทำไม่เสร็จ เหมาะกับการทดลอง AI เครื่องมือช่วยเขียนโค้ด
  • โปรเจกต์ที่นำกลับมาชุบชีวิตคือ shim ที่เชื่อม YouTube Music กับ OpenSubsonic API
  • OpenSubsonic ถูกใช้เป็นสัญญา API ที่ช่วย แยก music streaming client ออกจาก server
  • ฝั่ง server ใช้ Navidrome, desktop client ใช้ Feishin, และ Android ใช้ Symfonium
• shim นี้ทำหน้าที่เปิด YouTube Music ให้อยู่ในรูปแบบ OpenSubsonic API เพื่อให้ client ใด ๆ ก็เชื่อมต่อได้
  • ใช้ ytmusicapi สำหรับดึง metadata และเรียก yt-dlp แบบ programmatic สำหรับการสตรีม
  • การสตรีมพื้นฐานเชื่อมได้ค่อนข้างง่าย แต่ยังเหลืองานปลายยาวในการทำ endpoint ให้ครบตามมาตรฐาน
• โปรเจกต์นี้เน้นการ ทำตามสเปกที่ชัดเจน มากกว่าการแก้ปัญหาใหม่หรือปัญหาเชิงสร้างสรรค์ จึงเข้ากับเครื่องมือช่วยเขียนโค้ดได้ดี
  • ทำเป็นการทดลองเขียนใหม่ทั้งหมดตั้งแต่ต้นด้วย Claude Code และ Opus 4.6

การตั้งค่าเริ่มต้น

• จุดเริ่มต้นคือ โปรเจกต์ขนาดเล็กที่จำกัดโครงสร้างไว้ล่วงหน้า
  • สร้างโปรเจกต์ uv และเพิ่ม dependency ได้แก่ fastapi, pydantic, ytmusicapi, yt-dlp
  • เปลี่ยน main.py เป็นไฟล์ main ตัวอย่างของ FastAPI และนำ OpenAPI spec ของ OpenSubsonic ใส่ไว้ในโฟลเดอร์
  • ใน README เขียนสั้น ๆ ถึงบทบาทของ server, ไลบรารีที่ใช้, URL เอกสาร และตำแหน่งของ openapi.json
  • เพิ่มไฟล์ TODO ว่าง ๆ และสร้าง CLAUDE.md ด้วย /init
• ใน CLAUDE.md มีการเขียน กติกาการพัฒนา แยกไว้เพื่อลดการสั่งซ้ำ
  • กำหนดให้ method arguments และ return values ต้องมี type annotation และ docstring
  • การทำ data modeling ให้ยึดตามแนวทางของ Pydantic V2
  • docstring ต้องมีส่วน args และ returns ตามสไตล์ Google
  • test ใช้ pytest style แบบใหม่ โดยใช้ฟังก์ชันระดับบน, assert และ fixture
• จุดเริ่มต้นนี้ถูกจัดไว้เป็น git repository

ลำดับการทำ MVP

• วิธีทำงานคือใช้ plan mode และวนรอบสั้น ๆ
  • โยนงานถัดไปเป็น prompt แล้วตรวจว่ามีอะไรตกหล่นหรือมีปัญหาจากแผนเริ่มต้นหรือไม่
  • ถ้าทิศทางเริ่มเพี้ยน ก็เพิ่มลิงก์ทรัพยากรที่เกี่ยวข้อง หรือถ้ามีหลายทางเลือกก็ให้ใช้ search tool หาแนวทางที่เป็นธรรมเนียมมากกว่า
  • หลังจบแต่ละงานจะใช้ "Accept and clear context" เพื่อล้าง context แล้ววนต่อ
• การลงมือรอบแรกโฟกัสที่การสร้าง stub สำหรับ JSON endpoint แบบใหม่ จาก OpenAPI spec
  • แม้จะมีทั้ง XML endpoint แบบเก่าและ JSON endpoint แบบใหม่ แต่จำกัดขอบเขตให้รองรับเฉพาะของใหม่
  • หลัง implement แล้วจะมีขั้นตรวจซ้ำว่า method ทั้งหมดตรงหรือไม่
  • แม้มีสเปกให้ดู รอบแรกก็ยังพลาด และการตรวจรอบสองช่วยจับข้อผิดพลาดส่วนใหญ่ได้
• หลังการเปลี่ยนแปลงใหญ่ จะรัน /init ใหม่เพื่อ อัปเดต CLAUDE.md ให้ตรงกับสถานะล่าสุด
• ขั้นต่อไปคือกำหนดและเชื่อม ฟังก์ชันขั้นต่ำที่ค้นหาและสตรีมได้
  • ตั้งเป้าให้ Subsonic client เชื่อมต่อ ค้นหาเพลง และเล่นเพลงได้ในระดับขั้นต่ำ
  • ใช้ ytmusicapi สำหรับการค้นหา และ yt-dlp สำหรับการสตรีม

ปัญหาที่เจอเมื่อเชื่อมต่อจริงและการปรับแก้

• ภายนอกดูเหมือน implementation จะออกมาใช้ได้อย่างรวดเร็ว แต่พอลองเชื่อมกับ Feishin จริงกลับพังทันที
  • จึงต้องทดสอบกับ client โดยตรง แล้วส่ง server request log ให้ Claude Code เพื่อแก้ซ้ำไปมา
  • มีรายละเอียดบางอย่างที่สเปกไม่บอกชัด เช่นต้องตัด suffix .view ออกจาก endpoint
• ทุกครั้งที่เจอ error จะสร้าง unit test เพิ่มเพื่อกัน regression
• หลังจากวนแก้ไม่กี่รอบ Feishin ก็เริ่ม เล่นเสียงได้จริง
  • ปัญหาหลักอยู่ที่ stub endpoint ไม่ได้คืนค่าอะไรเลย
  • endpoint ส่วนใหญ่จึงต้องแก้ให้คืน response ที่โครงสร้างถูกต้อง แม้ข้อมูลภายในจะว่าง
• อย่างไรก็ดี MVP ระดับนี้ก็ยังไม่ต่างจาก POC เดิมมากนัก และความใช้งานได้จริงยังขึ้นกับงานปลายยาวในลำดับถัดไป

งานปลายยาวและการขยายฟังก์ชันทั้งระบบ

• ตาม เอกสาร OpenSubsonic API มี ประมาณ 80 endpoint กระจายอยู่ใน 15 หมวดหมู่
• ขอบเขตที่จำเป็นต่อ MVP มีไม่มากนัก
  • getLicense, getUser, getGenres, getMusicDirectories คืน collection ที่ว่างแต่ยัง valid
  • getSong ทำแบบ pass-through โดยคืน ID จาก query parameter ตรง ๆ และเติมค่าเริ่มต้นที่จำเป็น
  • search3 implement ด้วยการเรียก ytmusicapi แบบง่าย ๆ
  • stream ดึง URL ของฟอร์แมต "bestaudio" ผ่านการเรียก yt-dlp ที่ครอบด้วย asyncio.to_thread
  • getCoverArt ดึง URL ของรูปปกผ่าน yt-dlp
• หากต้องการรองรับ ฟังก์ชันทั้งหมดของ Subsonic client ก็ยังต้องทำเพิ่ม
  • ใส่ memory cache แบบง่ายให้กับการเรียก ytmusicapi เพื่อหลบข้อจำกัดด้าน usage
  • ใช้ sqlite สำหรับเก็บ metadata เพลง และ implement endpoint ทั้งหมดในหมวด browsing
  • getTopSongs ก็ทำโดย query รายการ top songs
• ระหว่างสตรีม มีการเก็บเพลงลงดิสก์เพื่อ หลีกเลี่ยงการดาวน์โหลดซ้ำ
  • หาก client ตัดการเชื่อมต่อกับ stream endpoint ก่อนดาวน์โหลดเสร็จ ต้องมีการจัดการเพิ่มเพื่อล้างไฟล์ที่ไม่สมบูรณ์
• งานเหล่านี้เดิมก็ทำเองได้ แต่เป็นส่วนที่ไม่เคยทำจนจบ และเพราะไม่มีแผน deploy จึงยังข้ามส่วนยากอย่าง authentication ไป
• สุดท้ายจึงได้ บริการที่ใช้งานได้จริง ซึ่งให้ Subsonic client เชื่อมต่อได้ ภายในช่วงเย็นสั้น ๆ และตั้งชื่อโปรเจกต์ว่า Sub-standard

เหมาะจะใช้กับงานแบบไหน

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

[GN⁺]

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

• โปรเจ็กต์ที่ปล่อยทิ้งไว้บ่อยที่สุดของผมคือวิดีโอเกม
  ผมมีโฟลเดอร์โปรเจ็กต์ที่หยุดไว้เป็นสิบ ๆ อัน แต่ตอนนี้เริ่มกลับมามองมันเป็นการทดลองอีกครั้ง
  อาทิตย์ก่อนผมลองหยิบอันหนึ่งกลับมารันกับ Claude แล้วมันเข้ากันได้ดีมาก แถมยังช่วยตั้งทิศทางให้ตรงด้วย
  เพราะผมบอกไว้ตั้งแต่แรกว่าเป็นโปรเจ็กต์ที่เคยทิ้ง มันเลยผลักให้ผมทำ V0 gameplay loop ให้จบก่อน แล้วค่อยต่อยอดจากความสนุกตรงนั้น ทำให้ไม่เลิกกลางทาง
  พอให้ไอเดียด้านเกมดีไซน์ มันก็ให้โค้ดที่รันได้มา พอให้ paper เรื่อง procedural algorithm มันก็เอาไปทำ implementation ให้ได้ด้วย ช่วย brainstorm ไอเท็ม ทำกราฟิกแอสเซ็ต และแม้แต่ช่วยสร้าง lore ได้ด้วย
  ชุด Claude Code + Godot นี่สนุกมาก และไม่ได้รู้สึกสนุกกับการใช้คอมพิวเตอร์แบบนี้มานานแล้ว

  • นี่เป็นครั้งแรกที่ผมเห็นคนเรียก LLM ว่า he แทนที่จะเป็น it
    ไม่ได้จะตำหนิอะไรนะ แต่รู้สึกทั้งน่าสนใจและแอบไม่สบายใจนิด ๆ
  • ของผมตรงกันข้ามเลย
    ผมมีโฟลเดอร์ การทดลอง เป็นสิบ ๆ อัน แล้วตอนนี้หลายอันกำลังกลายเป็นโปรเจ็กต์จริง
  • สิ่งที่สนุกช่วงนี้คือการหยิบโปรเจ็กต์ที่เริ่มด้วย agent driven development เมื่อหลายเดือนก่อนหรือปีก่อน แล้วติดขัดจนหยุดไป กลับมาทำต่อด้วย Claude หรือ codex รุ่นใหม่แล้วดันไปได้ไกลขึ้น
    บางอันตอนนี้รันได้แล้ว แต่บางอันก็ยังซับซ้อนเกินกว่าที่เอเจนต์จะรับมือไหว
    ถึงอย่างนั้น การทำแอปใช้ส่วนตัวก็กำลังง่ายขึ้นเรื่อย ๆ
    อีกไม่นานคงไปถึงจุดที่พูดว่า “Alexa ช่วยสร้างแอป iPhone ที่ถ่ายรูปอาหารในตู้เย็น รวบรวมข้อมูลโภชนาการ ซิงก์กับแอปออกกำลังกาย เอาไปเทียบกับวัตถุดิบที่ตรงเป้าหมายในแอปสุขภาพ แล้วส่งอีเมลแนะนำวัตถุดิบที่ดีกว่าโดยดูจากงบ พื้นที่ และข้อจำกัดด้านอาหารให้หน่อย” แล้ว 15 นาทีต่อมาก็มีแอปใช้
  • ดูเหมือน Godot จะไม่ใช่ เครื่องมือที่ออกแบบมาให้เข้ากับ LLM เท่าไร
    อย่างเช่นมันสร้างไฟล์ tres ที่ผิดมาหลายครั้ง และการปล่อยให้ LLM สร้าง ID เองก็ดูไม่ค่อยเสถียรพอสมควร
  • ฝั่ง procedural ผมก็กำลังทดลองเอา LLM เข้าไปเป็นส่วนหนึ่งของ procedural loop อยู่เหมือนกัน
    เป็นแนวเอา live narrative มาวางทับด้านบน
    โมเดลแบบรันโลคัลยังช้าและยังไม่เก่งมาก แต่ก็น่าสนใจมากที่จะดูว่ามันให้ผลลัพธ์แบบไหน

• ยอดเยี่ยมจริง ๆ
  ตอนนี้มี ซอฟต์แวร์ใช้ส่วนตัว เยอะมาก
  เมื่อวานผมทำ native text editor ที่รวมกับ MediaWiki แบบเต็มตัว และมีทั้ง autocomplete สำหรับลิงก์กับตัวช่วยพิมพ์ไวยากรณ์
  ซอฟต์แวร์แบบนี้แทบไม่มีค่าอะไรสำหรับคนอื่น เลยไม่มีเหตุผลที่ใครจะทำมันนอกจากผมเอง และเมื่อก่อนผมก็ทำไม่ได้เพราะใช้เวลานานเกินไป
  แต่พอให้เอเจนต์ช่วยเขียนโค้ด คอขวดก็ไม่ใช่การ implementation อีกต่อไป แต่เป็น สมาธิของผมเอง และการโยนงานใช้ส่วนตัวพวกนี้ใส่ลงไปในช่องว่างในหัวก็เข้ากันดีมาก
  รู้สึกว่าเป็นช่วงเวลาที่ดีจริง ๆ

  • เมื่อไม่กี่สัปดาห์ก่อนผมเพิ่งทำ Quake 2 mod ที่เริ่มไว้ตั้งแต่ปี 1998 เสร็จในที่สุด
    AI ช่วยให้ผมข้ามพ้นทั้งภาวะหมดไฟหลัง COVID และกองโปรเจ็กต์ค้าง ๆ ครึ่ง ๆ กลาง ๆ ได้
    วันนี้ก็เพิ่งซ่อมเครื่องมือ RDP ที่เกี่ยวกับเทอร์มินัล และกำลังกลับไปจัดการ issue ที่เคยเปิดไว้ใน OpenRA เมื่อ 10 ปีก่อน
    เอนจินเร็วขึ้น 10 เท่า และตอนนี้ pathfinding ก็ใช้งานได้ถูกต้องเป็นส่วนใหญ่แล้ว
  • มันสุดยอดจริง ๆ
    ผมมีเครื่องมือส่วนตัว ราว 120 ตัว แล้ว และที่ว่าคอขวดย้ายจากการ implementation ไปเป็น context switching นี่ตรงมาก
    ตอนนี้เลยมีไฟล์ markdown ไว้ใน project root ของทุกโปรเจ็กต์ และทุกครั้งที่หยุดก็จะจดสถานะกับขั้นตอนถัดไปไว้
    จะได้ไม่ต้องเสียเวลา 20 นาทีหลังกลับมาอีกครั้งเพื่อกู้คืนว่า “ฉันทำค้างไว้ถึงไหนนะ?”
    ยังไงคนอื่นก็ไม่ได้ใช้ด้วย เลยไม่ต้องแบกรับภาระเรื่อง edge case หรือเอกสาร แค่แก้ปัญหาของตัวเองให้ตรงจุดแล้วไปต่อโปรเจ็กต์ถัดไปได้เลย
  • ผมสงสัยว่าอยู่มาได้นานแค่ไหนโดยไม่มี AI
    พอมองจากการระเบิดของ productivity ตอนนี้ รู้สึกว่าก็คงต้องใช้เวลาพอสมควรกว่าจะสะสมความต้องการยิบย่อยได้มากขนาดนี้
  • ผมยังทำแอปสำหรับวางแผน Scavenger Hunt ในช่วงอีสเตอร์ด้วย
    พอนึกว่ามันเฉพาะทางแค่ไหนแล้วก็ตลกดี

• เดิมทีผมเขียนโค้ดเป็นอยู่แล้ว แต่ไม่มีเวลา และ AI ก็เป็น game changer เต็ม ๆ ที่ทำให้ผมได้ปล่อย โปรเจ็กต์โอเพนซอร์ส ออกสู่โลก
  ตอนนี้ผมทำแอป GUI แบบรันโลคัลบน Linux ที่เมื่อก่อนยังไม่ค่อยมีแรงจูงใจจะทำ ได้อย่างสนุกมาก

  • Sambervise: https://github.com/edward-murrell/sambervise
    เป็นแอป Linux GUI สำหรับจัดการ Samba 4 Active Directory Domain Controller จากระยะไกล
  • Krbtray: https://github.com/edward-murrell/krbtray
    เป็นแอป system tray GTK3 สำหรับจัดการ Kerberos ticket ในสภาพแวดล้อม GTK ที่ใช้ Linux Mint / Cinnamon และ GtkStatusIcon
  • อันนี้ทำให้ผมเริ่มเอนเอียงไปทาง AI coding จริง ๆ
    เพราะทั้งสองตัวเป็นแอปประเภทที่ผมต้องใช้จริงและเคยมองหาอยู่พอดี
  • อีกการเปลี่ยนแปลงสำคัญคือ ต้นทุนของการ refactor ครั้งใหญ่ ลดลงไปมาก
    ด้วยผู้ช่วยเขียนโค้ด ตอนนี้ผมลองเปลี่ยนโครงสร้างลึก ๆ รวมถึงการออกแบบโมดูลได้ด้วยเวลาน้อยกว่าสมัยก่อนมาก
    แน่นอนว่าไม่ได้ไม่มีต้นทุนเลย บางโมเดลก็ยังปล่อยโค้ดที่ไม่ผ่านมาตรฐานด้าน maintainability ออกมาบ่อย
    ต่อให้ประหยัดเวลาเขียนไปได้ ก็ไม่ได้แปลว่าเวลาที่ต้องใช้กับการแก้ซ้ำ เก็บงาน และเสริม system prompt หรือไฟล์ instruction จะหายไป

• ผมไม่ค่อยเห็นด้วยกับคำพูดที่ว่าถ้าใช้เครื่องมือมากไปจะ deskilling
  ผมเป็นมิลเลนเนียล และทำเฟอร์นิเจอร์ด้วยเครื่องมือช่างมือกับงานเข้าไม้แบบโบราณ
  ไม่ได้มีใครสอนผมด้วย แค่เรียนจากข้อมูลบนอินเทอร์เน็ต แต่สุดท้ายก็เรียนรู้สิ่งที่ต้องการได้
  ผมไม่กลัวว่าจะเสียทักษะนี้ไปในภายหลัง เพราะถ้าจำเป็นก็เรียนใหม่ได้
  หนังสือ วิดีโอ เครื่องมือ และไม้ ไม่ได้หายไปไหน
  การใช้ AI ไม่ได้ทำให้เกิด หลุมดำ ในสมองเพียงเพราะพิมพ์โค้ดด้วยมือน้อยลง
  มันไม่ใช่การสูญเสียข้อมูลถาวรแบบ Alzheimer’s แค่ต้องใช้เวลาวอร์มกลับมานิดหน่อยแล้วก็คืนฟอร์มได้เร็ว
  คนที่เขียนโค้ดแล้วผันไปงานบริหาร ก่อนกลับมาอีกหลายปีให้หลังก็แค่ฝืดไปนิดหน่อยแล้วก็หยิบกลับมาทำต่อได้
  โดยเฉพาะถ้าเป็นโปรเจ็กต์ส่วนตัว ก็ไม่จำเป็นต้องเผา Opus token ด้วยซ้ำ
  ใช้ subscription ราคาถูกกับอะไรอย่าง MiniMax ก็ได้ รันในคอนเทนเนอร์แบบ yolo mode แล้วให้มันมีแค่ context, prompt, web search และระบบ ticket อย่าง beads
  ไม่ได้รีบอะไรอยู่แล้ว แค่ยึดลำดับ brainstorm → plan → implementation → testing และเตรียมวิธีทดสอบจริงไว้ ไม่ใช่มีแค่ mock หรือ unit test ก็ประหยัดทั้งเวลาและเงิน และสุดท้ายก็ทำเสร็จได้

• เมื่อ 12 ปีก่อนผมพยายามทำแอปง่าย ๆ ที่แสดงว่าหนึ่งวัน หนึ่งสัปดาห์ หรือหนึ่งเดือนของผมเหลือเท่าไรด้วยความยาวของแท่ง และแสดงสภาพอากาศด้วยแท่งสำหรับอุณหภูมิสูงสุด-ต่ำสุด ปริมาณเมฆ ฯลฯ
  ผมทำได้ระดับหนึ่งด้วยข้อความและ ASCII แต่ทำอินเทอร์เฟซที่อยากใช้ทุกวันไม่สำเร็จ และสุดท้ายก็ทำกราฟิก UI ไม่ได้
  พอผมอธิบาย กราฟิกอินเทอร์เฟซ ที่ต้องการให้ Claude Code แล้วสั่งให้ทำ มันก็ออกมาเป็นแอปแบบที่ผมอยากได้เป๊ะ ๆ แถมยังเจอบั๊กใน date parser ที่ผมไม่เคยรู้มาก่อนด้วย
  ตอนนี้ผมเปิดแอปนั้นค้างไว้ที่มุมจอตลอด
  ต่อไปผมว่าจะทำ แอป iPhone ที่ปิดนาฬิกาปลุกตอนเช้าให้อัตโนมัติในวันที่ลูก ๆ ไม่มีเรียน
  ผมไม่รู้อะไรเกี่ยวกับแอป iPhone เลย และก็ไม่มีเวลาเรียนด้วย เมื่อก่อนเลยไม่กล้าคิด
  สำหรับแอปใช้ส่วนตัว Claude Code ยอดเยี่ยมจริง ๆ และเพราะคุณภาพโค้ดไม่ได้สำคัญมาก ผลลัพธ์ที่ได้ก็ใช้ตรง ๆ ได้สบาย

  • Claude Code เหมาะกับแอปใช้ส่วนตัวมากจริง ๆ
    ตัวจัดการ clipboard บน Mac ที่ผมใช้มาหลายปีเริ่มเพี้ยนหลังอัปเดต OS และแอปทดแทนใน App Store ก็ไม่มีฟีเจอร์ที่ผมต้องการ
    ผมเลยอ่านบทความของ Simon Willison เรื่อง SwiftUI vibe coding แล้วใช้ Claude Code สร้างเอง
    ต้องวนแก้อยู่ไม่กี่รอบ แต่ตอนนี้มันทำทุกอย่างที่ผมอยากได้จากเมนูบาร์บน Mac และยังได้มากกว่านั้นอีก
    โดยเฉพาะตอนที่ผมถาม CC เรื่อง ไอเดียฟีเจอร์เพิ่มเติม มันเสนอทางเลือกยาวมากที่ผมไม่เคยนึกถึง แล้วผมก็ให้มันลงมือทำตามตัวที่เลือกไว้ได้เลย ซึ่งน่าประทับใจมาก
    สองวันก่อนผมอยากได้ markdown editor แบบเฉพาะทางที่คล้ายคอมโพเนนต์แก้ไข markdown ตัวใหม่ของ LibreOffice แต่เล็กและเบากว่า
    ผมเลยให้ GPT 5.5 ช่วยทำโครง แล้วให้ CC ลงมือ implement สุดท้ายแค่สองรอบของ vibe coding ก็ได้แอป Mac แบบ native ที่เบา ๆ ซึ่งแทบจะเสร็จแล้ว ทั้งเปิดไฟล์ สร้างไฟล์ แก้ไขแบบคล้ายเวิร์ดโปรเซสเซอร์ และบันทึกเป็น canonical markdown ได้
    ตอนนี้ยังขาดแค่ markdown table และวันนี้กะจะให้มันทำต่อ
    https://simonwillison.net/2026/Mar/27/vibe-coding-swiftui/
    https://news.ycombinator.com/item?id=47298885
  • ใช่เลย
    ผมชอบการสร้างของนะ แต่บางครั้งก็แค่อยากได้ ผลลัพธ์ที่สร้างเสร็จแล้ว แบบเร็ว ๆ
    เวลาที่อยากได้เครื่องมือส่วนตัวเฉพาะทางโดยไม่ต้องยอมสละทั้งสุดสัปดาห์ ความช่วยเหลือจาก LLM นี่ดีมาก และคุณภาพโค้ดก็ไม่ได้สำคัญนัก
  • อาจไม่จำเป็นต้องทำแอปเองด้วยซ้ำ
    บน iPhone แก้ได้ด้วย แอป Shortcuts ที่มีมาให้เลย
    คุณสร้าง shortcut สำหรับปิดนาฬิกาปลุกทั้งหมดได้ แล้วให้อ่านสัญญาณอย่างปฏิทินเพื่อเปิดหรือปิดนาฬิกาปลุกในวันที่หรือเวลาที่กำหนด และตั้งให้รันตามตารางประจำก็ได้

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

  • ผมมีงานอดิเรกหลายอย่าง และการเขียนโปรแกรมก็เป็นแค่อย่างหนึ่งในนั้น
    บางครั้งผมต้องการซอฟต์แวร์ที่จะช่วยให้งานอดิเรกอื่นสนุกขึ้น แต่ก็ไม่ได้อยากดึงเวลาออกจากงานอดิเรก X เพื่อมานั่งทำซอฟต์แวร์นั้นเอง
    แถมงานแบบนั้นบางทีก็ไม่ใช่การเขียนโค้ดประเภทที่ผมทำเพื่อความสนุกด้วย
    สำหรับผม นี่แหละคือ sweet spot ของการเขียนโค้ดแบบมี LLM ช่วย และผมก็ทำ helper app หลายตัวเพื่อให้สนุกกับงานอดิเรกอื่นได้มากขึ้นจริง ๆ
    มันก็ยังเป็นเวลาให้กับงานอดิเรกอยู่ เพียงแต่งานอดิเรกนั้นไม่จำเป็นต้องเป็นการเขียนโค้ด
  • ถ้าคุณเขียนโค้ดเพื่อการเขียนโค้ดเอง ก็อาจใช่
    แต่ถ้าคุณมี itch ที่อยากแก้หรือมีความทะเยอทะยานที่อยากทำให้สำเร็จ เพียงแต่ขาดเวลาหรือแรงจูงใจ ผมไม่เห็นว่าทำไมสิ่งนั้นต้องถูกมองเป็น แรงงานในเวลาว่าง
    เมื่อก่อนโปรเจ็กต์หนึ่งกินทั้งสุดสัปดาห์หรือวันหยุด ตอนนี้แค่ 15 นาทีก็ตั้งโครงได้แล้ว ซึ่งมันกลับใกล้เคียงกับสิ่งตรงข้ามของงานมากกว่า
  • ผมเห็นด้วยกับมุมมองนี้ และคิดว่าเป็นท่าทีที่ค่อนข้างดีต่อสุขภาพ
    ผมเขียนโปรแกรมมามากกว่า 30 ปี และก็พอใจกับแอป command line มาตลอด เพิ่งไม่นานนี้เองที่เริ่มเรียน Qt แล้วติด UI แอปเดสก์ท็อปแบบจริงจังเข้าไป
    เส้นโค้งการเรียนรู้ชันมาก แต่ตอนนี้ก็ผ่านจุดนั้นมาได้ระดับหนึ่งแล้ว
    แต่พอผมโพสต์ภาพหน้าจอแอปพร้อมบอกว่าเป็นโอเพนซอร์สฟรีลง LinkedIn กลับมีคอมเมนต์เป็นร้อยจาก คนสไตล์ LinkedIn ที่ไม่ได้จะจ้างผมอยู่แล้ว
    มีทั้งแนว “อยากเอาไปอินทิเกรตกับ workflow ของเรา” หรือ “คุณไม่ใช่คนแรกที่ลองทำแบบนี้” ซึ่งไม่ได้สร้างแรงจูงใจเลย กลับให้ความรู้สึกเหมือนทำประโยชน์ให้คนอื่นฟรี ๆ หรือโดนวิจารณ์ไร้สาระเสียมากกว่า
    ผมเลยช็อกจนปล่อยมือไปประมาณเดือนหนึ่ง ก่อนจะสรุปกับตัวเองว่า สิ่งที่ผมรักจริง ๆ คือ ตัวกระบวนการ ของการเรียน Qt และการเห็นโปรแกรมเก่า ๆ ของตัวเองกลับมามีชีวิต
    ตอนนี้ผมเลยปฏิบัติกับสิ่งนี้เหมือน project car ของตัวเอง
    คอยรื้อ คอยแก้ ยกเครื่อง data model ใหม่หมดเพื่อดูข้อดีข้อเสียของดีไซน์แบบอื่น ทำ graphical view เอง และลองใส่การแปลภาษาเข้าไป
    เชิงฟังก์ชันมันเสร็จไปนานแล้ว แต่ผมมีเวอร์ชันที่โครงสร้างภายในต่างกันไปอย่างสิ้นเชิงอยู่ราวห้าตัว และนั่นแหละคือความสนุก
    ผมใช้มันในงานทุกวันทั้งวันได้ดี และก็จะไม่พูดถึงมันบน LinkedIn อีกแล้ว

• ใน repo ส่วนตัวของผมมี งานลองทำแอปจดโน้ต อยู่ตั้งสามอัน และทุกอันก็หยุดอยู่กลางช่องว่างระหว่างไอเดียกับเวลาว่าง
  แต่ด้วย Claude Code ผมทำตัวที่อยากได้จริง ๆ จนเสร็จภายในสองเดือน
  กระบวนการสร้างมันคือหนึ่งในงานอดิเรกที่ดีที่สุดเท่าที่ผมเคยเจอ ดีกว่าเล่นเกมหรือไถฟีดเยอะ
  พอไอเดียที่ผมเก็บมาหลายปีได้ถูกปล่อยออกมาจริง ๆ แอปนั้นก็ยิ่งมีตัวตนของผมฝังอยู่ลึกขึ้น และผมคิดว่าในอนาคตจะมี solo builder ที่สร้างของแบบนี้มากขึ้นอีกเยอะ

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

• ประสบการณ์ของผมแทบเหมือนกันเลย
  side project สำหรับการเปรียบเทียบและสรุปผลอันหนึ่งค้างอยู่ที่ เสร็จ 20% มานานกว่าหนึ่งปี ผมเปิดมันเดือนละครั้ง ดูรายการสิ่งที่ต้องทำ แล้วก็เหนื่อยจนปิดแท็บหนี
  แต่พอได้จับคู่กับ Claude อยู่สองสามสุดสัปดาห์ ผมก็ข้ามกำแพงของงานครึ่ง ๆ กลาง ๆ ไปได้
  สิ่งที่น่าทึ่งไม่ใช่ความเร็วล้วน ๆ แต่เป็นการที่ ต้นทุนการกลับเข้าไปทำต่อ หายไป ปกติแค่จะทำอะไรต่อผมต้องใช้เวลาหนึ่งชั่วโมงโหลดโค้ดเก่าของตัวเองกลับเข้าหัวก่อน
  hype ที่เกินจริงมันน่ารำคาญก็จริง แต่คนที่ชอบเยาะเย้ยเครื่องมือแบบนี้ส่วนใหญ่น่าจะยังไม่เคยลองใช้มันกับงานน่าเบื่อแบบนี้จริง ๆ ว่ามีประโยชน์แค่ไหน

• ผมมี ไอเดีย มากกว่าสิ่งที่รับมือไหวอยู่เสมอ และในนั้นก็มีหลายอันที่ดีไม่น้อย
  ด้วยเครื่องมือ AI ตอนนี้ผมสามารถเอาไอเดียได้มากขึ้นมาทำให้เป็นรูปเป็นร่างที่พอใช้งานได้
  แต่ในทางประชด คุณค่าของการลงมือทำแบบนั้นกำลังลดลงอย่างรวดเร็ว
  ไม่กี่สัปดาห์ก่อนผมทำไลบรารี search ขนาดเล็กที่รันในเบราว์เซอร์และไม่ต้องใช้เซิร์ฟเวอร์ รองรับ query กับ aggregation สไตล์ Elasticsearch ได้เกือบทั้งหมด ทั้ง term/matching query และยังใส่ ANN vector search ผ่าน WebGPU เข้าไปด้วย
  มันแทบจะเป็นแนว “ใส่ฟีเจอร์ X เข้าไป” แล้วก็ได้เลย และตอนนี้ผมก็เอาไปใช้กับเว็บไซต์จริงแล้วด้วย
  มันขยายสเกลไม่ได้ แต่สำหรับบล็อกหรือเว็บเอกสารนี่ดีมาก และเว็บเอกสารอยู่ที่ https://querylight.tryformation.com/
  มันทำงานตรงตามที่ผมจินตนาการไว้เป๊ะ และผมก็น่าจะใส่ฟีเจอร์ปลายหางของ Elasticsearch เพิ่มได้อีกโดยไม่ต้องออกแรงมาก
  แต่ใน GitHub กระแสตอบรับค่อนข้างเฉย ๆ
  ตอนนี้เหมือนทุกคนยุ่งกับการใช้ AI ทำของของตัวเอง จนไม่ได้ตื่นเต้นกับความพยายามของคนอื่นมากนัก ซึ่งก็เข้าใจได้เหมือนกัน
  ถ้าต้องการไลบรารี search ก็สร้างเองได้ หรือจะให้ AI ช่วยเลือกอันที่เหมาะก็ได้
  แต่แรกการทำสิ่งนี้ก็ไม่ได้ใช้แรงงานมหาศาลอยู่แล้ว
  มูลค่าทางเศรษฐกิจ ของโปรเจ็กต์แบบนี้กำลังลดลงอย่างรวดเร็ว
  ถึงอย่างนั้นผมก็ยังชอบการสร้างอยู่ดีเลยจะทำต่อ และคิดว่าการเรียนรู้เส้นโค้งของการใช้เครื่องมือพวกนี้ก็สำคัญ
  ต่อไปก็ยังมีงานให้ทำอีกมาก แต่ผู้คนจะคาดหวังผลลัพธ์ที่ดีพอโดยจ่ายน้อยลง และถ้าจะตามความคาดหวังนั้นให้ทันก็ต้องชำนาญเครื่องมือ
  สุดท้ายพอขอบเขตที่เป็นไปได้กว้างขึ้น มาตรฐานของความทะเยอทะยาน ก็จะสูงขึ้นตามไปด้วย ถ้าคิดว่า AI จะทำงานแทนให้หมดจนคนไม่ต้องคาดหวังอะไรอีก ก็คิดผิด
  ช่วงหลายเดือนมานี้ผมเองก็ทำงานยาวมากเหมือนกัน

• หลายปีมานี้ผมคิด ไอเดียผลิตภัณฑ์ ได้หลายอันทุกสัปดาห์ แต่ทั้งหมดก็แค่กองอยู่ใน Apple Notes
  แต่แค่เดือนที่ผ่านมา ผมทำสามอันจากนั้นจนกลายเป็น beta ที่ใช้งานได้จริง และตอนนี้ก็ใช้ทั้งสามตัวทุกวัน