Ali-Reza Adl-Tabatabai, Người sáng lập và Giám đốc điều hành tại Gitar – Loạt phỏng vấn

Ali-Reza Adl-Tabatabai, Người sáng lập và Giám đốc điều hành tại Gitar, là một nhà lãnh đạo kỹ thuật kỳ cựu với sự nghiệp bao gồm một số công ty công nghệ hàng đầu tại Thung lũng Silicon, bao gồm Uber, Google, Facebook, Intel, AMD và IBM. Trước khi ra mắt Gitar vào năm 2023, ông từng là Giám đốc kỹ thuật cấp cao tại Uber, nơi ông đã giúp lãnh đạo các sáng kiến nền tảng nhà phát triển của công ty, sau các vai trò lãnh đạo trước đó tại Google giám sát Kỹ thuật độ tin cậy Trang web cho các sản phẩm như Truyền thông, Ảnh, Xã hội, Đám mây và cơ sở hạ tầng kỹ thuật.

Trước đó trong sự nghiệp của mình, ông đã làm việc về công nghệ biên dịch, máy ảo, hệ thống tính toán song song và tối ưu hóa phần cứng tại Intel Labs và nhóm HipHop VM của Facebook, đồng thời cũng giảng dạy thiết kế biên dịch nâng cao tại Đại học Stanford. Sự nghiệp kéo dài hàng thập kỷ của ông trong lĩnh vực ngôn ngữ lập trình, độ tin cậy cơ sở hạ tầng, công cụ nhà phát triển và kiến trúc hệ thống quy mô lớn đã khiến ông trở thành một nhân vật nổi bật trong phong cảnh kỹ thuật phần mềm được hỗ trợ bởi AI đang phát triển.

Gitar tập trung vào một vấn đề ngày càng tăng xuất phát từ sự trỗi dậy của phát triển phần mềm hỗ trợ bởi AI: xác thực và bảo mật khối lượng lớn mã được tạo bởi máy hiện đang chảy vào các hệ thống doanh nghiệp. Nền tảng này sử dụng các tác nhân AI để tự động hóa xem xét mã, điều tra các lỗi đường ống CI/CD, xác định lỗi và lỗ hổng, đề xuất sửa lỗi và tích hợp trực tiếp vào các quy trình kỹ thuật hiện có thông qua các công cụ như GitHub, GitLab, Jenkins, Jira và Slack. Thay vì chỉ cạnh tranh trong việc tạo mã nhanh hơn, công ty đang định vị mình xung quanh những gì họ mô tả là “cổng kiểm soát chất lượng đại lý”, giúp các nhóm kỹ thuật duy trì độ tin cậy, bảo mật và giám sát hoạt động khi phát triển phần mềm ngày càng chuyển hướng sang các quy trình mã hóa tự động và hỗ trợ bởi AI.

Bạn đã lãnh đạo kỹ thuật tại Uber, Google và Intel Labs, làm việc trên các nền tảng nhà phát triển và cơ sở hạ tầng quy mô lớn. Những kinh nghiệm cụ thể từ hành trình đó đã dẫn bạn đến việc thành lập Gitar, và tại sao lại tập trung vào xác thực mã thay vì tạo mã?

Trong suốt thời gian tại Uber, Google, Facebook và Intel Labs, tôi đã làm việc trên các nền tảng nhà phát triển ở các quy mô khác nhau, và một bài học luôn xuất hiện: trải nghiệm nhà phát triển là một lợi thế cạnh tranh. Các công cụ tuyệt vời thu hút và giữ chân các kỹ sư giỏi nhất và cho phép các công ty di chuyển nhanh. Các nhà phát triển muốn có các công cụ nhanh, không có tiếng ồn, giúp họ duy trì trạng thái tập trung và tự động hóa công việc nhàm chán. Nhưng công cụ nhà phát triển bị phân mảnh sâu sắc, và hầu hết các công ty đều tiêu tốn một lượng lớn tài nguyên kỹ thuật chỉ để ghép lại một trải nghiệm nhất quán. Tôi đã chứng kiến tận mắt mức độ ảnh hưởng khi giải quyết vấn đề này.

AI thay đổi phương trình bằng cách cho phép tự động hóa nhiều hơn quy trình làm việc của nhà phát triển so với trước đây. Tạo mã đã được bao phủ khá tốt, nhưng điều đó chỉ chuyển瓶 cổ chai xuống hạ lưu, sang việc xác thực, tái cấu trúc và bảo trì mã mà chúng ta hiện đang sản xuất với khối lượng chưa từng có. Đó là nơi Gitar tập trung. Khi AI viết nhiều mã hơn, tài nguyên khan hiếm không phải là tạo mã; đó là niềm tin, sự chính xác và khả năng bảo trì của những gì được gửi. Xác thực mã là phần của quy trình làm việc quyết định liệu mã được tạo bởi AI có thực sự đến sản xuất một cách an toàn hay không, và đó là vấn đề khó hơn và có giá trị hơn để giải quyết.

Với sự trỗi dậy của mã được tạo bởi AI, nhiều nhóm hiện đang phải đối mặt với những gì một số người gọi là quá tải mã. Vấn đề này có ý nghĩa như thế nào trong các doanh nghiệp ngày nay, và các nhóm đang gặp khó khăn nhất ở đâu?

Sự thay đổi không nằm ở việc viết mã. Phần đó đã di chuyển nhanh hơn so với hầu hết các nhóm có thể hấp thụ. Điều đã thay đổi là mọi thứ sau đó. Các công cụ AI đang tạo ra một dòng yêu cầu kéo liên tục, thường nhanh hơn so với các nhóm có thể xem xét chúng, điều này tạo ra áp lực ở những phần của hệ thống mà không được thiết kế cho mức đầu ra này.

Mỗi thay đổi vẫn phải vượt qua xác thực. Xem xét mã. CI. Kiểm tra bảo mật. Phê duyệt. Không có gì trong số đó biến mất chỉ vì mã được tạo nhanh hơn. Điều từng là một dòng chảy có thể quản lý đã trở thành một danh sách chờ. Các nhóm không còn bị chặn bởi ý tưởng hoặc thực hiện nữa. Họ bị chặn bởi sự tự tin. Liệu điều này có thể gửi? Nó có an toàn không? Nó có phá vỡ điều gì tinh vi không?

Đó là nơi ma sát nằm hiện nay. Không phải trong tạo mã, mà trong việc đưa mã qua vạch đích mà không giới thiệu rủi ro.

Công nghiệp đã tập trung chủ yếu vào tạo mã nhanh hơn. Tại sao bạn tin rằng xác thực đã bị bỏ qua, và tại sao nó lại trở nên quan trọng hơn bây giờ?

Bởi vì hệ thống hạ lưu của tạo mã chưa tiến hóa với cùng tốc độ. Khi đầu ra tăng, mọi thứ hạ lưu đều bị căng thẳng. Yêu cầu kéo trở nên lớn hơn và thường xuyên hơn. Các lỗi CI bắt đầu xếp hàng. Chu kỳ xem xét bị nén vì không ai có thời gian để đi sâu vào từng thay đổi.

Chất lượng bắt đầu trượt, không phải vì các kỹ sư không quan tâm, mà vì khối lượng buộc phải có sự đánh đổi. Các nhóm nền tảng chịu thêm gánh nặng, xử lý các vấn đề đường ống, phân loại các lỗi và cố gắng giữ mọi thứ di chuyển. Các kỹ sư cao cấp kết thúc bằng việc trở thành các phối hợp viên, ghép các nhật ký lại với nhau, chẩn đoán các vấn đề và quyết định những gì an toàn để hợp nhất.

Các nhóm phải đối mặt với một lựa chọn không thực sự hoạt động theo cách nào. Đẩy mã qua nhanh và đối phó với các hồi quy sau hoặc chậm lại và bảo vệ chất lượng, nhưng chấp nhận rằng tốc độ giảm. Căng thẳng đó đang xuất hiện trên các tổ chức kỹ thuật hiện nay.

Gitar sử dụng các tác nhân AI để xử lý xem xét mã, thử nghiệm và các quy trình CI. Làm thế nào các tác nhân này khác biệt cơ bản so với các công cụ phân tích tĩnh truyền thống và các đường ống dựa trên quy tắc?

Sự khác biệt không phải là thẩm mỹ. Một tác nhân thực sự cần làm được nhiều hơn là phản ứng với các提示. Nó cần xử lý công việc nhiều bước, lập kế hoạch, sử dụng các công cụ, theo dõi ngữ cảnh và di chuyển các nhiệm vụ вперед mà không cần đầu vào liên tục.

Hầu hết các hệ thống không đáp ứng được tiêu chuẩn đó. Chúng tạo ra đầu ra, nhưng chúng không quản lý thực hiện. Khi các công cụ này được đặt vào các quy trình làm việc thực, các khoảng trống sẽ xuất hiện nhanh chóng. Chúng không giảm phức tạp. Trong nhiều trường hợp, chúng thêm một lớp khác mà ai đó phải quản lý.

Đó là lý do tại sao cuộc trò chuyện đang chuyển từ “liệu chúng ta có các tác nhân” sang “công việc thực sự có thể được xử lý một cách đáng tin cậy”.

Tin cậy là một rào cản chính đối với tự động hóa trong phát triển phần mềm. Gitar đảm bảo quy trình xác thực của mình đáng tin cậy đến mức nào để các nhóm có thể dựa vào?

Mô hình hoạt động là đơn giản. Chia công việc thành các bước nhỏ hơn. Xác định các ranh giới rõ ràng. Xác thực đầu ra liên tục. Giữ cho con người tham gia vào các quyết định mang rủi ro.

Các tác nhân có thể xem xét mã và đưa ra các vấn đề dễ bị bỏ qua ở quy mô. Chúng có thể phân tích các lỗi CI, nhóm các lỗi liên quan và chỉ ra một nguyên nhân có thể. Chúng có thể đề xuất sửa lỗi và, trong một số trường hợp, áp dụng chúng một cách có kiểm soát.

Điều này giảm bớt lượng công việc triệt để thủ công mà các kỹ sư phải thực hiện. Nó không loại bỏ các kỹ sư khỏi vòng lặp, mà thay đổi nơi họ dành thời gian. Hầu hết các hệ thống hoạt động với các điểm kiểm tra, không phải là độc lập hoàn toàn.

Nền tảng của bạn cho phép các nhóm tạo ra các tác nhân của riêng họ. Tính tùy chỉnh quan trọng như thế nào đối với việc áp dụng doanh nghiệp, và những trường hợp sử dụng thú vị nhất bạn đang thấy là gì?

Tùy chỉnh là điều cần thiết cho việc áp dụng doanh nghiệp. Mỗi nhóm nền tảng đều dành một lượng lớn tài nguyên để tùy chỉnh CI cho các nhu cầu cụ thể của công ty, và điều này truyền thống đòi hỏi phải có các tập lệnh tùy chỉnh, cấu hình, tích hợp công cụ, bộ xử lý nhật ký và phần còn lại của băng dính giữ cơ sở hạ tầng phát triển hiện đại lại với nhau.

Gitar thu gọn công việc đó. Các nhóm nền tảng có thể viết các kiểm tra tùy chỉnh bằng cách sử dụng các lời nhắc ngôn ngữ tự nhiên, điều này cho phép họ xác thực những thứ khó hoặc không thể với phân tích chương trình truyền thống, ví dụ như đánh dấu các chuỗi người dùng模糊 cho dịch, hoặc xác thực các cập nhật cho các tệp AGENTS.md. Họ cũng có thể tự động hóa các quy trình làm việc tùy chỉnh trên các yêu cầu kéo: liên kết các yêu cầu kéo với các vấn đề Jira, mở các vé theo dõi cho các nhận xét xem xét chưa giải quyết, tự động thử lại các thử nghiệm không ổn định hoặc thêm các danh sách việc cần làm tùy chỉnh vào tóm tắt yêu cầu kéo.

Các trường hợp sử dụng thú vị nhất thường là những trường hợp chúng tôi không dự kiến. Các nhóm biết cơ sở mã và điểm đau của họ tốt hơn bất kỳ nhà cung cấp nào, vì vậy khi bạn đưa cho họ một nguyên thủy biến “chúng tôi ước CI chỉ kiểm tra X” thành một lời nhắc 10 dòng, họ ngay lập tức bắt đầu tự động hóa những thứ chúng tôi sẽ không bao giờ xây dựng theo mặc định. Đó chính xác là những gì chúng tôi muốn.

Các nhóm kỹ thuật hiện đại phụ thuộc vào một chồng công cụ phức tạp như GitHub, GitLab và Jira. Việc tích hợp vào các quy trình làm việc hiện có quan trọng như thế nào so với việc cố gắng thay thế chúng?

Sự áp dụng phụ thuộc vào việc gặp các nhà phát triển ở nơi họ đã có. Các kỹ sư không muốn một bề mặt khác để học, một bảng điều khiển khác để kiểm tra hoặc nhiều hơn nữa việc chuyển đổi ngữ cảnh giữa các công cụ. Họ muốn các quy trình làm việc hiện có của mình trở nên nhanh hơn và yên tĩnh hơn. Vì vậy, tích hợp sâu với GitHub, GitLab, Jira và phần còn lại của chồng công cụ không phải là một điều gì đó tốt cho chúng tôi; đó là toàn bộ chiến lược.

Nhưng tham vọng của chúng tôi đi xa hơn tích hợp. Chúng tôi không cố gắng thay thế các công cụ này, và chúng tôi không chỉ cố gắng cắm vào chúng. Chúng tôi đang tự động hóa các quy trình làm việc chạy trên chúng. Xem xét yêu cầu kéo, liên kết vé, các nhiệm vụ theo dõi, các thử nghiệm không ổn định, tất cả đều nên xảy ra tự động, trong nền. Và chúng tôi đang đẩy xa hơn: một tác nhân chỉnh sửa yêu cầu kéo trực tiếp để giải quyết phản hồi xem xét và sửa lỗi CI, và cuối cùng xử lý phê duyệt và hợp nhất cho các thay đổi đáp ứng các chính sách của nhóm. Vai trò của nhà phát triển thay đổi từ việc điều khiển từng bước sang thiết lập ý định, xem xét kết quả và xử lý các ngoại lệ.

Trạng thái cuối cùng không phải là một công cụ mới mà các nhà phát triển đăng nhập. Đó là các công cụ hiện có làm được nhiều hơn trên riêng của chúng, vì vậy các nhà phát triển có thể tập trung vào công việc thực sự đòi hỏi phán quyết của họ.

Bạn đã đề xuất rằng xem xét mã của con người cuối cùng có thể trở thành ngoại lệ chứ không phải quy tắc. Điều gì cần xảy ra để các tổ chức cảm thấy thoải mái với sự thay đổi đó?

Tin cậy được xây dựng theo từng giai đoạn, không phải tất cả cùng một lúc. Các tổ chức cần thấy, với mã của riêng họ, rằng AI có thể tìm ra các lỗi và lỗ hổng thực sự quan trọng và thực thi các quy tắc tùy chỉnh của họ với độ chính xác và phạm vi rộng. Từ đó, con đường đến việc hợp nhất tự động là một tiến trình tự nhiên qua bốn cấp độ tin cậy ngày càng tăng.

Cấp độ đầu tiên là phát hiện. Các nhóm xây dựng sự tự tin rằng các tác nhân tìm thấy các vấn đề thực sự với tỷ lệ dương tính giả thấp. Khi sự tự tin đó được thiết lập, họ cho phép AI tự động chặn các yêu cầu kéo khi nó tìm thấy các vấn đề quan trọng.

Cấp độ thứ hai là khắc phục. AI không chỉ đánh dấu các vấn đề, mà còn sửa chúng, mở khóa yêu cầu kéo và chuyển CI sang màu xanh mà không cần can thiệp của con người. Tin cậy ở đây có nghĩa là tác nhân có thể giải quyết các vấn đề và lỗi CI một cách chính xác, mà không làm hỏng mọi thứ.

Cấp độ thứ ba là phê duyệt. Khi các nhóm thấy các tác nhân đáng tin cậy chuyển yêu cầu kéo sang màu xanh, họ cho phép AI phê duyệt yêu cầu kéo theo các quy tắc họ định nghĩa. Việc đưa cho các tổ chức quyền kiểm soát rõ ràng các điều kiện cho phê duyệt tự động là những gì làm cho bước này cảm thấy an toàn chứ không phải là liều lĩnh.

Cấp độ thứ tư là hợp nhất. AI hạ thấp thay đổi, lại dưới các điều kiện mà nhóm cảm thấy thoải mái. Bước này có một tiêu chuẩn riêng: tác nhân phải giải quyết các xung đột hợp nhất một cách chính xác, mà không giới thiệu các hồi quy hoặc phá vỡ chính. Điều đó quan trọng hơn những gì mọi người nhận ra, vì tần suất xung đột tăng lên với thông lượng cam kết, và thông lượng đang bùng nổ khi AI tạo ra nhiều mã hơn. Các kho mã lớn đã cảm nhận được điều này; mọi người khác sắp cảm nhận được.

Sự thay đổi sang AI làm người xem xét mã mặc định không phải là một bước nhảy vĩ đại của niềm tin. Đó là một thang, và các tổ chức leo lên từng bậc một khi bằng chứng tích lũy.

Khi AI đảm nhận nhiều hơn quá trình mã hóa, bạn nhìn thấy vai trò của các kỹ sư cao cấp sẽ phát triển như thế nào trong vài năm tới?

Các kỹ sư cao cấp đã chuyển sang các vai trò điều phối, ghép các nhật ký lại với nhau, chẩn đoán các vấn đề và quyết định những gì an toàn để hợp nhất. Đó không phải là một vai trò mà ai đó đã lên kế hoạch. Đó là một phản ứng đối với hệ thống bị vỡ dưới tải.

Khi các tác nhân đảm nhận nhiều hơn công việc xác thực lặp đi lặp lại, các kỹ sư vẫn ở trong vòng lặp nhưng di chuyển lên cao hơn trong ngăn xếp. Họ dành ít thời gian hơn cho việc triệt để thủ công và nhiều thời gian hơn để đưa ra quyết định về những gì nên gửi và tại sao.

Gitar gần đây đã huy động được 9 triệu đô la để mở rộng quy mô nền tảng. Ưu tiên hàng đầu của bạn cho nguồn vốn này là gì, và thành công trông như thế nào trong 12 đến 18 tháng tới?

Vốn đi đến hai ưu tiên. Đầu tiên là thị trường: chúng tôi đang mở rộng chuyển động doanh nghiệp và đầu tư vào nhận thức của nhà phát triển để các nhóm sẽ được hưởng lợi từ Gitar thực sự biết chúng tôi tồn tại. Thứ hai là sản phẩm: chúng tôi tiếp tục xây dựng theo tầm nhìn của chúng tôi về xác thực mã tự động và chất lượng đầy đủ, điều này có nghĩa là các khả năng tác nhân sâu hơn, phạm vi quy trình làm việc rộng hơn và tích hợp chặt chẽ hơn với các công cụ mà các nhà phát triển đã sử dụng.

Thành công trong 12 đến 18 tháng tới trông giống như một cơ sở khách hàng doanh nghiệp có ý nghĩa đang chạy Gitar trên các cơ sở mã của họ, một cộng đồng nhà phát triển công nhận chúng tôi là mặc định cho xác thực mã được hỗ trợ bởi AI, và bằng chứng rõ ràng rằng các tác nhân của chúng tôi đang thực hiện nhiều hơn công việc xem xét, khắc phục và hợp nhất một cách tự động theo thời gian. Nếu chúng tôi đang trên đúng hướng, cuộc trò chuyện một năm từ bây giờ không phải là liệu AI có thể xác thực mã hay không, mà là bao nhiêu phần của đường ống xác thực một nhóm đã giao cho các tác nhân.

Cảm ơn vì cuộc phỏng vấn tuyệt vời, những người đọc muốn tìm hiểu thêm nên truy cập Gitar.