275 - Khi Big Tech chuyển mình thành AI Factory
Chào các bạn,
Chào mừng các bạn quay lại với Grokking Newsletter. Do thời gian bị giới hạn nên nhóm biên tập không gửi newsletter thường xuyên được. Tần suất hiện tại sẽ cố gắng duy trì là một tháng một số, xoay tua bởi các thành viên.
Trong số newsletter kỳ này, chúng ta sẽ cùng tham khảo những góc nhìn thực tế từ bạn n^4 - một kỹ sư hiện đang làm việc tại tập đoàn công nghệ quy mô hàng nghìn nhân sự. Đây là những đúc kết từ chính quá trình đón đầu làn sóng dịch chuyển, khi doanh nghiệp nỗ lực xây dựng chiến lược biến mình thành một "AI factory".
Định nghĩa về các cấp độ tự động hóa của agent
Có nhiều nơi định nghĩa các cấp độ này, ví dụ như có nơi sẽ phân loại dựa theo vai trò của user như này, hoặc OpenAI cũng sẽ có thang đo phân loại nội bộ như chatbot/reasoners/agents/innovators/organizations, … Để có một chiến lược tốt, thường các công ty sẽ phải đưa ra một thang định nghĩa về các cấp độ tự động của agent trong hệ thống của mình. Dựa vào thang định nghĩa này, công ty sẽ bắt đầu phân tích để tìm ra khoảng gap giữa quy trình làm việc hiện tại và quy trình làm việc lý tưởng để lập kế hoạch thay đổi.
Trong công ty mình, tạm thời có thể dùng định nghĩa về các cấp độ nôm na như sau:
L1: dùng AI dưới dạng chatbot, kỹ sư copy code từ chatbot như GPT, gemini, chạy code, sau đó copy lỗi nhờ chatbot review và sửa lỗi.
L2: kỹ sư con người sử dụng coding agent để code, tuy nhiên kỹ sư con người sẽ cần phải cung cấp những chỉ dẫn cụ thể như chạy test này, commit, refactor chỗ này, update docs, …
L3: kỹ sư con người sử dụng coding agent để code, tạo merge request, và agent có thể tự động thực hiện toàn bộ các thao tác từ spec sang merge-request một cách chủ động mà không cần con người can thiệp giữa chừng. Merge-request được tạo ra bởi agent cũng đã bao gồm những bước kiểm định như chạy các loại test cases cần thiết.
L4: kỹ sư con người sử dụng coding agent để orchestrate các bước sau khi tạo merge-request (MR), ví dụ như review MR, deploy, chạy end-to-end test, kiểm tra kết quả lỗi CI/CD, …
L5: agents sẽ tự động tạo ra MR, deploy MR, theo dõi kết quả deploy trên production và tìm các dấu hiệu bất thường liên quan, rollback khi cần cũng như tạo ra các tasks để chỉnh sửa khi có sự cố.
Sự thăng cấp trong các cấp độ sẽ tương ứng với việc agent chủ động hơn trong việc hoàn thành task càng ngày càng hoàn chỉnh trong một quy trình làm việc phức tạp. Đối với một tổ chức lớn, việc đưa một tính năng từ lúc còn là ý tưởng đến khi tính năng được đến tay người dùng cuối là một quy trình trải qua rất nhiều khâu, nên việc ứng dụng AI sẽ phải đi qua từng giai đoạn một để đảm bảo mọi thứ được an toàn và ổn định.
Suy cho cùng, nếu AI làm tăng tốc độ nhưng làm giảm chất lượng hệ thống thì không phải là điều những tổ chức trưởng thành muốn hướng tới.
Sự thay đổi trong cách làm việc
Việc chuyển đổi và tích hợp AI ngày càng sâu rộng vào trong quy trình làm việc cũng dẫn đến nhiều thay đổi về cách các kỹ sư làm việc.
Spec-driven được nhấn mạnh nhiều hơn. Để đạt đến cấp độ 3 và 4, một bạn kỹ sư cần phải thay đổi các làm việc của mình. Thay vì “cùng làm với AI”, bạn kỹ sư phải thay đổi tư duy thành “đóng gói công việc” cho AI hoàn thành, thông qua việc định nghĩa những tasks có scope được giới hạn phạm vi. Một task được định nghĩa tốt thường sẽ bao gồm một số thành phần như: the goal is clear, the scope is bounded, what is the expected behavior, what is the acceptance criteria. Đối với các bạn manager, team lead, vốn đã quen với việc đóng gói task và giao việc, điều này có vẻ tự nhiên hơn. Tuy nhiên đối với nhiều bạn kỹ sư trẻ hơn thì đây là điều không dễ và là một loại kỹ năng cần rèn luyện.
Spec driven development không chỉ đơn giản là dùng skill gì, dùng tool gì để tạo ra spec, mà đó còn là sự thay đổi trong thói quen làm việc và cách tư duy. Và khi spec đang được tạo ra bởi AI nhiều hơn thì Spec-review cũng trở thành một kỹ năng quan trọng mà một bạn kỹ sư cần rèn luyện. Bạn phải nhìn vào spec của AI tạo ra và có khả năng đánh giá được nó tốt hay không, nó đi đúng hướng hay không. Đây là kỹ năng khó và cũng cần thời gian để trao dồi.
Code review trở thành quan trọng. Hiện giờ, chất lượng code của AI ngày càng tốt lên, nhưng có thể nói vẫn chưa đủ tốt để chạy đúng trong mọi trường hợp theo quan điểm của tổ chức nơi mình làm việc, đặc biệt là khi có những legacy/hidden context ẩn giấu trong tasks đó mà con người không đề cập đến.
Vai trò review của con người đang được nhấn mạnh trở lại (ít nhất là trong công ty mình). Và đi kèm với nó là các MR/Code changes sẽ cần phải được cung cấp kèm theo các dữ kiện bổ sung để giúp quá trình review được dễ dàng hơn. Ví dụ như code này tại sao phải thay đổi, đã có những trade-off gì được cân nhắc, các loại tests nào đã được chạy trong quá trình code này được tạo ra, … Khi có đủ dữ kiện, người review sẽ có thể review ngày càng hiệu quả hơn thay vì phải tự hình dung toàn bộ thay đổi trong đầu trước khi thực sự review.
Nếu code tạo ra nhanh, mà con người phải tốn quá nhiều thời gian review thì thời gian tiết kiệm chưa chắc đã nhiều. Và điều này cũng dễ dẫn đến việc review trở nên thiếu cẩn trọng hơn.
Agent review trở thành quan trọng nhưng chưa thay thế hoàn toàn con người. Từ vấn đề review trở thành một bottleneck, thì đề xuất của mọi người hay nêu ra sẽ là để agent review nhiều hơn. Đề xuất này nghe có vẻ hợp lý, tuy nhiên sau khi công ty mình triển khai agent review thì tỷ lệ chấp thuận feedback từ agent chỉ khoảng 50%. Tại sao? Có nhiều nguyên nhân có thể kể ra như agent dễ chỉ ra những lỗi vụn vặt hoặc không đúng do không có context về thư viện được dùng, không có context về business liên quan, …
Ngoài ra, chi phí review cũng trở thành một vấn đề. Lúc ban đầu, bộ rules để review sẽ khá cơ bản. Nhưng dần dần, mọi người sẽ có khuynh hướng bổ sung thêm ngày càng nhiều rules, chia nhỏ rules ra, …. và đến khi bạn có khoảng 30 bộ rules để review, mỗi rules chiếm 50-100k token thì việc agent review trở thành một vấn đề. Bạn sẽ phải chạy review đối với từng rule một vì nếu dồn chung kết quả có thể không chính xác nữa. Chi phí vì vậy sẽ tăng ngày càng cao.
Chưa kể đến, nếu review là tự động thì việc thay đổi một dòng có có thể kích hoạt 3-4 bộ rules review, liệu có đáng không?
Harness engineering và feedback loop. Một từ khóa khác mà cộng đồng đề cập đến nhiều trong thời gian gần đây đó là harness engineering. Thuật ngữ này có nhiều cách hiểu, nhưng hiểu một cách nôm na theo ý mình thì harness engineering là ám chỉ việc tập trung xây dựng vào ecosystem và môi trường cho agent thực thi một cách an toàn. Nếu hình dung các hệ thống của các công ty lớn vốn dĩ cần đạt 99.9% hoặc 99.99%, nếu đưa các thành phần non-deterministic nhiều hơn vào thì làm sao để làm cho hệ thống vẫn duy trì độ ổn định này? Hoặc nếu agent đang vận hành ở cấp độ L3/L4/L5 thì làm sao để đảm bảo agents vẫn tạo ra kết quả đáng tin cậy và an toàn? Những kỹ thuật truyền thống như unit tests, integration tests, end-to-end tests, … đang trở lại và ngày càng nhấn mạnh nhiều hơn. Kèm theo đó là những bài toán mới như cơ chế phân quyền cho agent cho từng loại tác vụ, cơ chế detect các tác vụ nguy hiểm (như delete, reset, …) sẽ phải được xây dựng.
Những suy nghĩ về tương lai
Nhìn chung, công việc của kỹ sư phần mềm đang thay đổi, đó là điều chắc chắn. Vai trò của người kỹ sư đã bớt tập trung vào việc hoàn thành từng task cụ thể mà thay vào đó sẽ tập trung vào việc xây dựng môi trường cho agents thực thi tasks một cách trơn tru, hiệu quả và an toàn. Nhìn theo một khía cạnh nào đó, việc chuyển dịch từ L2 sang L3/L4 sẽ khiến nhiều bạn kỹ sư khó thích nghi vì mục tiêu công việc của bạn đã thay đổi, trở nên abstract hơn.
Kiến thức fundamental liệu có còn quan trọng? Theo mình nghĩ những kiến thức về hệ điều hành, network, bảo mật, hạ tầng, … vẫn nên được xem là quan trọng. Để kỹ sư có thể review được kết quả agent tạo ra, kỹ sư cần có kiến thức nền tảng và tư duy tốt để thẩm định. Không phải kết quả nào cũng có thể kiểm tra dễ dàng như UI, những thay đổi trong hạ tầng, backend logic của một hệ thống lớn cần người kỹ sư hiểu sâu các thành phần của hệ thống đó để có thể đưa ra được quyết định phù hợp.
Tuy nhiên, một điều rất là rõ ràng là ngôn ngữ, nền tảng sẽ không còn được xem là một trở ngại nữa. Một bạn kỹ sư giờ có thể làm được nhiều vai trò, nhiều nền tảng cùng lúc. Golang/Python/Java/Ruby/… sẽ trở nên giống nhau, bạn kỹ sư sẽ quan tâm nhiều hơn về cách cấu trúc dữ liệu của ngôn ngữ đó có xử lý tốt concurrency hay không, về thuật toán nào hiệu quả hơn, về cách tổ chức data in memory nên như thế nào, cách design data schema nên như thế nào, … thay vì cú pháp cụ thể.
Ngành phần mềm đã đi một vòng tròn. Trong quá khứ, một người kỹ sư phải nắm nhiều thứ như FE/BE/Mobile, miễn là phần mềm thì phải làm được vì lượng kiến thức còn ít. Dần dần, chuyên môn hóa đưa đến sự phân hoạch FE/BE/Data/Fullstack engineer, … Nhưng với AI, mọi thứ đang quay về giống như quá khứ khi Software Engineer chỉ đơn thuần là Software Engineer, người dùng kiến thức Computer Science của mình để giải quyết các vấn đề kỹ thuật, bất kể vấn đề đó cần được giải quyết bằng ngôn ngữ gì.