- Đây là ngôn ngữ lập trình thế hệ mới dựa trên LLM, có thể thu gọn codebase 5~10 lần
- Thay vì viết code, lập trình viên viết đặc tả (spec) ngắn gọn, rồi mã được tự động sinh ra bằng lệnh
codespeak build
- Khi đặc tả thay đổi, hệ thống sẽ chuyển phần chênh lệch đặc tả (diff) thành chênh lệch mã để áp dụng
- Cũng hỗ trợ dự án pha trộn giữa mã viết tay và mã sinh tự động, và trong các ví dụ mã nguồn mở thực tế đã ghi nhận tỷ lệ vượt qua kiểm thử được cải thiện
- Tập trung vào kỹ thuật phần mềm theo nhóm xử lý phần mềm phức tạp, hướng tới môi trường phát triển thân thiện hơn với con người thông qua bảo trì lấy đặc tả làm trung tâm
Tổng quan về CodeSpeak
- CodeSpeak là ngôn ngữ lập trình thế hệ mới được vận hành bởi LLM, hướng tới mục tiêu giảm codebase xuống 5~10 lần
- Theo mô tả trên trang web, hiệu quả được nhấn mạnh bằng câu “Shrink your codebase 5–10x”
- Ngôn ngữ này là công cụ để xây dựng hệ thống cấp độ production, được thiết kế cho các dự án dài hạn chứ không chỉ là prototype đơn giản
- Đối tượng người dùng chính là các nhóm kỹ sư phát triển phần mềm phức tạp, theo định hướng phát triển hợp tác thay vì kiểu thử nghiệm tập trung vào lập trình viên cá nhân
Phương thức phát triển dựa trên đặc tả
- Cốt lõi của CodeSpeak là triết lý “Maintain Specs, Not Code”
- Lập trình viên viết đặc tả (spec) ngắn gọn, rồi mã được tự động sinh ra bằng lệnh
codespeak build
- Khi đặc tả được sửa, hệ thống sẽ tự động chuyển thay đổi trong đặc tả (diff) thành thay đổi trong mã (diff)
- Cách tiếp cận này nhấn mạnh rằng việc duy trì và quản lý đặc tả dễ hơn với con người so với duy trì mã
Hỗ trợ dự án pha trộn
- CodeSpeak hỗ trợ các dự án nơi mã viết tay hiện có và mã sinh tự động cùng tồn tại
- Ví dụ được nêu là trường hợp fork kho lưu trữ MarkItDown của Microsoft
- Cung cấp hướng dẫn tutorial để xử lý dự án pha trộn theo từng bước
Tính năng chuyển đổi code → đặc tả (sắp ra mắt)
- CodeSpeak đang chuẩn bị tính năng phân tích mã hiện có để chuyển thành đặc tả
- Qua đó, có thể thay thế một phần mã hiện có bằng đặc tả nhỏ hơn 5~10 lần
- Nhấn mạnh rằng bảo trì đặc tả thân thiện với con người hơn so với bảo trì mã
Nghiên cứu tình huống thực tế (Case Studies)
- CodeSpeak đã thử nghiệm bằng cách chuyển mã của nhiều dự án mã nguồn mở sang đặc tả
- Hỗ trợ phụ đề WebVTT của yt-dlp: 255 LOC → 38 LOC, thu gọn 6.7 lần, thêm 37 bài kiểm thử
- Trình tạo SSN Ý của Faker: 165 LOC → 21 LOC, thu gọn 7.9 lần, thêm 13 bài kiểm thử
- Tự động phát hiện encoding của beautifulsoup4: 826 LOC → 141 LOC, thu gọn 5.9 lần, thêm 25 bài kiểm thử
- Bộ chuyển đổi EML→Markdown của markitdown: 139 LOC → 14 LOC, thu gọn 9.9 lần, thêm 27 bài kiểm thử
- Ở mỗi trường hợp, tỷ lệ vượt qua kiểm thử được giữ nguyên hoặc cải thiện, cho thấy hiệu quả thực tế của cách tiếp cận dựa trên đặc tả
Tóm tắt
- CodeSpeak là ngôn ngữ lập trình AI lấy đặc tả làm trung tâm, kết hợp giữa tự động sinh mã và hiệu quả bảo trì
- Sinh mã dựa trên LLM, đồng bộ đặc tả-mã, và hỗ trợ dự án pha trộn là những đặc điểm chính
- Các ví dụ thực tế đã chứng minh khả năng thu gọn mã và cải thiện kiểm thử, qua đó cho thấy tiềm năng nâng cao năng suất kỹ thuật phần mềm theo nhóm
4 bình luận
Không biết gọi đây là một ngôn ngữ có phải chỉ để câu tương tác hay đúng là thời đại đã thành ra như vậy rồi.
> Như Joel Spolsky từng nói trong một bài giảng tại Yale, những nỗ lực nhằm ‘tạo ra chương trình từ đặc tả (spec)’ từ trước đến nay đều đã thất bại
> Nếu đặc tả đủ chi tiết để định nghĩa hoàn toàn chương trình, thì việc viết bản đặc tả đó tự nó cũng khó chẳng kém gì viết chương trình
Dù về nguyên tắc tôi đồng ý, nhưng chuyện đó cũng là điều hiển nhiên; ngay từ đầu đã không có cái gì là hoàn toàn trọn vẹn, giống như chứng minh của Gödel. Nên có vẻ như đây là đang phê phán nỗ lực đó dựa trên giả định rằng sẽ tồn tại một sản phẩm hoàn hảo.
Điều này khiến tôi liên tưởng đến MDD (Model Driven Dev.).
Ý kiến trên Hacker News
Như Joel Spolsky từng nói trong một bài giảng ở Yale, các nỗ lực "tạo chương trình từ đặc tả (spec)" từ trước đến nay đều thất bại
Nếu đặc tả đủ chi tiết để định nghĩa hoàn toàn chương trình, thì việc viết đặc tả đó tự nó đã khó gần bằng việc lập trình rồi
Liên kết bài giảng gốc
Bây giờ ta có thể tạo chương trình ngay cả với prompt không hoàn chỉnh, và nghiên cứu cách xử lý prompt một cách có hệ thống là điều có giá trị
Khả năng mở rộng đang chuyển từ việc thêm tính năng sang định nghĩa ràng buộc hành vi và tính bất biến về cấu trúc
Kiểu như “1. nhận thông tin từ người dùng, 2. gửi yêu cầu HTTP, 3. nếu lỗi thì báo cáo”,
nhưng nếu vậy thì tôi nghĩ viết hẳn một script sẽ nhanh hơn nhiều và có tính quyết định hơn
Đây không phải một ngôn ngữ mới, mà là workflow và công cụ cho phát triển dựa trên LLM
Thay vì mã nguồn, bạn duy trì các tệp đặc tả Markdown, và
codespeaksẽ sửa mã dựa trên diff của đặc tảƯu điểm là prompt được quản lý phiên bản cùng với mã, còn nhược điểm là đặc tả không thể phản ánh mọi chi tiết của mã
Họ đang thử nghiệm công cụ
codespeak takeoverđể chuyển mã thành đặc tả và phản ánh prompt của phiên làm việc agentHọ mô tả đây là sự chuyển đổi từ “sprint mode” ngắn hạn sang “marathon mode” dài hạn
Liên kết blog liên quan
Ý tưởng quá đơn giản nên ai cũng có thể nhanh chóng tái hiện, và phiên bản mã nguồn mở sẽ sớm thay thế
Có người đề xuất cần một chính sách cho phép "thay đổi nhỏ"
Nhìn chung, ý tưởng về một trình biên dịch giả mã tăng dần khá thú vị
Có lẽ 5 năm nữa chúng ta sẽ không viết mã theo cách này, và đặc tả kỹ thuật ở mức tiếng Anh tự nhiên là đủ rồi
Cách tiếp cận này giống tooling ánh xạ đặc tả sang mã hơn là một ngôn ngữ
Nhưng mô hình thì không quyết định, nên cùng một đặc tả vẫn có thể cho ra kết quả khác nhau mỗi lần
Đặc tả về bản chất là bản tóm tắt có mức mất mát thông tin lớn, nên ở codebase quy mô lớn sẽ khó giữ được tính nhất quán
Điều tôi muốn thấy là một pipeline có thể kiểm chứng: từ đặc tả văn bản → đặc tả hình thức (formal spec) → mã
Điều quan trọng không phải bản thân mã mà là tính nhất quán của kết quả hành vi
Càng trừu tượng hơn mã thì càng có nhiều cách hiện thực, nên tính quyết định vẫn không được đảm bảo
Tôi nghĩ các bài test tự động mới nên đóng vai trò là đặc tả thực sự
Họ cho rằng nếu cố định seed thì có thể nhận được cùng một đầu ra cho cùng một đầu vào
Cursor hay Antigravity được tối ưu cho kiểu “vibe coding” lấy con người làm trung tâm, còn Kiro thì chuyên cho phát triển dựa trên đặc tả theo hướng agent
Nó dùng các định dạng có cấu trúc như EARS, INCOSE, và tạo kiểm tra tính nhất quán tự động cùng kiểm thử dựa trên thuộc tính (PBT)
Khi đặc tả đủ vững thì phần hiện thực gần như tự động đi theo
Tôi đang chạy song song nhiều CLI agent để có được kết quả hoàn thiện hơn
Vấn đề của ngôn ngữ prompt hình thức không nằm ở sự mơ hồ mà ở khả năng hiểu ngữ cảnh còn thiếu của mô hình
Cùng một prompt nhưng kết quả sẽ khác nhau tùy theo ngữ cảnh
Dù có hình thức hóa prompt thì cũng vô ích nếu mô hình hiểu sai codebase
Vì mô hình được tối ưu cho ngôn ngữ hội thoại, nên người ta cho rằng thay vì trực tiếp dùng ngôn ngữ hình thức, chỉ nên dùng nó khi thực sự cần
Có người bày tỏ mong muốn đơn giản là giá như có thể truyền đạt ý định cho máy tính bằng một cách có tính quyết định và hình thức
Khái niệm này xuất phát từ một tiền đề hiểu sai về cấu trúc bên trong của LLM
Theo nghiên cứu gần đây, LLM có một giai đoạn xử lý riêng giữa mã hóa và giải mã,
và sau khi huấn luyện xong thì bản thân ngôn ngữ có thể không còn quan trọng đến vậy
Liên kết nghiên cứu liên quan
Mục tiêu là giúp con người diễn đạt rõ ràng điều họ muốn
Tôi không chắc liệu có thật sự cần công cụ kiểu này không
Chỉ cần tự viết đặc tả Markdown, rồi bảo agent sinh mã là đủ
Trong phần “Prerequisites” của tutorial có ghi là cần khóa API Anthropic
Có thể đây chỉ là biện pháp tạm thời vì đang ở bản alpha, nhưng tôi vẫn thắc mắc vì sao nhất thiết phải dùng API
Có vẻ như chỉ cần chèn prompt trực tiếp vào một phiên như Claude Code là được
Liên kết tham khảo
Dự án này rất giống với đặc tả ngôn ngữ bộ thực thi LLM mà tôi đang làm nên thấy rất thú vị
Dự án AIL của tôi dùng YAML để định nghĩa và chạy các chuỗi prompt
Điểm cốt lõi là có một "động cơ tinh chỉnh prompt" để chuyển ngôn ngữ tự nhiên của người dùng thành các lệnh có cấu trúc
Ví dụ, nó phân tích ý định của người dùng, chia thành từng bước, rồi tối ưu theo các chuẩn kỹ thuật prompt hiện đại
Nếu có một bộ chặn như vậy thì sẽ có thể làm theo kiểu “hãy chuyển điều tôi vừa nói sang định dạng CodeSpeak”
Đây thực sự là một ý tưởng rất hay, tôi nhất định sẽ đào sâu hơn nữa