Nếu dùng poethepoet thì có thể định nghĩa và sử dụng các tác vụ ngay trong pyproject.toml, nên tôi dùng nó thay cho just.

HDDkkkkkkkkkkkkkkkk

Đúng vậy đó hahaha

Giống như đang so sánh ô tô với marathon..

kkkkk "cứ như thể tính năng đó phải tồn tại vậy"

Tôi hoàn toàn đồng ý với bạn!

kkkkkk

Phát triển dựa trên ảo giác... chắc có thể gọi là vậy nhỉ;;

> Có vẻ sẽ rất hợp nếu đảm nhận vai trò lead, nhưng người đó đã từ chối những vai trò bổ sung như vậy.
> Khi tác giả đề xuất những thử thách mới để phát triển thì ...

Từ góc nhìn của một kỹ sư, chẳng phải phát triển là làm tốt hơn nữa những việc mình vốn đã làm tốt sao?

Cảm ơn bạn vì những lời chia sẻ hay!!

Có lẽ họ đã nghĩ đến mức lương và chế độ đãi ngộ không tăng tương xứng so với trách nhiệm và khối lượng công việc ngày càng nhiều hơn.

Điều này là rất thường thấy
Tất nhiên, nếu là một người lãnh đạo tốt, họ sẽ lắng nghe một cách tử tế
và giải quyết vấn đề một cách chính xác

Dù xem sách hay đọc câu chữ nào đi nữa,
điều về mục số 3 lúc nào cũng được viết như vậy,
nhưng trên thực tế
tại sao lại hỏi những điều như thế này
tại sao đến giờ mới nhắc tới
đến cả cái này cũng hỏi sao
bộ ba này có thể khiến bạn bị nhìn nhận là một đối tác kém chất lượng

Hiện tại tôi cũng đang làm một Computer-use Agent tên là UseDesktop.

https://youtu.be/aBkbsvMxP_A?si=uaugxKQEu4ZEz7jq

usedesktop.com

Vì vậy tôi đồng ý với phần lớn nội dung.

Bài này thiên về bức tranh tổng quan hơn là các mẹo thực chiến, nên nếu bổ sung thêm vài kinh nghiệm khi phát triển agentic/agent dựa trên LLM thì cuối cùng, LLM là thứ dựa trên transformer (tức là suy luận dựa trên xác suất, dự đoán token tiếp theo từ token/state hiện tại theo ngữ cảnh/ngữ nghĩa chứ không thực sự “hiểu” và nói ra từ tiếp theo), nên dù có viết sys prompt tốt đến đâu thì cũng khá thường xuyên không trả ra câu trả lời như mong muốn (ví dụ yêu cầu trả lời bằng JSON output nhưng thỉnh thoảng lại quên mất } chẳng hạn). Vì vậy, việc luôn thêm nhiều fallback function dựa trên regex là bắt buộc.

Ngoài ra, khi viết sys prompt để buộc structured output thì thường nên dùng non-reasoning model, và context càng dài thì hallucination càng hay xảy ra, nên thà tạo nhiều sys prompt rồi chain chúng lại còn tốt hơn.

Khi phát triển dịch vụ, có thể phát sinh nhiều loại lỗi, nên mấu chốt là phải thiết kế cấu trúc service theo hướng mô-đun hóa và fault-tolerant (ví dụ supervisor agent chạy async còn các agent khác chạy sync), đặc biệt là với các hệ agentic/agent vốn thường xuyên tạo ra unexpected output.
Vì thế, ngay từ đầu khi viết code thì nên cố gắng tuân thủ SRP và viết theo hướng declarative; tôi muốn nói rằng tiếp cận theo kiểu functional sẽ tốt hơn (= không có side effect và flow trực quan).

Ngoài ra, còn tùy bạn dùng LLM qua API hay tự phục vụ model, nhưng nếu định tự phục vụ SLM hoặc LLM thì đừng model serving trên cùng server đang host backend; nên tách riêng IO bound task và CPU bound tasks (tức các tác vụ cần GPU, phép nhân ma trận v.v.) sang các server khác nhau để fault-tolerant hơn và tốt hơn (ví dụ host CPU bound task trên runpod).

Ngoài những điều này còn nhiều mẹo phát triển khác nữa, nhưng sợ dài quá nên tôi chỉ viết đến đây thôi.

Hy vọng sẽ giúp ích cho ai đó.

Các dịch vụ được cài đặt trên máy chủ từ xa riêng thì sao?

Bản dịch tiếng Hàn thì nhét bản dịch máy tệ hại vào đã đành, giờ còn tiến hóa hơn nữa rồi nhỉ. Chặn còn chưa nổi dịch máy, thì giờ cứ nếm luôn cả đống AI tệ hại đó đi!

Cgi thì còn tạm hiểu được, nhưng phản ứng về JSP mới thật sự gây ngạc nhiên haha
JSP đã trở thành một di vật cổ đại đến mức đó rồi sao.

Tôi thực sự ghét các tính năng AI, đặc biệt là những dịch vụ cứ chờ sẵn ở chế độ nền rồi nói rằng sẽ giúp đỡ.
Nếu chạy từ xa thì có vấn đề là thông tin của tôi bị cung cấp, còn nếu chạy cục bộ thì lại có vấn đề là tiêu tốn tài nguyên máy tính của tôi (CPU, bộ nhớ, pin, ...).

Có vẻ sẽ là một tài liệu tham khảo tốt.

Một lập trình viên gốc Nga đã chuyển từ Yandex sang Riot, và hiện nay tiếp tục chuyển việc sang JPMorganChase.