Bối cảnh
Mọi chuyện bắt đầu từ vài buổi họp 1-1 với team lead của tôi. Anh ấy khá tò mò về cách tôi dùng các công cụ AI, xây dựng Harness cá nhân và tổ chức workflow AI Coding của mình. Lý do chính là vì tôi đang giao requirement rất nhanh và chất lượng, thậm chí đã đảm nhận vai trò owner chính cho một số dự án. Thế nên, tôi tranh thủ cơ hội này để hệ thống lại workflow AI hằng ngày của mình. Hiện tại, trong nhóm tôi chủ yếu làm phát triển Agent, đồng thời duy trì logic nghiệp vụ backend hiện có.
Trước đó, tôi từng chia sẻ các workflow liên quan trên Xiaohongshu. Bối cảnh lúc đó là GPT-5.4 và Opus 4.6 đã có thể hoàn thành tốt task khi được cung cấp context chuẩn xác và ràng buộc hợp lý. Sự trỗi dậy của Harness Engineering giúp mọi người nhận ra: bạn có thể kiểm soát các model mạnh mẽ tốt hơn bằng cách thêm vào những ràng buộc.
Ví dụ, các Skill như Superpowers đưa ra một cách triển khai khá "nặng", chủ yếu xoay quanh Spec và TDD, giúp mọi người tổ chức và đẩy tiến độ task dễ dàng hơn.
Nhưng làm vậy cũng có mặt trái. Cảm giác rõ rệt nhất là: Token tiêu hao cực kỳ nhanh. Các Skill như Superpowers chứa rất nhiều Workflow dùng để ép model phải làm theo bước tiếp theo. Dù xét trên tổng thể, một bước nào đó không còn cần thiết nữa — chẳng hạn context đã đủ và có thể code luôn — model vẫn cứ máy móc chạy theo quy trình đã định sẵn.
Khi các model mới ra mắt, tôi thấy nhiều developer chia sẻ rằng họ gần như không còn dùng mấy Skill quá nặng nề này nữa. Một lý do chính là sau khi năng lực model được nâng cấp, những ràng buộc và quy trình mà trước đây ta tưởng là hữu ích lại trở thành nhiễu đối với model. Chẳng hạn, khi OpenAI ra mắt Astra, họ đã viết hẳn một bài blog hướng dẫn cách dọn dẹp các Skill và system prompt không cần thiết để cải thiện trải nghiệm sử dụng model.
Vì vậy, bài viết này sẽ đúc kết từ thực tế làm việc của tôi trong vài tháng qua để chia sẻ những phương pháp đang thực sự hiệu quả với bản thân, bàn về cách tận dụng tốt hơn các Agent nhằm nâng cao hiệu suất phát triển hằng ngày.
1. Những Skill và Prompt tôi thường dùng
Cách tôi phân bổ công cụ hiện tại:
Hiện tôi chủ yếu dùng Codex + GPT-5.6 Sol để code, còn Astra lo phần planning. Trước khi Astra ra mắt, việc planning chủ yếu được giao cho GPT-5.6 Sol Max.
Với những requirement đơn giản, tôi dùng pi + DeepSeek V4 Flash để triển khai; việc phản biện giải pháp (adversarial review) và Code Review chủ yếu do Claude 5 Fable đảm nhận. Trong các dự án cá nhân, tôi cũng dùng bản web của GPT-6 Pro để thiết kế giải pháp chính.
Những Skill tôi thường dùng
- think: Skill của tw93, chủ yếu dùng để chốt giải pháp và brainstorm.
- grill me / grill with docs: Chủ yếu dùng để làm rõ requirement. Bằng cách liên tục đặt câu hỏi, nó giúp làm sáng tỏ mục tiêu, ràng buộc và các đánh đổi, sau đó ghi nhận lại thành ADR hoặc CONTEXT.md tùy theo quy trình phát triển. Nó giúp tôi đào ra những vấn đề bị bỏ sót lúc chốt yêu cầu ban đầu.
- implement: Dùng kèm với grill, nằm trong bộ Skills của Matt Pocock, dùng để triển khai các plan hoặc Issue đã được định nghĩa rõ ràng.
- ponytail: Dùng để dọn dẹp những chỗ AI thiết kế thừa (over-design), giúp việc Review dễ thở hơn. Tôi dùng cái này khá thường xuyên vì GPT-5.6 Sol rất hay over-design.
- handoff: Đóng gói context hiện tại thành file, giúp tiếp nối task ở session mới dễ dàng hơn. Tôi thường dùng nó để chuyển giao từ Codex sang Claude Code hoặc pi agent.
- check: Dùng để review code, thường dùng khi submit MR.
- Các Skill tự đúc kết từ công việc và dự án cá nhân: Chủ yếu là các SOP quy trình có thể tái sử dụng, ví dụ như end-to-end testing. Lời khuyên của tôi là trong công việc hằng ngày, nếu một quy trình lặp lại quá ba lần, hãy nhờ Codex đóng gói nó thành một Skill để dùng lại luôn về sau.
Những Prompt tôi thường dùng
Dạo này tôi hiếm khi tự viết những đoạn Prompt dài dằng dặc. Khi cần, tôi thường để Codex lo phần soạn thảo. Ví dụ, sau nhiều vòng thảo luận, nếu muốn chuyển context hiện tại cho GPT Pro để thiết kế giải pháp, tôi sẽ bảo Codex tạo một Prompt handoff hoàn chỉnh trước.
Ngoài ra, tôi rất hay dùng các loại Prompt siêu ngắn dưới đây.
Đôi khi chúng mang lại hiệu quả kiểu "một câu nói thay ngàn lời". Tôi hiểu chúng như những "lối tắt tư duy" của model.
Chúng không phải thần chú, mà là những phương pháp luận đã được chuẩn hóa cao trong tri thức nhân loại. Trong quá trình training, model đã đọc vô số paper, code, tài liệu thiết kế và các cuộc thảo luận liên quan, nên thường ta không cần viết tay hàng trăm dòng Workflow, chỉ cần bảo nó áp dụng phương pháp tư duy nào là đủ. Dưới đây là một số prompt tôi thấy cực kỳ hiệu quả qua thực tế sử dụng:
- First Principles (Tư duy nguyên bản): Đừng tối ưu tiếp theo hướng giải pháp cũ, hãy hỏi lại xem vấn đề này thực chất nên được giải quyết thế nào. Ví dụ, nếu một API bị chậm, bạn có thể nói:
Đừng tiếp tục thiết kế dựa trên giải pháp mặc định là "thêm Redis cache". Hãy phân tích từ first principles xem tại sao API này chậm, và giải pháp tối thiểu cần thiết là gì.
Trọng tâm của model sẽ chuyển từ "thiết kế Redis thế nào" sang:
Nút thắt nằm ở SQL, network, serialization, lock contention hay tính toán trùng lặp? Nếu thêm index vào SQL là xong thì việc gì phải lôi Redis vào?
Loại Prompt này cực kỳ phù hợp khi bạn nghi ngờ "có khi câu hỏi đặt ra đã sai ngay từ đầu".
- Adversarial Review (Phản biện đối kháng): Đừng tìm lý do bảo vệ giải pháp của tôi, hãy cố chứng minh nó sai đi.
Cách hỏi thông thường sẽ là:
Giúp tôi xem giải pháp kỹ thuật này có vấn đề gì không.
Có thể đổi thành:
Hãy adversarial review giải pháp này, ưu tiên tìm các phản ví dụ có thể lật đổ những giả định cốt lõi.
Giả sử giải pháp của bạn là "dùng distributed lock để xử lý request trùng lặp", model sẽ không chỉ bảo bạn set timeout cho lock thế nào, mà bắt đầu vặn lại:
Request trùng lặp có thực sự cần mutual exclusion không? Dùng interface idempotency có giải quyết được không? Lỡ service lock sập thì sao? Lock hết hạn mà nghiệp vụ chưa chạy xong thì sao? Có phải chúng ta vừa tạo thêm một điểm lỗi phân tán mới chỉ để giải quyết một vấn đề cục bộ không?
Loại Prompt này đặc biệt hữu dụng khi review giải pháp và Code Review.
- Ablation Experiments (Thí nghiệm loại bỏ): Hệ thống chạy tốt hơn không có nghĩa là mọi thứ bạn thêm vào đều hữu ích.
Ví dụ, bạn làm liền ba tối ưu:
Sau khi thêm index, Redis cache và batch query, độ trễ API giảm từ 800ms xuống 100ms.
Lúc này, bạn có thể hỏi thẳng:
Hãy thiết kế ablation experiment cho ba tối ưu này để xác định xem lợi ích thực sự đến từ đâu.
Model sẽ thiết kế các nhóm đối chứng theo những tổ hợp khác nhau, bắt đầu từ Baseline, so sánh giữa việc chỉ thêm index, index + cache, index + cache + batch query, v.v.
Cuối cùng, nó có thể phát hiện ra:
Chỉ cần thêm index là độ trễ đã giảm từ 800ms xuống 120ms, hai giải pháp phức tạp còn lại chỉ góp thêm 20ms.
Nhờ vậy, bạn biết rõ hơn đoạn code nào đáng giữ và sự phức tạp nào là không cần thiết.
- Occam's Razor (Dao cạo Occam): Khi hiệu quả tương đương nhau, hãy ưu tiên giải pháp ít giả định và ít phức tạp hơn.
Ví dụ, Agent thiết kế một giải pháp thế này:
Kafka + Redis + Distributed Lock + State Machine + Timed Compensation.
Bạn chỉ cần bồi thêm một câu:
Hãy review lại thiết kế này bằng Occam's Razor, lược bỏ mọi cơ chế không thực sự cần thiết miễn là vẫn đáp ứng được yêu cầu.
Rất nhiều trường hợp, cuối cùng nó sẽ nhận ra:
Tình huống hiện tại chỉ ghi vào một database duy nhất, một transaction cộng thêm unique index là đủ rồi.
Câu này cực kỳ hữu dụng với các Coding Agent hiện nay, vì model rất dễ over-design chỉ để cho "đầy đủ".
- High Cohesion, Low Coupling (Gắn kết cao, phụ thuộc thấp): Kiểm tra lại trách nhiệm và ranh giới của code.
Ví dụ, nếu bạn thấy OrderService đã phình lên 2000 dòng, bạn có thể hỏi:
Hãy review lại ranh giới trách nhiệm của OrderService theo nguyên tắc gắn kết cao, phụ thuộc thấp, đừng tách chỉ để tách.
Model thường sẽ bắt đầu rà soát:
Tại sao service order lại ôm đồm cả tồn kho, coupon, SMS, thanh toán lẫn báo cáo? Logic nào thực sự thuộc về domain order, và logic nào nên giao cho module khác qua các interface ổn định?
Nó kích hoạt không chỉ việc "tách file" đơn thuần, mà cả một hệ thống phán đoán về module hóa, che giấu thông tin, chiều hướng phụ thuộc và phân chia trách nhiệm.
Thế nên, tôi giờ hiếm khi viết kiểu:
Bước 1 phân tích requirement, Bước 2 kiểm tra giả định, Bước 3 tìm phương án thay thế, Bước 4...
Rất nhiều phương pháp luận chín muồi model đã học thuộc rồi. Tôi thích nói thẳng với nó:
Hãy phân tích lại từ first principles, adversarial review giải pháp hiện tại; các cơ chế cốt lõi phải được kiểm chứng qua ablation experiment; giải pháp tuân theo Occam's Razor, code đảm bảo high cohesion và low coupling.
Đằng sau vài chục chữ này thực chất là năm hành động nhận thức khác nhau đã được chỉ định:
Định nghĩa lại vấn đề → Tấn công các giả định → Kiểm chứng mức độ đóng góp → Loại bỏ sự phức tạp → Sắp xếp lại ranh giới hệ thống.
Đây cũng là sự thay đổi của Prompt Engineering trong kỷ nguyên model mới theo góc nhìn của tôi: Thay vì viết sẵn một quy trình tư duy cứng nhắc cho model, tốt hơn là dùng các phương pháp luận chuẩn xác để bảo nó "hãy nghĩ theo cách nào", sau đó bổ sung những ràng buộc thực sự cần thiết cho task hiện tại.
2. Workflow phát triển hằng ngày của tôi
Sau khi nhận requirement, tôi thường chuyển context liên quan cho Agent trước, như PRD, biên bản họp, lịch sử chat và feedback của user, rồi dùng grill để chốt lại yêu cầu với nó.
Mấy tài liệu này thường không phải là một requirement hoàn chỉnh và đồng nhất. PRD có thể chưa được cập nhật, một số giới hạn mới được bổ sung trong cuộc họp, độ ưu tiên bị thay đổi qua tin nhắn. Ngay cả cách tôi hiểu requirement cũng có thể chứa những giả định chưa được nói ra.
Tôi để Agent đối chiếu các tài liệu này với Wiki của team và code hiện có, sau đó làm rõ mục tiêu, ranh giới và các đánh đổi ảnh hưởng đến việc triển khai thông qua việc liên tục đặt câu hỏi. Có câu tôi trả lời được ngay, có câu phải quay lại xác nhận với product hoặc đồng nghiệp liên quan.
Ở khâu này, tôi canh một ngưỡng: khi những câu hỏi còn lại không làm thay đổi đáng kể hướng triển khai và kết quả nghiệm thu nữa thì có thể bắt đầu code.
Tôi không bắt nó phải lên kế hoạch chi tiết mọi thứ từ trước, nếu không bản thân việc chốt requirement sẽ trở thành một quy trình cực kỳ nặng nề.
Kết luận sau khi chốt sẽ được ghi nhận vào Spec hoặc CONTEXT.md, chủ yếu lưu lại vấn đề cần giải quyết lần này, phạm vi, các quyết định quan trọng và tiêu chí nghiệm thu. Việc này cũng giúp các Agent phụ trách triển khai và review phía sau dùng chung một context, không cần đọc lại toàn bộ lịch sử chat.
Sau khi chốt giải pháp, tôi để Agent chính tự quyết định cách thực thi dựa trên độ phức tạp của task. Requirement đơn giản thì code luôn; requirement phức tạp thì xẻ nhỏ thành các Issue có ranh giới rõ ràng, có thể nghiệm thu độc lập. Chỉ những phần có thể chạy độc lập mới được giao cho subagent phát triển song song ở các worktree khác nhau, cuối cùng Agent chính sẽ gom lại.
Coding Agent phải hoàn thành test trước. Khi nó nghĩ là đã xong, tôi sẽ kéo thêm các Agent khác vào phản biện chéo tùy theo độ phức tạp của task. Vấn đề phát hiện được sẽ gom lại gửi cho coding Agent chính, tức Codex, để sửa và verify lại.
Trước khi tự tay Review, tôi cũng chạy end-to-end test.
Hiện tôi không đọc từng dòng code được sinh ra nữa, chủ yếu nhìn vào kết quả test và logic nghiệp vụ cốt lõi. Ở đây có một tiền đề quan trọng: Phạm vi mỗi MR phải đủ nhỏ, và các luồng nghiệp vụ hoàn chỉnh được verify dần trong quá trình phát triển.
MR nhỏ giúp phần thay đổi cần hiểu và phán đoán mỗi lần nằm trong tầm kiểm soát; end-to-end test giúp kiểm tra xem những thay đổi đó có đứng vững khi ghép vào luồng nghiệp vụ thực tế hay không. Khi Review thủ công, tôi tập trung xác nhận logic nghiệp vụ và xem kết quả test hiện có đã đủ để chốt đợt release này chưa.
3. Cách xây dựng End-to-End Testing thân thiện với Agent
AI giờ viết test case rất giỏi, thường viết cả trăm dòng test cho một Bugfix (đặc biệt là 5.6 sol). Nhiều khi, viết nhiều test không phải là vấn đề, nhưng sau khi deploy và上线, ta vẫn dính lỗi ngoài dự kiến.
Qua thực tế làm việc, tôi thấy một vấn đề cốt lõi là: Không cung cấp cho Agent môi trường end-to-end testing, khiến nó mất cơ hội tự phát hiện lỗi ngay trong giai đoạn code và self-test.
Nếu xây dựng được môi trường như vậy, cho phép Agent chạy task từ entry point thực tế của môi trường test một cách tiện lợi, kiểm tra xuyên suốt đến kết quả mà user cần, ta mới dám tự tin để code do AI viết chạy trên hệ thống thật.
Trong thực tế phát triển, tôi đã dựng một bộ môi trường test end-to-end cho nghiệp vụ của nhóm. Agent có thể dễ dàng truy vấn bảng database, xem log và SSH vào máy để troubleshoot.
Toàn bộ quá trình xây dựng thực chất là để Agent trích xuất lại quy trình self-test hằng ngày của tôi, gom các công cụ và năng lực rời rạc lại với nhau: Cái gì tool hóa được thì biến thành MCP hoặc CLI; quy trình nào dùng lại được thì viết thành Skill.
Việc này đúng là tốn công sức lúc đầu, nhưng đừng ngại phiền. Một khi đã dựng xong, tốc độ phát triển tăng lên rõ rệt, giảm thiểu việc làm lại và nguy cơ lỗi production, bạn cũng không phải nơm nớp lo sợ cả ngày xem code AI viết có gây họa gì không.
Xoay quanh việc end-to-end testing thân thiện với Agent, tôi chủ yếu làm bốn việc:
- Giúp Agent làm quen với môi trường: Như hỗ trợ khởi động môi trường test bằng một click, tạo data test, làm rõ phiên bản hiện tại, tài khoản test và quyền hạn, đồng thời cung cấp khả năng dọn dẹp và reset.
- Cho phép Agent thao tác trên hệ thống nghiệp vụ: Chạy luồng nghiệp vụ thực tế qua browser, API hoặc CLI.
- Giúp Agent truy vấn database và log dễ dàng: Xác nhận kết quả lưu trữ qua MCP database read-only, khoanh vùng lỗi qua Skill hệ thống log và truy vấn Trace.
- Tái sử dụng các quy trình nhàm chán nhưng ổn định: Viết các thao tác ổn định thành script, gom entry point và cách troubleshoot thành Skill, giảm bớt can thiệp thủ công và hội thoại lặp đi lặp lại.
Dựa trên những việc đó, đây là vài phương pháp tôi thấy đang hiệu quả:
- Browser Automation: Khi hệ thống nghiệp vụ cần thao tác trên browser, tôi khuyên dùng trình duyệt mã nguồn mở ego lite. Rất tiện và nhanh. Kết hợp với pi agent + DeepSeek V4 Flash, test chạy khá lẹ, tiết kiệm thời gian.
- Gom thao tác về một CLI duy nhất: Tích hợp các Skill tái sử dụng được, MCP đã cấu hình và script đã viết thành một CLI test thống nhất, cung cấp sẵn khả năng kiểm tra môi trường, chuẩn bị data, chạy scenario, truy vấn kết quả và dọn dẹp. Cái này cũng có thể biến thành công cụ tăng hiệu suất nội bộ. Hiện tôi đã đóng gói bộ này thành CLI, lúc gặp lỗi dùng để troubleshoot cũng rất tiện.
- Để Tool phục vụ trực tiếp cho việc nghiệm thu: Truy vấn DB dùng để xác nhận trạng thái, log và Trace dùng để giải thích nguyên nhân thất bại, nhưng kết quả kỳ vọng vẫn phải lấy từ business contract. Đừng để Agent tự suy diễn cái gì là đúng chỉ vì nó thấy hệ thống trả về như vậy. Với logic nghiệp vụ phức tạp, hệ thống hoàn toàn có thể trả về một kết quả trông có vẻ hợp lý nhưng thực chất lại sai spec. Tool giúp ta thu thập bằng chứng, chứ không định nghĩa đáp án đúng thay ta.
- Nếu bản thân Product là một Agent, hãy kiểm tra cả chất lượng câu trả lời: Nếu sản phẩm đang test bản thân nó là một Agent, ngoài việc luồng nghiệp vụ có chạy thông không, chất lượng câu trả lời cũng cần được xem xét. Đây là cái ta hay gọi là Agent Eval, bài này sẽ không đi sâu thêm.
4. Cách Review code do AI viết
Các phần trước đã chia sẻ cách để AI viết code chất lượng cao, nhưng suy cho cùng, developer vẫn là người chịu trách nhiệm chính cho requirement nghiệp vụ.
Không có Review, hệ thống lớn rất dễ toang.
Chắc bạn cũng không muốn nửa đêm bị gọi On-call, để rồi phát hiện ra thủ phạm là đoạn code do AI viết.
Về khoản Review, hiện tôi có mấy thói quen chính:
- Xem tiêu chí nghiệm thu trước, rồi mới đến kết quả test: Đầu tiên kiểm tra tiêu chí nghiệm thu mà Agent đưa ra, sau đó đối chiếu với kết quả end-to-end test trước đó để xem đã đạt kỳ vọng chưa, có sót gì không. Đừng chỉ nhìn số lượng test pass, mà phải xem những test đó có thực sự verify điều mà requirement này quan tâm hay không.
- Bám theo luồng nghiệp vụ để xem code, dồn sức vào những phần rủi ro cao: Tôi chủ yếu soi quyền hạn, thay đổi trạng thái, concurrency, retry, tính nhất quán dữ liệu và những phần rủi ro cao như migration, rollback. Mấy đoạn CRUD theo pattern ổn định thì lướt nhanh hơn — thậm chí giờ có những phần tôi không buồn nhìn nữa.
- Soi kỹ các abstraction và cơ chế mới thêm vào: Với những abstraction và cơ chế mới, tôi dùng tư duy kiểu Occam's Razor để bắt AI review lại: Chúng có thực sự cần thiết không, có cách triển khai nào đơn giản hơn không, có phải ta đang đưa quá nhiều sự phức tạp vào chỉ để giải quyết một vấn đề cục bộ không?
- Cân nhắc dựng Review Bot chuyên dụng khi có quá nhiều MR: Nếu trong nhóm có nhiều MR, có thể thiết kế một Review Bot riêng để lo việc cross-review. Khác với việc gọi trực tiếp pi agent / Claude Code để phản biện như đã nói ở trên, cách này nhấn mạnh việc kết hợp thông tin thay đổi trên Git với quy trình review được thiết kế sẵn, tạo thành năng lực review có thể lặp lại, chuyên phục vụ cho MR.
5. Vài đúc kết và suy ngẫm
Nút thắt cổ chai lớn nhất của tôi trong quá trình phát triển hiện tại là tốc độ Review.
Agent có thể đẩy song song nhiều task, nhưng tốc độ hiểu nghiệp vụ, phán đoán giải pháp và xác nhận delivery của tôi thì không tăng theo tỷ lệ tương ứng. Nếu cứ để nó viết nhiều hơn, khả năng cao bạn chỉ đang chất đống thêm code chờ review mà thôi.
Thế nên, điều tôi muốn cải thiện tiếp theo là làm sao để những lỗi lặp đi lặp lại được phát hiện và sửa trước khi đến tay tôi.
Những vấn đề có thể tìm ra qua type checking, test và business assertion thì nên để Agent tự xử lý trong lúc code càng nhiều càng tốt; phần cần tôi phán đoán sẽ tập trung vào việc requirement có được hiểu đúng không, logic nghiệp vụ cốt lõi có vững không, và lần thay đổi này còn rủi ro nào chưa được kiểm chứng.
Review Bot chuyên dụng có thể giúp làm những việc này, nhưng giá trị của nó nằm ở chỗ có giảm được việc bỏ sót lỗi nghiêm trọng và gánh nặng thủ công hay không, chứ không phải ở việc nó comment được bao nhiêu dòng.
Điều này cũng khiến khái niệm Harness trong tôi dần trở nên cụ thể hơn: Ngoài việc cung cấp context chuẩn xác cho Agent, chúng còn cần môi trường để thực thi task, và căn cứ để phán đoán kết quả.
Tôi đã gom các thao tác lặp đi lặp lại khi self-test hằng ngày thành CLI, script và Skill, để nó tự chạy hệ thống, tự kiểm tra kết quả và tự tìm bằng chứng lỗi. Trong các task tương lai, những năng lực này có thể tiếp tục được dùng, và dần chuyển giao cho đồng nghiệp khác tái sử dụng.
Đồng thời, workflow này cũng cần thường xuyên được "làm phép trừ".
Một số bước chỉ đang bù đắp cho nhược điểm của một thế hệ model nào đó. Khi model thay đổi, lợi ích của những bước này cần được đánh giá lại. Task đơn giản thì làm luôn, task phức tạp thì thêm planning, chia nhỏ và cross-review. Ví dụ, sau khi Astra cập nhật, tôi đã xóa bớt một số ràng buộc quá khắt khe trong AGENTS.md. Model liên tục tiến hóa, workflow của chúng ta cũng phải tiến hóa theo.
Tất nhiên, test và Review có thể giảm bớt sự bất định, nhưng con người vẫn phải đưa ra tiêu chí nghiệm thu đúng đắn. Kể cả khi code và test khớp nhau, chúng vẫn có thể cùng nhau hiểu sai requirement. End-to-end test chỉ bao quát được hành vi trong môi trường và kịch bản được chọn; traffic, concurrency và phân bố dữ liệu trên production vẫn có thể sinh ra vấn đề mới.
Là một developer mới đi làm như tôi, tôi vẫn mong muốn học hỏi thêm nhiều kiến thức chuyên môn trong nghề thông qua công việc. Tuy nhiên, AI đúng là đã lấy đi một số cơ hội được tự mình "vấp ngã". Những kinh nghiệm xương máu vốn dĩ phải trải qua lỗi lầm và tự mò mẫm nguyên nhân, giờ có khi chỉ còn là một câu nói của AI:
"Tôi sai rồi, đang sửa đây."
Thế nên,
Bây giờ tôi dành một phần thời gian phát triển hằng ngày cho việc học hỏi và chiêm nghiệm, đồng thời tự hỏi: Năng lực nào mới thực sự cần thiết cho anh em R&D trong kỷ nguyên AI.
Bài viết này ghi lại bộ phương pháp mà tôi dần mày mò ra trong nghiệp vụ của mình suốt vài tháng đầu đi làm. Phạm vi áp dụng và những thiếu sót của nó, tôi vẫn đang tiếp tục khám phá.
Mọi người có thể thử chọn một luồng self-test hay làm, cho Agent tự chạy độc lập, lưu lại bằng chứng, rồi đúc kết những bước hiệu quả.
Do yêu cầu bảo mật của công ty, nhiều chi tiết không thể đưa vào bài. Hy vọng bài viết này mang tính "ném gạch dẫn đường", rất mong được nghe thêm những best practice từ mọi người trong quá trình làm việc thực tế~
