การทำให้ซอฟต์แวร์กลายเป็น Emacs
(sockpuppet.org)- ด้วย AI agent ตอนนี้สามารถสร้างแอปเนทีฟส่วนตัวได้ภายในไม่กี่ชั่วโมง ทำให้ซอฟต์แวร์กำลังขยับเข้าสู่โลกของการปรับแต่งแบบ Emacs
- MDV.app เป็น ตัวดู Markdown สำหรับ macOS โดยเพิ่มฟีเจอร์ค้นหา, ดัชนี SQLite FTS, บุ๊กมาร์ก, สารบัญ และการจำตำแหน่งได้ภายในเวลาไม่กี่ชั่วโมง
- ปัญหาที่แอป Electron แต่ละตัวพก สำเนา Chromium ของตัวเองมาด้วย และความยากของการพัฒนา UI แบบเนทีฟนั้นใหญ่ไม่น้อย แต่ Claude รับมือกับ SwiftUI ได้อย่างชำนาญ
- เหมือนกับวัฒนธรรม Emacs ที่แต่ละคนแก้ความไม่สะดวกของตัวเอง เครื่องมือ เฉพาะทางมากๆ จะเพิ่มขึ้น และคุณค่าของไอเดีย การสังเกต และพรอมป์ต์จะมากกว่าผลิตภัณฑ์สำเร็จรูป
- การเขียนโค้ดด้วยเอเจนต์ทำให้การติด UI ที่ใช้งานดี เข้ากับไซด์โปรเจกต์และเครื่องมือเทอร์มินัลง่ายขึ้น และเปลี่ยนการทำ UI แบบเนทีฟให้กลายเป็นเรื่องสนุก
เหตุผลที่ลงมือสร้าง Markdown viewer เอง
- ในการพัฒนาซอฟต์แวร์ Markdown ถูกใช้เป็นภาษากลางมาตั้งแต่ก่อนยุค LLM และหลังยุคเอเจนต์เมื่อเครื่องมือ TUI กลับมาเพิ่มขึ้นอีกครั้ง ประสบการณ์การเลื่อนอ่าน Markdown ยาวๆ ในเทอร์มินัลก็ยิ่งทนได้ยากขึ้น
- ตัวดู Markdown แบบ TUI มีทั้ง glow ของ Charm และ Markless ที่ Josh สร้างขึ้น โดย Markless รองรับการนำทางผ่านสารบัญด้วย แต่เทอร์มินัลมักใช้ ฟอนต์ความกว้างคงที่ จึงทำให้อ่านนานๆ แล้วล้า
- บน macOS มีตัวแก้ไข Markdown แบบกราฟิกอย่าง Obsidian, Typora, Bear ที่อ่านสบาย แต่ทั้งหมดเป็น ตัวแก้ไข ดังนั้นทันทีที่เปิดไฟล์
.mdสภาพแวดล้อมการแก้ไขและการจัดวางหน้าต่างเดิมก็ถูกรบกวน - ตัวดู Markdown ใน App Store ตอนแรกดูเหมือนใช้ได้ แต่พอลองใช้งานจริงก็พบปัญหา เช่น ไม่มีการค้นหา, มี in-app purchase, หรือไม่สามารถคัดลอกข้อความที่เลือกไปยังคลิปบอร์ดได้
- ในปี 2026 แทนที่จะเสียเวลาหาตัวดูที่พอเหมาะต่อไป จึงเปลี่ยนมาคิดว่าเราสามารถ สร้าง Markdown viewer ที่ต้องการได้ด้วย AI agent
MDV.app ที่สร้างด้วย Claude
- MDV.app ถูกสร้างขึ้นภายในไม่กี่ชั่วโมงจนมีคุณภาพดีกว่าตัวดู Markdown เฉพาะทางที่เจอใน App Store และเวลาที่ใช้โต้ตอบจริงมีเพียงประมาณ 30 นาที
- มีการเตรียม MacBook เครื่องเก่าด้วย Xcode และ git พร้อมตั้งค่าสภาพแวดล้อมของ Claude ขณะที่การเตรียมความช่วยเหลือเกี่ยวกับ Swift และดีไซน์ของ macOS ได้ทำไว้ล่วงหน้าตั้งแต่หลายสัปดาห์ก่อน
- MDV อาจไม่ใช่แอป macOS ที่ดีที่สุดหรือซอฟต์แวร์ที่เก่งเป็นพิเศษ แต่ในฐานะตัวดู Markdown สำหรับ macOS แบบเฉพาะทางก็ถือว่าดีพอมาก และช่วยยกระดับคุณภาพชีวิตได้ชัดเจน
- ฟีเจอร์หลักของ MDV คือ การเลือกและคัดลอกข้อความ จากเอกสาร, การค้นหาสตริงแบบตายตัว, ดัชนี SQLite FTS สำหรับไฟล์ Markdown ทั้งหมดในประวัติที่แก้ไขได้, บุ๊กมาร์กด้วยคีย์ลัด และการนำทางผ่านสารบัญ
- เมื่อสลับไปมาระหว่างเอกสาร แอปจะจำตำแหน่งไว้และกลับมาอ่านต่อได้แม้รีสตาร์ตแล้ว พร้อมมีธีมสีและตัวอักษรที่อ่านสบาย ทำให้เมื่อคลิกไฟล์
.mdก็เปิดเข้าสู่สภาพแวดล้อมการอ่านที่ต้องการได้ทันที
ข้อจำกัดของ Electron และการเปลี่ยนแปลงของ Native UI
- ทุกครั้งที่มีข้อความ Signal เข้ามา หน้าจอจะกะพริบ และอาการนี้ไม่หยุดจนกว่าจะซ่อนแอป Signal อย่างชัดเจน ทำให้เกิดการกะพริบจางๆ ต่อเนื่องจนเกือบกระตุ้นไมเกรน
- ปรากฏการณ์นี้เกิดขึ้นเพราะ Signal เป็น แอป Electron ซึ่งภายนอกดูเหมือนแอป macOS แบบเนทีฟ แต่จริงๆ แล้วเป็นโครงสร้างที่ใช้สำเนา Chromium เรนเดอร์หน้าเว็บลับอยู่ภายใน
- ตลอด 10 ปีที่ผ่านมา แอป UI แทบทั้งหมดดูเหมือนต่างก็พก สำเนา Chromium ของตัวเองมาด้วย และแม้ Electron จะไม่ใช่ตัวเลือกที่ดีนัก แต่ก็ยังดีพอให้ถูกใช้งานมาเรื่อยๆ
- การสร้าง UI แบบเนทีฟจริงๆ ในอดีตเป็นงานที่ยาก และแม้แต่การหาคนระดับทั่วไปมารับผิดชอบงานนี้ก็ยังยาก ขณะที่นักพัฒนา macOS native UI ที่เก่งจริงมีอยู่น้อย
- Claude ไม่ได้แค่แทนที่นักพัฒนา SwiftUI ระดับทั่วไปเท่านั้น แต่ยังถูกมองได้ว่าเป็นนักพัฒนา SwiftUI ที่มีความชำนาญจริง
วิธีที่วัฒนธรรม Emacs ซึมออกไปสู่ซอฟต์แวร์โดยรวม
- MDV ไม่ได้เป็นผลิตภัณฑ์สำเร็จรูปที่อยากแนะนำให้ติดตั้งใช้ แต่ควรถูกมองเหมือน
.emacsตั้งค่าเจ๋งๆ ของผู้ใช้ Emacs ที่เอาไว้ขโมยไอเดียแล้วไปสร้างสิ่งที่ดีกว่าด้วยตัวเอง - ในวัฒนธรรม Emacs ผู้ใช้ที่ใช้งานมานานจะสร้างแอปพลิเคชันด้วย elisp เพื่อแก้ความไม่สะดวกส่วนตัวที่เริ่มต้นจากการแก้ไขข้อความ และเครื่องมือเหล่านั้นก็ค่อยๆ ขยายเลยขอบเขตอันสมเหตุสมผลของสิ่งที่โปรแกรมแก้ไขข้อความควรทำ
- /r/emacs ใกล้เคียงกับ วัฒนธรรมการโชว์ของ มากกว่าการโปรโมตผลิตภัณฑ์แบบ Product Hunt และแม้จะมีแพ็กเกจ elisp ที่คนใช้กันกว้างขวางอยู่บ้าง แต่ยกเว้น Magit แล้ว คนจำนวนมากก็มักจะกลับไปทำเวอร์ชันที่ตัวเองคิดว่าเจ๋งกว่าขึ้นใหม่
- จุดอ่อนของวัฒนธรรม Emacs คือแพ็กเกจนอกเหนือจาก Magit มักหน้าตาไม่สวย ช้า และมีประสบการณ์ใช้งานที่แย่แบบที่จะค้นพบได้ก็ต่อเมื่ออยู่กับ elisp มานานแล้ว
- AI agent ได้ผลักวัฒนธรรมนี้ออกไปนอกโลก Emacs และเมื่อมันสามารถสร้าง native UI ได้อย่างมั่นคงหากเข้าถึงหน้าจอและอินพุตได้ native UI ก็ย้ายจากโลกของโปรแกรมที่บรรจุหีบห่ออย่างมืออาชีพไปสู่โลกของ การปรับแต่งเฉพาะบุคคล
ความเป็นไปได้ของเครื่องมือเนทีฟส่วนบุคคล
- ซอฟต์แวร์ที่ถูก Emacsification ส่วนใหญ่จะเป็นซอฟต์แวร์ส่วนบุคคลที่มีประโยชน์กับคนสร้างเท่านั้น และจะมีเครื่องมือจำนวนมากที่ถูกลืมไปเหมือนโปรแกรม elisp เก่าๆ ที่ค้างอยู่ใน
.emacs - บางครั้งโปรแกรมแบบนี้อาจข้ามเส้นไปจนมีประโยชน์พอให้หลายคนติดตั้งใช้ได้ แต่ถึงตอนนั้น สิ่งสำคัญที่สุดก็อาจไม่ใช่ตัวผลลัพธ์ที่แจกจ่ายหรือซอร์สโค้ด
- หากเอเจนต์เป็นคนเขียนโค้ด SwiftUI ทั้งหมด การอ่านซอร์สโค้ดอย่างละเอียดอาจสำคัญน้อยกว่าการเห็น ไอเดียและการสังเกต ว่า “ของแบบนี้ก็สร้างได้และใช้งานได้ดี”
- สำหรับซอฟต์แวร์ลักษณะนี้ พรอมป์ต์ อาจมีค่ามากกว่าซอร์สโค้ด และสำหรับคนที่คุ้นเคยกับการทำให้ซอฟต์แวร์ทำงานเอง ทุกอย่างจะกลายเป็นสิ่งที่ตั้งโปรแกรมได้ ไม่ใช่แค่ในเชิงเทคนิคแต่ในทางปฏิบัติด้วย
- การเรียกซอฟต์แวร์ที่สร้างด้วยเอเจนต์ว่า “build” อาจฟังดูเกินจริงเมื่อเทียบกับแรงที่ลงไป เพราะประสบการณ์จริงใกล้เคียงกับการ ปรับตั้งค่า (configuring) บนแพลตฟอร์มที่อยู่ๆ ก็ปรับได้มากขึ้นมหาศาล
- นักพัฒนาที่ใช้ AI กำลังปิดงานไซด์โปรเจกต์สุ่มๆ ที่กองไว้หลายปีได้เสียที
- ตอนนี้เครื่องมือที่เฉพาะทางมากเหล่านั้นไม่เพียงแค่ทำเสร็จได้ แต่ยังมี UI ที่ใช้งานดี ได้ด้วย ซึ่งทำให้เหตุผลเดิมบางส่วนที่ต้องยอมทนกับ UI อึนๆ ของ Emacs อ่อนลง
- ความเป็นไปได้ในการปรับปรุงแอปเทอร์มินัลให้ดีขึ้นอย่างง่ายดายเพิ่มขึ้นมาก และเครื่องมืออย่าง
iostat,iostatข้ามหลายโฮสต์ หรือbpftraceก็อาจถูกทำให้อยู่ในรูปแบบที่เข้าใจง่ายกว่าเดิมได้ - ความซับซ้อนที่ Brendan Gregg ต้องยอมรับเพื่อทำภาพแสดงผลบนเทอร์มินัลของ
bpftraceไม่จำเป็นต้องทนแบบเดิมอีกต่อไป และก็มี ตัวอย่างที่ทำเองจริง ด้วย - ในฐานะนักวิจัยช่องโหว่ ความก้าวหน้าของการพัฒนา exploit ด้วย agent coding ในครึ่งแรกของปี 2026 เป็นเรื่องน่าสนใจ แต่สำหรับคนส่วนใหญ่มันเป็นการเปลี่ยนแปลงที่มาพร้อมความหวาดกลัว ขณะที่การที่การสร้าง native UI กลายเป็นเรื่องสนุกนั้นแทบจะเป็นข่าวดีล้วนๆ
- ขอแนะนำให้สร้าง เครื่องมือที่เฉพาะเจาะจงเกินพอดีกับปัญหาของตัวเอง ใช้มันให้สนุกสักพัก แล้วแชร์ต่อ หรือถ้าจะให้ดีกว่านั้นก็แชร์ทั้งภาพหน้าจอและพรอมป์ต์ที่ใช้
1 ความคิดเห็น
ความคิดเห็นบน Hacker News
ตอนนี้ผมคิดว่าพื้นที่หลายอย่างที่กลายเป็น ซอฟต์แวร์เฉพาะทางแบบแพ็กสำเร็จรูป ไปแล้ว น่าจะถึงเวลาที่พวก nerd จะดึงกลับมาทำเองได้อีกครั้ง: แอปพอดแคสต์, แอปฟังเพลง, feed reader, ไคลเอนต์ Bluesky, แอปจดโน้ต, แอป bookmark/read-it-later บนเดสก์ท็อป, แชตและแมสเซนเจอร์, ตัวติดตามเวลา, ตัวจัดการสูตรอาหาร อะไรพวกนี้
ใช้ Claude ก็ทำผลลัพธ์ที่ดีกว่าของทดแทนเดิมได้สบาย แม้อาจไม่ใช่แอประดับดีที่สุดหรือแข่งขันระดับโลกได้ แต่ทำแอปที่เข้ากับวิธีทำงานแปลกเฉพาะตัวของเราได้ดีกว่ามาก
Music.app ใช้แล้วทรมาน แต่ Apple ก็แยกฟังก์ชันหลักออกมาเป็น MusicKit ตั้งนานแล้ว ตอนนี้สินค้าจริงคือ MusicKit แล้ว เลยไม่รู้เหมือนกันว่าทำไมเรายังต้องใช้ Music.app อยู่ และนี่แหละคือความเปลี่ยนแปลงใหม่
การทดลองไปทางนั้นคือ https://github.com/dharmatech/9social
ไคลเอนต์ตัวแรกเขียนสำหรับ plan9 และการทำแบบนี้ช่วยให้การออกแบบยังซื่อตรง ถ้ามันรันได้บน plan9/rc/acme ก็แปลว่ามันสมเหตุสมผล
เดโมวิดีโออยู่ที่ https://youtu.be/q6qVnlCjcAI และตอนนี้ตัว implementation ยังมีโค้ดไม่ถึง 3000 บรรทัด
ถ้าจะพูดถึง Emacs, 9social ได้แรงบันดาลใจอย่างมากจากโปรเจกต์ Emacs ที่ชื่อ Org Social: https://github.com/tanrax/org-social
มันคืออินเทอร์เฟซแบบ spreadsheet ที่ยังทำไม่เสร็จสำหรับกรอกเวลา ทำไว้ใช้กับงานที่ปรึกษา แต่ยังไปไม่ถึงขั้นเก็บข้อมูล มีอัลกอริทึมน่ารัก ๆ ที่รองรับวิธีกรอกเวลาที่คนใช้กันจริงแทบทุกแบบ ผมทำมันเพราะไม่ชอบที่ตัวติดตามเวลาทั่วไปบังคับให้กรอกข้อมูลแบบมีโครงสร้าง: https://stackoverflow.com/a/49185071/59087
ตัวจัดการสูตรอาหาร: https://repo.autonoma.ca/repo/recipe-fiddle
ในยุค LLM งานอย่างการจัดหมวดหมู่วัตถุดิบและฟอร์แมตเป็น TeX สำหรับพิมพ์ PDF น่าจะง่ายขึ้นมาก ไอเดียของโปรเจกต์นี้คือแทบจะคัดลอก/วางสูตรจากเว็บหรือสแกนลายมือแล้วให้มันจัดรูปแบบให้อัตโนมัติ
ใน F-Droid ไม่มีแอปไหนที่ตรงเงื่อนไขทั้งหมดนี้ ก็เลยสร้าง APK เองเสียเลย
ผมคิดว่ายุค LLM ทำให้การผลิตซอฟต์แวร์ง่ายเกินไปจนทุกอย่างกลายเป็นเหมือน ไฟล์ .emacs ไปหมด กล่าวคือแต่ละคนจะมีดักแด้ซอฟต์แวร์ที่เป็นของตัวเองสุด ๆ และปรับแต่งได้ไม่รู้จบ
อย่างที่ OP พูด มันง่ายกว่าการติดตั้งหรือเรียนรู้ของที่มีอยู่แล้วเสียอีกที่จะสร้างวิธีแก้ของตัวเอง
Lisp ก็เป็นอุปมาได้ดีเหมือนกัน คำวิจารณ์เก่า ๆ ต่อ Lisp macro คือโปรแกรมเมอร์ทุกคนจะเปลี่ยนทุกอย่างเป็นภาษาส่วนตัวของตัวเอง จนคนอื่นอ่านไม่รู้เรื่อง
มันทำให้นึกถึงบทความปี 2007 ของ Mark Tarver ชื่อ "The Bipolar Lisp Programmer": https://hn.algolia.com/?query=comments%3E0%20The%20Bipolar%20Lisp%20Programmer&type=story&dateRange=all&sort=byDate&storyText=none&prefix
เขาพูดถึง "brilliant bipolar mind" ซึ่งชวนให้นึกถึงคำว่า AI psychosis ที่ทุกวันนี้โผล่มาบ่อย ทั้งแบบประชดและแบบจริงจัง
ในบทความของ Tarver https://www.marktarver.com/bipolar.html เขาบอกว่า "throw-away design" ของชุมชน Lisp เหมาะกับ BBM มาก Lisp ทำให้โยนอะไรสักอย่างขึ้นมาง่ายเกินไป จนแต่ละคนสร้างวิธีแก้ของตัวเองแล้วก็พอใจถ้ามันใช้กับตัวเองได้
แต่ใน C/C++ การสร้างอะไรที่มีความหมายมันยากพอที่จะนับเป็นความสำเร็จ เลยมีแรงจูงใจให้ทำเอกสารและร่วมมือกัน ในมุมมองนายจ้าง คน 10 คนที่สื่อสาร ทำเอกสาร และทำงานร่วมกันได้ ย่อมดึงดูดกว่านักแฮ็ก Lisp 1 คนที่แทนได้ยาก
พอการผลิตง่ายขึ้น การบริโภคกลับกลายเป็นคอขวด และการแชร์ก็ยากขึ้น ไฟล์ .emacs มีความเป็นส่วนตัวเหมือนลายนิ้วมือ เอาชิ้นส่วนมาหยิบใช้ได้ แต่ไม่อยากใช้ของทั้งก้อนจากคนอื่น
ยิ่งดักแด้พวกนี้ถูกปรับแต่งมากเท่าไร คนอื่นก็ยิ่งเข้าใจหรืออยากใช้ได้ยากขึ้น ไม่ใช่แค่ต้นทุนทางความคิดสูง แต่ยังอึดอัดเหมือนใส่เสื้อผ้าคนอื่น เรื่องนี้อาจเรียกว่าไม่ใช่ AI psychosis แต่เป็น AI solipsism มากกว่า
ในโลกซอฟต์แวร์ การจัดการคอนฟิกกำลังกลายเป็นส่วนที่ยาก เราจะแชร์ source และทำ version control กันอย่างไร? source คืออะไรกันแน่? prompt หรือ? ตอนท้าย OP เองก็เอนไปทางแชร์ screenshot กับ prompt มากกว่าโค้ด
ใน Show HN ก็มีการลองหยั่งเชิงว่าควรแชร์ prompt เพราะโค้ดที่สร้างขึ้นมาไม่ใช่ source อีกต่อไป แต่โดนคนที่รู้เรื่องคัดค้านหนักมาก: https://news.ycombinator.com/item?id=47213630
แรงกดดันที่ GitHub กำลังรับอยู่ก็คงหนีไม่พ้นกระแสนี้ ผู้สืบทอดจะหน้าตาเป็นอย่างไรยังไม่ชัด แต่สุดท้ายต้องมีแน่ ตอนนี้ยังดูเหมือนอยู่ในยุครถม้าไร้ม้า
สิ่งที่สำคัญกว่านั้นคือการทำงานเป็นทีม ถ้าทุกคนเป็น BBM หมด หรือแต่ละคนมีฝูง BBM คลุ้มคลั่งของตัวเองที่สร้างของให้ตัวเองตลอด 24 ชั่วโมง แล้วเราจะทำงานร่วมกันอย่างไร? ดักแด้แต่ละอันจะสื่อสารและทำงานร่วมกันได้อย่างไร? ทีมของพวก AI solipsist ฟังดูขัดแย้งในตัวเอง
ทีมและสตาร์ตอัปที่อยู่แนวหน้าของการพัฒนาแบบ agentic และ AI-driven น่าจะกำลังเจอเรื่องนี้อยู่จริงตอนนี้ เช่น ปัญหาว่าจะเอาโค้ดที่ฉันสร้างกับโค้ดที่คุณสร้างมารวมกันอย่างไร แรงเสียดทานแบบนี้อาจทำให้กำไรด้าน productivity จากโค้ดที่สร้างขึ้นต้องคืนกลับไปบางส่วน
น่าเสียดายที่ยังไม่ค่อยมีใครพูดเรื่องนี้ในที่สาธารณะ ทุกคนไม่อยากเป็นคนแรกที่นั่งลงท่ามกลางเสียงปรบมือบังคับ แต่ถ้าแกล้งทำเหมือนมันเป็นมื้อฟรีไร้ข้อเสีย การถกเถียงก็จะน่าเบื่อและวิวัฒนาการก็จะช้าลง
ถ้าคนที่ทำงานจริงจังและล้ำหน้าที่สุดกับเครื่องมือใหม่ไม่พูดถึงข้อเสีย สุดท้ายเรื่องข้อเสียของ AI ในงานพัฒนาซอฟต์แวร์ก็จะเหลือแต่ฝั่งเหยียด ๆ ที่คิดว่า AI ไม่มีคุณค่าอะไรเลย บรรยากาศตอนนี้เหมือนพูดเรื่องจำนวนบั๊กที่เพิ่มขึ้นหรือ productivity ที่นิ่งนานนั้นยากกว่าพูดเรื่องมนุษยชาติล่มสลายเสียอีก
ผมอยากรู้ว่าจริง ๆ แล้วมันเกิดอะไรขึ้น ผู้คนรับมืออย่างไร และเมื่อเวลาผ่านไปมันเปลี่ยนไปอย่างไร คงต้องไป meetup อะไรสักอย่างหรือเปล่า
แม้แต่ชื่อบทความวิจัยที่เกี่ยวข้องก็ยังชื่อว่า "Easier to Write, Harder to Read": https://papers.ssrn.com/sol3/papers.cfm?abstract_id=6726702
แล้วผมจะไปอ่านผลผลิตจากบทสนทนาเฉพาะของใครกับ LLM ทำไม? แค่รู้หัวข้อบทสนทนา ผมก็ไปคุยให้ดีกว่าเองได้
ซอฟต์แวร์แบบนี้ก็คล้ายกัน อาจมีรสนิยมแทรกอยู่บ้าง แต่ส่วนใหญ่สิ่งสำคัญคือไอเดียกับ สูตร
น่าจะมีเธรดรายเดือนชื่อ "Vibe HN"
อยากรู้ว่าจะมีใครแชร์วิดีโอการสร้าง WhatsApp แบบคัสตอมได้ในเวลาที่สั้นกว่านั้นไหม ยังไม่ต้องพูดถึงโจทย์ดึงคนอื่นเข้ามาใช้แมสเซนเจอร์เฉพาะกิจนั้นเลย
ตอนนี้กลายเป็น "ฉันจะโยน ticket นี้ให้ Claude ดู นายลองกับ Copilot แล้วมาเทียบผลกัน" หรือ "ฉันจะเปิด PR จากผลลัพธ์หยาบ ๆ ของฉัน แล้วนายรีวิวด้วยเครื่องมือของนาย" ซึ่งพูดตามตรงมันแทบไร้ความหมาย และ pair programming ตายสนิทแล้ว
ใครจะอยากมานั่งดูการรันหลาย agent แก้ปัญหาใน work tree คนละอัน และคอยแก้ความไม่ตรงกันใน agents.md กันล่ะ
มีการผลักดันให้สร้าง cloud pipeline อัตโนมัติเต็มรูปแบบที่เดินเองได้ แต่ดูเหมือนผู้บริหารจะกดเรื่องนี้ไว้เงียบ ๆ พอถึงวันที่พิสูจน์ได้ว่ามันบินได้จริง บางคนก็คงเสียเก้าอี้สบาย ๆ ไป น่าจะเป็นตรรกะง่าย ๆ แบบนั้น
UNIX ไม่ได้ถูกทำให้เป็นสินค้า แต่มันเป็นสภาพแวดล้อมที่ปรับให้เหมาะกับการสร้างเครื่องมือและแก้ปัญหาจริง โดยพวกเขาเขียนเครื่องมือด้วย C ส่วนพวก BBM ในช่วงนั้นคงกำลังยุ่งกับ Lisp อยู่ที่ Boston
C++ เป็นอีกเรื่องไปเลย และตรงนั้นต้องมี IDE
ที่ Emacs มีคุณสมบัติแบบนั้นก็เพราะมันใช้ Lisp แนวโน้มทั่วไปที่โปรแกรมเมอร์เริ่มสร้างทุกอย่างเองนั้นถูกสังเกตใน Lisp มาก่อน และถูกเรียกว่า The Lisp Curse
มันถูกเรียกว่า curse เพราะโปรแกรมเมอร์จะหยุดร่วมมือกัน ทุกคนกลายเป็นพ่อมดที่ขังตัวอยู่ในหอคอยของตัวเอง ความก้าวหน้าโดยรวมก็หยุดและยุคมืดก็มาถึง
ยุค LLM ทำให้เกิด ซอฟต์แวร์ส่วนตัว จริง
แต่พูดตรง ๆ เวลาที่ผมใช้ Emacs ไม่ได้สอนให้ผมสร้างซอฟต์แวร์ส่วนตัวได้เลย คอนฟิก Emacs ของผมเปราะบางมาก และพอพยายามใช้ร่วมกันบน Windows กับ macOS มันกลายเป็นฝันร้าย
โปรเจกต์สมัยมหาวิทยาลัยของผมเขียนด้วยส่วนผสมประหลาดของ org-mode กับ workflow บางอย่างเพื่อสร้างไฟล์ LaTeX ที่สวยงาม ตอนนี้ผมอธิบายไม่ได้แล้วด้วยซ้ำว่าจะ compile มันใหม่ยังไง ถ้าต้องทำคงให้ LLM แปลมันเป็น LaTeX ตรง ๆ ไปเลย
ในชีวิตผม อยากให้มีภาระดูแลรักษาน้อยที่สุดเท่าที่เป็นไปได้ และการทำทุกอย่างเองก็ไม่ได้สอดคล้องกับเป้าหมายนั้นเสมอไป
แต่ผมก็เคยเขียนแอป NETFX ใหม่เป็น Rust เพราะหงุดหงิดกับเวลาติดตั้ง 20 นาที: https://github.com/bevan-philip/wlan-optimizer
งานประจำวันของโปรแกรมเมอร์คือเปลี่ยนพฤติกรรมของระบบคอมพิวเตอร์ ไม่ว่าจะ local, remote, cloud หรือ embedded ข้อกำหนดเปลี่ยน ขอบเขตสั่นไหว problem space วิวัฒน์ และการทับถมเป็นสิ่งหลีกเลี่ยงไม่ได้
เราต้องสลับไปมาระหว่าง language stack, data type, format, CLI กับเว็บทูล, protocol, paradigm, โอเพนซอร์สกับแอป proprietary ตลอดเวลา
เพราะงั้นเราต้องปรับตัวตลอด และ control plane ของตัวเองก็ต้องปรับตามความเปลี่ยนแปลงด้วย หัวใจคือ automation เรื่องน่ารำคาญเล็ก ๆ ทุกอย่างทำให้เป็นอัตโนมัติได้และควรทำด้วย นี่คือการแปลง workflow ไปเรื่อย ๆ หรือก็คือการดูแลรักษาเครื่องมืออย่างต่อเนื่อง แต่ไม่ใช่การบำรุงรักษาเชิงรับที่น่าทรมาน
การเป็นโปรแกรมเมอร์แต่ไม่อยากสร้างซอฟต์แวร์ให้ตัวเองอย่างต่อเนื่องนั้นเป็นภาพลวงตา มันเหมือนเชฟที่เปิดไฟในร้านอาหารได้แต่กลับบ้านแล้วไม่จับมีดเลย
Emacs คือครัวบ้านของเชฟ การบำรุงรักษามีทั้งแบบเชิงรับอย่างซ่อมของพังหรือตามความเปลี่ยนแปลง และแบบเชิงสร้างสรรค์ที่ค่อย ๆ ปั้นเครื่องมือให้เข้ากับความเข้าใจที่พัฒนาไป โปรแกรมเมอร์ควรเกลียดอย่างแรกและถูกดึงดูดโดยอย่างหลัง
Emacs เหมาะกับการบำรุงรักษาเชิงสร้างสรรค์แทบจะเป็นเอกลักษณ์ เพราะเครื่องมือกับงานมีนิสัยแบบเดียวกัน
คนมักบ่นว่า Emacs "ต้องลงทุนกับคอนฟิกเยอะเกินไป" แต่ส่วนใหญ่แปลว่า "ยังไม่อยากลงทุนก่อนจะเห็นคุณค่า" ซึ่งในระยะยาวไม่ใช่กลยุทธ์ที่ฉลาดนัก ควรมอง Emacs เป็นเครื่องมือสารพัดประโยชน์ที่จะลดภาระบำรุงรักษารวมตลอดอาชีพและทั้งชีวิตมากกว่า
คอนฟิก Emacs หรือ VIM เป็นแค่ไฟล์ข้อความธรรมดา เปิดด้วย editor บ้าน ๆ ก็ได้ แก้ให้ตรงกับความต้องการก็ได้ และเรายังรู้ด้วยว่าอะไรอยู่ตรงไหน คอนฟิก VIM ของผมมีอายุ 20 ปีแล้ว เมื่อ 1-2 ปีก่อนเพิ่งเลิกจัดการแพ็กเกจด้วยมือแล้วหันมาใช้ plugin manager เท่านั้น
ตรงนี้ไม่มี gatekeeper และไม่มี dependency
แต่วิธีแบบตอนนี้ต้องจ่ายเงินให้บริษัทภายนอก 20-200 ดอลลาร์ หรือไม่ก็ต้องมี GPU ที่แรงพอสมควรสำหรับรัน local แล้วก็ต้องเขียนคำสั่งลงในไฟล์ข้อความและคอยแก้ไปเรื่อย ๆ จนกว่าจะได้อย่างที่ต้องการ
มันคือการเพิ่ม dependency ให้ตัวเอง และถ้ามันพันกันยุ่งจนมนุษย์รีวิวลำบาก dependency นั้นก็จะกลายเป็น dependency แบบหนัก ไม่ว่าจะเป็น GPU ราคาแพงหรือการส่งข้อมูลไปให้บริษัทที่ต้องทำให้ผู้ถือหุ้นพอใจก็ตาม
เราต้องแยกให้ออกว่าสองอย่างนี้ต่างกันอย่างไร และต้นทุนจริงที่เราจ่ายคืออะไร
แนวคิดเรื่อง ซอฟต์แวร์ส่วนตัว หรือการเขียนโปรแกรมเพื่อตัวเองนั้น เป็นวิสัยทัศน์ดั้งเดิมของคอมพิวเตอร์ในบ้านตั้งแต่ยุค 1960
ตอนนั้นยังไม่ได้ทำนาย PC ไว้ตรง ๆ แต่มีแนวคิดว่าทุกคนจะมี terminal คอมพิวเตอร์ที่บ้านและเขียนโปรแกรมเพื่อทำงานที่ตัวเองต้องการ เขาจินตนาการว่าการเขียนโปรแกรมจะง่ายจนใคร ๆ ก็เรียนได้
เรายังไปไม่ถึงจุดนั้น แต่ LLM กำลังพาเราเข้าใกล้ขึ้น
คือแนวคิดที่ว่าคนที่ไม่ใช่มืออาชีพสามารถสร้างซอฟต์แวร์น่าสนใจได้ในสภาพแวดล้อมแบบ authoring ที่มีองค์ประกอบที่ออกแบบมาดีและมีอุปมาอุปไมยที่เข้าใจง่าย โดยตัดชั้นของความซับซ้อนที่เกิดโดยบังเอิญหรือออกแบบเกินจำเป็นออกไป
แม้ในวิสัยทัศน์นี้ ซอฟต์แวร์ก็ยังต้องการการคิดเชิงตรรกะอย่างรอบคอบ แต่ความยุ่งยากในการแปลงความคิดนั้นให้เป็นโค้ดที่รันได้จะลดลงมาก และไม่มีฝันร้ายเรื่อง toolchain กับ build system ด้วย
แต่แทนที่จะไปทางนั้น เรากลับสร้างโมเดลที่ทรงพลังเกินไปให้มาคอยท่องคำสั่งที่ซับซ้อนแทนเราและนำมาผสมใหม่ ทว่า ความซับซ้อนยังคงอยู่ และยังทึบสำหรับคนที่ไม่ใช่มืออาชีพ
ถึงอย่างนั้น LLM ก็อาจช่วยลบความซับซ้อนนั้นออกไปได้บางส่วน ทิศทางที่บุคคลทั่วไปเข้าใจซอฟต์แวร์ที่ LLM สร้างได้ง่ายและแก้ไขเองได้ยังเป็นไปได้อยู่ และน่าจะเสริมกับโลกของ LLM ได้ดีด้วย
นี่ไม่ใช่คำถามว่าจะเป็นไปได้ไหม แต่เป็นเรื่องของเวลา อย่างนานก็ 10 ปี และน่าจะเร็วกว่านั้นมาก ตอนนี้ญาติที่เขียนโค้ดไม่เป็นของผมก็ทำแบบนี้กันอยู่แล้ว
อนาคตของการใช้คอมพิวเตอร์แบบนี้ช่างน่ารักจริง ๆ และเป็นทิศทางที่เสริมพลังอย่างมหาศาล
ตอนนี้แอป Swift มี 15,000 บรรทัด โดยเป็นเทสต์ 5,000 บรรทัด และ implementation 10,000 บรรทัด มันเกือบเสร็จแล้วและทำงานที่ต้องการได้ ใช้เวลา 20 ชั่วโมง
ถ้าต้องทำเองโดยไม่เคยจับ Swift มาก่อน ส่วนตัวผมว่าคงใช้ 500 ชั่วโมง
พวกเราส่วนใหญ่น่าจะขี้เกียจเกินกว่าจะไปไกลขนาดนั้น แต่ก็เป็นเรื่องที่ควรคิดไว้
แนวคิดของตัวแอปพลิเคชันเองจะลื่นไหลขึ้นมาก
ถ้าแอปถูกสร้างด้วยภาษาที่เป็น dynamic language ก็ไม่มีเหตุผลอะไรที่จะห้ามผู้ใช้เขียนโค้ดทับเองและเพิ่มฟีเจอร์ใหม่หมดจด
ไม่ได้เกี่ยวกับเนื้อหาบทความโดยตรงนัก แต่ผมไม่เห็นด้วยกับความเห็นที่ว่าเทอร์มินัลซึ่งเกือบตลอดเวลาเป็น fixed-width นั้นทำให้อ่านงานเขียนยาว ๆ แล้วเหนื่อย สำหรับผม การอ่านงานเขียนยาวด้วย ฟอนต์ fixed-width สบายกว่ามาก
ผู้เขียนชี้ประเด็นที่น่าสนใจ ตัวแปรที่มีผลคือความยากในการ สร้าง เครื่องมือ ความยากในการเผยแพร่ ประโยชน์ที่มันให้คนอื่นได้ ผลตอบแทนทางสังคมเมื่อเผยแพร่ และแรงจูงใจทางลบจากการเพิ่ม dependency
ความยากในการหาโซลูชันสำเร็จรูปจะเพิ่มขึ้นตามต้นทุนที่ใครสักคนต้องจ่ายเพื่อสร้างมัน และต้นทุนที่ใครสักคนต้องจ่ายเพื่อหาวิธีเผยแพร่มัน ในทางกลับกัน ยิ่งมันมีประโยชน์ต่อชุมชน คนก็จะยิ่งบอกต่อ ทำให้หาเจอง่ายขึ้น
ถ้าความยากในการสร้างกับความยากในการเผยแพร่ต่างกันมาก โดยเฉพาะเมื่อฝั่งสร้างสูงกว่ามาก คนก็มักจะลงมือสร้างเองแล้วลืมมันไป ถ้าฝั่งเผยแพร่ต่ำ จำนวนวิธีแก้ปัญหาก็จะยิ่งน้อยลง
ถ้าทั้งสองอย่างต่ำ และประโยชน์ต่อคนอื่นกับผลตอบแทนทางสังคมสูงกว่าต้นทุนของ dependency ก็จะเกิดสถานการณ์แบบ leftpad แพ็กเกจจำนวนมากใน NPM อยู่ในจุดที่ประโยชน์และผลตอบแทนสูง ขณะที่ต้นทุน dependency ต่ำ
ใน Emacs Lisp สมัยก่อนความยากในการสร้างสูง แต่ตอนนี้ต่ำ และถ้าผ่าน learning curve ไปได้ ความยากในการเผยแพร่ก็ต่ำด้วย ประโยชน์ ผลตอบแทน และต้นทุน dependency ก็ไม่ได้สูงไปทางไหนมาก
แบบนี้เลยเกิดสถานการณ์ที่คนลงมือสร้างเองก่อนจะค้นหาด้วยซ้ำว่ามีเครื่องมืออยู่แล้วหรือไม่ ส่วน VSCode หรือ Eclipse ยุคก่อนต่างออกไปเพราะความยากในการเผยแพร่สูง
ผมว่าอีกไม่นานคงมีคนที่อายุน้อยกว่าผมเอาเรื่องนี้ไปทำเป็น หัวข้องานวิจัย แล้วปล่อยสู่โลก
บทความนี้บอกเป็นนัยถึงความเปลี่ยนแปลงอย่างหนึ่งของ LLM coding ที่ยังไม่เกิดขึ้นจริงเต็มที่ นั่นคือเราอาจจะทิ้ง Electron/React Native แล้วให้ LLM แปลง Figma, wireframe และสเปกพฤติกรรม ไปเป็นแอป native จริงของแต่ละแพลตฟอร์มได้หรือเปล่า?
ถ้าเป็นแอป CRUD แค่มีสเปก API กับ UI mockup หรือแม้แต่ภาพหน้าจอของแพลตฟอร์มที่ทำไปแล้ว ก็น่าจะไปได้ไกลมาก งานแบบกำหนดขอบเขตชัดเจนนี้เป็นงานที่ LLM ทำได้ดี และการทดสอบความเท่าเทียมกันก็น่าจะทำอัตโนมัติได้พอสมควร
ข้ออ้างอย่าง "สักวันอาจเพิ่ม Android" หรือ "ผู้ใช้ Mac/Linux ไม่มากพอ" จะยังใช้ได้อยู่ไหม? หรือการที่แอป iOS ไม่ทำ flow ที่ใช้น้อยอย่างรีเซ็ตรหัสผ่าน แล้วเด้ง WebView แปลก ๆ ขึ้นมา จะยังพออ้างได้อยู่หรือเปล่า?
แม้แต่แอปที่มี logic ในอุปกรณ์แบบไม่ใช่แค่เรื่องเล็ก ๆ LLM ก็แสดงศักยภาพพอสมควรแล้วในการเขียนใหม่เป็นภาษาอย่าง Go หรือ Rust ที่ cross-compile ง่าย
ถ้าจะพูดให้แรงกว่านั้น ตอนนี้ยังมีเหตุผลอะไรให้เรียน SwiftUI อยู่หรือ? สำหรับงานส่วนใหญ่ ความเชี่ยวชาญ SwiftUI อยู่ในหมวดเดียวกับ "การเรียน Microsoft Word ให้ลึกมาก ๆ"
ผมเคารพคนที่ทุ่มเวลาไปทางนั้น แต่ไม่ว่าจะทำหรือไม่ทำ ความต่างของผลลัพธ์ก็ดูจะระดับไม่กี่มิลลิเมตร
ไม่ได้หมายความว่าผมคิดแบบนั้นกับการเขียนโปรแกรมทั้งหมดนะ แค่รู้สึกว่าตอนนี้บางภาษามีเหตุผลให้เชี่ยวชาญแบบเฉพาะทางที่ซับซ้อนขึ้นกว่าเดิม