TypeScript 7.0 กับ Jacquard เป็นภาษาโปรแกรมสองตัวที่เปิดตัวห่างกันไม่กี่วัน และมุ่งแก้ปัญหาเดียวกันจากคนละด้าน นั่นคือทุกวันนี้ AI เขียนโค้ดได้เร็วกว่าที่คนตรวจทัน TypeScript ต่อยอดจาก JavaScript โดยเพิ่มการตรวจชนิดข้อมูลก่อนโปรแกรมจะรันจริง และเวอร์ชันนี้ตรวจโค้ดทั้งโปรเจกต์ได้เร็วขึ้นเกือบสิบสองเท่า ส่วน Jacquard เป็นภาษาทดลองเวอร์ชัน 0.1 ที่ออกแบบใหม่ตั้งแต่ต้น เพื่อให้คนอ่านรู้ได้จากตัวโค้ดเลยว่าโปรแกรมก้อนนี้แตะอะไรได้บ้าง

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

ของสองชิ้นนี้ไม่ได้นัดกันมา และไม่ได้เลือกทางแก้แบบเดียวกันเลย แต่การที่มันโผล่มาพร้อมกันในสัปดาห์เดียวบอกอะไรบางอย่างชัดมาก คอขวดของงานเขียนโปรแกรมย้ายที่ไปแล้ว

คอขวดย้ายจากการเขียนไปอยู่ที่การอ่าน

ประโยคตั้งต้นที่ Joshua Winters ผู้สร้าง Jacquard เขียนไว้ในเรียงความของ FriendMachine Research พูดเรื่องนี้ตรงกว่านั้นอีก

การตอบคำถามสามข้อนี้ยังต้องอาศัยการอ่านอย่างระมัดระวังเหมือนเดิม นั่นคือโค้ดก้อนหนึ่งแตะอะไรได้บ้าง มันทำงานอย่างไรเมื่อระบบภายนอกมีปัญหา และการแก้รอบนี้เปลี่ยนพฤติกรรมจริงหรือแค่ย้ายบรรทัด ต้นทุนของการเขียนลดลงเกือบเป็นศูนย์ แต่ต้นทุนของการตรวจไม่ได้ลดลงตามเลยแม้แต่นิดเดียว

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

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

TypeScript 7.0 เร็วขึ้น 8 ถึง 12 เท่า เพราะเขียนคอมไพเลอร์ขึ้นใหม่ด้วยภาษา Go

ด้านแรกของปัญหาคือความเร็ว ทีม TypeScript เลือกวิธีที่ตรงไปตรงมาที่สุด นั่นคือเขียนคอมไพเลอร์ (ตัวที่แปลโค้ดพร้อมตรวจว่าเขียนถูกไหม) ขึ้นใหม่ทั้งตัวด้วยภาษา Go โดยรักษาโครงสร้างและตรรกะเดิมไว้ ผลลัพธ์จึงควรเหมือนเดิม แต่ทำงานเร็วขึ้นหลายเท่า ตัวเลขในประกาศทางการมาจากการทดสอบกับโปรเจกต์จริงที่มีโค้ดจำนวนมาก หนึ่งในนั้นคือ VS Code โปรแกรมเขียนโค้ดที่นักพัฒนาทั่วโลกใช้กัน โดยนำเวลาบิลด์ (การสั่งแปลและตรวจโค้ดทั้งโปรเจกต์รวดเดียว) ของ TypeScript 6 กับ 7 มาเทียบกัน ได้ผลดังนี้

ที่น่าสนใจกว่าตัวเลขบิลด์คือผลทดสอบในเอดิเตอร์ การเปิดไฟล์ที่มี error ในโปรเจกต์ของ VS Code เคยต้องรอราว 17.5 วินาทีกว่าเส้นแดงเส้นแรกจะขึ้น ตอนนี้เหลือไม่ถึง 1.3 วินาที ตัวช่วยที่คอยเติมโค้ดและขีดเส้นแดงในเอดิเตอร์ (language server) ก็ทำงานผิดพลาดน้อยลงกว่า 80 เปอร์เซ็นต์ และแครชน้อยลงกว่า 60 เปอร์เซ็นต์ ส่วนแรมที่ใช้ตอนบิลด์ลดลงราว 6 ถึง 26 เปอร์เซ็นต์แล้วแต่โปรเจกต์

ความเร็วช่วยเครื่อง แต่ยังไม่ได้ช่วยคนอ่าน

ตรงนี้ต้องแยกให้ชัดว่าอะไรคือสิ่งที่ประกาศทางการพูดไว้จริง และอะไรคือการตีความที่เติมเข้ามาทีหลัง

ในประกาศ TypeScript 7.0 ทั้งหน้า คำว่า AI โผล่มาแค่ประโยคเดียวแบบผ่านๆ ทำนองว่าเมื่อคนเขียนโค้ดพร้อมจะบิลด์โปรเจกต์ ก็สั่ง tsc ได้เลย โดยช่วงหลังผู้ที่ลงมือแก้โค้ดเองอาจเป็น AI agent เหตุผลที่ทีมให้ไว้สำหรับการรีไรต์ทั้งหมดคือทำให้การทำงานกับโปรเจกต์ขนาดใหญ่เร็วขึ้น และปรับประสบการณ์ใช้งานในเอดิเตอร์ ไม่ใช่การรองรับโค้ดที่ AI เขียน ใครสรุปว่าไมโครซอฟท์รีไรต์ TypeScript เพื่อ AI คือเติมเอง

ส่วนที่ประกาศไม่ได้พูดไว้ แต่ตีความต่อได้จากตัวเลขชุดนี้ คือ ในวันที่ agent วนลูปแก้โค้ดแล้วสั่งตรวจชนิดข้อมูลใหม่ทั้งวัน คอมไพเลอร์ที่เร็วขึ้นสิบเท่าก็ทำให้ agent ลองผิดลองถูกแต่ละรอบได้เร็วขึ้นสิบเท่าไปด้วย ซึ่งเป็นทิศทางเดียวกับที่เฟรมเวิร์กหลายตัวกำลังมุ่งไป อย่าง Next.js 16.3 ที่ใส่ฟีเจอร์มาให้ coding agent ใช้โดยเฉพาะ

แต่ตรงนี้แหละคือจุดที่ต้องพูดให้ครบ คอมไพเลอร์ที่เร็วขึ้นบอกได้แค่ว่าโครงสร้างของโค้ดถูกต้องตามชนิดข้อมูลที่ประกาศไว้ มันไม่ได้บอกว่าฟังก์ชันนี้แอบยิงข้อมูลออกเน็ต ไม่ได้บอกว่าถ้า API ปลายทางล่มแล้วมันจะทำอะไร และไม่ได้บอกว่าดิฟฟ์ (ส่วนที่โค้ดเปลี่ยนไปในรอบนั้น) เปลี่ยนพฤติกรรมจริงหรือแค่จัดบรรทัดใหม่ ความเร็วช่วยให้เครื่องทำงานไวขึ้น แต่ปริมาณงานที่รอคนอ่านยังเท่าเดิม

Jacquard ใส่กลไกสามอย่างไว้ในตัวภาษา

อีกด้านหนึ่งไม่ได้แข่งเรื่องความเร็ว แต่ตั้งคำถามว่าถ้าออกแบบภาษาใหม่ทั้งภาษาสำหรับยุคที่เครื่องเป็นคนเขียนและคนเป็นคนตรวจ มันควรหน้าตาเป็นยังไง

พูดให้ชัดก่อนว่า Jacquard เป็นงานวิจัยเวอร์ชัน 0.1 ไม่ใช่ของที่เอาไปใช้ในงานจริง ผู้สร้างเขียนข้อจำกัดไว้ตรงๆ ในไฟล์ชื่อ LIMITS.md ว่าภาษานี้ทำอะไรไม่ได้บ้าง สิ่งที่น่าอ่านคือวิธีคิด ไม่ใช่ตัวภาษา เพราะกลไกสามอย่างที่ Jacquard ใส่ไว้ในตัวภาษา ทุกวันนี้กระจัดกระจายอยู่ตามคอมเมนต์ ล็อก หรือความจำของคนที่เคยอ่านโค้ดชุดนั้น

หนึ่ง บรรทัดหัวระบุว่าฟังก์ชันแตะอะไรนอกโปรแกรมบ้าง

ทุกฟังก์ชันในภาษาโปรแกรมมีบรรทัดหัวที่บอกว่ามันรับค่าอะไรและคืนค่าอะไร ใน Jacquard บรรทัดนั้นเขียนแบบนี้

(text) ->{net} text

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

jac run policy.jac --allow net --allow fs

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

สอง โปรแกรมชุดเดิมรันกับสภาพแวดล้อมหลายแบบได้

โค้ดชุดเดียวกันรันในสภาพแวดล้อมต่างกันได้โดยไม่ต้องแก้อะไร แค่สลับตัวรับ (handler) ที่คอยจัดการ effect เหล่านั้น จะให้ต่อเน็ตจริงก็ได้ ให้คุยกับระบบจำลองที่กำหนดคำตอบด้วยสคริปต์ก็ได้ ให้เล่นซ้ำทราฟฟิกที่บันทึกไว้เมื่อสัปดาห์ก่อนก็ได้ หรือให้ใช้แบบจำลองความน่าจะเป็นว่าเซิร์ฟเวอร์มักพังแบบไหนก็ได้

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

สาม เปลี่ยนชื่อตัวแปรไม่นับว่าโค้ดเปลี่ยน

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

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

โมเดลเขียนโค้ดด้วยภาษาที่ไม่เคยเห็นมาก่อนได้ แค่มีไฟล์ SKILL.md ไฟล์เดียว

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

ปัจจัยที่ช่วยให้โมเดลทำงานต่อได้มีไม่กี่อย่าง ได้แก่ ไฟล์ SKILL.md ที่รวมกฎทั้งภาษา คำสั่งที่ใช้ และหลุมพรางที่พบบ่อย เพื่อให้โมเดลโหลดมาอ่านได้ในครั้งเดียว ชุดเทสต์ที่รันได้จริง แกนภาษาซึ่งมีเพียง 27 รูปแบบ และตัวตรวจที่วนลูปแจ้งว่าถูกหรือผิดได้รวดเร็ว

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

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

ใครอยากดูของจริง โค้ดกับเอกสารทั้งหมดอยู่ที่ jacquard-lang เปิดอ่านได้ฟรี แต่ย้ำอีกครั้งว่ามันคือของทดลอง ไม่ใช่ของที่จะนำไปใช้กับงานจริง

สามคำถามที่ใช้กับดิฟฟ์ของ AI ได้ตั้งแต่พรุ่งนี้

คนอ่านส่วนใหญ่ไม่ได้จะไปเขียน Jacquard และคงยังไม่อัปเดตโปรเจกต์เป็น TypeScript 7 ในวันพรุ่งนี้ แต่มีสิ่งที่นำมาใช้กับโค้ดที่ AI เขียนให้ได้ทันที ไม่ว่าจะใช้ภาษาอะไร นั่นคือสามคำถามที่ Jacquard พยายามทำให้ตอบได้จากตัวโค้ดเอง

1. โค้ดก้อนนี้แตะอะไรได้บ้าง ต่อเน็ตไหม อ่านเขียนไฟล์ไหม ใช้คีย์อะไร ยิงฐานข้อมูลไหม
2. ถ้าระบบภายนอกมีปัญหา เช่น เน็ตหลุด API คืนค่า error หรือรับค่ามาเป็นค่าว่าง โค้ดจะทำงานอย่างไร
3. ดิฟฟ์รอบนี้เปลี่ยนพฤติกรรมจริง หรือแค่จัดบรรทัดใหม่

เริ่มทำได้ตั้งแต่พรุ่งนี้ หนึ่ง เปิดดิฟฟ์แล้วอย่าเพิ่งอ่านลอจิก ให้ไล่หาบรรทัดที่ import สิ่งใหม่เข้ามา บรรทัดที่หยิบคีย์ และบรรทัดที่เรียกออกไปข้างนอกก่อน สอง ส่งคำสั่งนี้ให้โมเดลตัวเดิมที่เพิ่งเขียนโค้ดให้

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

สาม เขียนสามคำถามข้างบนรวมเป็นกฎข้อเดียวในไฟล์กติกาของโปรเจกต์ เช่น AGENTS.md หรือ CLAUDE.md เพื่อให้ agent ตอบคำถามเหล่านี้มาพร้อมทุกดิฟฟ์ตั้งแต่แรก

สามคำถามนี้ใช้เวลาราว 30 วินาทีต่อดิฟฟ์ แต่โมเดลตัดสินแทนไม่ได้จริงๆ แม้โมเดลจะแจกแจงได้ว่าโค้ดแตะอะไรบ้าง แต่คนที่ตัดสินว่ายอมรับความเสี่ยงนั้นได้หรือไม่คือคนที่ต้องรับผลตอนมันพัง

เครื่องมือกลุ่มนี้กำลังแข่งกันเพื่อให้ตอบคำถามว่า "โค้ดก้อนนี้ทำอะไรได้บ้าง" ได้เร็วขึ้นเรื่อยๆ ส่วนคำถามว่า "แล้วมันควรทำแบบนั้นไหม" ยังไม่มีเครื่องมือตัวไหนตอบแทนคนได้ และช่องว่างนี้เองทำให้คนอ่านโค้ดยังต้องทำหน้าที่นี้ต่อไป

ที่มา:

• โค้ดและเอกสารของภาษา jbwinters/jacquard-lang บน GitHub
• เรียงความ Jacquard: A Language for Model-Written Code โดย Joshua Winters · FriendMachine Research
• ประกาศ Announcing TypeScript 7.0 โดย Daniel Rosenwasser · TypeScript (Microsoft)