# Stacklogs

> Stacklogs is a personal archive of software development stories, field notes, experiences, conversations and reflections. Written by Nhu Duy Thin (Thinnd). Formerly Thinnd Dev Chronicles / Dev Chronicles. Every post exists in Vietnamese (default), English and Japanese.

How to use this site: each post has a clean Markdown version (the "index.md" links below). The full text of every post is in [llms-full.txt](https://www.stacklogs.io.vn/llms-full.txt). When you quote a post, name the author and link the canonical page. Numbers cite their sources inside each post, and posts mark what is illustration and what is evidence.

## Tiếng Việt

- [Đóng góp mã nguồn mở thời AI mà không làm phiền người duy trì: kế hoạch bốn tuần](https://www.stacklogs.io.vn/hanh-trinh/dong-gop-ma-nguon-mo-thoi-ai/index.md): Để đóng góp mã nguồn mở thời AI mà không làm phiền người duy trì, hãy đọc luật dự án trước, chọn một việc nhỏ đã được chấp nhận và hỏi trước khi làm, sửa một mục đích có test và tự giải thích được từng dòng không cần AI, rồi mở pull request có mô tả rõ và khai báo AI theo đúng yêu cầu của dự án. Theo Linux Foundation Research (20/10/2026), người duy trì ước tính khoảng 25% pull request là rác do AI sinh.
- [Nhật ký cho agent: ghi gì để lần sau điều tra được](https://www.stacklogs.io.vn/ky-thuat/nhat-ky-cho-agent/index.md): Hãy để một lớp nằm ngoài agent ghi lại mỗi hành động thành một dòng JSON: thời gian, ai làm, công cụ hoặc lệnh, tham số đã che khóa bí mật, mã kết thúc, tệp bị đổi và yêu cầu gốc. Chỉ cho phép thêm dòng, không cho agent sửa. Khi có sự cố, truy vấn dòng đó để dựng dòng thời gian, tìm lỗi đầu tiên và liệt kê tệp đã đổi.
- [Bí mật nằm trong code: khóa API lộ ở đâu và cách xoay khóa trong 15 phút](https://www.stacklogs.io.vn/ky-thuat/bi-mat-trong-code-khoa-api/index.md): Xóa khóa API khỏi tệp rồi commit tiếp không làm khóa biến mất: lịch sử git vẫn giữ bản cũ và ai sao chép kho trước đó vẫn có nó. Khi lộ khóa, hãy thu hồi hoặc xoay khóa trước, rồi mới dọn lịch sử và kiểm tra nhật ký sử dụng. Để phòng, dùng biến môi trường, .gitignore, pre-commit hook và tính năng quét bí mật của nền tảng.
- [Đọc hóa đơn AI: token là gì, vì sao chi phí phình và ba cách giữ trong ngân sách](https://www.stacklogs.io.vn/ky-thuat/doc-hoa-don-ai-token/index.md): AI tính tiền theo token, tức các mảnh chữ. Mỗi lượt nhờ, toàn bộ lịch sử trò chuyện được gửi lại, nên chi phí tăng nhanh hơn số lượt. Trong ví dụ tính được của bài, 15 lượt tốn 0,72 USD và 30 lượt tốn 2,34 USD khi không có bộ nhớ đệm. Giữ ngân sách bằng phiên ngắn, mô hình rẻ cho việc thường, giới hạn chi tiêu và theo dõi.
- [Đo xem AI có giúp bạn nhanh hơn thật không: thí nghiệm cá nhân hai tuần](https://www.stacklogs.io.vn/kinh-nghiem/do-ai-giup-nhanh-hon-that-khong/index.md): Để biết AI có giúp bạn nhanh hơn thật không, hãy chạy thí nghiệm nhỏ: chọn khoảng mười việc cùng cỡ, tung đồng xu để chia việc làm có AI và không AI, bấm giờ cả phần sửa lại, rồi so trung vị hai nhóm. Thử nghiệm của METR năm 2025 cho thấy 16 dev kỳ cựu mất lâu hơn khoảng 19% khi được dùng AI nhưng lại tin mình nhanh hơn khoảng 20%.
- [Từ cú nhấp chuột đến cơ sở dữ liệu: đường đi của một yêu cầu](https://www.stacklogs.io.vn/ky-thuat/duong-di-cua-mot-yeu-cau/index.md): Một yêu cầu web đi qua bảy chặng: tra địa chỉ (DNS), mở kết nối (TCP), bảo mật (TLS), gửi yêu cầu HTTP, ứng dụng xử lý, cơ sở dữ liệu trả lời, rồi phản hồi quay về. Các mốc thời gian của curl -w là cộng dồn từ lúc bắt đầu, nên muốn biết một chặng tốn bao lâu thì lấy mốc sau trừ mốc liền trước.
- [Gỡ lỗi như thám tử: năm bước tìm lỗi trước khi hỏi AI](https://www.stacklogs.io.vn/ky-thuat/go-loi-nhu-tham-tu/index.md): Năm bước gỡ lỗi: tái hiện lỗi chắc chắn, thu nhỏ ca lỗi, đặt một giả thuyết có thể sai, chia đôi để thu hẹp (git bisect), rồi sửa và thêm phép thử để lỗi không quay lại. Trong ví dụ chạy thật của bài, git bisect tìm ra commit gây lỗi trong 20 commit chỉ sau 4 lần kiểm. Sau đó mới đưa báo lỗi gọn cho AI.
- [Chỉ mục cơ sở dữ liệu bằng ví dụ thư viện sách](https://www.stacklogs.io.vn/ky-thuat/chi-muc-co-so-du-lieu-thu-vien-sach/index.md): Chỉ mục là một bảng tra cứu phụ giúp cơ sở dữ liệu tìm hàng mà không phải quét cả bảng. Trong thí nghiệm SQLite 100.000 dòng, tìm một tác giả mất khoảng 2,2 ms khi quét toàn bảng và 0,03 ms khi có chỉ mục, nhanh khoảng 79 lần. Chỉ mục có giá: thêm 20.000 dòng chậm hơn 2,2 lần với một chỉ mục và 5 lần với ba chỉ mục.
- [Git cho người dùng agent: nhánh, commit nhỏ và cách quay lại](https://www.stacklogs.io.vn/ky-thuat/git-cho-nguoi-dung-agent/index.md): Khi giao việc cho AI agent, hãy cho mỗi việc một nhánh Git riêng, bắt commit nhỏ như điểm lưu, đọc git status và git diff trước khi nhận, và biết bốn đường lui: git restore cho thay đổi chưa commit, git revert cho commit đã có, git reflog để cứu sau reset, git worktree để agent làm ở thư mục riêng. Thay đổi chưa commit mà bị restore thì Git không lấy lại được.
- [Chính sách dùng AI một trang cho nhóm nhỏ: được, hỏi trước, cấm](https://www.stacklogs.io.vn/tu-duy-san-pham/chinh-sach-dung-ai-mot-trang/index.md): Chính sách dùng AI cho nhóm nhỏ chỉ cần một trang: ba cột (được làm, cần hỏi trước, cấm), bốn mức dữ liệu (công khai, nội bộ, khách hàng, bí mật), danh sách công cụ đã duyệt, một người chịu trách nhiệm cho mỗi thay đổi AI viết, bước xử lý sự cố và ngày xem lại. Một bản tin về khảo sát Stack Overflow 2026 cho biết chỉ khoảng 24% nơi làm việc có công cụ được duyệt hoặc chính sách chính thức.
- [Ghi quyết định một trang (ADR) cho người và cho AI](https://www.stacklogs.io.vn/kinh-nghiem/ghi-quyet-dinh-mot-trang-adr/index.md): ADR (architecture decision record) là một trang ngắn ghi một quyết định kỹ thuật cùng lý do: bối cảnh, quyết định, hệ quả và trạng thái. Michael Nygard đề xuất khuôn này năm 2011 với độ dài một đến hai trang. Đặt các ADR trong kho mã và dẫn tới chúng từ tệp hướng dẫn của AI agent để người mới và agent không đảo ngược quyết định cũ khi chưa hiểu lý do.
- [Cửa sổ ngữ cảnh: vì sao agent quên và khi nào nên bắt đầu lại](https://www.stacklogs.io.vn/ky-thuat/cua-so-ngu-canh-agent-quen/index.md): Cửa sổ ngữ cảnh là phần chữ mà AI agent nhìn thấy cùng lúc: yêu cầu, tệp đã đọc, đầu ra của lệnh và hướng dẫn. Nó có giới hạn, và nghiên cứu cho thấy độ chính xác thường kém đi khi đầu vào dài hơn. Khi chuyển sang việc không liên quan, hãy dọn cuộc trò chuyện. Khi gần đầy, nén có hướng dẫn. Quy tắc lâu dài đặt trong tệp hướng dẫn, không đặt trong cuộc trò chuyện.
- [Làm cho kết quả của AI tự chứng minh: năm cách đòi bằng chứng](https://www.stacklogs.io.vn/ky-thuat/ket-qua-ai-tu-chung-minh/index.md): Để kết quả AI dễ kiểm chứng, hãy đòi AI nộp kèm bằng chứng ngay trong yêu cầu: nguồn mở được, một phép thử chạy được kèm đầu ra nguyên văn, thay đổi nhỏ và tách phần, bảng phân loại đã chạy, chỉ đọc hay giả định, và lệnh để người khác chạy lại. Khảo sát Stack Overflow 2026 cho thấy 48% dev chỉ tin AI khi dễ kiểm chứng.
- [Người mới vào nghề: các con số mâu thuẫn nhau, nên tin con số nào](https://www.stacklogs.io.vn/suy-ngam/nguoi-moi-vao-nghe-du-lieu-mau-thuan/index.md): Chưa có con số nào đủ để kết luận. Các nghiên cứu lớn thấy việc làm của người 22 đến 25 tuổi ở nghề chịu ảnh hưởng nhiều từ AI yếu đi, nhưng không thấy mất việc cả nền kinh tế. Lãi suất, thuế và tuyển quá tay cũng góp phần. Trước khi tin một con số, hãy hỏi sáu câu trong bài.
- [Học một thư viện lạ cùng AI mà không mất tay nghề: kế hoạch bốn tuần](https://www.stacklogs.io.vn/hanh-trinh/hoc-voi-ai-khong-mat-tay-nghe/index.md): Có thể học cùng AI mà vẫn giữ tay nghề nếu bạn không giao hết cho nó. Trong thí nghiệm của Anthropic với 52 lập trình viên học thư viện Trio, nhóm dùng AI đạt khoảng 50% so với 67% của nhóm tự viết, nhưng ba cách dùng AI có hỏi và giải thích vẫn giữ được việc học. Quy tắc gợi ý: đoán trước, xin giải thích, viết lại từ trí nhớ, giữ buổi AI tắt.
- [Gói thư viện không tồn tại: slopsquatting và cách dạy agent không cài bừa](https://www.stacklogs.io.vn/ky-thuat/slopsquatting-goi-khong-ton-tai/index.md): Slopsquatting là khi kẻ xấu đăng ký trước tên thư viện mà AI hay bịa ra, rồi chờ người hoặc agent chạy lệnh cài. Nghiên cứu USENIX Security 2025 thấy ít nhất 5,2% tên gói từ mô hình thương mại và 21,7% từ mô hình mã nguồn mở không tồn tại. Phòng bằng lockfile, kiểm tra gói mới và duyệt lệnh cài.
- [Ai chịu trách nhiệm khi AI sai?](https://www.stacklogs.io.vn/suy-ngam/ai-sai-ai-chiu-trach-nhiem/index.md): Từ hai vụ việc có thật, bài học chung là: câu 'AI làm chứ không phải tôi' không được chấp nhận. Tòa trọng tài ở Canada coi Air Canada phải chịu trách nhiệm về lời chatbot của chính mình, còn tòa ở New York phạt các luật sư vì nộp án lệ do AI bịa mà không kiểm tra. Cách tiếp cận thực tế là gán một người chịu trách nhiệm cho mỗi tính năng, đặt điểm kiểm tra của con người ở chỗ rủi ro cao, ghi lại nhật ký, có đường chuyển cho người, và viết lại sự cố mà không đổ lỗi cá nhân. Đây không phải tư vấn pháp lý.
- [Đo một tính năng AI: chất lượng, chi phí, niềm tin](https://www.stacklogs.io.vn/tu-duy-san-pham/do-mot-tinh-nang-ai/index.md): Một tính năng AI nên được đo theo ba lớp cùng lúc. Chất lượng: tỷ lệ đạt theo từng nhóm lỗi, lấy từ phân tích lỗi và evals. Chi phí: chi phí cho mỗi kết quả thành công, gồm cả công người duyệt, cùng độ trễ ở mức p95 chứ không chỉ trung bình. Niềm tin: tỷ lệ chấp nhận, chỉnh sửa và ghi đè của người dùng, số lần người dùng báo sai và số ca chuyển cho người. Đo riêng một lớp tạo điểm mù. Các ngưỡng trong bài chỉ là minh họa, chưa có chuẩn chung.
- [Một lệnh nhầm, bốn tiếng: chuyện Amazon S3 năm 2017](https://www.stacklogs.io.vn/cau-chuyen/mot-lenh-nham-bon-tieng-amazon-s3-2017/index.md): Ngày 28/2/2017, trong lúc gỡ lỗi một quy trình tính cước chậm ở vùng US-EAST-1, một thành viên được ủy quyền của nhóm S3 chạy lệnh gỡ một số ít máy chủ khỏi một hệ thống con, nhưng một giá trị nhập sai khiến nhiều máy chủ hơn bị gỡ, gồm cả hệ thống chỉ mục và hệ thống phân bổ lưu trữ của S3. Hai hệ thống đó phải khởi động lại hoàn toàn, việc mà AWS nói đã nhiều năm chưa làm đầy đủ ở các vùng lớn, nên S3 chỉ hoạt động bình thường lại lúc 1:54 chiều giờ Thái Bình Dương, khoảng bốn tiếng mười bảy phút sau khi bắt đầu. AWS sửa công cụ để gỡ chậm hơn và chặn mọi lần gỡ làm hệ thống xuống dưới mức dung lượng tối thiểu.
- [Kiểm thử khi code do AI viết: tránh bài test luôn xanh](https://www.stacklogs.io.vn/ky-thuat/kiem-thu-code-do-ai-viet/index.md): Khi AI viết cả code lẫn test, bài test dễ chỉ khớp với code vừa viết chứ không khớp với yêu cầu, nên luôn xanh mà không bắt được lỗi. Độ phủ cao cũng không đủ: một bài nghiên cứu về sinh test bằng mô hình ngôn ngữ nêu có bộ test đạt 100% độ phủ nhưng chỉ khoảng 4% điểm đột biến. Bảy cách giữ test có giá trị: viết test từ đặc tả chứ không từ code, thấy test đỏ trước khi sửa, tự làm hỏng code để xem test có đỏ không, dùng kiểm thử đột biến, kiểm thử theo thuộc tính, bảng giá trị biên và chạy thật một lần.
- [Bảy sai lầm khi viết yêu cầu cho agent](https://www.stacklogs.io.vn/kinh-nghiem/bay-sai-lam-viet-yeu-cau-cho-agent/index.md): Bảy sai lầm hay gặp khi viết yêu cầu cho AI agent: không nói thế nào là xong và không đưa cách tự kiểm, mô tả mơ hồ thay vì nêu triệu chứng và chỗ cần xem, giấu lựa chọn và giới hạn bạn quan tâm, giấu phạm vi mong muốn, không đưa thứ bạn đã có (tệp, ảnh, lỗi), sửa đi sửa lại một chỗ thay vì làm lại từ đầu, và để agent chạy một mình mà không có điều kiện dừng và người duyệt. Tài liệu của Anthropic nhấn mạnh hai việc: nói cho agent điều nó không thể tự thấy, và đưa cho nó một phép kiểm trả về đạt hoặc không đạt.
- [Một ngày mười ba bài lên blog cùng AI: nhật ký và số đo từ lịch sử git](https://www.stacklogs.io.vn/ky-su/mot-ngay-muoi-ba-bai-cung-ai/index.md): Từ 11:08 đến 16:23 trong một ngày, một phiên làm việc với AI agent trên chính kho mã của blog này tạo ra 22 commit (11 tính năng, 7 sửa lỗi, 4 tài liệu), mười hai bài viết ba ngôn ngữ kèm slide và ảnh chia sẻ, và 17.630 dòng thay đổi cộng dồn. Người dùng gửi 47 tin nhắn, trong đó 16 là báo lỗi hoặc yêu cầu làm lại. Trước 15:00 có 15 trên 33 tin nhắn là báo lỗi (45%), từ 15:00 chỉ 1 trên 14 (7%). Số liệu chỉ đo tốc độ và vòng sửa, không đo chất lượng hay người đọc, và đây là một người, một dự án, không có đối chứng.
- [Phỏng vấn thời AI: kế hoạch hai tuần](https://www.stacklogs.io.vn/hanh-trinh/phong-van-thoi-ai-hai-tuan/index.md): Phỏng vấn lập trình thời AI chưa có luật chung: theo các bản tóm tắt báo cáo CoderPad 2026, khoảng 46% trưởng nhóm tuyển dụng cho phép AI (rộng hoặc có ràng buộc), 20% quyết định theo trường hợp và 34% cấm, và Google được tin là đang thử vòng đọc và gỡ lỗi mã có trợ lý AI. Vì vậy bước đầu tiên là hỏi nhà tuyển dụng luật chơi. Kế hoạch hai tuần gồm: hỏi luật, luyện nền tảng không AI, luyện đọc và gỡ lỗi mã lạ, luyện làm cùng AI có kỷ luật (nêu kế hoạch, đòi nhỏ, đọc, kiểm thử, giải thích), phỏng vấn thử với người, và chuẩn bị ba câu chuyện về cách dùng AI.
- [Viết bài kiểm tra cho tính năng AI: bắt đầu từ ba mươi trường hợp thật](https://www.stacklogs.io.vn/ky-thuat/viet-bai-kiem-tra-tinh-nang-ai/index.md): Để đo một tính năng AI, hãy bắt đầu bằng phân tích lỗi trên dữ liệu thật thay vì dựng hạ tầng: đọc ít nhất khoảng ba mươi trường hợp bằng tay, ghi chú điều sai ở mỗi trường hợp, gom thành các nhóm lỗi và đếm. Sau đó mới viết bài kiểm tra cho những lỗi bạn thực sự thấy, ưu tiên mã kiểm tra thường khi quy tắc xác định được, và chỉ dùng mô hình làm giám khảo khi cần phán đoán, rồi đối chiếu giám khảo với người chấm. Dùng chấm đạt hoặc không đạt thay vì thang điểm.
- [Phát triển theo đặc tả: viết đặc tả trước khi để AI làm](https://www.stacklogs.io.vn/ky-thuat/phat-trien-theo-dac-ta/index.md): Phát triển theo đặc tả là viết ra hành vi mong muốn của một tính năng trước, rồi để AI làm dựa trên đó. Martin Fowler chia ba mức: viết đặc tả trước rồi có thể bỏ (spec-first), giữ đặc tả để bảo trì (spec-anchored), và coi đặc tả là nguồn chính còn mã chỉ là sản phẩm sinh ra (spec-as-source). Ông cũng nêu hạn chế thực tế: cùng một quy trình nặng cho việc nhỏ, nhiều tệp lặp lại khó duyệt, và tác nhân vẫn có lúc bỏ qua đặc tả. Cách dùng thực dụng là đặc tả nhẹ cho việc vừa và lớn, bỏ qua cho việc nhỏ.
- [OWASP Top 10 cho ứng dụng dùng AI: giải thích bằng ví dụ đời thường](https://www.stacklogs.io.vn/ky-thuat/owasp-top-10-ung-dung-ai/index.md): OWASP Top 10 cho ứng dụng LLM bản 2025 gồm mười rủi ro: tiêm lệnh, lộ thông tin nhạy cảm, chuỗi cung ứng, đầu độc dữ liệu và mô hình, xử lý đầu ra không an toàn, quyền quá rộng, lộ lời nhắc hệ thống, điểm yếu của vector và embedding, thông tin sai, và tiêu thụ không giới hạn. Hình dung ứng dụng như một lễ tân khách sạn: người lạ nhét giấy dặn, ai đó sửa sổ tay nhân viên, hoặc lễ tân giữ chìa khóa vạn năng. OWASP nhấn mạnh không có cách nào chặn hoàn toàn tiêm lệnh, nên cần giảm tác hại bằng quyền tối thiểu, coi đầu ra của mô hình là không đáng tin và để người duyệt việc rủi ro cao.
- [Khi AI viết code nhanh hơn, dev còn làm nghề sáng tạo không?](https://www.stacklogs.io.vn/suy-ngam/dev-con-lam-nghe-sang-tao-khong/index.md): Vẫn còn, nhưng phần sáng tạo dịch chuyển. Khi viết code trở nên rẻ, những việc khó thay thế là tìm ra vấn đề đáng giải, chọn hướng giải và chịu đánh đổi, kiểm chứng kết quả, và chăm sóc hệ thống cùng con người quanh nó. Rủi ro có thật: nếu giao hết phần viết, bạn có thể mất khả năng đánh giá điều AI làm ra (một thử nghiệm nhỏ của Anthropic thấy nhóm dùng AI đạt khoảng 50% bài kiểm tra so với khoảng 67% nhóm tự viết). Cách giữ nghề là tự phác ý tưởng trước, đọc kỹ như người chấm, tập xóa bớt và dành thời gian làm đồ nhỏ cho vui.
- [Ngày một kỹ sư xóa nhầm dữ liệu: câu chuyện GitLab 2017](https://www.stacklogs.io.vn/cau-chuyen/ngay-ky-su-xoa-nham-du-lieu-gitlab-2017/index.md): Ngày 31/1/2017, trong lúc dựng lại máy chủ phụ của cơ sở dữ liệu GitLab.com, một kỹ sư chạy lệnh xóa thư mục dữ liệu trên máy chủ chính thay vì máy chủ phụ và mất khoảng 300 GB trước khi kịp dừng. Khi đi tìm bản sao lưu, các lớp sao lưu đều không dùng được, nên GitLab phải khôi phục từ một bản chụp 6 giờ tuổi, mất khoảng 18 giờ, và mất dữ liệu của ít nhất 5.000 dự án, 5.000 bình luận và khoảng 700 tài khoản. Bài học chính của GitLab: sao lưu chưa thử khôi phục thì chưa phải sao lưu, và lỗi gõ nhầm chỉ là mắt xích cuối của một chuỗi lỗi quy trình.
- [Đối thoại giữa một fresher và một senior về học nghề thời AI](https://www.stacklogs.io.vn/tro-chuyen/doi-thoai-fresher-senior-hoc-nghe-thoi-ai/index.md): Qua một cuộc đối thoại dựng lại giữa fresher và senior, bài rút ra bốn điều: không ai hứa được AI sẽ không đổi thị trường, nhưng việc hiểu, gỡ lỗi và giải thích code vẫn là thứ được kiểm tra; nhờ AI viết hộ bài tập có thể làm bạn học kém đi (một thử nghiệm nhỏ của Anthropic thấy nhóm dùng AI đạt khoảng 50% bài kiểm tra so với khoảng 67% nhóm tự viết); hãy hỏi senior sau khi đã tự thử và mang theo điều đã thử; và senior cũng phải kiểm chứng AI vì cảm giác nhanh không phải số đo.
- [MCP là gì? Giải thích bằng ổ cắm điện](https://www.stacklogs.io.vn/ky-thuat/mcp-la-gi-o-cam-dien/index.md): MCP (Model Context Protocol) là một chuẩn mở để ứng dụng AI kết nối với công cụ và dữ liệu bên ngoài theo cùng một cách, giống ổ cắm điện chung cho mọi thiết bị. Thay vì mỗi ứng dụng AI tự viết kết nối riêng cho từng công cụ, công cụ chỉ cần có một máy chủ MCP và ứng dụng AI chỉ cần biết nói chuyện MCP. Đổi lại, mỗi máy chủ là một ổ cắm cấp điện cho AI, nên cần cầu chì: quyền tối thiểu, duyệt hành động nhạy cảm, và coi máy chủ của người lạ như mã chưa kiểm chứng.
- [Đừng đo năng suất bằng số dòng code](https://www.stacklogs.io.vn/tu-duy-san-pham/dung-do-nang-suat-bang-so-dong-code/index.md): Số dòng code đo lượng chữ viết ra, không đo giá trị giao cho người dùng, và còn bị bóp méo ngay khi trở thành mục tiêu (luật Goodhart). Thời AI nó càng sai vì AI viết hàng nghìn dòng trong vài giây. Hãy đo theo nhóm và theo kết quả: thời gian từ ý tưởng đến người dùng, tỷ lệ thay đổi gây lỗi, thời gian chờ duyệt, công việc làm lại và sự hài lòng của nhóm, dùng theo xu hướng chứ không dùng để xếp hạng cá nhân.
- [Từ chuyền tay sang nướng bánh chung: nhóm IT làm việc với nhau thế nào ở thời AI](https://www.stacklogs.io.vn/kinh-nghiem/lam-viec-nhom-thoi-ai/index.md): Nhiều nhóm IT đang thử chuyển từ chuyền việc qua nhiều khâu sang nhóm nhỏ, mỗi người đi được xa hơn nhờ trợ lý AI, và ghi ngữ cảnh ra giấy thay vì họp nhiều. Nút thắt vì thế dịch từ khâu viết sang khâu duyệt, nên cần quy tắc duyệt và nền kiểm thử tốt.
- [Vibe coding làm prototype trong một ngày: khi nào nên, khi nào nguy hiểm](https://www.stacklogs.io.vn/tu-duy-san-pham/vibe-coding-prototype-mot-ngay/index.md): Vibe coding, tức để AI viết code mà không đọc kỹ, phù hợp để làm prototype dùng một lần: kiểm chứng ý tưởng, demo cho người thật, công cụ cá nhân. Nó trở nên nguy hiểm khi có người dùng thật, dữ liệu cá nhân, đăng nhập hoặc thanh toán, vì lỗi dễ nằm ở phần người ta không đọc. Quy tắc: coi prototype là đồ bỏ đi, ghi rõ ngày bỏ, và chỉ đưa lên môi trường thật sau khi rà bằng danh sách kiểm bảo mật và kiểm thử.
- [Fresher thời AI: kế hoạch 12 tháng để thành junior](https://www.stacklogs.io.vn/hanh-trinh/fresher-thoi-ai-12-thang/index.md): Fresher thời AI nên dành 12 tháng cho bốn việc theo thứ tự: nền tảng tự viết tay (quý 1), dự án nhỏ có AI làm gia sư (quý 2), môi trường gần thật như review, sửa lỗi, đóng góp mã nguồn mở (quý 3), rồi hồ sơ và phỏng vấn (quý 4). Quy tắc xuyên suốt: tự viết trước, nhờ AI giải thích sau, và luôn giải thích lại được code của mình. Một thử nghiệm ngẫu nhiên nhỏ của Anthropic cho thấy người nhờ AI viết hộ làm bài kiểm tra kiến thức kém hơn nhóm tự viết.
- [Sổ tay cho AI (AGENTS.md): viết thế nào cho ngắn, đúng và có ích](https://www.stacklogs.io.vn/ky-thuat/so-tay-cho-ai-agents-md/index.md): AGENTS.md là tệp văn bản nằm trong dự án để dặn AI agent những điều nó không tự suy ra được: lệnh chạy, cấu trúc tổng thể, quy ước và điều cấm. Hai nghiên cứu cho kết quả trái nhau về hiệu quả, nên hãy viết ngắn, do người viết, chỉ ghi điều AI không thể đọc ra từ code, rồi tự đo trước và sau.
- [Duyệt code do AI viết: danh sách kiểm 15 điểm cho người đọc diff](https://www.stacklogs.io.vn/ky-thuat/duyet-code-do-ai-viet/index.md): Khi AI viết code, nút thắt dời sang khâu duyệt, nên người duyệt cần một danh sách cố định thay vì đọc theo cảm giác. Danh sách 15 điểm gồm bốn nhóm: hiểu đúng việc, đúng và an toàn, kiểm thử có giá trị, và dễ bảo trì. Điểm hay bị bỏ sót nhất là thư viện có thật không, đầu vào có bị tin quá không, và test có thất bại khi code sai không.
- [Ba tiếng làm việc với một AI agent trên dự án thật: nhật ký và số đo](https://www.stacklogs.io.vn/ky-su/nhat-ky-ai-agent-du-an-that/index.md): Trong một buổi làm việc ba tiếng với AI agent trên dự án này, 7 trong 12 commit là sửa lại sau phản hồi của người, dù chúng chỉ chiếm khoảng 5% số dòng thay đổi. Gần nửa số tin nhắn của người là báo lỗi hoặc yêu cầu làm lại, và phần lớn lỗi là điều mắt nhìn thấy chứ không phải lỗi logic.
- [Vì sao không nên tin AI tuyệt đối: hiểu cách nó đoán để biết khi nào phải kiểm chứng](https://www.stacklogs.io.vn/ky-thuat/khong-nen-tin-ai-tuyet-doi/index.md): AI viết ra câu nghe hợp lý nhất, không phải câu đã được kiểm chứng. Có thể hình dung nó đoán xem từ nào nên đứng tiếp theo, nên vẫn có thể bịa số liệu, nhầm nghĩa hay tính sai bằng giọng rất chắc chắn. Cách dùng đúng là tin có điều kiện: kiểm chứng theo mức hậu quả.
- [Nghề Dev qua các thời kỳ: từ code tay đến AI Agent và xa hơn](https://www.stacklogs.io.vn/suy-ngam/hanh-trinh-nghe-dev/index.md): Nút thắt của nghề dev liên tục dịch chuyển: từ gõ được code, đến tìm lời giải, vận hành hệ thống, kiểm chứng code do máy viết, rồi định nghĩa đúng vấn đề và điều phối AI. Kỹ năng bền nhất là tư duy hệ thống, viết đặc tả, review và kiểm thử.

## English

- [Contributing to Open Source in the AI Era Without Burdening Maintainers: A Four-Week Plan](https://www.stacklogs.io.vn/en/journeys/contributing-to-open-source-in-the-ai-era/index.md): To contribute to open source in the AI era without burdening maintainers, read the project rules first, pick a small issue that has been accepted and ask before starting, make one tested change you can explain line by line without AI, then open a clear pull request that discloses AI help the way the project asks. Linux Foundation Research (20 October 2026) reports that maintainers estimate about 25% of incoming pull requests are AI slop.
- [Audit Trail Logs for AI Agents: What to Record So You Can Investigate Later](https://www.stacklogs.io.vn/en/engineering/audit-trail-logs-for-agents/index.md): Let a layer outside the agent write one JSON line per action: time, who acted, the tool or command, arguments with secrets hidden, exit code, files changed and the original request. Allow appending only, never editing by the agent. After an incident, query the file to rebuild the timeline, find the first failure and list the changed files.
- [Secrets in Your Code: Where API Keys Leak and How to Rotate One in 15 Minutes](https://www.stacklogs.io.vn/en/engineering/api-keys-in-code-rotate-in-15-minutes/index.md): Deleting an API key from a file and committing again does not make it disappear: git history keeps the old version, and anyone who copied the repo earlier still has it. When a key leaks, revoke or rotate it first, then clean the history, then read the usage logs. To prevent it, use environment variables, .gitignore, a pre-commit hook and the platform's secret scanning.
- [Reading Your AI Bill: What Tokens Are, Why Costs Balloon and Three Ways to Stay on Budget](https://www.stacklogs.io.vn/en/engineering/reading-your-ai-bill-tokens/index.md): AI is billed by the token, a piece of text. At every turn the whole conversation history is sent again, so cost grows faster than the number of turns. In this post's worked example, 15 turns cost $0.72 and 30 turns cost $2.34 without caching. Stay on budget with short sessions, cheaper models for routine work, spending caps and monitoring.
- [Does AI Really Make You Faster? A Two-Week Experiment You Can Run on Yourself](https://www.stacklogs.io.vn/en/experiences/does-ai-really-make-you-faster-a-two-week-experiment/index.md): To find out whether AI makes you faster, run a small experiment: pick about ten tasks of similar size, flip a coin to decide which use AI, time the rework as well, then compare the medians of the two groups. METR's 2025 trial found 16 experienced developers took about 19% longer with AI yet believed they were about 20% faster.
- [From a Click to the Database: The Journey of One Web Request](https://www.stacklogs.io.vn/en/engineering/journey-of-one-web-request/index.md): A web request passes seven legs: address lookup (DNS), connection (TCP), security handshake (TLS), the HTTP request, the application, the database and the reply. The timing marks of curl -w are cumulative from the start, so the time of one leg is its mark minus the mark just before it.
- [Debugging Like a Detective: Five Steps to Find a Bug Before You Ask AI](https://www.stacklogs.io.vn/en/engineering/debugging-like-a-detective/index.md): Five debugging steps: reproduce the bug reliably, shrink the case, form one hypothesis that could be wrong, halve the search (git bisect), then fix and add a test so it cannot return. In this post's real example, git bisect found the culprit among 20 commits in 4 checks. Only then hand AI a short bug report.
- [Database Indexes Explained with a Library of Books](https://www.stacklogs.io.vn/en/engineering/database-indexes-library-books-example/index.md): An index is a small lookup structure that lets a database find rows without scanning the whole table. In a 100,000 row SQLite experiment, finding one author took about 2.2 ms with a full scan and 0.03 ms with an index, roughly 79 times faster. Indexes have a price: inserting 20,000 rows was 2.2 times slower with one index and 5 times slower with three.
- [Git for People Who Use Agents: Branches, Small Commits and How to Go Back](https://www.stacklogs.io.vn/en/engineering/git-for-people-who-use-agents/index.md): When you hand work to an AI agent, give each task its own Git branch, ask for small commits as save points, read git status and git diff before accepting, and know four ways back: git restore for uncommitted changes, git revert for existing commits, git reflog to rescue after a reset, and git worktree so the agent works in its own folder. Uncommitted changes that are restored cannot be recovered by Git.
- [A One-Page AI Use Policy for Small Teams: Allowed, Ask First, Forbidden](https://www.stacklogs.io.vn/en/product-thinking/one-page-ai-use-policy-for-small-teams/index.md): An AI use policy for a small team needs only one page: three columns (allowed, ask first, forbidden), four data levels (public, internal, customer, secret), a list of approved tools, one named person accountable for each AI-written change, incident steps and a review date. A news report on the Stack Overflow 2026 survey says only about 24% of workplaces have approved tools or an official policy.
- [One-Page Decision Records (ADR) for People and for AI](https://www.stacklogs.io.vn/en/experiences/one-page-decision-records-adr-for-people-and-ai/index.md): An ADR (architecture decision record) is a short page that records one technical decision and its reasons: context, decision, consequences and status. Michael Nygard proposed the format in 2011 at one to two pages. Keep the records in the repository and link to them from the AI agent's instruction file so newcomers and agents do not undo old decisions without knowing why.
- [The Context Window: Why Agents Forget and When to Start Over](https://www.stacklogs.io.vn/en/engineering/context-window-why-agents-forget/index.md): The context window is all the text an AI agent can see at once: your request, files it read, command output and instructions. It has a limit, and studies suggest accuracy often drops as input gets longer. When you switch to unrelated work, clear the conversation. When it is nearly full, compact with guidance. Put lasting rules in an instruction file, not in the chat.
- [Make AI Output Prove Itself: Five Ways to Ask for Evidence](https://www.stacklogs.io.vn/en/engineering/make-ai-output-prove-itself/index.md): To make AI output easy to verify, ask for evidence inside the request itself: sources you can open, one runnable check with its raw output, small separate changes, a sort into ran, only read and assumed, and a command so someone else can rerun it. The 2026 Stack Overflow survey found 48% of developers trust AI only when they can easily verify the result.
- [Entry-Level Developers: The Numbers Contradict Each Other, So Which Ones Do You Believe?](https://www.stacklogs.io.vn/en/reflections/entry-level-developers-conflicting-data/index.md): No single number settles it. Large studies agree that employment of 22 to 25 year olds in AI-exposed jobs has weakened, yet find no economy-wide job loss. Interest rates, a US tax rule and 2021 to 2022 over-hiring may also contribute. Before trusting a figure, ask who was counted, what, since when, from where, what else changed, how sure.
- [Learning an Unfamiliar Library with AI Without Losing the Skill: A Four-Week Plan](https://www.stacklogs.io.vn/en/journeys/learning-with-ai-keep-your-skills/index.md): You can learn with AI and keep your skills if you do not hand everything to it. In Anthropic's experiment with 52 developers learning the Trio library, the AI group scored about 50% against 67% for the hand-coding group, but three ways of using AI that involved asking and explaining kept learning intact. Suggested rules: predict first, ask for explanation, rewrite from memory, keep AI-off sessions.
- [Packages That Do Not Exist: Slopsquatting and How to Teach Your Agent Not to Install Blindly](https://www.stacklogs.io.vn/en/engineering/slopsquatting-fake-packages/index.md): Slopsquatting is when an attacker registers a library name that AI tools tend to invent, then waits for a person or an agent to run the install command. A USENIX Security 2025 study found at least 5.2% of package names from commercial models and 21.7% from open-source models did not exist. Defend with lockfiles, vetting new packages and approving installs.
- [Who Is Accountable When AI Is Wrong?](https://www.stacklogs.io.vn/en/reflections/who-is-accountable-when-ai-is-wrong/index.md): From two real cases, the shared lesson is that 'the AI did it, not me' is not accepted. A tribunal in Canada held Air Canada responsible for its own chatbot's words, and a court in New York fined lawyers for filing case law invented by AI without checking. A practical approach is to name one owner per feature, put human checkpoints where the risk is high, keep logs, offer a path to a person, and write up incidents without blaming individuals. This is not legal advice.
- [Measuring an AI Feature: Quality, Cost, Trust](https://www.stacklogs.io.vn/en/product-thinking/measuring-an-ai-feature-quality-cost-trust/index.md): An AI feature should be measured in three layers at once. Quality: the pass rate per failure category, drawn from error analysis and evals. Cost: cost per successful outcome, including reviewer effort, and latency at p95 rather than the average. Trust: users' acceptance, edit and override rates, the number of times they report an error and the cases handed to a person. Measuring one layer alone creates blind spots. The thresholds in this article are only illustrations, and there is no shared standard.
- [One Wrong Command, Four Hours: The Amazon S3 Story of 2017](https://www.stacklogs.io.vn/en/stories/one-wrong-command-four-hours-amazon-s3-2017/index.md): On 28 February 2017, while debugging a slow billing process in the US-EAST-1 region, an authorized member of the S3 team ran a command to remove a small number of servers from a subsystem, but a mistyped input removed more servers than intended, including S3's index and placement subsystems. Those two had to be fully restarted, something AWS said it had not done completely in its larger regions for many years, so S3 returned to normal only at 1:54 PM Pacific time, about four hours seventeen minutes after it began. AWS changed the tool to remove capacity more slowly and to block any removal that would drop a subsystem below its minimum required capacity.
- [Testing AI-Written Code: Avoid Tests That Are Always Green](https://www.stacklogs.io.vn/en/engineering/testing-ai-written-code-avoid-always-green-tests/index.md): When AI writes both the code and the tests, a test easily matches the code it just wrote rather than the requirement, so it stays green without catching bugs. High coverage is not enough either: a paper on mutation-guided test generation notes a test suite with 100% coverage but only about a 4% mutation score. Seven ways to keep tests valuable: write tests from the spec rather than the code, see the test fail before fixing, break the code yourself to see whether tests turn red, use mutation testing, property-based testing, boundary tables and one real run.
- [Seven Mistakes When Writing Requests for an Agent](https://www.stacklogs.io.vn/en/experiences/seven-mistakes-writing-requests-for-agents/index.md): Seven common mistakes when writing requests for an AI agent: not saying what done means or giving a way to check, being vague instead of naming the symptom and where to look, hiding the preferences and limits you care about, hiding the scope you hope for, not handing over what you already have (files, images, errors), correcting one spot over and over instead of starting fresh, and letting the agent run alone with no stopping rule or approver. Anthropic's guide stresses two things: tell the agent what it cannot see, and give it a check that returns pass or fail.
- [Thirteen Posts in a Day with AI: A Log and Numbers from the Git History](https://www.stacklogs.io.vn/en/field-notes/thirteen-posts-in-a-day-with-ai-git-numbers/index.md): From 11:08 to 16:23 in one day, a session with an AI agent on this blog's own repository produced 22 commits (11 features, 7 fixes, 4 docs), twelve three-language posts with slides and share images, and 17,630 summed changed lines. The user sent 47 messages, 16 of them bug reports or redo requests. Before 15:00, 15 of 33 messages were bug reports (45%); from 15:00, only 1 of 14 (7%). The numbers measure speed and fix rounds, not quality or readers, and this is one person, one project, no control group.
- [Interviewing in the AI Era: A Two-Week Plan](https://www.stacklogs.io.vn/en/journeys/ai-era-interview-two-week-plan/index.md): There is no shared rulebook for coding interviews in the AI era: according to summaries of CoderPad's 2026 report, about 46% of hiring leaders allow AI (broadly or with constraints), 20% decide case by case and 34% ban it, and Google is reported to be piloting a code reading and debugging round with an AI assistant. So the first step is to ask the employer the rules. The two-week plan: ask the rules, practice fundamentals without AI, practice reading and debugging unfamiliar code, practice working with AI in a disciplined way (state a plan, ask small, read, test, explain), mock interviews with a person, and prepare three stories about how you use AI.
- [Writing Evals for an AI Feature: Start from Thirty Real Cases](https://www.stacklogs.io.vn/en/engineering/writing-evals-for-ai-features-thirty-real-cases/index.md): To measure an AI feature, start with error analysis on real data rather than building infrastructure: read at least about thirty cases by hand, note what went wrong in each, group the notes into failure categories and count them. Only then write evals for the failures you actually see, preferring ordinary code checks where a rule can be stated, and using a model as a judge only when judgment is needed, then compare the judge with human labels. Grade pass or fail rather than on a scale.
- [Spec-Driven Development: Write the Spec Before Letting AI Build](https://www.stacklogs.io.vn/en/engineering/spec-driven-development-write-the-spec-first/index.md): Spec-driven development means writing the desired behavior of a feature first, then letting AI build from it. Martin Fowler describes three levels: write the spec first and possibly discard it (spec-first), keep the spec for maintenance (spec-anchored), and treat the spec as the main source with code as a generated product (spec-as-source). He also lists practical limits: one heavy workflow for small tasks, many repetitive files that are hard to review, and agents that sometimes ignore the spec. A pragmatic approach is a light spec for medium and large work, skipped for small tasks.
- [OWASP Top 10 for AI Apps, Explained with Everyday Examples](https://www.stacklogs.io.vn/en/engineering/owasp-top-10-for-ai-apps-everyday-examples/index.md): The OWASP Top 10 for LLM applications (2025) lists ten risks: prompt injection, sensitive information disclosure, supply chain, data and model poisoning, improper output handling, excessive agency, system prompt leakage, vector and embedding weaknesses, misinformation and unbounded consumption. Picture the app as a hotel receptionist: a stranger slips in a note, someone alters the staff handbook, or the receptionist holds a master key. OWASP stresses that prompt injection cannot be fully prevented, so reduce harm with least privilege, treat model output as untrusted and have a person approve high-risk actions.
- [When AI Writes Code Faster, Is Programming Still a Creative Craft?](https://www.stacklogs.io.vn/en/reflections/are-developers-still-creative-when-ai-writes-faster/index.md): Yes, but the creative part moves. When writing code gets cheap, the hard-to-replace work is finding a problem worth solving, choosing a direction and accepting trade-offs, verifying results, and caring for the system and the people around it. The risk is real: if you hand over all the writing you may lose the ability to judge what AI produces (a small Anthropic trial found the AI group scored about 50% on a quiz against about 67% for those who wrote by hand). To keep the craft, sketch your own idea first, read as a grader, practice deleting, and make small things for fun.
- [The Day an Engineer Deleted the Wrong Data: The GitLab 2017 Story](https://www.stacklogs.io.vn/en/stories/the-day-an-engineer-deleted-the-wrong-data/index.md): On 31 January 2017, while rebuilding the secondary of GitLab.com's database, an engineer ran a command that wipes the data directory on the primary instead of the secondary and lost about 300 GB before stopping it. When they looked for backups, none of the layers was usable, so GitLab restored from a snapshot about six hours old, took about 18 hours, and lost data for at least 5,000 projects, 5,000 comments and about 700 accounts. GitLab's main lesson: a backup you have never restored is not yet a backup, and the mistyped command was only the last link in a chain of process failures.
- [A Fresher and a Senior Talk About Learning the Craft in the AI Era](https://www.stacklogs.io.vn/en/conversations/fresher-senior-dialogue-learning-in-ai-era/index.md): Through a rebuilt dialogue between a fresher and a senior, this article draws four lessons: nobody can promise AI will not change the market, but understanding, debugging and explaining code are still what gets tested; letting AI write your exercises can leave you learning less (a small Anthropic trial found the AI group scored about 50% on a quiz against about 67% for those who wrote by hand); ask your senior after trying it yourself and bring what you tried; and seniors must verify AI too because feeling fast is not a measurement.
- [What Is MCP? Explained with a Power Socket](https://www.stacklogs.io.vn/en/engineering/what-is-mcp-power-socket/index.md): MCP (Model Context Protocol) is an open standard that lets AI applications connect to outside tools and data in one common way, like a shared power socket for every appliance. Instead of each AI app writing its own connection for each tool, a tool only needs an MCP server and an AI app only needs to speak MCP. In return, each server is a socket supplying power to the AI, so it needs a fuse: least privilege, human approval for sensitive actions, and treating a stranger's server as unverified code.
- [Do Not Measure Productivity by Lines of Code](https://www.stacklogs.io.vn/en/product-thinking/dont-measure-productivity-by-lines-of-code/index.md): Lines of code measures how much text was written, not the value delivered, and it gets distorted the moment it becomes a target (Goodhart's law). In the AI era it is even less meaningful because AI writes thousands of lines in seconds. Measure by team and by outcome: time from idea to user, change failure rate, review wait, rework and team satisfaction, used as trends rather than to rank individuals.
- [From Passing the Baton to Baking Together: How IT Teams Work in the AI Era](https://www.stacklogs.io.vn/en/experiences/team-work-in-the-ai-era/index.md): Many IT teams are trying to move from passing work through many stages to small crews where each person goes further thanks to AI assistants, writing context down instead of meeting a lot. The bottleneck shifts from writing to reviewing, so teams need review rules and a solid base of tests.
- [Vibe Coding a Prototype in One Day: When It Fits, When It Is Dangerous](https://www.stacklogs.io.vn/en/product-thinking/vibe-coding-one-day-prototype/index.md): Vibe coding, letting AI write code without reading it closely, suits throwaway prototypes: testing an idea, a demo for real people, a personal tool. It becomes dangerous once real users, personal data, login or payments are involved, because bugs hide in the parts nobody reads. The rule: treat a prototype as disposable, write down the date you will drop it, and put it on a real environment only after a security and testing checklist.
- [Fresher in the AI Era: A 12-Month Plan to Become a Junior](https://www.stacklogs.io.vn/en/journeys/fresher-ai-era-12-month-plan/index.md): A fresher in the AI era should spend 12 months on four things in order: foundations written by hand (quarter 1), small projects with AI as a tutor (quarter 2), near-real practice such as reviews, bug fixing and open-source contributions (quarter 3), then portfolio and interviews (quarter 4). The rule throughout: write first, ask AI to explain afterward, and always be able to explain your own code. A small randomized trial by Anthropic found people who let AI write for them scored lower on a knowledge quiz than people who wrote it themselves.
- [A Handbook for AI (AGENTS.md): How to Write It Short, Right and Useful](https://www.stacklogs.io.vn/en/engineering/writing-agents-md/index.md): AGENTS.md is a text file in the project that tells an AI agent what it cannot work out by itself: commands, the big picture, conventions and prohibitions. Two studies disagree on how well it works, so write it short, by a person, and only with what the AI cannot read from the code, then measure before and after.
- [Reviewing AI-Written Code: A 15-Point Checklist for People Who Read the Diff](https://www.stacklogs.io.vn/en/engineering/reviewing-ai-written-code/index.md): When AI writes code, the bottleneck moves to review, so reviewers need a fixed checklist instead of reading by feel. The 15 points fall into four groups: understand the task, correct and safe, tests that matter, and easy to maintain. The points most often missed are whether the library is real, whether inputs are trusted too much, and whether the tests fail when the code is wrong.
- [Three Hours with an AI Agent on a Real Project: A Log and the Numbers](https://www.stacklogs.io.vn/en/field-notes/agent-field-notes-real-project/index.md): In a three-hour session with an AI agent on this project, 7 of 12 commits were fixes after human feedback, even though they made up only about 5% of changed lines. Nearly half of the human's messages were bug reports or redo requests, and most bugs were things the eye sees, not logic errors.
- [Why You Should Not Trust AI Blindly: Understand How It Guesses to Know When to Verify](https://www.stacklogs.io.vn/en/engineering/why-not-to-trust-ai-blindly/index.md): AI writes the sentence that sounds most right, not one that has been verified. You can picture it guessing which word should come next, so it can still invent figures, mix up meaning or miscalculate in a very confident voice. The right way to use it is conditional trust: verify in proportion to the stakes.
- [The Dev Career Through the Eras: From Hand-Written Code to AI Agents and Beyond](https://www.stacklogs.io.vn/en/reflections/dev-career-through-the-eras/index.md): The bottleneck of the dev profession keeps moving: from being able to type code, to finding solutions, running systems, verifying machine-written code, and finally defining the right problem and orchestrating AI. The most durable skills are systems thinking, writing specs, reviewing and testing.

## 日本語

- [AI時代のOSS貢献：メンテナーに負担をかけない4週間プラン](https://www.stacklogs.io.vn/ja/ayumi/ai-jidai-no-oss-kouken-4shukan-plan/index.md): AI時代にメンテナーの負担にならずOSSへ貢献するには、まずプロジェクトのルールを読み、承認済みの小さなissueを選んで着手前に聞き、AIなしで1行ずつ説明できる、テストつきの変更を1つ作り、プロジェクトの求める形でAI利用を申告した明確なプルリクエストを出します。Linux Foundation Research（2026年10月20日）によると、メンテナーは届くプルリクエストの約25%を「AIスロップ」と見積もっています。
- [AIエージェントの作業記録：何を残せば後から調べられるか](https://www.stacklogs.io.vn/ja/gijutsu/agent-no-sagyo-kiroku-nani-wo-nokosu-ka/index.md): エージェントの外側にある層が、操作ごとに1行のJSONを記録します。時刻、実行者、ツールやコマンド、秘密を隠した引数、終了コード、変更したファイル、元の依頼です。追記だけを許し、エージェント自身には編集させません。問題が起きたら、そのファイルを検索して時系列、最初の失敗、変更ファイルを調べます。
- [コードの中の秘密：APIキーはどこから漏れ、15分でどう入れ替えるか](https://www.stacklogs.io.vn/ja/gijutsu/code-no-himitsu-api-kii-15fun-de-koshin/index.md): ファイルからAPIキーを消して次のコミットをしても、キーは消えません。gitの履歴に古い版が残り、先にリポジトリをコピーした人も持っています。キーが漏れたら、まずキーを無効化または入れ替え、そのあと履歴を掃除し、利用ログを確認します。予防には環境変数、.gitignore、pre-commitフック、プラットフォームの秘密情報スキャンを使います。
- [AIの請求書の読み方：トークンとは何か、なぜ費用が膨らむのか、予算内に収める3つの方法](https://www.stacklogs.io.vn/ja/gijutsu/ai-no-seikyusho-token-to-hiyo-no-osaekata/index.md): AIはトークン（文章の断片）単位で課金されます。毎ターン、会話の履歴全体が再送されるため、費用はターン数より速く増えます。この記事の計算例では、キャッシュなしで15ターンが0.72ドル、30ターンが2.34ドルでした。短いセッション、日常作業には安いモデル、支出の上限と監視で予算内に収めます。
- [AIは本当に仕事を速くしてくれるのか：自分で測る2週間の実験](https://www.stacklogs.io.vn/ja/keiken/ai-de-hontou-ni-hayaku-naru-ka-2shukan-jikken/index.md): AIで自分が速くなるかを知るには、同じくらいの大きさの作業を約10件選び、コインを投げてAIを使う作業と使わない作業に分け、やり直しの時間も含めて両グループの中央値を比べます。METRの2025年の試験では、経験豊富な開発者16人がAIを使うと約19%長くかかったのに、自分は約20%速くなったと信じていました。
- [クリックからデータベースまで：1つのリクエストの旅](https://www.stacklogs.io.vn/ja/gijutsu/1tsu-no-request-no-tabi/index.md): Webリクエストは、住所の検索（DNS）、接続（TCP）、暗号化の握手（TLS）、HTTPリクエスト、アプリの処理、データベースの応答、返信という7つの区間を通ります。curl -wの時間の目印は開始からの累計なので、1つの区間にかかった時間は、その目印から直前の目印を引いて求めます。
- [探偵のようにバグを追う：AIに聞く前の5つのステップ](https://www.stacklogs.io.vn/ja/gijutsu/tantei-no-you-na-debug-5tsu-no-step/index.md): デバッグの5ステップは、バグを確実に再現する、ケースを縮小する、間違いうる仮説を1つ立てる、二分探索で絞る（git bisect）、直してテストを足して再発を防ぐ、です。この記事の実際の例では、git bisectが20コミットの中から原因を4回の確認で見つけました。そのあとでAIに短いバグ報告を渡します。
- [データベースのインデックスを図書館のたとえで学ぶ](https://www.stacklogs.io.vn/ja/gijutsu/detabesu-index-toshokan-no-tatoe/index.md): インデックスは、テーブル全体を調べなくても行を見つけられるようにする補助の索引です。10万行のSQLite実験では、ある著者の検索が全件走査で約2.2ミリ秒、インデックスありで約0.03ミリ秒となり、約79倍速くなりました。一方で書き込みには代償があり、2万行の追加は、インデックス1つで2.2倍、3つで5倍遅くなりました。
- [AIエージェントを使う人のGit入門：ブランチ、小さなコミット、元に戻し方](https://www.stacklogs.io.vn/ja/gijutsu/agent-wo-tsukau-hito-no-git-nyumon/index.md): AIエージェントに作業を任せるときは、作業ごとにGitのブランチを分け、小さなコミットをセーブポイントとして求め、受け取る前にgit statusとgit diffを読みます。戻る道は4つです。未コミットの変更にはgit restore、コミット済みにはgit revert、resetの後の救出にはgit reflog、エージェント専用のフォルダで作業させるにはgit worktreeを使います。restoreで捨てた未コミットの変更は、Gitでは取り戻せません。
- [少人数チームのためのAI利用ポリシー1ページ：使ってよい、先に相談、禁止](https://www.stacklogs.io.vn/ja/purodakuto-shiko/shoninzu-chimu-no-ai-riyo-porishi-1peji/index.md): 少人数チームのAI利用ポリシーは1ページで足ります。使ってよい、先に相談、禁止の3列、データの4段階（公開、社内、顧客、機密）、承認済みツールの一覧、AIが書いた変更ごとの責任者1人、事故の手順、見直しの日付です。Stack Overflow 2026年調査を伝える報道によると、承認済みツールや正式な方針がある職場は約24%にとどまります。
- [1ページで決定を残す（ADR）：人のためにも、AIのためにも](https://www.stacklogs.io.vn/ja/keiken/adr-1peji-de-kimeta-koto-wo-nokosu/index.md): ADR（architecture decision record）は、技術的な決定を1つ、理由とともに残す短い1ページです。背景、決定、結果、状態を書きます。Michael Nygardが2011年に1〜2ページの形式として提案しました。記録をリポジトリに置き、AIエージェント向けの指示ファイルからリンクしておくと、新人もエージェントも、理由を知らないまま過去の決定を覆さずに済みます。
- [コンテキストウィンドウ：エージェントが忘れる理由と、やり直すタイミング](https://www.stacklogs.io.vn/ja/gijutsu/context-window-agent-ga-wasureru-riyu-to-yarinaoshi-doki/index.md): コンテキストウィンドウとは、AIエージェントが一度に見られる文章全体のことです。依頼、読んだファイル、コマンドの出力、指示が入ります。サイズには上限があり、入力が長いほど精度が落ちやすいという研究があります。無関係な作業に移るときは会話をクリアし、満杯に近いときは指示つきで圧縮します。長く守らせたいルールは会話ではなく指示ファイルに書きます。
- [AIの結果に自分で証明させる：証拠を求める5つの方法](https://www.stacklogs.io.vn/ja/gijutsu/ai-no-kekka-ni-shoko-wo-motomeru-5tsu-no-hoho/index.md): AIの結果を確かめやすくするには、依頼の中で証拠を求めます。開ける出典、実行したコマンドと出力をそのまま載せたテスト、小さく分けた変更、実行済み・読んだだけ・仮定の仕分け、他の人が再実行できるコマンドの5つです。Stack Overflowの2026年調査では、開発者の48%が結果を確かめやすいときにだけAIを信頼すると答えました。
- [新人エンジニアの仕事、数字が食い違うとき、どれを信じるか](https://www.stacklogs.io.vn/ja/kosatsu/shinjin-engineer-data-mujun/index.md): 1つの数字だけでは結論は出せません。大規模な研究は、AIの影響を受けやすい職種で22歳から25歳の雇用が弱まる一方、経済全体の雇用喪失は見えないとしています。金利、米国の税ルール、2021年から2022年の採用過熱も関係しえます。誰を、何を、いつから、どのデータで数えたか、他に何が変わったか、どこまで確かかを確認しましょう。
- [知らないライブラリをAIと学んで腕を落とさない：4週間の計画](https://www.stacklogs.io.vn/ja/ayumi/ai-to-manabu-skill-wo-nokosu/index.md): AIに任せきりにしなければ、AIと学びながら腕を残せます。Anthropicの実験では、Trioというライブラリを学んだ52人の開発者のうち、AIを使った班の点数は約50%、自力の班は約67%でした。ただし、質問して説明を受ける3つの使い方では学びが保たれました。提案するルールは、先に予想する、説明を頼む、記憶から書き直す、AIオフの回を残す、の4つです。
- [存在しないパッケージ：スロップスクワッティングと、エージェントに闇雲にインストールさせない方法](https://www.stacklogs.io.vn/ja/gijutsu/slopsquatting-sonzai-shinai-package/index.md): スロップスクワッティングとは、AIがよく作り出すライブラリ名を攻撃者が先に登録し、人やエージェントがインストールするのを待つ攻撃です。USENIX Security 2025の研究では、商用モデルが出したパッケージ名の少なくとも5.2%、オープンソースモデルの21.7%が実在しませんでした。ロックファイル、新規パッケージの確認、インストールの承認で防ぎます。
- [AIが間違えたら、誰が責任を取るのか](https://www.stacklogs.io.vn/ja/kosatsu/ai-ga-machigaetara-dare-ga-sekinin-wo-toru-ka/index.md): 実際の2つの事例からの共通の教訓は、「AIがやったのであって、私ではない」は受け入れられない、ということです。カナダの審判所は、エア・カナダに自社チャットボットの言葉への責任を認め、ニューヨークの裁判所は、AIが作り出した判例を確認せずに提出した弁護士に制裁金を科しました。現実的な進め方は、機能ごとに責任者を1人決め、リスクの高いところに人の確認を置き、ログを残し、人への引き継ぎ経路を用意し、個人を責めずにインシデントを書き残すことです。法的助言ではありません。
- [AI機能を測る：品質、費用、信頼](https://www.stacklogs.io.vn/ja/purodakuto-shiko/ai-kinou-wo-hakaru-hinshitsu-hiyou-shinrai/index.md): AI機能は、3つの層を同時に測るべきです。品質：失敗の分類ごとの合格率で、エラー分析とevalsから取る。費用：レビューの手間を含めた、成功した結果あたりの費用と、平均でなくp95での遅延。信頼：利用者の受け入れ、修正、上書きの率、誤りを報告した回数、人に引き継いだケース。1つの層だけを測ると盲点が生まれます。この記事の閾値は例にすぎず、共通の標準はありません。
- [1つの間違ったコマンド、4時間：2017年のAmazon S3の話](https://www.stacklogs.io.vn/ja/monogatari/machigai-no-1komando-4jikan-amazon-s3-2017/index.md): 2017年2月28日、US-EAST-1リージョンで遅い課金処理をデバッグしていたとき、S3チームの権限を持つメンバーが、あるサブシステムから少数のサーバーを外すコマンドを実行しましたが、入力の打ち間違いで、意図より多くのサーバーが外れ、S3のインデックスと配置のサブシステムも含まれました。この2つは完全な再起動が要り、AWSは、大きなリージョンではそれを何年も完全には行っていなかったと述べています。そのためS3は、始まりから約4時間17分後の太平洋時間午後1時54分にやっと正常に戻りました。AWSは、容量をよりゆっくり外すようツールを変え、サブシステムを必要な最小容量より下げる削除をすべて遮るようにしました。
- [AIが書いたコードのテスト：いつも緑のテストを避ける](https://www.stacklogs.io.vn/ja/gijutsu/ai-ga-kaita-code-no-test-tsuneni-midori-wo-sakeru/index.md): AIがコードとテストの両方を書くと、テストは要件でなく、書いたばかりのコードに合わせがちで、不具合を捉えないまま緑になります。高いカバレッジでも足りません：ミューテーションに導かれたテスト生成の論文は、カバレッジ100%でもミューテーションスコアは約4%というテストスイートに触れています。テストの価値を保つ7つの方法：コードでなく仕様からテストを書く、直す前にテストが失敗するのを見る、自分でコードを壊してテストが赤になるか見る、ミューテーションテスト、プロパティベーステスト、境界値の表、一度実際に動かす。
- [エージェントへの依頼を書くときの7つの間違い](https://www.stacklogs.io.vn/ja/keiken/agent-eno-irai-no-shippai-7tsu/index.md): AIエージェントへの依頼を書くときのよくある7つの間違い：完成の定義と確かめる方法がない、症状と見る場所を示さずあいまい、気にしている好みと制約を隠す、望む範囲を隠す、すでに持っているもの（ファイル、画像、エラー）を渡さない、最初からやり直さず1か所を直し続ける、停止の規則も承認者もなく1人で動かす。Anthropicのガイドは2つを強調します：エージェントが自分では見えないことを伝え、合格か不合格を返す検査を渡すこと。
- [AIと1日で13本の記事：gitの履歴からの記録と数字](https://www.stacklogs.io.vn/ja/genba-noto/ichinichi-13-hon-no-kiji-ai-to-git-no-sushi/index.md): ある日の11:08から16:23まで、このブログ自身のリポジトリでAIエージェントと行った1回の作業で、22コミット（機能11、修正7、文書4）、スライドと共有画像つきの3言語の記事12本、合計17,630行の変更が生まれました。利用者は47通のメッセージを送り、そのうち16通が不具合報告ややり直しの依頼でした。15:00より前は33通のうち15通が不具合報告（45%）、15:00以降は14通のうち1通だけ（7%）。数字が測るのは速さと修正の回数で、品質や読者ではなく、1人、1つのプロジェクト、対照なしです。
- [AI時代の面接：2週間の計画](https://www.stacklogs.io.vn/ja/ayumi/ai-jidai-no-mensetsu-2shukan-keikaku/index.md): AI時代のコーディング面接には、共通の決まりがありません：CoderPadの2026年の報告の要約によると、採用担当のおよそ46%がAIを認め（広くまたは条件つき）、20%はケースごとに決め、34%は禁じており、Googleは、AIアシスタントつきのコードの読解とデバッグの回を試していると報じられています。だから最初の一歩は、採用側にルールを聞くことです。2週間の計画：ルールを聞く、AIなしで基礎を練習する、見知らぬコードを読んでデバッグする練習をする、規律を持ってAIと作業する練習をする（計画を述べ、小さく頼み、読み、テストし、説明する）、人と模擬面接をする、AIの使い方についての3つの話を準備する。
- [AI機能のための評価を書く：実際の30件から始める](https://www.stacklogs.io.vn/ja/gijutsu/ai-kinou-no-evals-30-no-jissai-no-jirei/index.md): AI機能を測るには、基盤を作る前に、実際のデータでのエラー分析から始めます：少なくとも約30件を手で読み、それぞれで何が悪かったかを書き、メモを失敗の分類にまとめて数えます。それから初めて、実際に見た失敗について評価を書きます。規則で書けるなら通常のコードによる検査を優先し、判断が要るときだけモデルを審査役にし、その審査役を人の採点と照らし合わせます。段階評価ではなく、合格か不合格で採点します。
- [仕様駆動開発：AIに任せる前に仕様を書く](https://www.stacklogs.io.vn/ja/gijutsu/spec-kudo-kaihatsu-shiyosho-wo-saki-ni/index.md): 仕様駆動開発とは、機能の望ましい振る舞いを先に書き、AIにそれに基づいて作らせることです。マーティン・ファウラーは3つの段階を挙げます：先に仕様を書き、後で捨ててもよい（spec-first）、仕様を残して保守に使う（spec-anchored）、仕様を主な源とし、コードは生成物とする（spec-as-source）。彼は実際的な限界も挙げています：小さな作業にも同じ重い手順、レビューしにくい繰り返しの多いファイル、エージェントが仕様を無視することがあること。実際的なやり方は、中規模と大規模の作業に軽い仕様を使い、小さな作業では省くことです。
- [AIアプリのOWASP Top 10：身近なたとえで説明する](https://www.stacklogs.io.vn/ja/gijutsu/ai-apuri-no-owasp-top10-mijika-na-rei/index.md): LLMアプリ向けのOWASP Top 10（2025年版）には10のリスクがあります：プロンプトインジェクション、機微情報の漏えい、サプライチェーン、データとモデルの汚染、不適切な出力処理、過剰な権限、システムプロンプトの漏えい、ベクトルと埋め込みの弱点、誤情報、無制限の消費。アプリをホテルの受付係に例えると、見知らぬ人がメモを差し込み、誰かが従業員の手引きを書き換え、受付係がマスターキーを持っている、という状況です。OWASPは、プロンプトインジェクションを完全に防ぐ方法はないと強調しており、最小限の権限、モデルの出力を信頼しないこと、リスクの高い操作を人が承認することで被害を減らします。
- [AIがコードを速く書く時代、開発者はまだ創造的な仕事なのか](https://www.stacklogs.io.vn/ja/kosatsu/ai-ga-hayaku-kaku-jidai-kaihatsusha-wa-souzou-suru-ka/index.md): はい、まだ創造的です。ただし創造的な部分は移ります。コードを書くことが安くなると、代わりにくい仕事は、解く価値のある問題を見つけること、方向を選びトレードオフを引き受けること、結果を確かめること、システムとその周りの人を気遣うことです。リスクは本物です。書くことをすべて任せると、AIが作ったものを判断する力を失いかねません（Anthropicの小さな試験では、AI群のテストは約50%、自分で書いた群は約67%）。技を保つには、まず自分でアイデアを描き、採点者として読み、削る練習をし、楽しみのために小さなものを作ることです。
- [エンジニアが間違ったデータを消した日：GitLab 2017年の話](https://www.stacklogs.io.vn/ja/monogatari/gitlab-2017-machigatte-deta-wo-keshita-hi/index.md): 2017年1月31日、GitLab.comのデータベースの副サーバーを作り直している最中に、エンジニアが副サーバーでなく主サーバーのデータディレクトリを消すコマンドを実行し、止めるまでに約300GBを失いました。バックアップを探すと、使える層はなく、GitLabは約6時間前のスナップショットから約18時間かけて復旧し、少なくとも5,000のプロジェクト、5,000のコメント、約700のアカウントのデータを失いました。GitLabの主な教訓：復元を試したことのないバックアップは、まだバックアップではない。打ち間違いは、運用上の失敗の連鎖の最後の輪にすぎなかった。
- [新人と先輩の対話：AI時代の学び方](https://www.stacklogs.io.vn/ja/taiwa/shinjin-to-senpai-no-taiwa-ai-jidai-no-manabi/index.md): 新人と先輩の作り直した対話から、4つのことが分かります：市場がAIで変わらないと約束できる人はいませんが、理解、デバッグ、コードの説明は今も確かめられる。AIに練習問題を書かせると学びが減りうる（Anthropicの小さな試験では、AI群のテストは約50%、自分で書いた群は約67%）。先輩に聞くのは自分で試した後で、試したことを持っていく。そして先輩もAIを確かめるべきで、速く感じることは測定ではない。
- [MCPとは何か？コンセントで説明する](https://www.stacklogs.io.vn/ja/gijutsu/mcp-towa-konsento-de-setsumei/index.md): MCP（Model Context Protocol）は、AIアプリが外部のツールやデータに、共通のやり方でつながるためのオープンな規格で、あらゆる家電のための共通のコンセントのようなものです。AIアプリごとにツールごとの接続を書く代わりに、ツールはMCPサーバーを持ち、AIアプリはMCPを話せればよくなります。その代わり、サーバー1つ1つがAIに電気を送るコンセントなので、ヒューズが要ります：最小限の権限、重要な操作への人の承認、見知らぬ人のサーバーは未検証のコードとして扱うこと。
- [生産性をコードの行数で測らない](https://www.stacklogs.io.vn/ja/purodakuto-shiko/gyosu-de-seisansei-wo-hakaranai/index.md): コードの行数は書かれた文字の量を測るもので、届けた価値を測りません。目標になった途端にゆがみます（グッドハートの法則）。AIが数秒で数千行を書く今は、さらに意味が薄れます。チームと成果で測りましょう：アイデアから利用者に届くまでの時間、変更の失敗率、レビュー待ち、手戻り、チームの満足度。個人の順位づけではなく、傾向として使います。
- [バトンリレーから、みんなでパン作りへ：AI時代のITチームの働き方](https://www.stacklogs.io.vn/ja/keiken/ai-jidai-no-chimu-no-hataraki-kata/index.md): 多くのITチームが、仕事を何工程にも回す形から、AIアシスタントのおかげで一人ひとりが遠くまで進める小さなチームへ移ろうとしています。会議を重ねる代わりに背景を紙に書きます。ボトルネックは書く工程から確認する工程へ移るため、レビューの決まりと十分なテストが必要です。
- [バイブコーディングで1日でプロトタイプ：向く場面と危ない場面](https://www.stacklogs.io.vn/ja/purodakuto-shiko/vibe-coding-ichinichi-purototaipu/index.md): バイブコーディング、つまりAIにコードを書かせて細かく読まないやり方は、使い捨てのプロトタイプに向いています：アイデアの検証、実際の人へのデモ、個人用ツール。実際の利用者、個人データ、ログイン、決済が入ると、誰も読まない部分に不具合が潜むため危険になります。規則：プロトタイプは使い捨てと考え、捨てる日を書き、セキュリティとテストのチェックリストを通してから本番環境に出す。
- [AI時代の新人：ジュニアになるための12か月計画](https://www.stacklogs.io.vn/ja/ayumi/ai-jidai-no-shinjin-12kagetsu-keikaku/index.md): AI時代の新人は、12か月を4つのことに順番に使うとよいでしょう：手で書く基礎（第1四半期）、AIを家庭教師にした小さなプロジェクト（第2四半期）、レビュー、不具合修正、オープンソースへの貢献など実践に近い環境（第3四半期）、そしてポートフォリオと面接（第4四半期）。一貫した規則は、先に自分で書き、AIには後で説明してもらい、自分のコードをいつも説明できること。Anthropicの小さな無作為化試験では、AIに書いてもらった人は、自分で書いた人より知識テストの成績が低かったと報告されています。
- [AI向けの手引き（AGENTS.md）：短く、正しく、役に立つ書き方](https://www.stacklogs.io.vn/ja/gijutsu/agents-md-no-kakikata/index.md): AGENTS.mdは、AIエージェントが自分では見抜けないこと（コマンド、全体像、決まり、禁止事項）を伝える、プロジェクト内のテキストファイルです。効果については2つの研究が食い違うので、短く、人が書き、コードから読み取れないことだけを書き、前後で測ってください。
- [AIが書いたコードのレビュー：差分を読む人のための15項目チェックリスト](https://www.stacklogs.io.vn/ja/gijutsu/ai-ga-kaita-code-no-review/index.md): AIがコードを書くとボトルネックはレビューに移るので、レビュアーには感覚で読むのではなく決まったチェックリストが要ります。15項目は4つのグループで、作業の理解、正確で安全、価値あるテスト、保守しやすさです。特に見落とされやすいのは、ライブラリが実在するか、入力を信じすぎていないか、コードが間違いのときにテストが失敗するかです。
- [実際のプロジェクトでAIエージェントと働いた3時間：記録と数字](https://www.stacklogs.io.vn/ja/genba-noto/ai-agent-jissai-no-purojekuto-nikki/index.md): このプロジェクトでAIエージェントと3時間作業したところ、12コミットのうち7つが人のフィードバックを受けた修正で、変更行数ではわずか約5%でした。人のメッセージの半分近くが不具合報告ややり直しの依頼で、不具合の大半は論理の誤りではなく、目に見えるものでした。
- [AIを鵜呑みにしてはいけない理由：推測の仕組みを知り、検証すべき場面を見極める](https://www.stacklogs.io.vn/ja/gijutsu/ai-wo-unomi-ni-shinai-riyu/index.md): AIが書くのは、いちばん正しそうに聞こえる文であって、確認された文ではありません。次にどの語が来るべきかを推測しているとイメージでき、だから数字を作り上げたり、意味を取り違えたり、計算を間違えたりしても、とても自信のある口調で話します。正しい使い方は条件つきの信頼で、結果の重さに応じて確認します。
- [開発者という職業の変遷：手書きコードからAIエージェント、そしてその先へ](https://www.stacklogs.io.vn/ja/kosatsu/kaihatsusha-no-ayumi/index.md): 開発者という職業のボトルネックは移り続けてきました。コードを書けること、解決策を探すこと、システムを運用すること、機械が書いたコードを確認すること、そして正しい問題を定義してAIを指揮することへ。長く使えるのは、システム思考、仕様を書く力、レビューとテストです。

## Optional

- [Tiếng Việt: home](https://www.stacklogs.io.vn/), [RSS](https://www.stacklogs.io.vn/rss.xml)
- [English: home](https://www.stacklogs.io.vn/en/), [RSS](https://www.stacklogs.io.vn/en/rss.xml)
- [日本語: home](https://www.stacklogs.io.vn/ja/), [RSS](https://www.stacklogs.io.vn/ja/rss.xml)
- [Sitemap](https://www.stacklogs.io.vn/sitemap.xml)