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 đổi thành “AI factory”. Tác giả mô tả năm cấp độ tự động hóa, từ việc kỹ sư dùng chatbot hỗ trợ từng thao tác đến khi các tác nhân có thể tự tạo thay đổi, triển khai, giám sát hệ thống và xử lý sự cố. Để tiến lên các cấp độ cao hơn, doanh nghiệp cần thay đổi cách làm việc: chia công việc thành đặc tả rõ ràng, tăng chất lượng đánh giá đặc tả và mã nguồn, đồng thời xây dựng môi trường vận hành an toàn với vòng phản hồi đáng tin cậy.

Vai trò của kỹ sư vì thế dịch chuyển từ trực tiếp hoàn thành từng tác vụ sang thiết kế điều kiện để các tác nhân làm việc hiệu quả. AI có thể làm giảm rào cản về ngôn ngữ lập trình và nền tảng, nhưng không làm mất đi giá trị của kiến thức nền tảng. Hiểu biết về hệ điều hành, mạng, bảo mật, hạ tầng và cấu trúc dữ liệu vẫn cần thiết để thẩm định kết quả, nhận diện bối cảnh ẩn và bảo đảm chất lượng của hệ thống lớn.

Điểm chính:

• Tự động hóa bằng tác nhân phát triển qua năm cấp độ, với phạm vi chủ động và trách nhiệm ngày càng lớn.
• Phát triển dựa trên đặc tả và khả năng đánh giá đặc tả trở thành kỹ năng quan trọng của kỹ sư.
• Đánh giá tự động giúp giảm tải nhưng chưa thể thay thế hoàn toàn con người vì thiếu bối cảnh và có chi phí cao.
• Doanh nghiệp cần đầu tư vào môi trường vận hành, kiểm thử, phân quyền và cơ chế ngăn tác vụ nguy hiểm.
• Kiến thức khoa học máy tính nền tảng vẫn là cơ sở để kỹ sư kiểm chứng và chịu trách nhiệm về kết quả do AI tạo ra.

The 80/20 rule for your whole life

Bài viết mở rộng nguyên tắc 80/20 thành một cách tổ chức cuộc sống: dành phần lớn nguồn lực để xây dựng nền tảng ổn định, còn phần nhỏ làm “phòng thí nghiệm” cho những thử nghiệm có kiểm soát. Từ các dự án tự chọn tại Google, đầu tư tài chính đến thực hành thiền, tác giả cho rằng phần nền tảng giúp giới hạn tổn thất, trong khi phần thử nghiệm tạo cơ hội học hỏi và tìm ra những bước ngoặt bất ngờ.

Ba thói quen cốt lõi là liên tục mở rộng kiến thức, rèn khả năng ra quyết định và kiên trì tích lũy. Thử nghiệm không cần luôn thành công; điều quan trọng là quy mô của mỗi thử nghiệm phải đủ nhỏ để thất bại trở thành học phí thay vì thảm họa. Khi đánh giá kết quả, nên nhìn toàn bộ danh mục và chất lượng của quá trình ra quyết định, không để một lựa chọn riêng lẻ hay một kết quả ngẫu nhiên chi phối nhận định.

Điểm chính:

• Xây dựng nền tảng ổn định trước khi dành nguồn lực cho các thử nghiệm rủi ro hơn.
• Theo đuổi sự tò mò ở nhiều lĩnh vực để tạo ra những kết nối và kỹ năng có giá trị lâu dài.
• Điều chỉnh chiến lược theo hoàn cảnh, biết khi nào nên hành động và khi nào nên giữ nguyên.
• Bảo vệ quá trình tích lũy khỏi tổn thất nghiêm trọng bằng kỷ luật và đóng góp đều đặn.
• Ghi lại thử nghiệm, đánh giá cả danh mục và xem thất bại có kiểm soát là chi phí của việc học.

Three Bad Managers

Bài viết kể về ba người quản lý thông minh và thành công nhưng có những khiếm khuyết lớn trong cách làm việc với con người. “Người nghệ sĩ” chỉ quan tâm đến sản phẩm sáng tạo mà xem nhẹ đội ngũ; “nhà độc tài” dùng quyền lực và sự áp đảo để điều khiển mọi cuộc thảo luận; còn “người cầm dao” có khả năng dẫn dắt nhưng giao tiếp khó hiểu và gần như không thực hiện vai trò quản lý. Qua đó, tác giả phân biệt người lãnh đạo giỏi định hướng nơi tổ chức sẽ đến với người quản lý giỏi giúp nhân viên hiểu họ đang ở đâu và vận hành công việc hằng ngày.

Tác giả không cho rằng nhân viên có thể thay đổi cấp trên, đặc biệt khi họ giữ vị trí cao. Cách thực tế hơn là nhận diện điều họ coi trọng rồi điều chỉnh cách chuẩn bị, giao tiếp và phối hợp. Với từng kiểu người, tác giả lần lượt dùng văn bản để giải thích các vấn đề con người, chuẩn bị chuyên môn thật kỹ để tranh luận bình đẳng, hoặc chủ động tránh cản trở. Bài học cốt lõi không phải là chấp nhận hành vi quản lý kém, mà là hiểu rằng mỗi mối quan hệ công việc đòi hỏi một cách thích nghi khác nhau.

Điểm chính:

• Thành tích lãnh đạo và năng lực quản lý con người là hai khía cạnh khác nhau.
• Một người có thể đưa ra định hướng chiến lược tốt nhưng vẫn yếu trong giao tiếp và vận hành đội ngũ.
• Nhân viên khó thay đổi cấp trên, nhưng có thể thay đổi cách chuẩn bị và truyền đạt thông tin.
• Hiểu điều cấp trên thực sự quan tâm giúp lựa chọn cách phối hợp hiệu quả hơn.
• Khả năng thích nghi với từng người là một kỹ năng thiết yếu trong môi trường làm việc.

Cross-Team Pragmatics

Bài viết 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 phát triển. Những nguyên nhân phổ biến gồm động lực cá nhân không đồng nhất, mục tiêu bị biến dạng khi truyền qua nhiều cấp, trách nhiệm không đi kèm quyền sở hữu và bất đồng nhỏ liên tục bị đẩy lên lãnh đạo cấp cao. Giải pháp gốc rễ là một chiến lược kỹ thuật thống nhất, liên kết 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 đưa ra quyết định.

Trong khi chiến lược dài hạn chưa hoàn thiện, tác giả đề xuất giảm số lần các đội buộc phải phối hợp trên đường găng. Hiến chương đội giúp làm rõ nhiệm vụ, ranh giới và cách tương tác; phân tích dòng giá trị cho thấy công việc đang chờ ở đâu; còn nguyên tắc 80% yêu cầu mỗi đội có thể tự hoàn thành phần lớn danh sách công việc mà không bị đội khác chặn. Khi tổ chức trưởng thành hơn, có thể áp dụng các mô hình như Team Topologies để chủ động lựa chọn hình thức tương tác phù hợp. Các công cụ này chỉ xử lý triệu chứng và tạo sự ổn định tạm thời; công 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.

Điểm chính:

• Sai lệch về động lực, mục tiêu, quyền sở hữu và quyền quyết định khiến phối hợp liên đội ngày càng tốn kém.
• Hiến chương đội biến các giả định ngầm thành phạm vi trách nhiệm và giao diện làm việc rõ ràng.
• Nên theo dõi dòng giá trị thực tế thay vì coi sơ đồ tổ chức là nguồn thông tin duy nhất.
• Mỗi đội cần kiểm soát phần lớn công việc của mình để giảm phụ thuộc trên đường găng.
• Công cụ tổ chức ngắn hạn phải đi cùng chiến lược kỹ thuật dài hạn nhằm xử lý nguyên nhân gốc rễ.

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, tập trung vào những hướng đi đã được các tổ chức ở Thung lũng Silicon hợp thức hóa. Theo tác giả, cuộc cách mạng máy tính cá nhân đã trưởng thành, 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 ưu tiên kỹ năng gọi vốn, tăng trưởng và vị thế hơn sự tò mò kỹ thuật. AI có thể tăng mạnh năng suất lập trình nhưng không tự tạo ra tiến bộ rộng hơn nếu con người thiếu ý tưởng khác biệt và không giải quyết các vấn đề khó trong phần cứng, chuỗi cung ứng hay vận hành doanh nghiệp.

Lối thoát được đề xuất là xây dựng niềm tin công nghệ từ tiếp xúc trực tiếp với thực tế. Nhà sáng lập cần hiểu sâu lĩnh vực mình muốn thay đổi, trở thành người vận hành giỏi trước khi áp dụng phần mềm và dùng tư duy nguyên lý đầu tiên để kiểm nghiệm giả thuyết. AI thường đưa ra câu trả lời gần với đồng thuận, vì vậy khả năng hình thành quan điểm riêng và theo đuổi nó đến khi có bằng chứng bác bỏ sẽ ngày càng có giá trị. Tác giả nhìn sự trỗi dậy của các hình thức truyền thông mới như một dấu hiệu rằng sản phẩm có chủ đích, độc đáo và thực sự hữu ích vẫn có thể lan truyền nhờ giá trị nội tại.

Điểm chính:

• Sự đồng dạng về nguồn vốn, đào tạo và câu chuyện thị trường có thể thu hẹp không gian ý tưởng công nghệ.
• Phần mềm và AI chỉ là công cụ; nhiều cơ hội lớn nằm ở phần cứng và sự phức tạp trong vận hành thực tế.
• Hiểu sâu một lĩnh vực phải đến trước việc thiết kế giải pháp phần mềm cho lĩnh vực đó.
• Niềm tin vững chắc nên được hình thành qua trải nghiệm, nguyên lý đầu tiên và khả năng kiểm chứng.
• Ý tưởng khác biệt có giá trị hơn khi AI ngày càng giỏi tạo ra những câu trả lời theo xu hướng chung.

Fintech Engineering Handbook

Cẩm nang trình bày các nguyên tắc và mẫu thiết kế quan trọng khi xây dựng hệ thống mà tiền là đối tượng trung tâm. Toàn bộ nội dung xoay quanh ba yêu cầu: không tạo ra dữ liệu hoặc tiền ngoài ý muốn, không làm mất dữ liệu và không mặc nhiên tin tưởng bất kỳ thành phần nào. Từ đó, tác giả giải thích cách biểu diễn tiền với độ chính xác phù hợp, làm tròn có chủ đích, gắn số tiền với loại tiền tệ, quản lý tỷ giá và ghi nhận giao dịch bằng sổ cái kép bất biến.

Tài liệu cũng bao quát các vấn đề của hệ thống phân tán như tính lũy đẳng, xử lý đồng thời, giao hàng ít nhất một lần, khả năng tiếp tục sau sự cố và phát thông báo đáng tin cậy. Lịch sử kiểm toán phải ghi lại điều gì xảy ra, khi nào, do ai và vì sao; sai sót được sửa bằng bút toán đảo hoặc điều chỉnh thay vì xóa dữ liệu. Với nhà cung cấp bên ngoài và thông báo đẩy, hệ thống cần xác minh chữ ký, truy vấn lại nguồn chính thức và đối soát độc lập. 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 những nguyên tắc này phối hợp để bảo vệ số dư qua nhiều bước, độ trễ và tình huống lỗi.

Điểm chính:

• Không dùng số dấu phẩy động để lưu tiền; độ chính xác và cách làm tròn phải là quyết định rõ ràng.
• Sổ cái kép chỉ di chuyển giá trị giữa các tài khoản và không lưu số dư như nguồn sự thật.
• Dữ liệu tài chính cần bất biến, có dấu vết kiểm toán đầy đủ và được sửa bằng bản ghi bù trừ.
• Mọi thao tác có thể được thử lại phải có tính lũy đẳng và an toàn trước xử lý đồng thời.
• Đối soát là lớp bảo vệ độc lập để phát hiện chênh lệch giữa sổ nội bộ và thế giới bên ngoài.

How to Write an Effective Software Design Document

Bài viết hướng dẫn viết tài liệu thiết kế phần mềm để phát hiện quyết định sai trước khi triển khai và giúp nhiều bên thống nhất cách giải quyết vấn đề. Tài liệu đặc biệt có giá trị với dự án kéo dài, có nhiều người hoặc nhiều đội tham gia, yêu cầu còn mơ hồ hay chứa rủi ro nghiêm trọng. Mức đầu tư nên tỷ lệ với độ phức tạp, thời gian tồn tại và hậu quả của sai sót; một dự án nhỏ có thể chỉ cần một trang hoặc không cần tài liệu riêng.

Nguyên tắc chọn nội dung là hỏi “chi phí nếu quyết định này sai là bao nhiêu?”. Những lựa chọn khó đảo ngược như ngôn ngữ, kho dữ liệu, ranh giới hệ thống, bảo mật và quyền riêng tư cần được phân tích; chi tiết giao diện dễ sửa không nên chiếm thời gian đánh giá. Một tài liệu hữu ích thường nêu mục tiêu, bối cảnh, phạm vi và phần không thuộc phạm vi, kịch bản sử dụng, sơ đồ, ràng buộc, chỉ tiêu dịch vụ, giao diện, phụ thuộc, giám sát và tiến độ. Các vấn đề chưa giải quyết, quyết định đã chốt và phương án bị loại cũng cần được ghi lại ngắn gọn để người đánh giá hiểu lý do và tập trung phản hồi vào những điểm còn quan trọng.

Điểm chính:

• Viết tài liệu thiết kế khi dự án phức tạp, rủi ro, kéo dài hoặc cần phối hợp nhiều bên.
• Dành nhiều chi tiết hơn cho những quyết định khó đảo ngược và có hậu quả lớn.
• Mục tiêu nên mô tả tác động mong muốn, không chỉ liệt kê công nghệ sẽ sử dụng.
• Sơ đồ giúp người đánh giá nhanh chóng hiểu cấu trúc, luồng dữ liệu và ranh giới hệ thống.
• Ghi rõ vấn đề mở, phương án thay thế và quyết định đã chốt để quá trình đánh giá có trọng tâm.

The Cost YAGNI Was Never About

Kent Beck giải thích rằng YAGNI không phải quy tắc tiết kiệm công sức hay lời khuyên tránh thiết kế, mà là nguyên tắc chọn đúng thời điểm. Xây dựng cấu trúc trước khi tính năng thực sự cần đến sẽ tạo ra hai loại chi phí độc lập. Thứ nhất là mất quyền lựa chọn: nhóm cam kết với một dự đoán khi chưa có đủ thông tin, nên cấu trúc có thể không phù hợp với nhu cầu thực tế và làm các hướng đi khác trở nên khó khăn hơn. Chờ đợi vì thế là giữ lại khả năng đưa ra quyết định tốt hơn, không phải lười biếng.

Thứ hai là giá trị hiện tại ròng: chi phí được trả sớm trong khi giá trị từ tính năng bị nhận muộn hơn. Khoản thiệt hại này vẫn tồn tại ngay cả khi dự đoán ban đầu hoàn toàn chính xác. AI có thể làm chi phí tạo mã nguồn gần bằng không, nhưng không loại bỏ hai loại chi phí trên; ngược lại, nó khiến việc tạo ra những khung phần mềm mang tính suy đoán trở nên quá dễ dàng và làm nhóm hiểu mã nguồn ít hơn. Vì vậy, hãy xây dựng cấu trúc khi nhu cầu đã xuất hiện và cung cấp đủ thông tin để thiết kế đúng.

Điểm chính:

• YAGNI nói về thời điểm cam kết với một thiết kế, không chỉ về chi phí viết mã nguồn.
• Cấu trúc được xây quá sớm làm mất quyền lựa chọn khi thông tin mới xuất hiện.
• Trả chi phí trước và trì hoãn giá trị làm giảm giá trị hiện tại ròng của dự án.
• Dự đoán đúng vẫn không xóa được chi phí do cam kết và đầu tư quá sớm.
• AI làm mã nguồn rẻ hơn nhưng không làm cấu trúc suy đoán trở nên miễn phí.

a CVE dispute

Daniel Stenberg kể về tranh chấp CVE đầu tiên của dự án curl kể từ khi dự án trở thành cơ quan có quyền cấp mã lỗ hổng. Nhóm curl phân loại báo cáo dựa trên mức độ rủi ro thực tế và đôi khi từ chối cấp CVE cho lỗi có khả năng khai thác thấp hơn mức thấp. Lý do là mỗi CVE của libcurl, phần mềm hiện diện trên hàng tỷ thiết bị, có thể kích hoạt một lượng lớn công việc đánh giá, vá và phát hành lại trong toàn bộ hệ sinh thái. Vì vậy, nhóm muốn cảnh báo đầy đủ về vấn đề thật nhưng tránh tạo báo động cho kịch bản gần như chỉ tồn tại trên lý thuyết.

Tranh chấp liên quan đến lỗi kiểm tra 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 đồng thời xảy ra: ứng dụng phải sử dụng một tên không hợp lệ với DNS, có cách ánh xạ tên đó tới địa chỉ mạng, máy chủ giả mạo phải sở hữu chứng chỉ phù hợp và kẻ tấn công cục bộ phải có đủ quyền can thiệp. curl đã sửa lỗi và bổ sung kiểm thử, nhưng không xem đây là lỗ hổng cần CVE. Sau nhiều vòng yêu cầu giải trình, MITRE đồng ý với đánh giá của nhóm và kết luận không cấp mã CVE.

Điểm chính:

• Không phải mọi lỗi phần mềm đều là lỗ hổng bảo mật cần một mã CVE.
• Mức độ nghiêm trọng phải xét đến chuỗi điều kiện và khả năng khai thác trong thực tế.
• Dự án phổ biến cần cân nhắc chi phí mà mỗi cảnh báo tạo ra cho toàn bộ hệ sinh thái.
• Lỗi vẫn nên được sửa và bổ sung kiểm thử ngay cả khi không được phân loại là lỗ hổng.
• Quy trình tranh chấp cho phép một bên độc lập xem xét lại quyết định của cơ quan cấp CVE.

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 tách 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. Thông tin vị trí, thường được bổ sung bằng RoPE trong các mô hình hiện đại, giúp mô hình nhận biết thứ tự và khoảng cách. Trong mỗi khối transformer, cơ chế chú ý dùng các véc-tơ truy vấn, khóa và giá trị để xác định token nào liên quan; nhiều đầu chú ý cho phép theo dõi đồng thời các quan hệ ngữ pháp, tham chiếu và mẫu lặp khác nhau.

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

Điểm chính:

• Mô hình xử lý mã token và véc-tơ nhúng, không đọc trực tiếp chữ hoặc từ như con người.
• RoPE đưa quan hệ vị trí tương đối vào phép tính chú ý mà không cần thêm tham số học.
• Chú ý nhiều đầu cho phép mỗi token thu thập nhiều loại thông tin từ ngữ cảnh.
• Luồng dư và chuẩn hóa giúp các mạng transformer rất sâu có thể huấn luyện ổn định.
• Toàn bộ quá trình sinh văn bản là vòng lặp dự đoán và lấy mẫu từng token kế tiếp.

Bonus

Images: