Mời bạn thưởng thức Newsletter #125.

275 - Khi Big Tech chuyển mình thành AI Factory

Bài viết chia sẻ góc nhìn thực tế về quá trình một tập đoàn công nghệ lớn chuyển mình thành “AI factory”. Tác giả chia tự động hóa bằng tác nhân thành năm cấp độ: từ việc kỹ sư sao chép mã nguồn do chatbot tạo ra, đến tác nhân hỗ trợ theo từng chỉ dẫn, tự đi từ đặc tả tới yêu cầu hợp nhất kèm kiểm thử, rồi con người chỉ còn điều phối khâu đánh giá và triển khai, và cuối cùng là tác nhân tự triển khai, giám sát môi trường thật và xử lý sự cố. Mỗi bậc đòi hỏi tác nhân chủ động hơn, nên doanh nghiệp phải đầu tư vào môi trường vận hành an toàn, kiểm thử, phân quyền và cơ chế chặn các thao tác nguy hiểm.

Vai trò của kỹ sư vì thế dịch chuyển từ tự tay làm từng việc sang “đóng gói” công việc thành đặc tả có ranh giới, mục tiêu và tiêu chí nghiệm thu rõ ràng, điều khá khó với các kỹ sư mới vào nghề vốn quen viết mã theo kiểu mày mò. Đánh giá mã nguồn vẫn cần con người vì nhiều yêu cầu nằm trong bối cảnh ẩn; các hệ thống đánh giá tự động mới được chấp nhận khoảng một nửa số góp ý và tốn nhiều token khi mở rộng. Ngôn ngữ lập trình dần trở nên dễ thay thế, nhưng kiến thức về hệ điều hành, mạng, bảo mật, hạ tầng, cấu trúc dữ liệu và xử lý đồng thời vẫn là nền tảng để kỹ sư thẩm định và chịu trách nhiệm về kết quả do AI tạo ra.

The 80/20 rule for your whole life

Tác giả Yew Jin Lim đề xuất áp dụng nguyên tắc 80/20 cho cả cuộc sống: dành phần lớn nguồn lực xây dựng một nền tảng ổn định, còn phần nhỏ làm “phòng thí nghiệm” cho các thử nghiệm có kiểm soát. Nguyên tắc xuyên suốt là đánh giá cả danh mục chứ không phán xét từng vị thế riêng lẻ. Ví dụ đến từ chính trải nghiệm của tác giả: nhiều dự án tự chọn tại Google phần lớn không đi đến đâu nhưng cộng lại đã định hình năng lực của anh; tài khoản hưu trí tăng khoảng mười lần nhờ đóng góp tự động và kỷ luật không can thiệp; còn việc thiền tập sâu dần nhờ thực hành mỗi ngày.

Ba thói quen cốt lõi được rút ra là mở rộng kiến thức theo sự tò mò mà không đòi hỏi lợi ích ngay, làm chủ quyết định bằng cách tách cảm xúc khỏi từng kết quả, và kiên trì tích lũy để lãi kép phát huy tác dụng. Tác giả phân biệt rõ giao dịch ngắn hạn với đầu tư dài hạn và nhấn mạnh rằng khi nền tảng vẫn vững, nhiều lúc “không làm gì” lại là lựa chọn tốt nhất. Thử nghiệm không cần luôn thành công, miễn là mỗi lần đủ nhỏ để thất bại trở thành học phí thay vì thảm họa và phần nền tảng không bị đem ra đánh cược.

Three Bad Managers

Tác giả kể về ba người quản lý thông minh, thành công nhưng lại rất tệ trong việc quản lý con người, từ đó phân biệt lãnh đạo (vạch ra hướng đi cho tổ chức) với quản lý (giúp nhân viên hiểu mình đang ở đâu và vận hành công việc hằng ngày). “Người nghệ sĩ” là một người hướng nội tài năng, chỉ quan tâm đến sản phẩm sáng tạo và thờ ơ trước các vấn đề về con người. “Nhà độc tài” dùng quyền lực và sự áp đảo để chi phối thảo luận, chẳng hạn khơi lại những hướng thiết kế mà đội đã cân nhắc kỹ thay vì tin vào chuyên môn của họ. “Người cầm dao” thì thất thường đến mức mọi nỗ lực giao tiếp bằng lời hay bằng văn bản đều không hiệu quả.

Với mỗi người, tác giả chọn một cách thích nghi riêng: viết sẵn bản đánh giá chi tiết trước buổi gặp riêng với người nghệ sĩ, chuẩn bị chuyên môn thật kỹ để có thể phản biện ngang hàng với nhà độc tài, và đơn giản là tránh xa để tự làm việc với người cầm dao. Thông điệp cốt lõi là nhân viên hầu như không thể thay đổi cấp trên, nhất là khi họ ở vị trí cao, nhưng có thể thay đổi cách chuẩn bị, truyền đạt và phối hợp. Mỗi mối quan hệ công việc là một sự điều chỉnh, và khả năng thích nghi với từng người là một kỹ năng thiết yếu, không đồng nghĩa với việc chấp nhận cách quản lý kém.

Cross-Team Pragmatics

Phil Calçado phân tích vì sao phối hợp giữa các đội thường trở nên chậm chạp và căng thẳng khi tổ chức lớn dần. Các nguyên nhân gốc rễ khá dễ đoán: văn hóa đánh giá hiệu suất cá nhân khiến mỗi đội tối ưu cục bộ, mục tiêu chiến lược mâu thuẫn nhau khi truyền qua nhiều cấp (cắt giảm chi phí hạ tầng trong khi đội sản phẩm phải tăng doanh thu), trách nhiệm không đi kèm quyền sở hữu, và những bất đồng nhỏ liên tục bị đẩy lên lãnh đạo cấp cao thay vì được giải quyết nhanh. Giải pháp bền vững là một chiến lược kỹ thuật thống nhất, gắn cách doanh nghiệp cạnh tranh với cấu trúc đội ngũ, phạm vi sở hữu, cơ chế khuyến khích và cách ra quyết định.

Trong lúc chờ những thay đổi chậm rãi đó, tác giả đề xuất vài công cụ thực dụng để xử lý triệu chứng. Hiến chương đội biến các giả định ngầm thành ranh giới, phạm vi trách nhiệm và cách tương tác rõ ràng, giảm việc phải thương lượng lại liên tục. Phân tích dòng giá trị đi theo luồng công việc thực tế thay vì sơ đồ tổ chức để lộ ra những lần bàn giao thừa. Nguyên tắc 80% yêu cầu mỗi đội tự hoàn thành phần lớn công việc mà không bị đội khác chặn trên đường găng, còn mô hình Team Topologies giúp chủ động chọn kiểu tương tác giữa các đội. Các công cụ này chỉ mang lại ổn định tạm thời; việc lâu dài vẫn là liên tục điều chỉnh tổ chức theo cách giá trị thực sự được tạo ra.

Technological Involution

Bài viết lập luận rằng ngành công nghệ đang rơi vào trạng thái “nội quyển”: nhiều nhân lực và vốn hơn nhưng ý tưởng ngày càng đồng dạng. Theo tác giả, những ý tưởng hiển nhiên đã được khai thác gần hết, phần mềm thông thường dần bị hàng hóa hóa, còn văn hóa khởi nghiệp ở Thung lũng Silicon khiến nhà sáng lập tiếp nhận câu chuyện từ những người có ảnh hưởng thay vì tự hình thành niềm tin. Sự nổi tiếng tạo ra niềm tin chứ không phải giá trị thật, và xã hội cũng dần mất đi sự lạc quan về tương lai công nghệ. Trong khi đó, những bài toán khó nằm ở phần cứng, vi mạch và sự phức tạp trong vận hành doanh nghiệp, nơi phần lớn nhà sáng lập hiện nay còn thiếu kinh nghiệm thực tế.

AI rất giỏi lập trình nhưng có xu hướng đưa ra câu trả lời gần với số đông thay vì những góc nhìn khác thường nhưng có tác động lớn. Tác giả cho rằng chính giới hạn này lại để dành cơ hội cho sự sáng tạo của con người: người hiểu sâu lĩnh vực mình muốn thay đổi, kiểm nghiệm giả thuyết bằng tư duy nguyên lý đầu tiên và dám theo đuổi quan điểm riêng sẽ ngày càng có giá trị. Lối thoát khỏi nội quyển là quay về động lực nội tại, xây dựng thứ gì đó vì nó thực sự hấp dẫn về mặt trí tuệ thay vì tối ưu theo các chỉ số khởi nghiệp, và sự thành công của các hình thức truyền thông mới là minh chứng rằng sản phẩm có chủ đích vẫn có thể lan tỏa nhờ giá trị nội tại.

Fintech Engineering Handbook

Cẩm nang tổng hợp các nguyên tắc và mẫu thiết kế khi xây dựng hệ thống mà tiền là đối tượng trung tâm, xoay quanh ba yêu cầu: không tự tạo ra dữ liệu hay tiền, không làm mất dữ liệu, và không tin tưởng bất kỳ thành phần nào. Về biểu diễn tiền, tác giả so sánh số dấu phẩy động (hầu như không nên dùng), số có độ chính xác tùy ý, số nguyên theo đơn vị nhỏ nhất và số hữu tỉ, đồng thời cảnh báo rằng số trong JSON thường bị trình phân tích đọc thành số dấu phẩy động. Giao dịch được ghi bằng sổ cái kép, trong đó tiền chỉ di chuyển giữa các tài khoản và số dư được suy ra từ các bút toán; thời điểm phát sinh, thời điểm ghi sổ và thời điểm thanh toán cũng cần được lưu riêng.

Phần thực thi bao quát tạm giữ tiền để tránh chi tiêu hai lần, tính lũy đẳng với khóa định danh tường minh, khả năng tiếp tục sau sự cố và giao nhận ít nhất một lần. Với nhà cung cấp bên ngoài, hệ thống cần kiểm tra lược đồ ở ranh giới, lưu mọi yêu cầu và phản hồi, xác minh chữ ký của thông báo đẩy rồi truy vấn lại nguồn chính thức, và đối soát độc lập để phát hiện chênh lệch. Bản ghi đã hạch toán là bất biến, sai sót được sửa bằng bút toán bù trừ, còn thao tác nhạy cảm cần người khác phê duyệt. Các ví dụ về rút tiền mã hóa, nạp tiền bằng thẻ và chuyển đổi tài sản cho thấy các nguyên tắc này phối hợp với nhau qua nhiều bước và tình huống lỗi.

How to Write an Effective Software Design Document

Michael Lynch hướng dẫn cách viết tài liệu thiết kế phần mềm để phát hiện quyết định sai trước khi bắt tay vào triển khai và giúp các bên thống nhất cách giải quyết vấn đề. Tài liệu đáng đầu tư khi dự án có nhiều người phối hợp, kéo dài hơn ba tháng, sẽ chạy lâu dài trên môi trường thật, cần nhiều đội cùng tham gia, yêu cầu còn mơ hồ hoặc có rủi ro nghiêm trọng. Để quyết định nên viết gì, tác giả đưa ra một câu hỏi đơn giản: “cái giá của việc sai là bao nhiêu?”. Những lựa chọn khó đảo ngược về kiến trúc, lưu trữ dữ liệu, bảo mật hay quyền riêng tư cần được phân tích kỹ, còn chi tiết giao diện dễ sửa thì không đáng tốn thời gian.

Một tài liệu tốt thường có mục tiêu và bối cảnh, phạm vi cùng những gì nằm ngoài phạm vi, sơ đồ luồng dữ liệu và kiến trúc, chỉ tiêu mức dịch vụ đo lường được, các cân nhắc về bảo mật và quyền riêng tư, tiến độ với các mốc cụ thể, cùng danh sách vấn đề còn mở và đã giải quyết. Tài liệu nên tập trung vào những bài toán khó và việc thu thập phản hồi thay vì mô tả mọi chi tiết triển khai, vì khi đó bạn gần như đã viết xong mã nguồn. Tác giả cũng khuyên dùng công cụ vẽ sơ đồ có thể chỉnh sửa, định nghĩa thuật ngữ lạ, ghi lại các phương án thay thế để trả lời trước câu hỏi của người đọc, và viết sao cho cả những bên ngoài nhóm kỹ thuật cũng hiểu được.

The Cost YAGNI Was Never About

Kent Beck giải thích rằng YAGNI chưa bao giờ là chuyện tiết kiệm công sức viết mã nguồn, mà là nguyên tắc về thời điểm cam kết với một thiết kế. Xây dựng cấu trúc trước khi tính năng thực sự cần đến tạo ra hai khoản chi phí độc lập. Khoản thứ nhất là mất quyền lựa chọn: nhóm đặt cược vào một dự đoán khi chưa đủ thông tin, và khi yêu cầu thực tế khác đi thì phải tốn công đi vòng hoặc gỡ bỏ phần cấu trúc suy đoán đó. Ngay cả khi đoán đúng, nhóm vẫn thiệt vì đã từ bỏ cơ hội xây đúng cấu trúc vào lúc có thông tin tốt hơn; như tác giả nói, chờ đợi không phải lười biếng mà là đang nắm giữ một tài sản.

Khoản thứ hai là giá trị hiện tại ròng: chi phí bị đẩy lên sớm trong khi giá trị từ tính năng lại đến muộn, nên thiệt hại xảy ra bất kể dự đoán có chính xác hay không. Khi AI khiến việc tạo mã nguồn gần như miễn phí, lý do tiết kiệm công sức của YAGNI không còn, nhưng cả hai khoản chi phí trên vẫn nguyên vẹn. Thậm chí AI còn khiến việc sinh ra các khung phần mềm mang tính suy đoán trở nên quá dễ dàng. Vì vậy, hãy xây dựng cấu trúc khi nhu cầu đã xuất hiện và mang lại đủ thông tin để thiết kế đúng; YAGNI là kỷ luật về kinh tế chứ không phải sự tằn tiện.

a CVE dispute

Daniel Stenberg kể về tranh chấp CVE đầu tiên của curl kể từ khi dự án trở thành cơ quan có quyền cấp mã lỗ hổng. Với khoảng 30 tỷ bản cài đặt libcurl, mỗi CVE có thể kéo theo một lượng lớn công việc đánh giá, vá lỗi và phát hành lại trên toàn hệ sinh thái. Vì vậy, nhóm curl phân loại báo cáo theo rủi ro thực tế và đôi khi từ chối cấp CVE cho những lỗi có mức độ “thấp hơn cả mức thấp”, nhằm cảnh báo đầy đủ về vấn đề thật nhưng tránh gây báo động cho các kịch bản gần như chỉ tồn tại trên lý thuyết.

Lỗi bị tranh chấp nằm ở hàm so khớp tên máy chủ với chứng chỉ ký tự đại diện, khi tên máy chủ trong địa chỉ bắt đầu bằng dấu chấm. Để khai thác, nhiều điều kiện bất thường phải cùng xảy ra: người dùng truy cập một tên không hợp lệ với DNS, tên đó được phân giải bằng cách khác như tệp hosts cục bộ, máy chủ giả mạo có chứng chỉ phù hợp và kẻ tấn công phải kiểm soát được máy đó. curl đã sửa lỗi từ tháng 12/2025 nhưng không coi đây là lỗ hổng. Một nhà nghiên cứu bảo mật khiếu nại lên MITRE, và sau nhiều vòng xem xét trong năm 2026, MITRE đồng ý rằng đây chỉ là một lỗi đã được sửa, không phải lỗ hổng vì đòi hỏi kẻ tấn công cục bộ có đặc quyền. Câu chuyện cho thấy không phải lỗi nào cũng cần CVE, và quy trình tranh chấp giúp một bên độc lập xem xét lại quyết định.

How LLMs Actually Work

Bài viết giải thích cách mô hình ngôn ngữ lớn hoạt động mà không đi sâu vào toán học. Văn bản đầu vào được bộ tách từ chia thành các token và chuyển thành mã số, sau đó bảng nhúng biến mỗi mã thành một véc-tơ mang ý nghĩa đã học, nên những token có nghĩa gần nhau sẽ có véc-tơ gần nhau. Vì cơ chế chú ý không tự biết thứ tự, mô hình cần thêm thông tin vị trí; các mô hình hiện đại dùng RoPE, xoay véc-tơ truy vấn và khóa theo một góc phụ thuộc vào vị trí của token. Trong mỗi khối transformer, cơ chế chú ý so khớp truy vấn với khóa để quyết định lấy bao nhiêu thông tin từ véc-tơ giá trị của các token khác, còn nhiều đầu chú ý chạy song song giúp theo dõi cùng lúc các quan hệ ngữ pháp, tham chiếu và mẫu lặp.

Sau bước trao đổi giữa các token, mạng truyền thẳng xử lý riêng từng véc-tơ và chứa phần lớn tham số cũng như kiến thức của mô hình. Kết nối dư giúp thông tin tích lũy qua nhiều lớp mà không bị ghi đè, còn chuẩn hóa giữ cho độ lớn véc-tơ ổn định khi huấn luyện. Cuối cùng, véc-tơ của token cuối được chuyển thành phân phối xác suất trên toàn bộ từ vựng; mô hình lấy mẫu token tiếp theo, nối vào chuỗi rồi lặp lại, với nhiệt độ quyết định độ đa dạng của đầu ra. Các mô hình hiện đại dùng chung bộ khung này và chỉ khác nhau ở cấu hình, dữ liệu và cách huấn luyện.

Bonus

Images:

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.