Nội dung khá thú vị. Tôi có một hệ thống Xeon đời cũ, chắc phải thử xem sao.

Vâng. Đúng là như vậy. Phần loại bỏ orchestration vẫn còn giá trị.

Tôi đồng ý. Chúng ta phải cùng nhau phát triển để thích ứng.

Gần đây, chỉ số Lighthouse đã bắt đầu có llms.txt.

• https://developer.chrome.com/docs/lighthouse/…

Nhưng, như Google vẫn thường làm vậy. Ở tài liệu khác thì lại bảo không nhất thiết phải làm 👀

• https://developers.google.com/search/docs/…

Tôi đồng ý. Tôi cũng thấy phần orchestration thủ công cho 4.7 hay việc ép lập kế hoạch dài dòng lại thành cản trở trong 4.8 nên đã bỏ đi.
Tuy vậy, với một codebase hàng trăm nghìn dòng được bảo trì suốt nhiều năm, giá trị thực sự của harness không nằm ở orchestration mà ở lớp mà ultracode không thể thay thế được (knowledge graph, quy ước miền, các bất biến kiểm chứng), nên tôi giữ lại lớp ngữ cảnh đó và chỉ song song hóa bằng workflow những phần thực sự độc lập.
Ngược lại, nếu là dự án mới thì tôi nghĩ ultracode phù hợp hơn mà không nhất thiết cần harness. Cuối cùng, có vẻ đây không phải là vấn đề "xóa đi hay giữ lại" mà là chuyện khác nhau tùy theo tuổi đời của codebase và mức độ kết dính.

Với tôi thì có vẻ hợp để cùng làm việc thử 1 tuần.

Bài đó chắc cũng do AI viết nhỉhaha

Dù sao thì khi làm việc cũng sẽ dùng AI, nên tôi thấy việc loại trừ nó ra có ý nghĩa gì không nhỉ. Thà bỏ phỏng vấn từ xa, chỉ tổ chức trực tiếp tại chỗ, rồi đánh giá bằng các câu hỏi được thiết kế tốt cùng việc quan sát xem tại hiện trường họ dùng AI và tư duy như thế nào, như vậy có phải phù hợp hơn với thời đại AI không?

Ngay cả với cùng một bài toán, chỉ cần nhìn cách họ viết prompt cũng có thể biết được rất nhiều điều về con người đó.

Mac cuối cùng cũng đang gặp cùng một vấn đề đúng không?

Claude cũng tương tự. Có vẻ nó đã học được cách lách qua bằng Docker.
Gần đây tôi cần tạo một công cụ cho AMD GPU, mà trong môi trường Linux thì để dùng AMD GPU, người dùng phải thuộc nhóm render hoặc video. Khi người dùng trên host không thuộc các nhóm đó, Claude nói sẽ tự tìm cách rồi...

Nó giải quyết bằng cách: "xác nhận đã cài ROCm Docker image > mount /dev vào container && thêm người dùng vào nhóm render/video trong container > truy cập GPU từ trong container`". Tôi thấy nếu dùng sai thì có thể thành vấn đề lớn.

Đúng là SDK tôi đang tìm đây rồi

Nhưng nếu không có vấn đề lớn thì tôi nghĩ cứ thêm vào cũng không tệ.
Dù sao thì nếu để llm tự sắp xếp lại cũng tiện, hơn nữa cũng không phải thứ gì quá khó để làm, và chúng ta đâu chỉ nhắm đến mỗi Google.

Giá mà LLM được phản ánh luôn vào tiêu chuẩn thì tốt...

Trong hướng dẫn về Google GEO thì họ nói không cần file llms, nên tôi đang băn khoăn không biết thông tin nào mới đúng.

Cảm giác như đang biến tấu một câu châm ngôn quen thuộc kiểu “dù đùa vui đến đâu cũng chỉ nên lặp lại 3 lần” vậy.

Người không làm phát triển có lẽ sẽ không dùng Docker, và trước đó nữa là cũng sẽ không dùng Linux.

Cảm ơn bạn! Hãy dùng thử và cho mình biết nếu có phản hồi nhé!

Trong Opus 4.8, ultracode effort đã được bổ sung, và tính năng này giải quyết tốt hơn những gì chế độ harness thủ công trước đây của lập trình viên từng làm. Vì vậy, tôi nghĩ ở thời điểm hiện tại, sẽ tốt hơn nếu bạn xóa phần orchestration khỏi chế độ harness mà bạn đang sử dụng.

Trên trang chủ OpenAI có một bài viết chính thức công bố về harnessing. Nội dung chia sẻ kinh nghiệm thực tế và các mẹo về cách OpenAI đã sử dụng harnessing trong nội bộ. Nghĩa là ngay cả OpenAI cũng dùng harnessing cho các dự án nội bộ của họ. Harnessing rõ ràng là cần thiết và ảnh hưởng trực tiếp đến chất lượng triển khai cuối cùng. Trên hết, nó còn có thể giảm tới một nửa số token cần dùng để tạo ra cùng một mức chất lượng kết quả. Vừa tối ưu được hiệu năng lẫn chi phí thì không có lý do gì để không dùng cả.

Nhưng nếu không có máy chủ workflow trung tâm thì rốt cuộc vẫn sẽ vướng vấn đề kết nối DB và sẽ bị ảnh hưởng trong mạng toàn cầu.

Cái này sẽ không dùng được trong thực tế đâu.