Không phải vibe coding, agentic, MCP: Đây mới là điều các kĩ sư trưởng cần quan tâm

Bài viết dựa trên quan điểm cá nhân, không sử dụng AI và không đại diện cho bất kì tổ chức nào.

Đôi nét về một vài thông tin dẫn đến góc nhìn của bài viết này, bạn có thể tin hay không thì tùy:

• Trong thời AI, có thêm 300% lượng code được release và thêm 400% bug như một kết quả biết trước.
• Ron, 18 năm ở Microsoft, người đóng góp lớn trong việc cải thiện hiệu năng TypeScript. Gabriela, giám đốc AI của Microsoft, đã tham dự các cuộc họp để nói lời chia tay thay vì ngừng làm việc và đặt trạng thái Out Of Office như được yêu cầu. Cả hai đều không đơn độc trong con số hàng nghìn kĩ sư bị sa thải.
• The good, the bad & the ugly là bình thường của mọi làn sóng. Đi nhanh theo sóng là quan trọng và đi xa lại càng quan trọng. OpenAI Codex và sắp tới là sự kiện Google I/O, Microsoft Build sẽ ngày càng khó thở cho các 'Average Joe'.

AI dù có mạnh cũng chỉ là công cụ, quan trọng vẫn là đội ngũ kĩ sư

Trong bối cảnh mà cuộc đua về AI trong kỹ thuật phần mềm ngày càng nóng lên, thật dễ bị cuốn vào câu chuyện về tốc độ và năng suất cá nhân: dùng AI giúp một dev cá nhân tăng bao nhiêu phần trăm năng suất? Tiết kiệm được bao nhiêu giờ cho một tác vụ cụ thể? Những câu hỏi này dù có vẻ thực tế nhưng lại đang vô tình xem nhẹ đi tính chất cốt lõi, bất di bất dịch của ngành kỹ thuật phần mềm: đó là một bộ môn mang tính cộng tác tập thể cao.

Lịch sử phát triển của ngành đã cho chúng ta quá nhiều bài học. Vẫn với những công cụ lập trình, ngôn ngữ, framework hay IDE như nhau, tại sao có đội ngũ lại trở thành 'high performance team' với khả năng tạo ra sản phẩm chất lượng cao, bền vững, trong khi đội khác lại vật lộn với đống technical debt và quy trình kém hiệu quả? Câu trả lời chưa bao giờ nằm hoàn toàn ở công cụ. Nó nằm ở cách con người làm việc cùng nhau, cách họ chia sẻ kiến thức, cách họ phối hợp giải quyết vấn đề và văn hóa làm việc của tập thể đó.

Điều này làm tôi không khỏi suy nghĩ về những phong trào, phương pháp luận từng làm mưa làm gió một thời như TDD (Test-Driven Development), Pair Programming, Scrum... Chúng đều là những công cụ hoặc khuôn khổ tuyệt vời để nâng cao chất lượng và hiệu quả làm việc nhóm, nhưng cũng không ít lần bị 'biến tướng', áp dụng một cách máy móc hoặc hời hợt trong các đội ngũ thất bại.

Liệu giờ đây, AI - một công cụ thậm chí còn mạnh mẽ và phức tạp hơn - có đang đối mặt với nguy cơ tương tự? Nó có đang bị nhìn nhận như một viên đạn bạc giải quyết mọi vấn đề về năng suất cá nhân, mà bỏ qua câu hỏi quan trọng hơn: làm thế nào để đội ngũ ứng dụng AI để trở nên tốt hơn?

Cộng tác với AI là team sport trong ngành phần mềm, không phải câu chuyện cá nhân

Và dù ở thời kỳ nào, tỷ lệ các engineering leader thật sự 'eat your own dog food' - lăn xả vào tìm hiểu, thực hành sâu sắc những công cụ, phương pháp mới (giờ đây là những AI keyword trong engineering) để có thể chuẩn bị và dẫn dắt đội ngũ của mình - có lẽ vẫn còn khá khiêm tốn.

Chính vì vậy, trọng tâm không nên đặt vào việc từng cá nhân dùng AI nhanh đến mức nào, mà phải là: workflow làm việc của cả đội ngũ sẽ thay đổi thế nào khi AI tham gia? Và quan trọng hơn nữa là: Đội ngũ sẽ cộng tác với nhau như thế nào khi đã có 'người chơi mới' là AI? Đây mới là yếu tố quyết định sự thành bại trong việc ứng dụng AI ở quy mô tập thể. Những thứ như template prompt hay một bộ plugin 'thần thánh' chỉ là kết quả, là sản phẩm phụ của quá trình định hình lại workflow và cách cộng tác hiệu quả đó, chứ không phải là điểm khởi đầu hay yếu tố cốt lõi.

Nói một cách đơn giản, câu hỏi "Bạn thực hiện code review như thế nào?" nay đã có thêm nhiều lớp nghĩa và thách thức mới trong thời đại AI. Trả lời câu hỏi này khi chỉ dừng lại ở mức lý thuyết hay chém gió trên mạng sẽ rất khác với việc tìm ra câu trả lời thực sự hiệu quả khi bạn phải vật lộn để áp dụng AI vào quy trình làm việc của một tập thể con người phức tạp. Đó là sự khác biệt giữa lý thuyết suông và thực chiến.

Sẵn sàng thay đổi cho một thời kì mới tái định hình ngành khi chung sống với AI

Chuyện gì xảy ra với những người thợ dệt trong cách mạng công nghiệp lần thứ nhất? Họ đập phá máy móc, biểu tình, và sau đó thì sao?

Lịch sử cho thấy, làn sóng công nghệ mới không dừng lại vì sự chống đối. Có lẽ với xu hướng chi phí để tạo ra phần mềm ngày càng giảm đi nhờ AI, trong khi chi phí chi trả cho các hệ thống tính toán AI ngày càng tăng (cho việc training, inference các mô hình lớn), thì tác động tái định hình ngành công nghiệp phần mềm sẽ ngày càng rõ rệt. Điều này không chỉ là sự thay đổi về công cụ, mà là sự dịch chuyển cơ bản về cấu trúc giá trị và vai trò của con người trong chuỗi sản xuất.

Đối tượng lâm nguy nhất chính là 'Average Joe' - những kỹ sư ở mức trung bình. Vì sao ư? Vì công việc của họ thường xoay quanh việc thực hiện các tác vụ mang tính lặp lại, có khuôn mẫu rõ ràng hoặc yêu cầu kiến thức ở mức áp dụng công thức có sẵn. Đây chính là 'miền đất hứa' cho AI. AI có thể tạo ra boilerplate code, viết các hàm dựa trên mô tả cụ thể (mà nhiều khi mô tả này lại đến từ một AI khác), thậm chí là fix bug đơn giản nhanh hơn, rẻ hơn và đôi khi chính xác hơn 'Average Joe' nếu chỉ xét về tốc độ hoàn thành tác vụ đơn lẻ. Sự khác biệt giữa họ và chất lượng của AI sẽ ngày càng thuần túy mang tính 'có tóc để chịu trách nhiệm', khiến vai trò của 'Average Joe' trở nên mờ nhạt và dễ thay thế hơn trong mắt các tổ chức ưu tiên hiệu quả chi phí.

Sự thay đổi mà AI đem đến khác nhau cho từng nhóm trong tháp nguồn lực

Ngược lại, đối tượng hưởng lợi nhất chính là đội ngũ tinh hoa. Họ là những người có khả năng tư duy phản biện sâu sắc, hiểu biết hệ thống ở mức độ kiến trúc, có kỹ năng giải quyết vấn đề phức tạp, đặc biệt là khả năng dẫn dắt AI. Đối với họ, AI không phải là thứ làm thay, mà là một công cụ mạnh mẽ để mở rộng năng lực của bản thân. AI giúp họ xử lý các phần tốn thời gian và chờ đợi 'Average Joe' để họ có thể tập trung vào việc thiết kế, tối ưu hóa, đưa ra quyết định chiến lược và giải quyết những thách thức mà AI hiện tại chưa thể chạm tới. Họ dùng AI để đi nhanh hơn, sáng tạo hơn, chứ không phải để làm những gì AI có thể làm. Họ biến AI thành một người cộng sự đắc lực không cần quản lý cảm xúc, cứ như người hướng nội không cần đi nhậu để công việc hanh thông.

Thế còn đối tượng junior, những người mới bước chân vào ngành thì sao? Họ sẽ gặp nhiều thách thức hơn so với thế hệ trước. Lý do là bởi nhiều công việc 'nhập môn', những tác vụ đơn giản giúp junior làm quen với codebase, quy trình làm việc và các khái niệm cơ bản giờ đây có thể bị AI xử lý một phần hoặc toàn bộ. Cơ hội để 'đụng tay đụng chân' với những thứ căn bản, từ đó xây dựng nền tảng vững chắc, có thể sẽ ít đi. Đồng thời, khoảng cách giữa kỹ năng AI có thể làm và kỹ năng cần có để trở thành một kỹ sư 'tinh hoa' ngày càng rộng, đòi hỏi các junior phải tăng tốc độ học hỏi, không chỉ về công nghệ mà còn về cách làm việc cùng AI và phát triển các kỹ năng mềm, tư duy hệ thống ngay từ sớm. Cơ hội vẫn đó, nhưng cánh cửa có thể hẹp hơn và yêu cầu bước qua sẽ cao hơn đáng kể. Nhất là thông thường họ sẽ vấp phải lực lượng 'Average Joe' khi đi làm.

Chắc chắn mô hình tổ chức, cấu trúc nguồn lực và các phương pháp luận về sản xuất trong lĩnh vực phần mềm sẽ thay đổi đáng kể.

Refactor mọi thứ: từ cách chia sẻ kiến thức đến cấu trúc mã nguồn

Một trong những tác động đáng chú ý nhất mà AI mang lại, nếu không được quản lý khéo léo, đó là nguy cơ đứt gãy kết nối giữa các thành viên trong đội, đặc biệt là giữa junior và senior.

Có một thực tế đáng buồn nhưng không thể phủ nhận: nếu như tổ chức phần lớn là 'Average Joe', những người chỉ làm việc ở mức đủ yêu cầu và ngại giao tiếp phức tạp, thì thay vì kêu gọi tinh thần chia sẻ, việc 'bảo' junior tự đi hỏi AI có lẽ sẽ là lựa chọn nhanh gọn và 'hiệu quả' hơn trong ngắn hạn. Junior cũng dễ dàng tìm câu trả lời tức thời từ AI hơn là chờ đợi sự hướng dẫn của senior đang bận rộn.

Tuy nhiên, sự đứt gãy về mặt kết nối con người này không hề có lợi cho tổ chức về lâu dài. Quá trình truyền thụ kinh nghiệm, văn hóa làm việc, tư duy giải quyết vấn đề phức tạp và bối cảnh hệ thống (system context) từ senior sang junior là cực kỳ quan trọng để xây dựng một đội ngũ bền vững và có chiều sâu. Nếu AI thay thế luôn cả vai trò 'người hướng dẫn ban đầu', junior sẽ thiếu đi nền tảng và khó có thể phát triển lên các cấp độ cao hơn.

Do đó, chúng ta cần 'refactor' lại cách chia sẻ kiến thức. Hãy tư duy theo hướng này: chúng ta vẫn sẽ thảo luận và tương tác, nhưng không bàn đi xẻ lại những gì mà AI có thể trả lời ngay lập tức chỉ với 1, 2 câu prompt đơn giản. Thay vào đó, chúng ta tập trung vào việc thảo luận những thứ mà AI chưa thể hiểu hoặc đưa ra đáp án cuối cùng:

• Tại sao lại chọn kiến trúc này chứ không phải kiến trúc khác?
• Trade-off giữa performance và operation excellence trong trường hợp này là gì?
• Làm thế nào để lồng ghép best practice của team vào đoạn code do AI sinh ra?

Cách tiếp cận này giúp chúng ta rút ngắn thời gian họp cho những thứ 'AI-able' nhưng đồng thời đẩy chất lượng cuộc họp và sự tương tác lên nhiều lần, tập trung vào giá trị con người.

Refactor mọi thứ trên quan điểm có AI, chứ không phải ráng ứng dụng AI vào hiện trạng

Không chỉ cách làm việc và chia sẻ kiến thức cần 'refactor', mà ngay cả cấu trúc mã nguồn (code structure) cũng có thể cần được xem xét lại dưới góc độ của AI.

Nếu như monorepo với large context từ lâu đã là xu hướng và ngày càng hưởng lợi khi các AI model có khả năng xử lý ngữ cảnh lớn hơn, thì liệu giờ đây, khi mà vibe coding và việc AI dễ dàng tạo ra code với phong cách hoặc chất lượng không đồng đều trên diện rộng, việc chuẩn bị cho khả năng tách nhỏ repository hoặc module để giảm thiểu context và giới hạn mức độ ảnh hưởng từ code kém chất lượng có nên được cân nhắc một cách nghiêm túc? Mục đích không chỉ để con người dễ hiểu và quản lý, mà còn để tạo ra các rào cản (guardrail) vật lý hoặc logic cho AI.

Hoặc giả sử, trong mỗi folder hoặc module quan trọng, chúng ta lại có một tài liệu chỉ thị (instruction document) riêng biệt, đóng vai trò như một 'hiến pháp nhỏ' hay 'prompt template chi tiết' dành cho các AI agent hoặc các công cụ AI khác khi làm việc trong khu vực đó. Điều này nhằm đảm bảo kiểm soát chất lượng code do AI gen ra tốt hơn, đồng bộ hóa phong cách, tuân thủ kiến trúc vi mô và giúp cho quá trình code review (của con người) trở nên hiệu quả hơn rất nhiều.

Việc 'refactor' này đòi hỏi sự chủ động từ technical lead và toàn bộ đội ngũ. Đó là quá trình liên tục thử nghiệm, đánh giá và điều chỉnh cách chúng ta tương tác với nhau và với công cụ AI, nhằm đảm bảo AI thực sự là đòn bẩy cho năng suất và chất lượng của cả tập thể, chứ không phải là yếu tố gây ra sự cô lập và hỗn loạn trong codebase.

Lời kết

Đây là tất cả những bí kíp 'thượng thừa' về cách làm chủ AI, tái định hình đội ngũ và nghiền nát 'Average Joe' trong kỷ nguyên số! Tất cả những nội dung này, cùng với tuyệt chiêu "Nhìn Code AI Đoán Tính Cách Lập Trình Viên", sẽ có trong khóa đào tạo "Phù Thủy Kiến Trúc Phần Mềm AI" do mình sắp khai giảng. Đảm bảo sau một lộ trình, bạn không chỉ tự tin làm chủ AI mà còn có thể vô địch siêu cấp vũ trụ!

Đùa thôi (một nửa!). Dù mình có đi dạy thật và những chủ đề này chắc chắn sẽ được mổ xẻ sâu hơn, nhưng nếu các bạn đã đủ kiên nhẫn đọc đến tận dòng này, chứng tỏ các bạn thực sự quan tâm đến tương lai của ngành và vai trò của mình trong đó. Một like, một share, hoặc đơn giản là một comment "đã đọc" cũng là động lực lớn rồi. (Và không có 300 bài code AI siêu cấp vũ trụ nào đâu, AI tự viết hết rồi cần gì mình cho nữa!).

Ngành engineering đang bước vào một giai đoạn hoàn toàn mới, đầy thách thức nhưng cũng không thiếu cơ hội. Nếu bạn đang ngày đêm chứng kiến và là một phần của sự thay đổi chóng mặt này, tôi thực lòng mong bạn sẽ luôn giữ vững tinh thần phản biện, không ngừng học hỏi, là nguồn cảm hứng và điểm tựa vững chắc cho đội ngũ của mình.

Hãy nhớ rằng, công cụ thay đổi, quy trình thay đổi, nhưng giá trị cốt lõi của một kĩ sư giỏi và một tech lead tài ba nằm ở khả năng tư duy, giải quyết vấn đề, và xây dựng đội ngũ.