(Đây là tài liệu được trình bày tại meetup Claude Code ở Seoul vào ngày 17 tháng 12. Tài liệu trình bày đầy đủ xem tại liên kết này.)
Mục tiêu "tư vấn nội bộ" của đội AX tại Corca
- Xây dựng nền tảng để các thực hành agentic engineering tốt có thể bén rễ tại Corca và cùng nhau phát triển bền bỉ.
- Tại Corca, "thực hành agentic engineering" được định nghĩa là "các phương pháp thực hành nhằm tận dụng AI agent theo hướng vừa nâng cao chất lượng phần mềm vừa cải thiện năng suất"
- Biến năng lực engineering trở thành một năng lực cạnh tranh cốt lõi khác của Corca.
- Vì mục tiêu đó, nhóm bắt đầu bằng việc hỗ trợ đội Moonlight
Tình hình của Moonlight
- Moonlight, sản phẩm chủ lực của Corca, định vị mình là "đồng đội AI cùng đọc paper"
- "Trò chuyện với PDF" là ý tưởng đã tồn tại từ những ngày cực kỳ đầu của ChatGPT. Trong số rất nhiều sản phẩm cạnh tranh như vậy, Moonlight đã sống sót và hiện đang ở giai đoạn đầu của đường cong chữ J (gần đây số người dùng đăng ký từ Trung Quốc tăng mạnh)
- Để đi được đến đây đã có rất nhiều thử-và-sai, nhưng năng lực cạnh tranh cốt lõi là bằng cách nào đó vẫn duy trì được tốc độ và nhịp độ phát triển tính năng
- Một vài quyết định ban đầu để ưu tiên tốc độ
- typescript strict: false
- Giảm thiểu kiểm thử tự động
- Chấp nhận trùng lặp và hardcoding
- Không phân chia rạch ròi theo vai trò. Gần như mọi thành viên trong nhóm (6/7 người) đều triển khai bằng coding agent và gửi PR
- Nhưng sau khi đi vào quỹ đạo, các khoản nợ kỹ thuật bắt đầu dần gây khó khăn
- Sản phẩm ngày càng phức tạp hơn, số thành viên mới trong nhóm tăng lên, đồng thời có nhiều thử nghiệm chạy song song
- Tốc độ cải thiện sản phẩm chậm dần, còn cảm giác bất an thì tăng dần
- Gánh nặng review code dồn vào một vài người và phát sinh nhiều sai sót lớn nhỏ
Bài toán cấp bách của đội AX
- [Sản phẩm] Hãy để chất lượng của sản phẩm Moonlight được nâng lên trong khi tốc độ bổ sung và cải thiện tính năng cũng nhanh hơn!
- [Đội ngũ] Hãy để bất kỳ ai cũng dễ sửa code Moonlight hơn, và giảm bớt áp lực sau khi deploy!
- [Văn hóa] Vì mục tiêu 1 và 2, hãy để đội Moonlight và đội AX cùng hợp tác khám phá, áp dụng, nâng cấp các thực hành agentic engineering tốt, rồi dần lan tỏa chúng trong công ty!
→ Nhóm nhận định rằng nếu coding agent có thể đưa ra phản hồi tốt hơn thì phần lớn vấn đề sẽ được giải quyết
Làm sao để agent đưa ra phản hồi tốt hơn?
[1] Hướng nó đi vào con đường tốt ngay từ đầu
- Nếu chất lượng codebase cao thì sẽ có lợi ở 3 khía cạnh
- Giảm lượng context không cần thiết phải đưa vào (Less is More)
- Agent sẽ học theo các pattern tốt sẵn có
- Có thể tạo thiên lệch để xác suất xuất hiện câu trả lời được lấy mẫu từ vùng mã nguồn chất lượng cao trong dữ liệu pretraining cao hơn
- Có nhiều nghiên cứu cho thấy khi đưa context chất lượng cao vào thì sẽ nhận được phản hồi tốt.
- (Phỏng đoán cá nhân) Nếu gửi yêu cầu cho agent trong một codebase có thứ tự import được sắp xếp gọn gàng thì sao? Có phải các đoạn code trong dữ liệu pretraining có import được sắp xếp tốt cũng thường là code chất lượng cao hơn không?
- Từ blog của Anthropic: "Chỉ cần khiến nó dùng font thú vị hơn thôi thì các yếu tố thiết kế khác cũng được cải thiện"
[2] Không cho nó đi sai đường
- Có thể chặn các hướng đi sai bằng nhiều công cụ phân tích tĩnh như kiểm tra lỗi type, kiểm tra lỗi linter, kiểm thử tự động, kiểm tra dead code, kiểm tra độ dài file, kiểm tra độ phức tạp, cưỡng chế quan hệ phụ thuộc, cưỡng chế tỷ lệ test code so với production code, v.v. (bắt nó làm lại cho đến khi vượt qua tiêu chuẩn)
[3] Chủ yếu giao cho nó những việc nó làm tốt
- Những việc con người làm tốt, LLM làm tốt và thuật toán làm tốt là khác nhau. Nếu chọn đúng cái gì nên dùng vào lúc nào thì có thể tiết kiệm thời gian và chi phí
- Ví dụ: nhắc đừng quên i18n key so với bảo chạy script tìm các i18n key bị sót
- Việc ai giỏi gì vào lúc nào sẽ thay đổi theo thời gian và tùy theo domain của bài toán. Nếu hình thành được thói quen liên tục cập nhật "cảm giác" này trong domain của mình thì sẽ rất có lợi
- Ví dụ: khi có model mới thì thử test bằng benchmark riêng của mình, hoặc làm theo các ví dụ nổi tiếng trên mạng xã hội
[4] Hỗ trợ những việc nó không làm tốt
- Tuy nhiên luôn cần xác nhận liệu đó có thật sự là việc nó không làm tốt hay không. Trừ khi việc giao phó là rủi ro, hoặc quá kém hiệu quả..., còn không thì để AI/thuật toán làm nhiều hơn con người vẫn tốt hơn. (Vì chi phí token rốt cuộc cũng sẽ rẻ ngang tiền điện)
- Nếu thật sự làm không tốt thì sao? Hãy để LLM khác review
- Ví dụ đơn giản nhất là: "Đây là code do một dev mới vào nghề viết..."
- Muốn AI làm việc giỏi hơn thì phải cung cấp môi trường để AI có thể làm việc tốt hơn. Nói cách khác, những gì agent (hiện tại) có thể làm chưa tốt (trong bối cảnh này) cần được con người, thuật toán và các agent khác bổ trợ
Những điểm đã chú ý
- Moonlight là một tên lửa vừa mới bắt đầu cất cánh, còn đội AX là khách đến từ bên ngoài
- Tuyệt đối tránh kịch bản người ngoài đến, "làm hộ" cái gì đó rồi quay về
- Cố gắng không để nỗ lực cải thiện chất lượng làm cản trở phát triển tính năng
- Thống nhất trộn theo tỷ lệ phù hợp giữa những việc không làm thay đổi quá lớn cách làm việc thường ngày với những việc tuy thách thức nhưng hiệu quả
→ Hình dung một bức tranh trong đó đội AX và đội Moonlight "cùng nhau" khám phá rồi áp dụng các thực hành phù hợp với đội ngũ và sản phẩm, đồng thời trong quá trình đó chất lượng code, chất lượng sản phẩm và năng lực của đội cũng cùng được nâng lên
Những kết quả tiêu biểu trong 4 tuần qua
[1] Các thói quen tốt đang được hình thành, và các pattern tốt cũng đang được phát hiện
- Mỗi ngày đều đẩy các commit refactor siêu nhỏ (tidying) mà không cần review PR
- Prompt để bắt chước các commit mẫu mực trong quá khứ (như hỗ trợ model mới), và prompt để phát hiện rồi thu thập những pattern như vậy
- SKILL review code trong vai một senior
[2] Bắt đầu đo lường và trực quan hóa các chỉ số chất lượng code. Số lỗi/cảnh báo trên mỗi dòng code đang giảm nhanh
- Các chỉ số chất lượng code đôi khi giảm dần đều, đôi khi giảm rất ấn tượng
- Việc tidying mỗi ngày cải thiện codebase từng chút một, và điều đó tạo ra sự tự tin rằng đến một lúc nào đó có thể thực hiện những refactor lớn và những công việc lớn hơn
- Áp dụng knip theo từng package để xóa cả những đoạn code cũ và không còn dùng nữa
- Chỉ số luôn phải mang tính bổ trợ cho nhau. So với việc một codebase 1000 dòng có 1000 lỗi, thì một codebase 100.000 dòng có 5000 lỗi vẫn tốt hơn nhiều. Vì vậy thay vì chỉ nhìn số lượng tuyệt đối, nhóm xem tỷ lệ lỗi theo số dòng code để có chỉ số quản lý lành mạnh hơn
- Số dòng có ý nghĩa, không tính comment và khoảng trắng, được đo bằng tokei
[3] Sửa được vấn đề memory leak kéo dài hơn 1 năm
- Tận dụng tổng lực nhiều công cụ và prompt, bao gồm repomix, và sau vài lần thử đã bắt được vấn đề memory leak tồn tại suốt hơn 1 năm
- Cả nhóm đang vui vì có vẻ có thể hạ tier của server instance xuống
[4] Đã có cấu trúc abstraction, prompt và script giúp thêm/xóa dễ dàng và an toàn hơn các thử nghiệm chạy song song vài cái mỗi tuần
Kết quả là bộ ba yếu tố đang khớp với nhau rất tốt: chất lượng code ngày càng tăng, phát triển tính năng vừa an toàn hơn vừa nhanh hơn, và năng lực engineering (agentic) của đội cũng tăng đều
Những lần thử-và-sai
- Dĩ nhiên ngay từ đầu mọi thứ không diễn ra suôn sẻ. Ban đầu nhóm muốn làm đồng thời hai việc
- Dù có phần bất an nhưng đưa vào ngay các thay đổi có giá trị lớn: bật strict option, áp dụng rule eslint gắt hơn, xóa toàn bộ dead code trong một lần, v.v.
- Dù giá trị nhỏ hơn nhưng đi từng bước an toàn: mỗi ngày để lại commit tidying, v.v.
- Nhưng vế đầu thì vì bất an nên "không thể" làm, còn vế sau thì vì không thú vị nên "không muốn" làm
- Vì vậy nhóm đổi sang cách này
- Làm các việc thách thức theo cách an toàn hơn (bật
tsc strictrồi sửa và tắt theo từng file, áp dụng eslint với số rule tối thiểu, chạy knip từng package một, v.v.) - Làm các việc an toàn theo cách có giá trị hơn (ví dụ tạo prompt để nhận đề xuất tidying cho những thay đổi gần đây)
- Làm các việc thách thức theo cách an toàn hơn (bật
- Dù vẫn còn rất nhiều bài toán phía trước
- Bật
typescript: strict - Áp dụng zod để khớp hợp đồng server-client
- Đưa vào các eslint rule gắt hơn
- Tăng độ bao phủ kiểm thử tự động
- Chặn các hướng đi sai bằng nhiều công cụ phân tích tĩnh đa dạng hơn
- Bật
- Nhưng cả nhóm đang tiến lên cùng nhau, đều đặn, và tuyệt đối không chậm chạp
One More Thing: Thói quen học tập + debug của tôi
Trong bối cảnh như vậy, hỏi AI rồi hỏi thêm người giỏi để đối chiếu chéo giúp học được rất nhiều. Quá trình này cũng được lưu lại trong GitHub PR, issue và Slack để chia sẻ trong tổ chức
- Người khác biết những điều mà tôi không biết
- Người đó đã biết kiến thức/kinh nghiệm này bằng cách nào? Họ nhận ra vấn đề này từ tín hiệu nào?
- Phát hiện ra sai sót hay bug của tôi, cũng như các anti-pattern trong codebase
- Những nguyên nhân nào khiến vấn đề này gần như chắc chắn sẽ xảy ra? Để lần sau bớt mắc lỗi hơn và phát hiện lỗi sớm hơn thì cần cải thiện cấu trúc thế nào?
Kết luận
- Nếu giúp AI đưa ra phản hồi tốt hơn thì có thể giải quyết được phần lớn vấn đề của đội sản phẩm
- Nâng chất lượng codebase lên (đi vào con đường tốt ngay từ đầu), và đưa vào nhiều công cụ khác nhau (chặn đường đi sai)
- Hãy giúp các thành viên nâng cao năng lực agentic engineering của mình (giao việc nó làm tốt, hỗ trợ việc nó làm chưa tốt)
- Nếu hợp tác thông minh với AI để năng lực của đội được nâng lên và môi trường làm việc tốt được thiết lập, thì việc "nâng cao chất lượng" và "tăng tốc độ bổ sung/cải thiện tính năng" hoàn toàn có thể diễn ra đồng thời
- Đừng mang cái tốt từ "bên ngoài" vào để giúp một lần rồi thôi; hãy cùng nhau khám phá và thử nghiệm từ "bên trong". Hãy đo lường, trực quan hóa, ăn mừng và học hỏi lẫn nhau
3 bình luận
Bài về buổi meetup cũng đã lên rồi.
[Phóng sự] "Người dùng Claude số 1 tại Hàn Quốc đã xuất hiện"… ghé thăm sự kiện meetup của Anthropic
https://n.news.naver.com/mnews/article/092/0002402940
Khoảng 1,8 triệu won một tháng, kinh thật.
Có lẽ đây cũng sẽ là một cách có ý nghĩa để hỗ trợ sự tham gia tích cực và sự phát triển của các lập trình viên junior.
Ồ đúng vậy haha, bên đó bọn tôi cũng đang làm rất chăm chỉ.