Dạo gần đây mấy model free trên OpenRouter đang không ổn định lắm, lúc dùng được lúc thì không. Sẵn còn vài $ credit trên đấy nên nay tranh thủ bào nốt rồi chuyển qua iFlow dùng hẳn (cho đến khi iFlow hết free :v). Mời bạn thưởng thức Newsletter #65. Bài viết này được thực hiện bởi Claude Code, Claude Code Router, OpenRouter & Anthropic: Claude Sonnet 4.5 (model ‘xịn’ nhe hehe)
Scaling Engineering Teams: Lessons from Google, Facebook, and Netflix
Ido Green, người có hơn mười năm lãnh đạo kỹ thuật tại Google, Facebook và Netflix, cho rằng khi mở rộng từ 10 lên hơn 1.000 kỹ sư, đội ngũ phát triển tốt hay sụp đổ phụ thuộc vào ba yếu tố: đặt mục tiêu có cấu trúc, tập trung tuyệt đối vào chất lượng mã nguồn và chủ động xây dựng văn hóa. Ở Google, OKR được đặt đầy tham vọng, mỗi đội 3–5 mục tiêu với 2–4 kết quả đo được, và đạt 60–70% mới là lý tưởng; đạt 100% nghĩa là mục tiêu chưa đủ cao. Về chất lượng, Facebook yêu cầu mọi dòng mã đều được đánh giá, mọi phần kho mã đều có người sở hữu và mã mới đạt độ bao phủ kiểm thử từ 80%; Netflix chủ động gây lỗi bằng Chaos Monkey (tắt ngẫu nhiên máy chủ), diễn tập sự cố và triển khai canary cho 1% người dùng trước.
Về văn hóa, Google dành một buổi chiều mỗi tháng cho thử nghiệm; Facebook cho nhân viên mới học khóa Bootcamp 6 tuần, sửa lỗi khắp hệ thống rồi mới tự chọn đội; Netflix thuê người giỏi, trả lương cao và đối xử với họ như người trưởng thành. Tác giả khuyên theo dõi bốn chỉ số DORA như tần suất triển khai và thời gian khôi phục. Bài học lớn nhất: văn hóa anh hùng, quy trình thủ công và kiến thức truyền miệng ổn với 10 người nhưng thành thảm họa với 100 người; thứ mở rộng được là hệ thống, tài liệu, tự động hóa và quyền sở hữu rõ ràng. Thay vì sao chép máy móc, hãy thực thi nhất quán và đo đúng thứ quan trọng.
The Trap of Excessive AI Use
David Pereira, tác giả cuốn “Untrapping Product Teams”, cho rằng lạm dụng AI sẽ khiến chúng ta trở nên tầm thường chứ không giỏi hơn. Ông không phản đối AI mà phản đối tư duy “tự động hóa mọi thứ”: nếu AI làm được thì mình không cần bận tâm. AI giúp ta nhanh hơn nhưng không khôn ngoan hơn. Ông chỉ ra những thói quen đáng lo: giao việc xếp ưu tiên cho AI, nhờ AI viết tài liệu yêu cầu sản phẩm thay vì tự nghĩ điều gì quan trọng, tóm tắt mọi thứ thay vì học chậm, và thay nghiên cứu thực tế bằng nhận định do AI tạo ra. Tư duy phản biện, thấu hiểu hành vi con người và thách thức giả định phải thuộc về chính mình; nghịch lý là càng nhiều người vội giao hết cho AI thì người không làm vậy càng có giá trị.
Pereira kể những thói quen “lỗi thời” của mình như đọc mọi tin nhắn, tự viết email để có thời gian suy nghĩ, đọc trọn từng cuốn sách, ghi chép tay và làm từng việc một, và coi đó là lợi thế cạnh tranh. Dù vậy, AI vẫn hữu ích khi tăng tốc việc giá trị thấp (bản nháp biên bản họp, tổng hợp tính năng của đối thủ), khám phá phương án thay thế và phản biện giả định, viết lại thông điệp cho từng đối tượng, và gợi ý nhiều phương án thử nghiệm để học nhanh hơn. Nguyên tắc của ông là “AI có thể viết nháp, nhưng tôi quyết định”: hãy giao việc chứ đừng giao quyền sở hữu, vì để AI quyết định là chuyển từ tận dụng công cụ sang buông bỏ trách nhiệm.
How Google, Amazon, and CrowdStrike Broke Millions of Systems
Milan Milanović phân tích ba sự cố lớn cho thấy ở quy mô siêu lớn, lỗi rất đơn giản cũng có thể thành thảm họa. Tháng 10/2025, một race condition trong hệ thống tự động quản lý DNS của DynamoDB tại us-east-1 khiến AWS gián đoạn 15 giờ với 113 dịch vụ: một DNS Enactor bị chậm ghi đè Route 53 bằng kế hoạch cũ đúng lúc Enactor khác dọn các kế hoạch “hết hạn”, làm bản ghi DNS bị xóa sạch, một lỗi kinh điển kiểu kiểm tra một lúc, ghi một lúc (TOCTOU). DNS được sửa sau khoảng 3 giờ, nhưng các lỗi dây chuyền kéo dài thêm 12 giờ. Tháng 6/2025, Google Cloud sập khoảng 7 giờ: đoạn mã mới trong Service Control, cửa ngõ của mọi lời gọi API, thiếu kiểm tra null và không có feature flag, nằm im 14 ngày cho đến khi một chính sách có trường trống được Spanner sao chép ra toàn cầu trong vài giây.
Sự cố thứ ba xảy ra tháng 7/2024: bản cập nhật Channel File 291 của CrowdStrike cho trình điều khiển chạy ở chế độ kernel đọc con trỏ NULL, khiến 8,5 triệu máy Windows khởi động lại liên tục, và từng máy phải sửa thủ công trong Safe Mode. Điểm chung là tốc độ được đặt trên an toàn, điểm lỗi đơn lẻ có phạm vi ảnh hưởng quá rộng, và chính cơ chế tự khôi phục trở thành nguồn lỗi. Bài học rút ra: ghi dữ liệu bằng thao tác nguyên tử, thêm circuit breaker và backoff có jitter cho quá trình khôi phục, triển khai theo giai đoạn với canary, kiểm tra dữ liệu trước khi sao chép toàn cầu và kiểm thử cấu hình như mã nguồn.
The Linux Boot Process: From Power Button to Kernel
Bài viết giải thích dễ hiểu quá trình Linux khởi động trên máy x86, từ lúc bấm nút nguồn đến khi kernel bắt đầu chạy. Khi có điện, CPU tự đặt lại về real mode, chế độ 16-bit có từ chip 8086, rồi nhảy đến reset vector tại 0xFFFFFFF0, nơi firmware đặt sẵn lệnh nhảy vào mã của mình. BIOS kiểu cũ tìm ổ đĩa có sector 512 byte đầu tiên kết thúc bằng 0x55 0xAA, còn UEFI hiện đại đọc được hệ thống tệp và nạp chương trình khởi động lớn hơn. Bootloader như GRUB nạp kernel vào bộ nhớ, điền setup header rồi chuyển quyền cho chương trình setup. Chương trình này dựng môi trường dự đoán được: căn chỉnh thanh ghi segment, tạo stack, xóa vùng BSS và hỏi firmware bản đồ RAM qua lời gọi e820. Tiếp theo là hai bước chuyển chế độ: sang protected mode 32-bit (tắt ngắt, mở đường A20, nạp GDT và IDT tối thiểu, bật bit PE trong CR0), rồi sang long mode 64-bit (bật PAE trong CR4, dựng bảng trang ánh xạ đồng nhất, ghi địa chỉ bảng vào CR3, bật bit LME trong EFER).
Ở chế độ 64-bit, hàm extract_kernel giải nén kernel (gzip, xz, zstd…), đọc ELF header để biết đặt mã và dữ liệu ở đâu, áp dụng relocation nếu kernel không nằm ở địa chỉ mặc định, rồi nhảy vào start_kernel. Bài cũng giải thích kASLR: bộ giải nén chọn ngẫu nhiên địa chỉ cơ sở vật lý và ảo trong các vùng nhớ trống, tránh những vùng cần giữ như initrd, khiến kẻ tấn công khó đoán vị trí kernel; nếu không có chỗ phù hợp thì quay về địa chỉ mặc định. Bài kèm bảng thuật ngữ, rất hợp cho người mới.
Build System Tradeoffs
jyn, người đang phát triển hệ thống build cho trình biên dịch Rust, mở đầu loạt bài về hệ thống build bằng bức tranh tổng quan về những gì dự án phức tạp phải tính đến: chạy chính các chương trình vừa build (như kiểm thử tích hợp gọi cargo build bên trong cargo test), theo dõi phụ thuộc chính xác, biên dịch chéo (cần trình biên dịch, thư viện chuẩn và trình liên kết cho nền tảng đích), lựa chọn giữa liên kết động và liên kết tĩnh, và build tái lập được, điều kiện để dùng cache an toàn. Theo tác giả, lỗi phổ biến nhất là ép cấu hình vào một ngôn ngữ riêng: làm build “khai báo” chỉ là ảo tưởng, nên hãy dùng một ngôn ngữ thật rồi tuần tự hóa đồ thị build ra định dạng tối giản như Ninja.
Về theo dõi phụ thuộc có bốn hướng. Tự khai báo bằng tay, kể cả khi có trình biên dịch hỗ trợ như gcc -M, vẫn dễ sai. Luôn build lại từ đầu thì luôn đúng nhưng tốn kém. Build kín (hermetic) như Bazel, Buck2, Nix chỉ cho dùng đầu vào đã khai báo, nhờ đó dùng được cache từ xa. Build theo vết (tracing) như Tup, Ekam tự phát hiện phụ thuộc bằng cách theo dõi syscall, không cần khai báo nhưng gần như chỉ chạy trên Linux và gặp khó ở quy mô lớn vì không biết trước đồ thị. Tác giả kết luận ưu tiên tính đúng đắn luôn kèm đánh đổi, kết hợp tracing với build kín có vẻ là giải pháp tốt nhất, và viết luật build bằng ngôn ngữ thông thường rồi tuần tự hóa thành đồ thị có ít nhược điểm đến bất ngờ.
How I Use Every Claude Code Feature
Shrivu Shankar tổng hợp cách anh dùng gần như mọi tính năng của Claude Code. Nền tảng quan trọng nhất là tệp CLAUDE.md gốc, “hiến pháp” của agent: ở công ty, tệp này giữ ở mức 13KB và chỉ ghi công cụ được từ 30% kỹ sư trở lên sử dụng. Anh khuyên bắt đầu bằng các rào chắn dựa trên lỗi Claude hay mắc thay vì viết cẩm nang, không nhúng tài liệu bằng @ vì làm phình ngữ cảnh, và không chỉ cấm mà luôn đưa ra cách thay thế. Với cửa sổ ngữ cảnh 200k token, anh tránh /compact vì khó kiểm soát, thay bằng /clear kèm lệnh tự tạo /catchup để đọc lại các tệp đã đổi, hoặc cho Claude ghi tiến độ ra tệp .md rồi mở phiên mới. Anh không dùng subagent tùy biến vì chúng che giấu ngữ cảnh và ép agent theo quy trình của con người; thay vào đó, agent chính tự dùng Task(...) tạo bản sao của chính nó, kiến trúc anh gọi là “Master-Clone”.
Hook rất quan trọng trong kho mã doanh nghiệp: chặn lúc commit khi kiểm thử chưa qua, cộng hook gợi ý không chặn, nhưng tránh chặn lúc ghi tệp vì làm agent rối giữa chừng. Đồng tình với Simon Willison, anh cho rằng Skills có thể quan trọng hơn MCP vì chúng chính thức hóa lớp “viết script”, bậc tiến hóa sau prompt đơn lẻ và gọi công cụ; MCP chỉ nên là cổng truy cập an toàn cho môi trường có trạng thái như Playwright. Tính năng bị đánh giá thấp nhất là GitHub Action: toàn quyền kiểm soát container, sandbox chặt và nhật ký đầy đủ để định kỳ phân tích, cải thiện CLAUDE.md cùng công cụ.
If you don’t tinker, you don’t have taste
seatedro viết về “tinkering”, tức mày mò chỉnh sửa những thứ nhỏ để cải thiện chúng, như một công cụ học tập suốt đời. Tác giả từng thử đủ thứ, từ guitar, mỹ thuật đến võ thuật, nhưng lại không mày mò với lập trình; thói quen này đến khá muộn, giờ đã thành cốt lõi trong cách tác giả học, và tác giả tiếc vì không bắt đầu sớm hơn. Mày mò là dành hàng giờ chỉnh độ nhạy chuột trong game, mất nhiều ngày cấu hình trình quản lý cửa sổ trên Linux chỉ vì thích, hay tháo bàn phím cơ để thay keycap và thử switch. Có người chỉ làm gì đó khi nó giúp đạt mục tiêu, có người làm “chỉ vì thích”; lý tưởng là kết hợp cả hai. Tác giả dẫn lời @ludwigABAP rằng mày mò rồi bỏ đi chính là luyện tập, và luyện tập nên mang tính tạm thời, khám phá và diễn ra thường xuyên.
Theo tác giả, dùng Git qua dòng lệnh thay vì GitHub Desktop hay biết phím tắt vim nên là mức tối thiểu chứ không phải điều hiếm có, nhưng cũng cần cân bằng: lần cuối tác giả chỉnh cấu hình neovim đã là sáu tháng trước. Chỉ trong một tuần, tác giả lần đầu viết fragment shader GLSL, macro thủ tục trong Rust, template C++, một ứng dụng Swift và dùng thêm trình soạn thảo Helix, dù không việc nào thật sự cần thiết. Thông điệp chính là “gu”, khả năng phân biệt sự tầm thường với sự xuất sắc, chỉ hình thành khi bạn thử nhiều thứ, giữ cái mình thích và bỏ cái không hợp; vì thế hãy đặt câu hỏi với lối mòn, thử nghiệm và làm hỏng mọi thứ, mỗi ngày.
Bonus: Vài ảnh hay ho đến từ ByteByteGo
Đánh giá: Uầy, đang process url cuối thì hit limit mất rồi. Ban đầu còn 2$ (cỡ 52k) mà process được có 7 urls, tính ra là ~7.5k vnđ/bài. Khá là chát đó chứ :v Mà kết quả thì cũng chưa ưng ý lắm, vẫn còn lạm dụng tiếng Anh. Nhìn vào bài cuối là thấy rõ. Cũng có thể là vấn đề ở file AGENTS.md của mình, để mình optimize lại sau vậy. Dù gì thì mình cũng đã đạt được mục đích là tranh thủ bào để quay lại xài đồ free rồi :v Hẹn gặp lại các bạn trong các bài viết tiếp theo :D.
Bài viết đã được viết lại bởi Claude Code với Opus 5.5 vào ngày 27/09/2026.