- เป็น ภาษาโปรแกรมมิงยุคถัดไป ที่ขับเคลื่อนด้วย LLM และสามารถ ลดขนาดโค้ดเบสได้ 5~10 เท่า
- นักพัฒนาเขียน สเปก (spec) ที่กระชับ แทนโค้ด และใช้คำสั่ง
codespeak build เพื่อให้ระบบสร้างโค้ดอัตโนมัติ
- เมื่อสเปกมีการเปลี่ยนแปลง ระบบจะ แปลง diff ของสเปก ให้เป็น diff ของโค้ดแล้วนำไปสะท้อนให้อัตโนมัติ
- รองรับ โปรเจกต์แบบผสม ที่มีทั้งโค้ดเขียนเองและโค้ดที่สร้างอัตโนมัติอยู่ร่วมกัน และมีการยืนยันในกรณีโอเพนซอร์สจริงว่า อัตราการผ่านการทดสอบดีขึ้น
- มุ่งเน้น งานวิศวกรรมแบบทีม สำหรับการจัดการซอฟต์แวร์ที่ซับซ้อน และตั้งเป้าสู่ สภาพแวดล้อมการพัฒนาที่เป็นมิตรต่อมนุษย์ ผ่านการบำรุงรักษาแบบยึดสเปกเป็นศูนย์กลาง
ภาพรวมของ CodeSpeak
- CodeSpeak คือ ภาษาโปรแกรมมิงยุคถัดไปที่ขับเคลื่อนด้วย LLM โดยมีเป้าหมายเพื่อลดขนาดโค้ดเบสลง 5~10 เท่า
- ตามคำอธิบายในเว็บไซต์ มีข้อความว่า “Shrink your codebase 5–10x” เพื่อเน้นประสิทธิภาพ
- ภาษานี้เป็นเครื่องมือสำหรับสร้าง ระบบระดับ production ออกแบบมาสำหรับโปรเจกต์ระยะยาว ไม่ใช่แค่ต้นแบบง่าย ๆ
- กำหนดให้ ทีมวิศวกรที่พัฒนาซอฟต์แวร์ซับซ้อน เป็นผู้ใช้หลัก และมุ่งไปที่ การพัฒนาแบบร่วมมือกัน มากกว่าการเขียนโค้ดเชิงทดลองของนักพัฒนาเดี่ยว
แนวทางการพัฒนาแบบอิงสเปก
- แกนหลักของ CodeSpeak คือแนวคิด “Maintain Specs, Not Code”
- นักพัฒนาเขียนสเปก (spec) ที่กระชับ และใช้คำสั่ง
codespeak build เพื่อให้ระบบสร้างโค้ดอัตโนมัติ
- เมื่อมีการแก้ไขสเปก ระบบจะ แปลงการเปลี่ยนแปลง (diff) ของสเปก ให้เป็น การเปลี่ยนแปลง (diff) ของโค้ด โดยอัตโนมัติ
- แนวทางนี้เน้นว่า การดูแลและจัดการสเปกนั้น ง่ายกว่าสำหรับมนุษย์ เมื่อเทียบกับการดูแลโค้ด
รองรับโปรเจกต์แบบผสม
- CodeSpeak รองรับ โปรเจกต์ที่โค้ดเขียนเองเดิมกับโค้ดที่สร้างอัตโนมัติอยู่ร่วมกัน
- มีการยกตัวอย่างกรณีฟอร์กรีโพซิทอรี MarkItDown ของ Microsoft
- มี คู่มือสอนใช้งาน สำหรับการจัดการโปรเจกต์แบบผสมเป็นลำดับขั้น
ความสามารถแปลงโค้ด → สเปก (อยู่ระหว่างเตรียม)
- CodeSpeak กำลังเตรียมฟังก์ชันสำหรับวิเคราะห์โค้ดเดิมแล้ว แปลงเป็นสเปก
- สิ่งนี้จะช่วยให้แทนที่โค้ดเดิมบางส่วนด้วย สเปกที่เล็กลง 5~10 เท่า ได้
- พร้อมเน้นย้ำว่าการบำรุงรักษาสเปกนั้น เป็นมิตรต่อมนุษย์ มากกว่าการบำรุงรักษาโค้ด
กรณีศึกษาจริง (Case Studies)
- CodeSpeak นำโค้ดจาก โปรเจกต์โอเพนซอร์สหลายรายการ มาแปลงเป็นสเปกเพื่อทดสอบ
- รองรับคำบรรยาย WebVTT ของ yt-dlp: 255 LOC → 38 LOC ลดลง 6.7 เท่า เพิ่มการทดสอบ 37 รายการ
- ตัวสร้างเลข SSN อิตาลีของ Faker: 165 LOC → 21 LOC ลดลง 7.9 เท่า เพิ่มการทดสอบ 13 รายการ
- การตรวจจับ encoding อัตโนมัติของ beautifulsoup4: 826 LOC → 141 LOC ลดลง 5.9 เท่า เพิ่มการทดสอบ 25 รายการ
- ตัวแปลง EML→Markdown ของ markitdown: 139 LOC → 14 LOC ลดลง 9.9 เท่า เพิ่มการทดสอบ 27 รายการ
- ในแต่ละกรณี อัตราการผ่านการทดสอบยังคงเดิมหรือดีขึ้น แสดงให้เห็นถึงประสิทธิผลของแนวทางแบบอิงสเปก
สรุป
- CodeSpeak คือ ภาษาโปรแกรมมิง AI ที่ยึดสเปกเป็นศูนย์กลาง ซึ่งผสานการสร้างโค้ดอัตโนมัติกับประสิทธิภาพในการบำรุงรักษา
- คุณสมบัติหลักคือ การสร้างโค้ดด้วย LLM, การซิงก์ระหว่างสเปกกับโค้ด, และ การรองรับโปรเจกต์แบบผสม
- กรณีศึกษาจริงพิสูจน์ให้เห็นทั้งการลดโค้ดและการทดสอบที่ดีขึ้น ซึ่งชี้ให้เห็นถึงศักยภาพในการ เพิ่มผลิตภาพของงานวิศวกรรมซอฟต์แวร์แบบทีม
4 ความคิดเห็น
เรียกสิ่งนี้ว่า “ภาษา” นี่เป็นการตั้งใจปั่นกระแส หรือว่ายุคสมัยมันกลายเป็นแบบนั้นไปแล้ว
> อย่างที่ Joel Spolsky เคยพูดไว้ในการบรรยายที่มหาวิทยาลัยเยล ความพยายามที่จะ ‘สร้างโปรแกรมจากสเปก (spec)’ ล้วนล้มเหลวมาตลอด
> ถ้าสเปกมีรายละเอียดมากพอที่จะกำหนดโปรแกรมได้อย่างสมบูรณ์ การเขียนสเปกนั้นเองก็ยากพอ ๆ กับการเขียนโปรแกรมอยู่ดี
โดยหลักการก็เห็นด้วย แต่ก็เหมือนเป็นเรื่องที่แน่นอนอยู่แล้ว เพราะตั้งแต่แรกก็ไม่มีความสมบูรณ์แบบอยู่จริง เหมือนกับบทพิสูจน์ของเกอเดล เลยรู้สึกว่ากำลังวิจารณ์ความพยายามนี้บนสมมติฐานว่าจะต้องมีผลิตภัณฑ์ที่สมบูรณ์แบบอยู่จริง
ทำให้นึกถึง MDD(Model Driven Dev.)
ความคิดเห็นบน Hacker News
อย่างที่ Joel Spolsky เคยพูดไว้ในบรรยายที่ Yale ความพยายามที่จะ "สร้างโปรแกรมจากสเปก" ล้มเหลวมาโดยตลอด
ถ้าสเปกละเอียดพอจะนิยามโปรแกรมได้ครบถ้วน การเขียนสเปกนั้นก็ยากพอๆ กับการเขียนโปรแกรมเอง
ลิงก์ต้นฉบับของบรรยาย
ตอนนี้แม้แต่ พรอมป์ต์ที่ไม่สมบูรณ์ ก็ยังสร้างโปรแกรมได้ และมองว่างานวิจัยด้านการจัดการพรอมป์ต์อย่างเป็นระบบมีคุณค่า
ความสามารถในการขยายกำลังย้ายจากการเพิ่มฟังก์ชัน ไปสู่การนิยาม ข้อจำกัดของพฤติกรรมและความคงตัวเชิงโครงสร้าง
เช่น “1. รับข้อมูลจากผู้ใช้ 2. ส่ง HTTP request 3. ถ้ามี error ก็รายงาน”
ซึ่งถ้าเป็นแบบนั้น สู้ เขียนสคริปต์ไปเลยจะเร็วกว่าและให้ผลแน่นอนกว่า
นี่ไม่ใช่ภาษาใหม่ แต่เป็น เวิร์กโฟลว์และเครื่องมือสำหรับการพัฒนาด้วย LLM
แทนที่จะดูแลโค้ดโดยตรง ก็เก็บไฟล์สเปกแบบ Markdown แล้วให้
codespeakแก้โค้ดจาก diff ของสเปกข้อดีคือพรอมป์ต์ถูกจัดการเวอร์ชันไปพร้อมกับโค้ด ส่วนข้อเสียคือสเปกไม่อาจสะท้อนรายละเอียดทั้งหมดของโค้ดได้
กำลังทดลองใช้เครื่องมือชื่อ
codespeak takeoverเพื่อแปลงโค้ดเป็นสเปก และสะท้อน พรอมป์ต์ของ agent session ลงไปอธิบายว่าเป็นการเปลี่ยนจาก "โหมดสปรินต์" ระยะสั้น ไปเป็น "โหมดมาราธอน" ระยะยาว
ลิงก์บล็อกที่เกี่ยวข้อง
เพราะไอเดียง่ายมาก ใครๆ ก็ทำซ้ำได้เร็ว และคาดว่าเวอร์ชันโอเพนซอร์ซจะมาแทนในไม่ช้า
จึงเสนอว่าควรมีนโยบายที่ยอมให้เกิด "การเปลี่ยนแปลงเล็กน้อย" ได้
โดยรวมแล้วแนวคิดแบบ incremental pseudocode compiler น่าสนใจ
อีก 5 ปีข้างหน้าเราอาจไม่ได้เขียนโค้ดกันแบบนี้ และแค่มี สเปกเชิงเทคนิคระดับภาษาอังกฤษ ก็น่าจะพอ
วิธีนี้เป็นเครื่องมือที่ แมปสเปกไปเป็นโค้ด มากกว่าจะเป็นภาษา
แต่โมเดลมีความไม่เป็นเชิงกำหนด ดังนั้นแม้เป็นสเปกเดียวกัน ผลลัพธ์ก็อาจต่างกันทุกครั้ง
โดยธรรมชาติแล้วสเปกเป็น การสรุปที่สูญเสียข้อมูลสูง ทำให้ในโค้ดเบสขนาดใหญ่ การรักษาความสม่ำเสมอทำได้ยาก
สิ่งที่อยากเห็นคือ pipeline ที่ตรวจสอบได้ จาก text spec → formal spec → code
สิ่งสำคัญไม่ใช่ตัวโค้ด แต่เป็น ความสม่ำเสมอของผลลัพธ์เชิงพฤติกรรม
ยิ่งสเปกเป็นนามธรรมมากกว่าโค้ด ก็ยิ่งเปิดทางให้มีการนำไปใช้ได้หลากหลาย ดังนั้น ความเป็นเชิงกำหนด ก็ยังไม่อาจรับประกันได้
และคิดว่าการทดสอบอัตโนมัติควรทำหน้าที่เป็นสเปกที่แท้จริง
มองว่าถ้าล็อก seed ไว้ ก็จะได้ผลลัพธ์เดิมจากอินพุตเดิม
Cursor กับ Antigravity เหมาะกับการทำ ‘vibe coding’ ที่มีมนุษย์เป็นศูนย์กลาง แต่ Kiro เด่นด้าน การพัฒนาบนฐานสเปกที่มี agent เป็นศูนย์กลาง
มันใช้รูปแบบที่มีโครงสร้างอย่าง EARS, INCOSE และสร้าง การตรวจสอบความสอดคล้องอัตโนมัติ กับ property-based testing (PBT)
ถ้าสเปกแข็งแรงพอ การนำไปใช้จริงก็แทบจะตามมาเองโดยอัตโนมัติ
ตอนนี้กำลังรัน CLI agent หลายตัวแบบขนานเพื่อให้ได้ผลลัพธ์คุณภาพสูง
ปัญหาของ ภาษาพรอมป์ต์แบบเป็นทางการ ไม่ใช่ความกำกวม แต่คือ ความสามารถในการเข้าใจบริบทของโมเดลที่ยังไม่พอ
แม้จะเป็นพรอมป์ต์เดียวกัน ผลลัพธ์ก็เปลี่ยนไปตามคอนเท็กซ์
ต่อให้ทำพรอมป์ต์ให้เป็นทางการ ถ้าโมเดลเข้าใจโค้ดเบสผิดก็ไม่มีประโยชน์
เพราะโมเดลถูกปรับมาให้เหมาะกับภาษาสนทนา จึงมองว่า แทนที่จะใช้ภาษาทางการโดยตรง ควรใช้เฉพาะเวลาจำเป็นมากกว่า
มีการแสดงความหวังว่า ถ้าสามารถสื่อความตั้งใจกับคอมพิวเตอร์ได้ด้วยวิธีที่ เป็นเชิงกำหนดและเป็นทางการ ก็คงดี
แนวคิดนี้ตั้งต้นจากความเข้าใจที่คลาดเคลื่อนเกี่ยวกับโครงสร้างภายในของ LLM
งานวิจัยล่าสุดชี้ว่าใน LLM มี ขั้นตอนการประมวลผลแยกต่างหากระหว่างการเข้ารหัสกับการถอดรหัส และหลังการฝึกแล้ว ภาษาเองอาจไม่ได้สำคัญขนาดนั้น
ลิงก์งานวิจัยที่เกี่ยวข้อง
จุดประสงค์คือช่วยให้มนุษย์แสดงสิ่งที่ต้องการได้อย่างชัดเจน
ไม่แน่ใจว่าจำเป็นต้องมีเครื่องมือแบบนี้จริงหรือไม่
แค่ เขียนสเปก Markdown เองโดยตรง แล้วสั่ง agent ให้สร้างโค้ดก็น่าจะพอแล้ว
ใน “Prerequisites” ของบทช่วยสอนระบุว่าต้องมี Anthropic API key
อาจเป็นแค่มาตรการชั่วคราวเพราะยังเป็นอัลฟาเวอร์ชัน แต่ก็สงสัยว่าทำไมต้องใช้ API ด้วย
ดูเหมือนแค่ฉีดพรอมป์ต์เข้าไปใน session อย่าง Claude Code โดยตรงก็น่าจะได้
ลิงก์อ้างอิง
โปรเจ็กต์นี้น่าสนใจมาก เพราะคล้ายกับ สเปกภาษา executor สำหรับ LLM ที่ฉันกำลังทำอยู่
โปรเจ็กต์ AIL ของฉัน ใช้ YAML ในการนิยามและรัน prompt chain
แกนสำคัญคือมี "เอนจินกลั่นพรอมป์ต์" ที่แปลงภาษาธรรมชาติของผู้ใช้ให้เป็นคำสั่งที่มีโครงสร้าง
ตัวอย่างเช่น วิเคราะห์เจตนาของผู้ใช้ แยกเป็นขั้นตอน และปรับให้เหมาะกับ มาตรฐาน prompt engineering สมัยใหม่
ถ้ามี interceptor แบบนี้ ก็จะเปิดทางให้เกิดเวิร์กโฟลว์อย่าง "ช่วยแปลงสิ่งที่ฉันเพิ่งพูดเป็นรูปแบบ CodeSpeak ให้หน่อย" ได้
เป็นไอเดียที่เจ๋งมาก และตั้งใจจะลองศึกษาให้ลึกแน่นอน