7 คะแนน โดย chebread 2026-01-29 | 12 ความคิดเห็น | แชร์ทาง WhatsApp

บทนำ

สวัสดีครับ ผมเป็นนักศึกษาที่สนใจวิศวกรรมคอมพิวเตอร์ ครั้งนี้ผมได้พัฒนาโปรแกรมชื่อ lx และอยากลองโพสต์ครั้งแรกบน GeekNews ที่ก่อนหน้านี้มีแต่เป็นผู้อ่านอย่างเดียว

ช่วงนี้ไวบ์โค้ดดิ้งที่สั่ง AI ด้วยภาษาธรรมชาติแล้วให้มันเขียนโค้ดให้ทั้งหมดกำลังเป็นกระแส
ผมรู้สึกกลัวไวบ์โค้ดดิ้งแบบนี้
ไม่ใช่แค่ความกลัวเรื่องตกงานเท่านั้น แต่เป็นความสูญเสียในเชิงการเขียนโปรแกรมจากการถูกพรากไปทั้ง "ความสนุกของการเขียนโค้ด (Wrangling code) (ที่มา: Kent Beck - Augmented Coding: Beyond the Vibes)" และ "อำนาจการควบคุมของนักพัฒนา"

บางคนบอกว่าการเปลี่ยนแปลงครั้งนี้เป็นวิวัฒนาการตามธรรมชาติของการเขียนโปรแกรมที่ต่อเนื่องมาตั้งแต่บัตรเจาะรู สู่ภาษาเครื่อง แอสเซมบลี และภาษา C แต่ผมคิดว่าอุปมานี้ไม่ถูกต้อง
ในอดีต การสร้าง abstraction คือกระบวนการที่มอบ 'ค้อนที่ดีกว่า' ให้กับนักพัฒนา
แม้เครื่องมือจะพัฒนาอย่างต่อเนื่อง แต่ผู้ที่เหวี่ยงค้อนก็ยังคงเป็นมนุษย์ และผลลัพธ์ก็ยังอยู่ภายใต้การควบคุมของนักพัฒนาอย่างสมบูรณ์
แต่ AI coding ในปัจจุบันแตกต่างออกไป
ตอนนี้หุ่นยนต์เป็นฝ่ายเหวี่ยงค้อนแทน ส่วนนักพัฒนากลายเป็นเพียงคนดู หรืออย่างมากก็ทำได้แค่พยายามเกลี้ยกล่อมหุ่นยนต์เล็กน้อย
ถ้าเราไม่สามารถเหวี่ยงค้อนเองได้ ผมคิดว่าสิ่งนั้นก็ไม่อาจเรียกได้ว่าเป็นการเขียนโปรแกรมอีกต่อไป
เพราะมันไม่ได้อยู่ภายใต้การควบคุมของเราอย่างแท้จริง

ด้วยเหตุนี้ ผมจึงสร้าง lx ขึ้นมา
lx คือเครื่องมือที่แย่งค้อนกลับมาจากหุ่นยนต์แล้วส่งคืนสู่มือของนักพัฒนา
lx ช่วยให้สามารถใช้ AI เป็นเครื่องมือที่ควบคุมได้อย่างเข้มงวด

เนื้อหา

lx มีปรัชญาว่า "อินเทอร์เฟซเป็นของมนุษย์ ลอจิกเป็นของ AI"
นักพัฒนาจะกำหนดอินพุต/เอาต์พุตของฟังก์ชันและหน้าที่ของฟังก์ชันเพื่อสร้าง 'สัญญา' ขึ้นมา แล้ว AI จะรับผิดชอบเฉพาะการ implement ภายในฟังก์ชันนั้น

แนวทางนี้ช่วยรับประกันความต่อเนื่องของการพัฒนา
ทันทีที่เขียนอินพุต/เอาต์พุตของฟังก์ชัน ลอจิกนั้นก็ถือว่าเสร็จสมบูรณ์แล้ว
โปรแกรมเมอร์จึงสามารถเขียนลอจิกระดับบนต่อได้ทันทีโดยไม่ต้องจมอยู่กับรายละเอียดของการ implement และคง flow ของการพัฒนาไว้ได้อย่างไม่สะดุด

อีกทั้ง lx ไม่ใช่แค่การแทนที่ข้อความแบบง่าย ๆ แต่ใช้แพ็กเกจ github.com/tree-sitter/go-tree-sitter เพื่อ parse ซอร์สโค้ดโดยอิงกับ AST (Abstract Syntax Tree) ดังนั้นจึงไม่ทำให้โค้ดอื่นในไฟล์ คอมเมนต์ หรือ indentation ปนเปื้อน และจะเปลี่ยนเฉพาะลอจิกใน scope ที่ระบุอย่างปลอดภัยเท่านั้น

วิธีใช้งานพื้นฐาน

รูปแบบพื้นฐานของการใช้ lx มีดังนี้

package main  
  
import (  
	"fmt"  
  
	lx "github.com/chebread/lxgo"  
)  
  
func main() {  
	var year string = "2025-01-02"  
    // นักพัฒนาควบคุมจุดเรียกฟังก์ชันและ flow  
	result1 := LX_GetYear(year)  
  
	var age = 30  
	result2 := LX_GetAge(age)  
  
	fmt.Println(result1, result2)  
}  
  
func LX_GetYear(year string) (result string) {  
	// พรอมป์ต์ที่จะส่งให้ AI  
	lx.Generate("แปลงรูปแบบ yyyy-dd-mm เป็นวันที่แบบเกาหลี")  
	return  
}  
  
func LX_GetAge(year int) (result string) {  
	// สำหรับกรณีที่ไม่อยากเสียเวลาติดตั้งไลบรารี lx แยกตามภาษาโปรแกรม ก็รองรับรูปแบบคอมเมนต์มาร์กเกอร์ lx() แบบด้านล่างด้วย  
    // lx("แปลงอายุแบบเกาหลีเป็นอายุสากล")  
	return  
}  

ในโค้ดด้านบน ฟังก์ชัน LX_GetYear คือสัญญาที่นักพัฒนากำหนดไว้
เมื่อรันเครื่องมือ lx เครื่องมือจะตรวจจับมาร์กเกอร์ lx.Generate(...) หรือ // lx(...) ส่งพรอมป์ต์ไปยัง LLM แล้วเขียนทับ body ของฟังก์ชันนั้นด้วยโค้ดที่ทำงานได้จริง

ในขั้นตอนนี้มีการปรับแต่ง token optimization ด้วย โดยจะไม่ส่งทั้งไฟล์ แต่ส่งเฉพาะ signature ของฟังก์ชันและพรอมป์ต์ไปยัง LLM เพื่อลดต้นทุนและเพิ่มความปลอดภัย

2. การควบคุมของนักพัฒนา

แม้ลอจิกภายในฟังก์ชัน lx จะถูกเขียนโดย AI แต่ผู้ที่ใช้งานฟังก์ชันนั้นควรเป็นนักพัฒนา
อย่างไรก็ตาม หากผสมลอจิกที่ผู้ใช้กำหนดเองไว้ภายในฟังก์ชัน lx มันจะถูกมองข้าม ดังนั้นจึงสามารถควบคุมได้ผ่าน wrapper function ดังตัวอย่างด้านล่าง

package test  
  
import (  
	"fmt"  
	lx "github.com/chebread/lxgo"  
)  
  
func main() {  
	var year string = "2025-01-02"  
	result1 := ParseYear(year) // เรียก wrapper function  
  
	fmt.Println(result1)  
}  
  
// business logic ที่นักพัฒนาควบคุม  
func ParseYear(year string) string {  
    // ใช้ลอจิกที่ AI สร้างขึ้นเหมือนเป็นชิ้นส่วนหนึ่ง  
	res := LX_GetYear(year)  
    
    // การประมวลผลเพิ่มเติมของผลลัพธ์เป็นหน้าที่ของนักพัฒนา  
	foo := fmt.Sprintf("วันนี้คือ %v!", res)  
	return foo  
}  
  
func LX_GetYear(year string) (result string) {  
	lx.Generate("แปลงรูปแบบ yyyy-dd-mm เป็นวันที่แบบเกาหลี")  
	return  
}  

3. การจัดการ dependency อย่างปลอดภัยและความโปร่งใส

lx มุ่งตามหลัก Single Responsibility Principle (SRP)
มันทำหน้าที่เพียงสร้างโค้ดเท่านั้น ไม่ได้ build หรือรันโปรแกรม
และหากโค้ดที่ AI สร้างต้องการ external library lx ก็จะไม่ติดตั้งแพ็กเกจให้เองโดยพลการ

  1. Code: ระบุคอมเมนต์ // lx-dep: ... ไว้ด้านบนของโค้ดที่สร้าง

  2. Output: รายงานรายการที่ต้องติดตั้งผ่าน standard output ของ CLI

แต่จะรายงานให้นักพัฒนาทราบด้วยสองวิธีนี้แทน
นักพัฒนาสามารถตรวจสอบแล้วตัดสินใจเองว่าจะติดตั้ง dependency เหล่านั้นหรือไม่

4. การตั้งค่า

หากต้องการใช้ lx จำเป็นต้องตั้งค่า LLM โดยสร้าง lx-config.yaml ไว้ใน home directory (~/) หรือ project root (./) หากมีไฟล์อยู่ทั้งสองตำแหน่ง ระบบจะใช้ไฟล์ตั้งค่าแบบ local ก่อน ดังนั้นจึงสามารถจัดการการตั้งค่า lx แยกกันในแต่ละโปรเจกต์ได้

# lx-config.yaml  
provider: "gemini"  
api_key: "foo"  
model: "bar"  

5. การติดตั้งและการรัน

ผู้ใช้ Mac สามารถติดตั้งผ่าน Homebrew ได้ ส่วน OS อื่นสามารถดาวน์โหลดไบนารีจาก lx's GitHub Releases เพื่อติดตั้งได้

brew tap chebread/lx  
brew install lx  

หลังติดตั้งแล้ว ให้รันคำสั่ง lx ใน path ของโปรเจกต์เพื่อสร้างโค้ดจริง
lx มีฟีเจอร์ smart generation ดังนั้นฟังก์ชันที่สร้างโค้ดไปแล้วจะไม่เรียก LLM ซ้ำอีก ทำให้สามารถรันคำสั่ง lx ซ้ำได้อย่างสบายใจ

หมายเหตุ: lx ใช้เครื่องมือเฉพาะภาษาสำหรับ format โค้ดที่สร้างขึ้น (Go: goimports, Python: ruff, JS: prettier) ดังนั้นต้องติดตั้งเครื่องมือเหล่านี้ไว้ล่วงหน้า

6. ไลเซนส์

lx เผยแพร่ภายใต้ AGPL-3.0 License
เพื่อให้ lx มีส่วนช่วยต่อระบบนิเวศโอเพนซอร์ส พร้อมทั้งป้องกันไม่ให้เครื่องมือนี้ถูกนำไปปิดกั้นและครอบครองแบบปิด

บทสรุป

ซอฟต์แวร์คือผลลัพธ์ที่ถักทอขึ้นจากความพยายามอย่างไม่หยุดยั้งของมนุษย์ แม้ในยุค AI โปรแกรมเมอร์ก็ควรยังคงเป็นเจ้าของโค้ดอยู่เสมอ
lx ช่วยให้เรามอบ "งาน implement ที่น่าเบื่อ" อย่าง regex หรือ data parsing ให้ AI รับผิดชอบได้ ขณะเดียวกันมนุษย์ก็ยังถือครองโครงสร้างและ flow ของโปรแกรมได้อย่างสมบูรณ์
ผมขอแนะนำเครื่องมือนี้ให้กับนักพัฒนาที่ไม่อยากสูญเสียทั้งความสนุกของการเขียนโค้ด (Wrangling code) และอำนาจในการควบคุม!

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

 
moderator 2026-01-31

ความคิดเห็นที่ไม่เหมาะสมได้ถูกลบออกตามนโยบายการดำเนินงาน และบัญชีดังกล่าวถูกจำกัดการใช้งานแล้ว

 
callakrsos 2026-01-30

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

 
galadbran 2026-01-31

น่าสนใจมาก เพราะเป็นแนวทางที่สวนทางอย่างสิ้นเชิงกับบรรยากาศช่วงนี้ที่เหมือนว่าต้องไม่ดูโค้ดเลยถึงจะทำได้อย่างถูกต้อง
ขึ้นอยู่กับการเลือกใช้งาน ก็ดูเหมือนว่าน่าจะใช้ในแบบที่กำหนดขอบเขตให้ชัดเจนได้ว่า AI จะเข้าไปแตะตรงไหนบ้าง
เอามาลองทำเป็นสกิลของเหล่า coding agent ก็น่าจะไม่เลวเหมือนกันนะ?

 
chebread 2026-01-31

ผม/ฉันจะพิจารณาอย่างจริงจัง หากคุณสนใจ ก็รบกวนส่ง PR กันเข้ามาเยอะ ๆ!

 
narubrown 2026-01-30

ดูเหมือนจะเป็นโปรเจกต์ที่น่าสนใจมาก!

เขียนสเปกของ Ix -> ใช้ Ix Tool แทนที่ฟังก์ชัน lx ให้เป็นฟังก์ชันจริง -> แล้วคอมไพล์ด้วย go สินะ
พอมีเลเยอร์ที่ใช้ lx เกิดขึ้นในโปรเจกต์
ก็น่าจะแยกชั้นที่เขียนด้วย LLM ออกมาได้ เลยทำให้น่าจะดูแลรักษาได้สะดวกในภายหลังด้วย

ดูเป็นความพยายามที่น่าสนใจในการใช้ LLM เลยครับ!

 
chebread 2026-01-30

ขอบคุณครับ lx รองรับภาษาอื่นนอกเหนือจากภาษา Go ด้วย จึงฝากให้ช่วยลองใช้งานกันเยอะ ๆ และแนะนำความเห็นกันเข้ามาด้วยครับ!

 
iknowca 2026-01-30

เป้าหมายน่าสนใจ แต่ตลอดทั้งเนื้อหาหลักสัมผัสได้ชัดถึงสำนวนแบบเฉพาะของ AI
เลยทำให้เชื่อถือได้ยากครับ

 
chebread 2026-01-30

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

 
wegaia 2026-01-31

ว้าว น่าทึ่งมากที่นักเรียนมัธยมปลายเป็นคนคิดสิ่งนี้ขึ้นมาได้
ถ้าเก็บเกี่ยวประสบการณ์ได้มากกว่านี้ ก็น่าจะสร้างอะไรที่ยอดเยี่ยมยิ่งกว่าเดิมได้อีก

 
siabard 2026-01-30

คงเป็นแนวทางที่เมื่อสั่งคำสั่งจากบรรทัดคำสั่ง โค้ดที่เรียก lx.Generate จะถูกเปลี่ยนเป็นโค้ดที่ LLM เขียนขึ้น ใช่ไหมครับ?
ผมคิดว่าส่วนที่เรียกใช้อาจทำหน้าที่เป็นข้อจำกัดด้านชนิดข้อมูลได้ในระดับหนึ่ง ซึ่งเป็นไอเดียที่ดีครับ เลยสงสัยว่ากำลังพิจารณาวิธีที่ให้คำสั่ง lx รันอัตโนมัติในเอดิเตอร์เป็นต้น แล้วแทนที่โค้ด implementation ให้เลยด้วยหรือเปล่า (อีกอย่าง ถ้ามีวิธีสั่งสร้างโค้ดใหม่ตอนที่ไม่ถูกใจกับโค้ดที่สร้างออกมาก็น่าจะดีครับ)
ได้อ่านโปรเจกต์แล้วน่าสนใจมากครับ

 
chebread 2026-01-30

โค้ดที่เรียก lx.Generate ถ้าสั่งคำสั่งจากบรรทัดคำสั่งก็จะถูกเปลี่ยนเป็นโค้ดที่ LLM เขียนให้ แบบนั้นถูกต้องใช่ไหมครับ? -> ใช่ครับ ถูกต้อง!

ผมคิดว่าส่วนที่ใช้เรียกอาจกลายเป็นข้อจำกัดด้าน type ได้ ซึ่งเป็นไอเดียที่ดีทีเดียวครับ เลยอยากทราบว่ากำลังพิจารณาวิธีให้คำสั่ง lx ทำงานอัตโนมัติใน editor เป็นต้น แล้วนำไปแทนที่โค้ด implementation หรือไม่ครับ -> คิดว่าเป็นไอเดียที่ดีมากจริง ๆ ครับ จะนำไปพิจารณาอย่างจริงจัง

อีกอย่าง ถ้าโค้ดที่สร้างออกมาไม่ถูกใจ ก็น่าจะดีถ้ามีวิธีสร้างใหม่ได้ -> เนื่องจากปรัชญาของโปรเจกต์คือ AI ที่อยู่ภายใต้การควบคุมของนักพัฒนา ดังนั้นหากต้องการสร้างใหม่ จึงออกแบบให้สร้าง lx marker ขึ้นมาอีกครั้งครับ

 
maneuling 2026-01-30

พอเห็นว่าคนทำเป็นเด็กมัธยมปลายก็รีบคลานเข้ามาทิ้งคอมเมนต์แบบนี้ ระดับสติปัญญาก็พอดูออกเลยนะ

ส่องกระจกแล้วไปรักษาตัวหน่อยเถอะ

killdong | 9 เดือนก่อน | parent | on: ฉันใช้ ZIP bomb เพื่อปกป้องเซิร์ฟเวอร์ของฉัน (idiallo.com)
ผมมองว่าถ้าแม้แต่บนอินเทอร์เน็ตยังไม่รับผิดชอบต่อสิ่งที่ตัวเองพ่นออกมา ก็ควรถูกห้ามใช้อินเทอร์เน็ตได้แล้ว ช่วยตามเก็บสิ่งที่ตัวเองพ่นไว้หน่อยเถอะ