nokode - ถ้า LLM ทำได้ทุกอย่าง แล้วทำไมเรายังต้องเขียนโค้ด? (การทดลองเว็บแอป)

• การทดลองสร้าง เว็บเซิร์ฟเวอร์ที่ไม่มีแอปพลิเคชันลอจิกเลยแม้แต่น้อย เพื่อให้ LLM จัดการทุกคำขอทั้งหมด
  • เซิร์ฟเวอร์เพียงรับ HTTP request แล้วถาม LLM ว่า “ต้องทำอะไร?” จากนั้นให้ LLM จัดการส่วนที่เหลือทั้งหมด
• เซิร์ฟเวอร์ใช้เพียง 3 เครื่องมือคือ database, webResponse, updateMemory เพื่อทำฟังก์ชัน CRUD
• LLM ทำได้เองตั้งแต่ ออกแบบ SQL schema, สร้าง HTML·JSON, ไปจนถึงนำ feedback มาปรับใช้ และสามารถสร้างแอปจัดการรายชื่อผู้ติดต่อพื้นฐานได้
• ความเร็วตอบสนองอยู่ที่ 30~60 วินาที ต้นทุน สูงกว่าเว็บแอปแบบดั้งเดิม 100~1000 เท่า และยังมีปัญหาเรื่องความสม่ำเสมอของ UI กับความจำ
• ถึงอย่างนั้นก็ยังแสดงให้เห็นว่า สามารถสร้างแอป CRUD ที่ทำงานได้ครบโดยไม่ต้องมีโค้ด และชี้ว่าโค้ดอาจเป็นแนวคิดแบบช่วงเปลี่ยนผ่านเท่านั้น

---

ที่มา

• เริ่มต้นจาก ไอเดียลอย ๆ (Shower Thought) ว่า “สักวันหนึ่งเราอาจไม่จำเป็นต้องเขียนโค้ดอีกต่อไป”
  • ในอนาคต LLM อาจ ประมวลผลอินพุตแบบเรียลไทม์และส่งออกวิดีโอ 120fps จนเกิด คอมพิวติ้งที่ขับเคลื่อนด้วยเจตนาอย่างบริสุทธิ์ โดยไม่มีทั้งแอปและโค้ด
• แม้ในความเป็นจริงตอนนี้ยังเป็นเรื่องในระดับ นิยายวิทยาศาสตร์ แต่ผู้เขียนก็ตัดสินใจลองทดสอบเล่น ๆ ในช่วงสุดสัปดาห์ว่า “เทคโนโลยีปัจจุบันไปได้ไกลแค่ไหน”
• สมมติฐาน ของการทดลองเริ่มต้นจากการคาดไว้อยู่แล้วว่าอาจล้มเหลว
  • ขณะที่ AI ส่วนใหญ่เน้นไปที่ การสร้างโค้ด (เช่น Claude Code, Cursor, Copilot ฯลฯ)
    จึงลองสร้างโปรเจกต์นี้ขึ้นมาเพื่อทดสอบอีกมุมมองว่า “ถ้าตัดขั้นตอนการสร้างโค้ดออกไปทั้งหมดจะเป็นอย่างไร?”
• ผลลัพธ์คือสามารถสร้าง HTTP server ที่ไม่มีทั้ง route, controller หรือ business logic เลย และให้ทุกคำขอทำงานด้วยการถาม LLM ว่า “ต้องทำอะไร?”
• เป้าหมายของการทดลองคือพิสูจน์ว่า “อนาคตแบบนั้นยังอยู่อีกไกลแค่ไหน”

ภาพรวมโปรเจกต์

• nokode คือการทดลองที่สร้าง “เว็บเซิร์ฟเวอร์ที่ไม่มีแอปพลิเคชันลอจิก” เพื่อทดสอบโครงสร้างที่ให้ LLM จัดการทุกคำขอ
  • เซิร์ฟเวอร์เพียงรับ HTTP request แล้วถาม LLM ว่า “ต้องทำอะไร?” จากนั้นให้ LLM ทำส่วนที่เหลือทั้งหมด
• เป้าหมายคือพิสูจน์ว่า LLM สามารถทำแอปพลิเคชันลอจิกได้โดยตรงโดยไม่ต้องสร้างโค้ดก่อนหรือไม่
• สิ่งที่ใช้ทดลองคือ แอปจัดการรายชื่อผู้ติดต่อ (contact manager) ที่มีฟังก์ชัน CRUD พื้นฐาน (เพิ่ม, ดู, แก้ไข, ลบ)

โครงสร้างระบบ

• ฝั่งแบ็กเอนด์ประกอบด้วยเครื่องมือเพียง 3 ตัว
  • database: รัน SQL บน SQLite โดยให้ LLM ออกแบบ schema เองโดยตรง
  • webResponse: สร้าง response ในรูปแบบที่เหมาะสม เช่น HTML, JavaScript, JSON
  • updateMemory: เก็บ feedback ของผู้ใช้เป็น Markdown เพื่ออ้างอิงในการร้องขอครั้งถัดไป
• ตัวอย่างเช่น เมื่อเรียก /contacts จะสร้างหน้า HTML และเมื่อเรียก /api/contacts จะสร้าง JSON response
• ทุกหน้ามี feedback widget ติดมาด้วย ทำให้สามารถขอเช่น “ขยายปุ่มให้ใหญ่ขึ้น”, “เปลี่ยนเป็นธีมมืด” แล้วสะท้อนผลได้ทันที

ผลการทดลอง

• ในเชิงฟังก์ชันถือว่าทำงานได้สำเร็จ
  • การส่งฟอร์ม, การบันทึกข้อมูล, การแสดงผล UI, การตอบกลับ API ล้วนทำงานได้ตามปกติ
  • แม้ไม่มีตัวอย่างให้ LLM ก็ยังสามารถสร้าง database schema ที่เหมาะสม, SQL ที่ปลอดภัย, REST-style API, responsive layout, form validation, และ error handling ได้
• ปัญหาด้านประสิทธิภาพ
  • ใช้เวลา 30~60 วินาทีต่อคำขอ ช้ากว่าเว็บแอปทั่วไป (10~100ms) ราว 300~6000 เท่า
  • มีต้นทุน $0.01~0.05 ต่อคำขอ จึง แพงกว่า 100~1000 เท่า
  • มีความไม่สอดคล้องกันของสีและเลย์เอาต์ UI, จำสถานะก่อนหน้าไม่ได้, และหากสร้าง SQL ผิดก็จะเกิดข้อผิดพลาดทันที
  • การลองปรับแต่งพรอมป์ต์ด้วยข้อความอย่าง “⚡ THINK QUICKLY” กลับยิ่งทำให้ช้าลง

บทสรุปและนัยสำคัญ

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

วิธีรัน

• รัน npm install แล้วตั้งค่า provider ของ LLM และ API key ในไฟล์ .env
• รัน npm start แล้วเข้า http://localhost:3001 (คำขอแรกใช้เวลา 30~60 วินาที)
• สามารถแก้ prompt.md เพื่อเปลี่ยนประเภทแอปหรือฟังก์ชันได้
  • ลองเส้นทางอย่าง /game, /dashboard, /api/stats ได้
  • และพิมพ์ feedback เช่น “make this purple”, “add a search box” เพื่อให้ระบบสะท้อนผลทันที
• ต้นทุนต่อคำขออยู่ราว $0.001~0.05 ขึ้นอยู่กับโมเดล
• เผยแพร่ภายใต้ MIT License

[aer0700]

ประเด็นคงอยู่ที่ว่าพลังการประมวลผลจะเร็วขึ้นและถูกลงได้ไกลแค่ไหน
หากเป็นอนาคตที่เซิร์ฟเวอร์ทั่วไปเร็วขึ้นกว่าตอนนี้ 100,000 เท่า แต่ค่าใช้จ่ายในการดำเนินงานหรือติดตั้งยังเท่าเดิม แบบนั้นแนวทางนี้ก็น่าจะใช้ได้เหมือนกัน
เหมือนกับที่เมื่อการประมวลผลถูกลง เราก็ย้ายจากภาษาเครื่องมาเป็น c และจาก c ไปเป็น node js หรือ python ต่อไปในอนาคตก็อาจย้ายไปเป็น llm ก็ได้
หลายอย่างคงจะเปลี่ยนไป และก็น่าจะน่าสนุกในแบบของมันเอง น่าจะมีโอกาสใหม่ ๆ เกิดขึ้นด้วย

[GN⁺]

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

• ฉันก็คิดคล้าย ๆ กันมาสักพักแล้ว

  1. ถ้า การสร้างโค้ด ถูกทำให้เป็นอัตโนมัติเต็มรูปแบบจนทุกการค้นหาใน Google สร้างหน้าแบบปรับแต่งเฉพาะได้แบบเรียลไทม์ งั้นก็ไม่จำเป็นต้องมีคนสร้างเว็บไซต์อีกต่อไปไม่ใช่หรือ? ถึงจุดนั้นแล้ว “การพัฒนาเว็บ” ก็คงจะใกล้กับการ ออกแบบเจตนา(intent-shaping) มากกว่าการเขียนโค้ด
  2. อีกอย่าง ฉันไม่เห็นด้วยกับข้ออ้างที่ว่าการแชตคือรูปแบบอุดมคติของส่วนติดต่อผู้ใช้ ภาษาธรรมชาติมีความยืดหยุ่นก็จริง แต่ช้า กำกวม และเพิ่มภาระทางความคิด น่าจะเป็นไปได้ว่าระบบที่อิง LLM จะต้องการ โมเดล UI แบบใหม่ที่ผสานทั้งการสนทนาและการโต้ตอบแบบมีโครงสร้าง

• ฉันเริ่มคิดเรื่องนี้ครั้งแรกตอนที่ ChatGPT 3.5 ออกมา
  สักวันหนึ่ง AI อาจแทนที่โปรแกรมได้ทั้งหมดก็ได้ แต่แก่นสำคัญจริง ๆ คือการหา นามธรรม(abstraction) ที่ถูกต้อง
  ตัวอย่างเช่น การเปลี่ยนจาก CVS ไปเป็น Git เปิดทางให้ยุคของไมโครเซอร์วิส เช่นเดียวกัน นามธรรมที่ดีมีพลังในการเปลี่ยนปัญหาไปถึงระดับรากฐาน
  ถ้า LLM จะค้นพบนามธรรมแบบนี้ได้ด้วยตัวเอง ก็ต้องเรียนรู้ผ่านการปฏิสัมพันธ์กับโลกจริงเป็นเวลานาน

• ถ้าเพิ่มเครื่องมือให้ LLM แก้ไขไฟล์โค้ดได้โดยตรง ก็น่าจะช่วยให้ความเร็วในการตอบสนองและ ความสม่ำเสมอ ดีขึ้นมาก
  โค้ดจะกลายเป็นเหมือน หน่วยความจำ(memory) รูปแบบหนึ่ง
  การส่ง HTTP request ตรงไปที่ LLM ก็คล้าย cache miss และยังสามารถคงกลไก feedback ที่ไป trigger การอัปเดตโค้ดได้ด้วย

  • นี่เป็นแค่การทดลองง่าย ๆ และตั้งใจจะชี้ให้เห็นว่ายังมี คอขวด อยู่มาก
    ยังมีพื้นที่ให้ปรับแต่งอีกเยอะ แต่ในโลกความเป็นจริง วิธีเขียนโค้ดแบบดั้งเดิมก็น่าจะยังมีประสิทธิภาพกว่ามาก
  • โครงสร้างแบบนี้เหมือนการปลูก เมล็ด(seed) ที่กำหนดทิศทางการเติบโตและขอบเขต
  • อยากให้ลองสร้างกันดูโดยตรง

• มันฟังดูเหมือนคำถามว่า “ถ้าพฤติกรรมแบบ ไม่กำหนดตายตัว(non-deterministic) เป็นไปได้ แล้วทำไมต้องยึดให้เป็นแบบกำหนดตายตัวด้วย?”
  แต่คนส่วนใหญ่น่าจะไม่อยากได้เว็บแอปที่ทำงานต่างกันทุกครั้ง

  • จริง ๆ แล้วสิ่งที่ผู้คนต้องการไม่ใช่ “เว็บแอป” เอง แต่คือ วิธีแก้ปัญหา(solution)
    โค้ดแบบกำหนดตายตัวมีข้อจำกัดเมื่อใช้รับมือปัญหาที่ซับซ้อน และแนวทางที่ยืดหยุ่นแบบมนุษย์อาจเหมาะกว่า
  • LLM ในตอนนี้ยังถูกจำกัดอยู่กับ การสร้างข้อความ เป็นหลัก และแทบไม่มีหน่วยความจำระยะยาว
    แต่ในอนาคต LLM จะมี ความสามารถด้านเอาต์พุตและการจัดเก็บ ที่สมบูรณ์ขึ้น
    ตัวอย่างเช่น LLM อาจสร้างลิงก์ขึ้นมาเอง แล้วเมื่อคลิกก็ไป query ภายในอีกครั้ง หรือทำงานด้วยการจัดการฐานข้อมูลชั่วคราว
  • เจตนาของฉันไม่ใช่ว่าพฤติกรรมไม่กำหนดตายตัวนั้นดีกว่า แต่เพื่อแสดงให้เห็นช่องว่างระหว่างปัจจุบันกับยุค post-code
  • จริง ๆ แล้วซอฟต์แวร์ในทุกวันนี้ก็ไม่ได้กำหนดตายตัวอย่างสมบูรณ์
    ประสบการณ์ผู้ใช้เปลี่ยนไปเรื่อย ๆ จาก auto-update, A/B test, การเปลี่ยน UX และอื่น ๆ
  • ถ้าตั้งค่า temperature เป็น 0 และให้ LLM บันทึกการตั้งค่าลงไฟล์ในเครื่อง ก็สามารถสร้าง แอปแบบกำหนดตายตัว ได้เหมือนกัน

• ที่น่าสนใจคือ แนวทางนี้ ทำงานได้ด้วย context window เพียงอย่างเดียว โดยไม่ต้องมีเครื่องมือแยก
  ในเดือนกรกฎาคม 2025 ฉันได้ ทำ POC ไว้แล้ว

• การทดลองนี้แสดงให้เห็นได้ดีว่าแนวคิดของ “boilerplate code” อาจเปลี่ยนไปอย่างไร
  ถ้ารันหลายอินสแตนซ์พร้อมกันในแซนด์บ็อกซ์ แล้วใช้การประเมินภายในเพื่อเลือกผลลัพธ์ที่ทำได้ดีที่สุด มันก็จะกลายเป็น meta reinforcement learning รูปแบบหนึ่ง
  แต่ปัญหาคือการแปลงเจตนาของผู้ใช้ให้เป็นเอาต์พุตแบบกำหนดตายตัวนั้นยาก ขณะที่แอปแบบดั้งเดิมก็ขาดความยืดหยุ่น
  สุดท้ายแล้วหัวใจสำคัญคือจะทำ การประเมินเจตนา(intent evaluation) ให้เสถียรได้อย่างไร

  • แต่ก็มีความเสี่ยงที่โมเดลจะ overfit เข้ากับวิธีประเมินภายใน
    การสร้างวิธีประเมินที่ดีนั้นซับซ้อนไม่แพ้การสร้างโมเดล AI เอง

• การประมวลผลคำขอด้วยวิธีดั้งเดิมมี ความคุ้มค่าด้านต้นทุน สูงกว่าการใช้ LLM โดยตรงมาก
  โดยคร่าว ๆ แล้ว โมเดลขนาด 7 พันล้านพารามิเตอร์ต้องใช้มากกว่า 100 GFLOPs เพื่อสร้าง 10 โทเค็น
  มันสิ้นเปลืองพลังงานมาก

  • แต่ฉันก็คิดว่าเราควรนับ ต้นทุนพลังงาน ของแรงงานมนุษย์เข้าไปด้วยหรือเปล่า
    ถ้าทำงานในสาย enterprise IT จะเห็นว่าความไร้ประสิทธิภาพของมนุษย์เองก็ไม่น้อย
  • ทิศทางของอุตสาหกรรมไม่ได้สอดคล้องกับการปรับให้เหมาะที่สุดเสมอไป
    ในความเป็นจริง แม้แต่ ความไร้ประสิทธิภาพก็ยังกลายเป็นเทรนด์ ได้
  • ถึงอย่างนั้น การใช้ LLM เพื่อทำ ต้นแบบ(V1) อย่างรวดเร็ว จากนั้นค่อยตรวจสอบ product-market fit แล้วจึง optimize ด้วยโค้ดแบบดั้งเดิม ก็ยังเป็นแนวทางที่ใช้ได้

• หรืออาจแค่เอา LLM ไปวางบน port 443 แล้วสั่งว่า “คุณคือ HTTPS server และ app server” ก็พอ ;)

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

  • แต่ระบบอัตโนมัติแบบนี้อาจบั่นทอน ความเป็นผู้กระทำการ(agency) ของมนุษย์
    ท้ายที่สุดแล้วมนุษยชาติน่าจะแบ่งออกเป็นคนที่ยอมรับกับคนที่ปฏิเสธมัน
    เราเริ่มเห็นสัญญาณนั้นแล้วจากปรากฏการณ์อย่างการกลับมาของแผ่นเสียงไวนิล
  • อินเทอร์เฟซเสียงไม่ใช่คำตอบของการสื่อสารทุกแบบ
    แม้แต่มนุษย์ด้วยกันเองก็ยังมักชอบ ข้อความ มากกว่าในหลายกรณี
  • สัปดาห์นี้ฉันเองก็ลองใช้ WebSpeech ทำแอปจัดการความรู้ส่วนตัวที่รับเสียงพูด แล้วอ่านและแก้ไขไฟล์ org-mode กับ logseq
    ใช้จัดการงานที่ต้องทำ รายการซื้อของ ตารางเวลา ได้ครบ และปรับแต่งให้ตรงกับความต้องการของฉันได้ทั้งหมด
  • อนาคตแบบนี้ถูกพูดถึงบ่อยใน นิยายวิทยาศาสตร์
    งานที่ซับซ้อนสามารถอธิบายผ่านเสียงได้เพียงพอ แต่สำหรับงานง่าย ๆ ที่ต้องทำซ้ำ UI จะมีประสิทธิภาพกว่า
    เช่น ถ้าพูดว่า “ซื้อกางเกงให้หน่อย” พอต้องเลือกหนึ่งอย่างจากผลลัพธ์ 30 รายการ สุดท้ายก็ยังต้องมีอินเทอร์เฟซแบบมองเห็น

• ฉันก็เคยอัปโหลด PoC คล้ายกันไว้บน GitHub
  ช่วงแรกใช้ ‘design model’ ที่ช้าในการสร้างธีมแอปและ DB schema จากนั้นค่อยใช้โมเดลที่เร็วกว่าเพื่อจัดการการตอบสนอง
  ฉันลองใช้ PostREST เพื่อย้าย logic ไปไว้ใน DB แต่ก็มักเกิดปัญหาทั้งสร้าง schema ไม่สำเร็จและสร้าง query ผิด
  ใช้ไลบรารี CSS เพื่อรักษาความสม่ำเสมอของ UI และทำให้จำหน้าก่อนหน้าได้
  แนวทางนี้น่าจะใช้เป็น App Bench เพื่อประเมินว่า LLM สามารถสร้างแอปที่สมบูรณ์ได้ในครั้งเดียวหรือไม่