Gautam Korlam, Kỹ sư chính tại Sonar – Loạt phỏng vấn

Gautam Korlam, Kỹ sư chính tại Sonar, là một kỹ sư phần mềm kỳ cựu và nhà lãnh đạo công nghệ, người sự nghiệp tập trung vào hạ tầng cho nhà phát triển, chất lượng mã, tự động hoá và phát triển phần mềm hỗ trợ AI. Trước khi gia nhập Sonar, ông đồng sáng lập Gitar và giữ vị trí CTO, xây dựng một nền tảng AI‑native được thiết kế để tự động hoá việc xem xét mã, chẩn đoán các lỗi tích hợp liên tục (CI), xác định nguyên nhân gốc và tạo ra các bản sửa. Sonar đã mua lại Gitar vào tháng 5 năm 2026, với Korlam và đội ngũ Gitar gia nhập công ty để tiếp tục phát triển công nghệ này như một phần của nền tảng xác thực mã rộng hơn của Sonar. Trước Gitar, Korlam đã làm việc gần một thập kỷ tại Uber, bắt đầu từ kỹ sư sáng lập trong nhóm nền tảng di động và thăng tiến lên vị trí Kỹ sư chính. Trong thời gian ở đó, ông đã giúp xây dựng và mở rộng hạ tầng nhà phát triển tập trung của Uber, dẫn dắt các sáng kiến monorepo và hệ thống xây dựng lớn, phát triển môi trường phát triển từ xa và công cụ CI/CD, và thử nghiệm các mô hình ngôn ngữ lớn mã nguồn mở như StarCoder, OctoCoder và Code Llama để cải thiện việc lập trình hỗ trợ AI trong mã nguồn của Uber. Kinh nghiệm trước đó của ông bao gồm các vị trí kỹ thuật tại Lookout và công việc nghiên cứu tại UC Santa Barbara, cùng với các kỳ thực tập tại Microsoft và Oracle.

Sonar là một công ty phần mềm tập trung vào xác thực mã, xem xét mã tự động, chất lượng mã và bảo mật ứng dụng. Nền tảng chủ lực SonarQube của họ phân tích mã do nhà phát triển viết và mã do AI tạo ra để phát hiện lỗi, lỗ hổng, vấn đề bảo trì và các vấn đề chất lượng khác trước khi chúng tới môi trường sản xuất, với các giải pháp bao gồm đám mây, tự quản và quy trình làm việc trong môi trường phát triển tích hợp. Sonar cho biết công nghệ của mình được hơn 7 triệu nhà phát triển và 22.000 khách hàng sử dụng và phân tích hơn 750 tỷ dòng mã mỗi ngày. Việc mua lại Gitar đã mở rộng cách tiếp cận này thành việc xem xét và khắc phục mã AI‑native, kết hợp động cơ xác thực của SonarQube với các công cụ tự động có khả năng xem xét mã, điều tra các lỗi CI và đề xuất hoặc áp dụng các bản sửa khi phát triển phần mềm ngày càng được điều khiển bởi AI.

Sự nghiệp của bạn đã đưa bạn từ việc xây dựng hạ tầng di động và nhà phát triển của Uber tới việc đào tạo các mô hình ngôn ngữ lớn mã nguồn mở trên cơ sở mã của họ, trước khi đồng sáng lập Gitar và gia nhập Sonar sau khi công ty này mua lại. Những trải nghiệm đó đã hình thành niềm tin của bạn như thế nào rằng việc tạo mã chỉ là một phần của thách thức, trong khi việc xác thực nó một cách đáng tin cậy có thể là vấn đề khó hơn?

Tại Uber, tôi đã làm việc trên các phần của hệ thống quyết định liệu bất kỳ thay đổi nào có được đưa ra sản phẩm hay không: monorepo, quá trình xây dựng, hàng đợi CI, bộ kiểm thử. Khi việc tạo ra các thay đổi trở nên dễ dàng hơn, toàn bộ áp lực sẽ đổ lên những cơ chế này. Bạn sẽ thấy ngày càng nhiều dịch vụ tương tác theo những cách không ai dự đoán được, và ngày càng nhiều kỹ sư chờ đợi để biết liệu thay đổi của họ có an toàn để hợp nhất hay không.

Sau đó, tôi đã làm việc trên việc đào tạo các mô hình trên cơ sở mã của chúng tôi, và ở đó bất đối xứng trở nên rõ ràng. Một mô hình có thể tạo ra một triển khai khả dĩ một cách nhanh chóng. Tuy nhiên, việc chứng minh rằng triển khai đó phù hợp với hệ thống sản xuất thực tế, tuân theo các quy ước mà nhóm thực sự sử dụng, và không gây lỗi cho hai dịch vụ khác lại mất nhiều thời gian hơn, và phần lớn công việc đó rơi vào con người. Gitar ra đời từ những nhu cầu đó, và nó phù hợp với những gì Sonar đã thực hiện từ phía phân tích trong hơn mười bảy năm qua.

Bạn đã lập luận rằng việc xem xét mã bằng AI nên bổ sung cho phân tích quyết định thay vì thay thế nó. Những loại vấn đề nào được xác định tốt nhất thông qua phân tích dựa trên quy tắc có thể lặp lại, và AI có thể cung cấp khả năng nào mà các kỹ thuật truyền thống không thể?

Phân tích dựa trên quy tắc là công cụ phù hợp khi tính chất có thể quyết định được từ chính mã nguồn. Đầu vào ô nhiễm tới một điểm tiêu thụ, việc tham chiếu null trên một đường dẫn mà ai đó bỏ lỡ, thông tin đăng nhập được mã hoá cứng, một phụ thuộc có CVE đã biết, một import vượt qua lớp không nên. Bạn sẽ nhận được cùng một kết quả ở mỗi lần chạy và có thể chỉ ra lý do gây ra, vì vậy việc thực thi nên nằm ở lớp này.

Những gì các quy tắc không bao phủ là ý định. Không có trình phân tích nào có thể cho bạn biết một chuỗi hướng tới người dùng sẽ gây mơ hồ cho người dịch, hoặc một thay đổi tuyên bố đóng một ticket nhưng chỉ thực hiện một phần yêu cầu của ticket, hoặc một vòng lặp retry mới xung đột với cách phần còn lại của dịch vụ xử lý áp lực ngược. Một mô hình đọc diff cùng với issue được liên kết và ngữ cảnh toàn bộ codebase sẽ đưa ra những vấn đề này, và chúng nên xuất hiện như các phát hiện mà con người kiểm tra chứ không phải là phán quyết.

Các hệ thống AI có thể đánh giá logic kinh doanh, ý định của nhà phát triển và các đánh đổi kiến trúc, nhưng các kết luận của chúng là xác suất. Các đội phát triển có thể tận dụng lập luận ngữ cảnh này như thế nào mà không coi kết quả của AI reviewer là đúng tuyệt đối?

Việc xem xét bằng AI xứng đáng có vị trí của mình với những vấn đề mà các kiểm tra truyền thống bỏ lỡ: lỗi logic, hành vi không khớp với ý định đã nêu, một thay đổi có vẻ ổn khi xem riêng nhưng sai đối với hệ thống cụ thể này. Những kết luận đó mang tính xác suất, vì vậy chúng nên là đầu vào cho một quyết định chứ không phải là quyết định cuối cùng. Các đội duy trì ranh giới này bằng cách giữ các kiểm soát quyết định trước khi hợp nhất, bao gồm các bài kiểm tra tự động, xác thực CI, quét bảo mật, kiểm tra chính sách, và một con người chịu trách nhiệm cho thay đổi. AI có thể đề xuất các bản sửa, hoặc thực hiện chúng trong các rào cản mà đội đặt ra, miễn là những thay đổi đó vượt qua cùng một quá trình xác thực như bất kỳ mã nào do người viết và không được ưu tiên chỉ vì được tạo ra bởi máy.

Chúng tôi cũng áp dụng ranh giới tương tự trong triển khai của mình. Mô hình đề xuất các phát hiện, và phán quyết xem xét được tính toán trong mã dựa trên trạng thái của các phát hiện đó. Quy trình giải quyết hoạt động theo cùng cách. Khi mã liên quan đến một phát hiện đã biến mất khỏi diff, đó là một kiểm tra quyết định dựa trên diff đã phân tích, và mô hình không được phép hủy bỏ những gì diff đã sửa.

Phiên bản chung của điều này là giao lớp xác suất những công việc mà sai sót có thể phục hồi, giữ cho máy trạng thái hoạt động quyết định, và để trách nhiệm cho đội. Điều tạo niềm tin là bằng chứng mà ai đó có thể kiểm tra và kiểm soát, và chúng hoạt động giống nhau trong mọi lần chạy.

Sonar đang kết hợp việc xem xét pull request có nhận thức ngữ cảnh với phân tích quyết định và các cổng chất lượng. Quy trình xác thực đa lớp hiệu quả trông như thế nào, và các lớp khác nhau nên tương tác như thế nào mà không tạo ra công việc trùng lặp hoặc làm quá tải các nhà phát triển với quá nhiều phát hiện?

Phân tích quyết định và các cổng chất lượng giữ những yếu tố không thể thương lượng, và chúng là những gì một merge sẽ chặn lại. Việc xem xét ngữ cảnh đưa ra các quyết định phán đoán về việc một thay đổi có thực hiện đúng những gì nó khẳng định, có phù hợp với codebase hay không, và liệu một rủi ro nhất định có đáng để một người chú ý hay không.

Một bức tường các phát hiện sẽ bị bỏ qua với tỷ lệ tương đương như không có phát hiện nào. Chúng tôi loại bỏ trùng lặp giữa các reviewer trước khi bất kỳ thứ gì tới tác giả, loại bỏ các ứng cử viên mà không thể xác thực và tập trung vào các phát hiện có tín hiệu cao. Về phía quy tắc, một điều kiện quyết định liệu quy tắc có áp dụng cho diff hiện tại hay không trước khi bất kỳ mô hình nào chạy, vì vậy hầu hết các quy tắc không tốn chi phí trên phần lớn các thay đổi. Tất cả đều xuất hiện trên pull request mà nhà phát triển đã mở.

Khi các tác nhân viết mã tạo ra nhiều mã và pull request hơn, việc xem xét và xác thực phần mềm có thể trở thành nút thắt mới không? Những phần nào của quy trình xem xét nên được tự động hoá, và những quyết định nào nên để lại cho các kỹ sư có kinh nghiệm?

Việc xem xét và xác thực đã trở thành nút thắt. Trên thực tế, 2026 State of Code Developer Survey cho thấy các đội báo cáo dành khoảng một phần tư tuần làm việc để kiểm tra và sửa lỗi đầu ra của AI. Vì vậy, không ngạc nhiên khi chỉ có 48% nhà phát triển luôn kiểm tra mã do AI tạo ra trước khi cam kết, mặc dù đa số (96%) không hoàn toàn tin rằng nó đúng về chức năng.

Công việc đáng tự động hoá là những công việc cơ học và không thú vị: nhóm lại một lỗi CI để tìm nguyên nhân gốc để không ai phải đọc hàng nghìn dòng log, quyết định liệu một phát hiện vẫn còn áp dụng sau khi rebase, tái tạo lỗi, viết bản sửa rõ ràng. Các kỹ sư nên giữ lại ý định, thiết kế, và quyết định mức độ bằng chứng đủ cho một thay đổi cụ thể. Khi một kỹ sư cao cấp dành buổi tối để đọc log nhằm xác định trong chín lỗi nào quan trọng, đó là công việc phân loại hơn là phán đoán, và chính là loại công việc chúng ta nên gánh vác cho họ.

Các hệ thống xem xét mã AI có thể xác định vấn đề, đề xuất sửa chữa và xác thực các thay đổi đó với pipeline tích hợp liên tục. Làm thế nào để ngăn một hệ thống khắc phục tự động gây ra hồi quy hoặc tối ưu chỉ cho một bản build thành công thay vì chất lượng tổng thể của phần mềm?

Điều quan trọng nhất là không coi màu xanh (build thành công) là tiêu chí chấp nhận, vì một build vượt qua chỉ cho biết các bài kiểm tra hiện có không thất bại.

Hầu hết các ràng buộc chúng tôi đặt lên quá trình khắc phục của mình liên quan đến phạm vi. Gitar sửa các CI bị phá vỡ, và nó kiểm tra rằng commit trước khi đẩy của nó đã ở trạng thái xanh trước khi nhận trách nhiệm cho bất kỳ thứ gì. Nó dừng lại sau hai commit tiếp theo thay vì tiếp tục làm việc trên một build đỏ. Khi lỗi không liên quan đến thay đổi, là một test không ổn định hoặc một sự cố hạ tầng, nó sẽ đi theo đường retry thay vì đường sửa, vì mục tiêu “đánh bại test thất bại” là điều mà bạn ít muốn một tác nhân có khả năng theo đuổi.

Sau đó, thay đổi phải vượt qua một lớp mà Gitar không kiểm soát. SonarQube đánh giá kết quả theo tiêu chí riêng của mình, cổng chất lượng là yếu tố mà merge phụ thuộc, và đội sở hữu chính sách đó. Chúng tôi cũng kiểm tra thay đổi so với issue mà nó tuyên bố thực hiện, với việc trích xuất yêu cầu được tách riêng khỏi phán quyết hoàn thành, vì vậy một yêu cầu đã bị bỏ qua trong ticket sẽ không xuất hiện lại như đã được thực hiện.

Việc xem xét mã AI hiệu quả phụ thuộc vào việc hiểu các quy ước, phụ thuộc, kiến trúc và mục đích của một thay đổi đề xuất trong repository. AI reviewer cần những ngữ cảnh nào để đưa ra quyết định hữu ích, và các tổ chức có thể duy trì độ chính xác của ngữ cảnh đó khi hệ thống phát triển như thế nào?

Nó cần đủ ngữ cảnh để suy luận như một reviewer có kinh nghiệm, không chỉ đủ để đọc diff. Điều này bao gồm mục đích của thay đổi, các đường dẫn mã và thông tin kiểu liên quan, phụ thuộc, hành vi test, quy ước repository, và các ranh giới kiến trúc mà đội mong đợi thay đổi phải tuân thủ.

Ngữ cảnh cũng phải tồn tại cùng với mã. Giữ các quy tắc và hướng dẫn xem xét được phiên bản trong repository, cập nhật chúng khi dịch vụ hoặc quy ước thay đổi, và làm rõ quyền sở hữu cho các quyết định kiến trúc và chính sách. Nếu không, AI reviewer có thể đưa ra một đề xuất hợp lý riêng lẻ nhưng mâu thuẫn với cách hệ thống rộng hơn thực sự hoạt động.

Phân tích quyết định tạo ra kết quả nhất quán và có thể kiểm toán, trong khi việc xem xét dựa trên mô hình ngôn ngữ lớn có thể thay đổi giữa các lần chạy. Các doanh nghiệp nên tài liệu hoá, tái tạo và quản lý các phát hiện do AI tạo ra trong các môi trường có quy định hoặc nhạy cảm về bảo mật như thế nào?

Dòng truy xuất kiểm toán nên hiển thị thay đổi đã được xem xét, phát hiện AI, quyết định đã đưa ra, và bằng chứng độc lập được sử dụng để xác thực kết quả. Các đội có thể sử dụng AI để tăng tốc quá trình xem xét và khắc phục, trong khi vẫn giữ việc thực thi và quyết định phê duyệt dựa trên các chính sách đã định và trách nhiệm của con người.

Các nhà lãnh đạo kỹ thuật nên sử dụng những chỉ số nào để xác định liệu việc xem xét mã AI thực sự cải thiện quá trình phát triển phần mềm? Họ có nên ưu tiên thời gian xem xét, lỗi trượt, tỷ lệ false-positive, lỗi CI, nợ kỹ thuật, niềm tin của nhà phát triển hay một chỉ số khác?

Bắt đầu với kết quả, không phải số lượng bình luận mà hệ thống AI tạo ra. Tôi sẽ đo thời gian từ pull request đến merge, thời gian dành cho việc chẩn đoán lỗi CI, tỷ lệ các bản sửa qua được trong lần xác thực đầu tiên, và tần suất các issue trượt vào các giai đoạn sau hoặc sản xuất.

Sau đó, theo dõi các tín hiệu chất lượng như tỷ lệ false-positive và từ chối, các issue được mở lại, các hồi quy liên quan đến các thay đổi vừa được merge, và phản hồi của nhà phát triển về việc các phát hiện có thể hành động được không. Sự kết hợp chỉ số phù hợp sẽ khác nhau tùy đội, nhưng câu hỏi luôn nhất quán: chúng ta có đang giảm công việc tái làm và thời gian chờ xem xét mà không hạ thấp tiêu chuẩn cho phần mềm an toàn, đáng tin cậy không?

Nhìn về phía trước, bạn có kỳ vọng quá trình phát triển phần mềm sẽ trở thành một vòng lặp liên tục trong đó các tác nhân tạo, xem xét, kiểm thử và sửa mã dưới các rào cản quyết định? Trong môi trường đó, trách nhiệm và kỹ năng cần thiết của các kỹ sư phần mềm con người sẽ thay đổi như thế nào?

Vòng lặp đó đã tồn tại, và các đội thường áp dụng nó theo một thứ tự cố định: phát hiện trước, sau đó khắc phục, rồi phê duyệt theo các điều kiện họ ghi lại, cuối cùng là merge. Không ai nhảy thẳng tới bước cuối cùng, và bằng chứng thúc đẩy họ tiến lên là codebase của chính họ chứ không phải một chuẩn mực. Merge là bước tôi thấy thú vị nhất, vì tần suất xung đột tăng lên cùng với lưu lượng commit, và lưu lượng là thứ mà tất cả những điều này làm tăng.

Các kỹ năng có giá trị tăng lên nằm quanh vòng lặp hơn là bên trong nó. Việc chính xác về vấn đề và các ràng buộc của nó quan trọng hơn khi một tác nhân lấy mô tả của bạn một cách nguyên văn. Cũng như quyết định bằng chứng nào đủ để cho phép một thay đổi đi qua, điều mà trước đây tồn tại trong đầu người như một thói quen và giờ phải được ghi lại thành chính sách để tự động hoá áp dụng. Phần còn lại là thiết kế hệ thống: xác định phạm vi công việc tự động có thể chạm tới, có một thành phần mà tác nhân không kiểm soát để kiểm tra kết quả, và giữ cho nó có thể truy xuất khi có lỗi. Các kỹ sư sẽ dành ít thời gian hơn để tạo ra triển khai và nhiều thời gian hơn để quyết định những gì nên tồn tại và gì sẽ được coi là bằng chứng chứng minh nó hoạt động.

Cảm ơn bạn đã tham gia phỏng vấn tuyệt vời, độc giả muốn tìm hiểu thêm nên truy cập Sonar.