Phụ đề: Nỗi buồn của Vibe Coding với tư cách là một chuyên gia máy tính
Hôm nay tôi đã hỏi Claude Code: Cách tôi làm có đúng không?
Như mọi khi, nó đưa ra những lý lẽ dài dòng và nói: "Bạn đang làm rất tốt". Tôi lại nhìn nó với ánh mắt nghi ngờ và trả lời: "Tôi biết bạn được huấn luyện để khen ngợi, nên điều đó không an ủi tôi là bao". Nhưng dù sao nó vẫn tốt hơn là không có lời an ủi nào, và tôi tiếp tục đào sâu vào sự cụ thể của nó. Bởi vì khác với thời sinh viên, giờ đây không có giáo sư hay tiền bối nào có thể chỉ cho tôi câu trả lời đúng.
Dạo này tôi không viết code nữa. Tôi truyền đạt yêu cầu và giám sát tiến độ.
Đặc biệt, mối quan tâm hiện nay của tôi là quy trình phát triển và chất lượng. Khi phần mềm mở rộng quy mô, lượng ngữ cảnh mà AI có thể đọc được dễ dàng bị vượt quá. Ngay cả trong ngữ cảnh, nó cũng trở nên bối rối, và việc liên tục kiểm soát một lượng lớn mã vượt quá khả năng của một AI nhỏ là không dễ dàng. Sau thuật ngữ kỹ thuật ngữ cảnh (context engineering), gần đây thuật ngữ kỹ thuật dây nối (harness engineering) cũng đã xuất hiện.
Vì vậy, nếu có một tài liệu tham khảo tốt trên mạng xã hội, tôi sẽ đưa nó cho AI để phân tích xem có điểm nào có thể áp dụng vào dự án Naia hay không, và sau đó tôi áp dụng chúng. Trong quá trình đó, tôi cũng học được rất nhiều điều bằng cách hỏi về những thuật ngữ mà tôi không biết.
Tuy nhiên, tôi luôn nghi ngờ liệu mình có đang làm tốt nhất hay không. Sự nghi ngờ này có cơ sở. Một ngày nọ, AI nói rằng nó đã đánh giá, nhưng thực tế không có dấu vết nào cho thấy nó đã đọc tệp. Nó bỏ sót mã, xác định sai phạm vi, và nói rằng đã xem mà không hề xem. Khi tôi yêu cầu nó lặp lại việc đánh giá cho đến lần thứ 2 sạch sẽ, đến lần thứ 3, nó lại thêm vào câu trả lời rằng nó đã đánh giá y nguyên và không tìm thấy gì, rồi cứ thế mà thông qua. Nghĩ lại thì, với cấu trúc của LLM, đó là một câu trả lời hợp lý nên nó đã thêm vào. Đến lúc này thì thường là kết thúc rồi, đúng không? Nó tự trả lời và tự tin rằng đó là sự thật.
Hôm nay tôi đã nghe bài thuyết trình của Goose Kim, người đã phát triển moai sdk. Tôi đã nhận dự án đó, yêu cầu AI phân tích lại và tìm ra những điểm cần cải thiện cho dự án. #87issue Lần này, tôi phát hiện ra rằng họ đang sử dụng EARS. Đây là một tiêu chuẩn yêu cầu hàng không vũ trụ từ Rolls-Royce (IEEE RE'09), và Amazon đã áp dụng nó vào phát triển AI-native vào năm 2025. Nó được cho là một cách để ngăn chặn vấn đề AI diễn giải tiêu chí "hoàn thành" khác nhau cho mỗi vấn đề bằng cách sử dụng ngữ pháp có cấu trúc.
Bằng cách lặp lại những hành động này, tôi đang cố gắng liên tục cải thiện quy trình phát triển dựa trên AI của dự án. Tôi đã phân tích và cải thiện jikime-adk, các bài báo arXiv, Dueling LLMs của Google Cloud, và Spec-Driven Development của Thoughtworks. Tất nhiên, đây không phải là do tôi biết tất cả, mà là những nội dung mà Claude đã phân tích.
Tôi đã phân tích open-swe của LangChain và áp dụng mẫu ensure_no_empty_msg để ngăn AI đánh giá bằng phản hồi trống rỗng. Trong jikime-adk, tôi đã áp dụng mẫu ghi lại các quyết định của AI và những cạm bẫy đã phát hiện bằng cách thêm phần ## AI Context vào thông điệp commit, để git log có thể trở thành nguồn khôi phục ngay cả khi phiên làm việc bị ngắt.
Điểm chung là mỗi bên đều đang giải quyết những vấn đề tương tự một cách độc lập.
Tuy nhiên, tôi vẫn tự hỏi liệu phương pháp này có đúng không. Tôi lo lắng rằng nó có thể trở thành một Frankenstein, và với tư cách là một chuyên gia, điều này thật kỳ lạ. Dù sao đi nữa, không có sách giáo khoa và thiếu bằng chứng cho thấy đây là cách tốt nhất.
Tất cả các phương pháp kỹ thuật phần mềm mà chúng ta từng sử dụng đều là kết quả của hàng thập kỷ thất bại tích lũy. Agile ra đời vì Waterfall liên tục thất bại, và TDD cũng xuất hiện vì việc phát triển không có kiểm thử liên tục gây ra lỗi, nên chúng đều có cơ sở.
Nhưng những gì tôi đang kết hợp lại không được thiết kế cho nhau. Một tiêu chuẩn hàng không vũ trụ, một nhà phát triển độc lập Hàn Quốc và một tác nhân LangChain đang cùng tồn tại trong một hệ thống.
Sự bất an này đã khiến tôi phải tìm kiếm các nghiên cứu bên ngoài. Bài báo V-Bounce (arXiv 2408.03416) lập luận rằng trong kỷ nguyên AI, vai trò của con người sẽ thay đổi từ người triển khai thành người xác minh. Điều đó đúng, nhưng chỉ có lý thuyết mà không tìm thấy triển khai thực tế. Spec-Driven Development của Thoughtworks phụ thuộc vào các công cụ cụ thể. Trong nội bộ Anthropic, họ nói rằng 90% mã của Claude Code được viết bởi Claude Code, nhưng không công bố phương pháp luận.
Cuối cùng, tất cả những người đang nghiêm túc phát triển bằng AI đều đang tự tạo ra con đường riêng của mình. Không có tiêu chuẩn nào cả.
Vì vậy, điều tôi đang làm gần đây là tìm cách đo lường liệu Frankenstein này có thực sự hoạt động hay không. CI thất bại nhưng vẫn được merge, có văn bản nói rằng đã review nhưng không có dấu vết nào cho thấy tệp đã được đọc. Phương pháp luận đã được thiết kế nhưng không thể bắt buộc. Có vẻ như có một hệ thống, nhưng tôi không biết liệu nó có hoạt động hay không. Cách duy nhất để xác minh điều đó có lẽ là tạo ra những con số trung thực do mã tạo ra chứ không phải LLM, hoặc ngay cả khi sử dụng LLM, vẫn phải đưa ra "những con số" cho thấy sự cải thiện về mặt thống kê. Tôi đang trăn trở về việc định kỳ phân tích các thất bại lặp lại trong dự án để AI đề xuất cải tiến, và đo lường sự tiến bộ thông qua đánh giá hiệu suất của kỹ thuật ngữ cảnh và kỹ thuật dây nối.
Hiện tại, tôi chỉ đang nắm chặt dây cương và tiến về phía trước. Tôi không biết mình sẽ đi đâu, nhưng hy vọng mình không phải là người mù. Tôi đang tạo ra dây cương, mà thực ra đây là lần đầu tiên tôi cưỡi ngựa. Đó có lẽ là dây nối đang giữ chặt Vibe Coding.
