Người sáng lập tiền nhiệm của GitHub đã nhận 17 triệu USD từ a16z, xây dựng Git trong thời kỳ Agent

Viết bài: Leo

Bạn đã từng nghĩ rằng việc lập trình có thể hoàn toàn thay đổi chưa? Các nhà phát triển đang chuyển từ việc chỉ đơn thuần sử dụng công cụ AI sang xem AI như một nền tảng mới để xây dựng phần mềm. Đây không phải là một điều chỉnh nhỏ, mà là một cuộc chuyển đổi mô hình toàn diện. Hãy nghĩ xem, những khái niệm cốt lõi mà chúng ta luôn quen thuộc — kiểm soát phiên bản, nhánh, xem xét mã, thậm chí định nghĩa “hợp tác” — đều đang được định nghĩa lại do luồng công việc do AI agent điều khiển. Điều khiến tôi sốc hơn nữa là, Git mà chúng ta ngày ngày dùng thực ra là một công cụ được thiết kế cho luồng công việc vá lỗi danh sách email cách đây 20 năm, giờ lại phải phục vụ cho cảnh làm việc cùng lúc của các nhà phát triển và một nhóm AI agent.

Đây chính là lý do tại sao tin GitButler vừa nhận được khoản đầu tư 17 triệu USD vòng A khiến tôi phải dừng lại suy nghĩ nghiêm túc. Vòng gọi vốn này do a16z dẫn đầu, Fly Ventures và A Capital tiếp tục theo đuổi. Thú vị hơn nữa, CEO của GitButler, Scott Chacon, là một trong những đồng sáng lập của GitHub, ông đã viết cuốn “Pro Git” gần như mọi nhà phát triển đều đã đọc. Một người đã đạt thành công lớn trong lĩnh vực kiểm soát phiên bản, tại sao lại quay trở lại con đường khởi nghiệp để suy nghĩ lại về vấn đề tưởng chừng đã “giải quyết” này? Trong thông báo, ông nói rất thẳng thắn: “Chúng tôi không xây dựng một ‘Git tốt hơn’, mà là xây dựng hạ tầng nền tảng cho cách xây dựng phần mềm thế hệ tiếp theo.” Câu nói này ẩn chứa một cái nhìn sâu sắc về tương lai của phát triển phần mềm.

20 năm bế tắc của Git: Công cụ dành cho danh sách email

Tôi nhận thấy nhiều người chưa hiểu rõ về lịch sử của Git. Ban đầu, Git được nhóm Linux Kernel tạo ra vào năm 2005, với triết lý thiết kế dựa sâu vào truyền thống Unix. Scott trong cuộc phỏng vấn đề cập đến một chi tiết thú vị: nhóm phát triển Git chưa bao giờ định làm một giao diện thân thiện người dùng. Họ tuân theo triết lý Unix, xây dựng một loạt các “lệnh ống” cơ bản, mỗi lệnh làm một việc đơn giản, rồi bạn có thể dùng Perl script để kết nối chúng lại, làm bất cứ điều gì bạn muốn. Triết lý này rất hợp lý vào thời điểm đó, vì họ giả định chỉ có các chuyên gia kỹ thuật như nhóm Linux Kernel mới dùng được công cụ này.

Sau đó, mọi chuyện diễn ra như chúng ta đã biết. Một nhà phát triển tên Pasquy viết một số script Perl, đóng gói giao diện người dùng thống nhất cho Git, chính là các lệnh CLI mà chúng ta dùng ngày nay. Những script này ngày càng phổ biến, cuối cùng được hợp nhất vào lõi Git, trở thành “lớp sứ” (porcelain). Thú vị là, các lệnh này từ năm 2005, 2006 trở đi gần như không có thay đổi lớn. Ban đầu viết bằng Perl, sau đó viết lại bằng C, nhưng logic cốt lõi và giao diện người dùng gần như giữ nguyên. Scott nói rằng, khi ông viết “Pro Git” bản đầu tiên vào năm 2009, những lệnh này vẫn hoàn toàn có thể dùng y nguyên.

Sự ổn định này về mặt nào đó là tốt. Nhóm phát triển Git rất coi trọng khả năng tương thích ngược, họ không muốn loại bỏ bất kỳ chức năng nào đã tồn tại, sợ làm hỏng luồng công việc hiện có. Nhưng điều này cũng dẫn đến một vấn đề căn bản: giả định ban đầu của Git đã bị lệch lạc nghiêm trọng so với thực tiễn phát triển phần mềm ngày nay. Git được thiết kế để gửi patch qua danh sách email. Thời đó, nhà phát triển sẽ chỉnh sửa cục bộ, tạo ra một file patch, gửi qua email cho người duyệt, người duyệt xem xét rồi quyết định có chấp nhận hay không. Toàn bộ quy trình này là bất đồng bộ, dựa trên văn bản, theo kiểu đơn luồng.

Còn bây giờ thì sao? Chúng ta có tích hợp liên tục (CI), triển khai liên tục (CD), nhóm phân tán làm việc theo thời gian thực, các công cụ xem xét mã, các pipeline tự động kiểm thử và triển khai. Quan trọng hơn, giờ đây có AI agent viết mã quy mô lớn. Scott đề cập đến một quan sát khiến tôi ấn tượng: chúng ta đang dạy một nhóm AI agent sử dụng một công cụ được thiết kế cho danh sách email để vá lỗi. Cảm giác lệch lạc này giống như để một chiếc Tesla chạy trên đường dành cho xe ngựa.

Triết lý Unix của Git mang lại vấn đề gì?
Thiết kế của Git theo triết lý Unix gây ra một vấn đề khác: nó cố gắng dùng một bộ giao diện để phục vụ cả máy tính lẫn con người. Nếu bạn chạy “git branch”, theo mặc định bạn chỉ nhận được danh sách các nhánh, không có giao diện người dùng nào cả. Điều này vì Git cần đảm bảo rằng đầu ra của lệnh này vừa dễ đọc cho con người, vừa có thể phân tích được bởi các chương trình khác. Sự thỏa hiệp này dẫn đến kết quả: Git không đủ thân thiện với con người, cũng không tối ưu cho máy tính. Mặc dù có một số lệnh cung cấp tùy chọn “–porcelain” để xuất ra định dạng máy có thể đọc được, nhưng đó không phải là chuẩn, nhiều lệnh thậm chí không có tùy chọn này.

Thách thức mới trong thời đại AI Agent: Một thư mục làm việc đã không còn đủ

Khi AI bắt đầu tham gia lập trình quy mô lớn, giới hạn của Git trở nên rõ ràng hơn bao giờ hết. Gần đây, tôi cũng thử làm việc cùng lúc với nhiều AI agent, nhận thấy giả định cơ bản của Git — một nhà phát triển, một nhánh, luồng công việc tuyến tính — đã hoàn toàn không còn phù hợp. Nhà phát triển hiện đại không làm việc theo tuyến tính. Bạn có thể chạy đồng thời nhiều agent, một sửa lỗi UI, một tối ưu truy vấn database, một cập nhật tài liệu. Nhưng hệ thống chỉ mục của Git sẽ sụp đổ trong các chỉnh sửa song song này, vì nó giả định rằng bản sao làm việc cục bộ của bạn đại diện cho các chỉnh sửa đơn nhất, nguyên tử của toàn bộ kho mã.

Giải pháp truyền thống là dùng worktree, tức là tạo nhiều bản sao của kho mã cho từng nhiệm vụ song song. Nhưng điều này lại gây ra vấn đề mới. Nếu bạn có năm agent làm việc cùng lúc, bạn cần năm thư mục làm việc đầy đủ. Mặc dù Git đã tối ưu về lưu trữ, nhưng vẫn phải sao chép nhiều tệp và chiếm dụng không gian đĩa lớn. Quan trọng hơn, các agent này hoàn toàn cách ly, không thể nhìn thấy nhau cho đến khi hoàn thành và cố gắng hợp nhất, lúc đó mới phát hiện ra xung đột. Đến lúc đó, việc giải quyết xung đột đã rất tốn kém.

Giải pháp của GitButler là phân nhánh song song (parallel branches). Đây là một ý tưởng khiến tôi thích thú. Phân nhánh song song giống như nhánh bình thường, nhưng bạn có thể mở nhiều nhánh cùng lúc. Bạn có thể tận dụng lợi thế của worktree (cách ly logic), nhưng không cần sao chép tất cả các tệp. Tất cả các agent đều thao tác trong cùng một thư mục làm việc, nhưng các chỉnh sửa của chúng được phân bổ vào các nhánh ảo khác nhau. Scott mô tả trong phỏng vấn một cảnh tượng ấn tượng: họ để hai agent cùng làm việc, cả hai đều muốn chỉnh sửa cùng một tệp, nhưng cách sửa không tương thích. Kết quả là gì? Một agent tự động xếp chồng nhánh của nó lên nhánh của agent kia rồi tiếp tục làm việc, commit vào phần chồng của nó. Xử lý xung đột thông minh này gần như không thể thực hiện trong luồng làm việc Git truyền thống.

Tôi đặc biệt thích một thử nghiệm của nhóm GitButler, dù cuối cùng họ không áp dụng. Họ từng cố gắng tạo một kênh trò chuyện giữa các agent để chúng có thể trao đổi về công việc đang làm. Scott nói rằng tính năng này trông rất ngầu, họ có thể thấy các cuộc hội thoại giữa agent, rất muốn phát hành. Nhưng sau nhiều thử nghiệm, họ nhận ra tính năng này không thực sự hữu ích. Các agent tự phát hiện ra người khác đang chỉnh sửa tệp nào đó, tự suy luận nguyên nhân rồi điều chỉnh chiến lược làm việc của mình. Chúng không cần giao tiếp rõ ràng, vì giao tiếp mang lại chi phí, làm chậm quá trình. Phát hiện này rất có ý nghĩa: chúng ta không thể đơn giản áp dụng mô hình hợp tác của con người vào agent, vì agent có cách làm việc riêng của chúng.

Thiết kế lại giao diện người dùng: cho con người, cho agent, cho script

Gần đây, GitButler ra mắt công cụ CLI đã gây ấn tượng mạnh với tôi. Đây không chỉ là một wrapper đơn thuần cho Git, mà là một cách suy nghĩ lại toàn bộ cách thiết kế công cụ dòng lệnh. Scott đề cập một quan sát thú vị: khoảng 80% nhà phát triển vẫn dùng công cụ dòng lệnh để thao tác Git, dù có nhiều GUI tồn tại. Lý do đơn giản — hầu hết các GUI của Git chỉ là gói gọn các lệnh Git trong giao diện đồ họa, không thêm nhiều chức năng, thậm chí còn làm chậm thao tác. Nếu bạn biết rõ lệnh cần chạy, gõ trực tiếp sẽ nhanh hơn.

Nhưng CLI của GitButler khác biệt. Nó cung cấp các định dạng đầu ra phù hợp với từng tình huống. Nếu bạn chạy lệnh, nó sẽ trả về kết quả tối ưu, dễ đọc cho con người, kèm gợi ý và cảnh báo. Nếu bạn thêm “–json”, nó sẽ xuất ra dữ liệu JSON có cấu trúc, dễ cho script phân tích. Họ còn đang xem xét thêm “–markdown” để tối ưu cho agent, vì định dạng markdown dễ nhúng vào ngữ cảnh của agent hơn.

Thú vị hơn nữa, họ dựa trên quan sát hành vi của agent để tối ưu thiết kế công cụ. Họ phát hiện rằng, dù có tùy chọn “–json”, các agent thích dùng đầu ra dễ đọc hơn, rồi tự truyền qua pipe tới jq hoặc viết script Python để trích xuất thông tin. Một phát hiện khác là, sau khi chạy các lệnh chỉnh sửa, agent gần như luôn chạy “git status” để kiểm tra trạng thái. Vì vậy, nhóm GitButler đã thêm tùy chọn “–status-after” vào tất cả các lệnh chỉnh sửa, để sau khi thực hiện, tự động hiển thị trạng thái. Thiết kế này trái với triết lý Unix truyền thống, không phù hợp cho script, nhưng lại rất phù hợp cho agent.

Họ còn đang khám phá cách cung cấp nhiều ngữ cảnh hơn cho agent qua đầu ra. Ví dụ, trong kết quả lệnh, có thể chèn các gợi ý như “nếu bạn muốn làm điều này, chạy lệnh này”. Điều này không dành cho con người, vì sẽ gây rườm rà, nhưng với agent, đó là thông tin bổ sung giúp nó quyết định bước tiếp theo nhanh hơn. Scott nói đây là một vấn đề UX rất thú vị, vì chúng ta phải xem agent như một “hình mẫu người dùng” mới, với nhu cầu và hành vi khác hoàn toàn con người.

Thay đổi bản chất của phát triển phần mềm: từ viết mã sang viết đặc tả

Trong cuộc phỏng vấn, Scott đề cập một quan điểm khiến tôi suy nghĩ sâu sắc: những kỹ sư phần mềm xuất sắc nhất trong tương lai có thể không phải là người viết mã tốt nhất, mà là người giỏi giao tiếp, viết lách, mô tả rõ ràng. Nghe có vẻ phản trực giác, vì nhiều người chọn lập trình để tránh giao tiếp với người, mà là để “giao tiếp” với máy. Nhưng suy nghĩ kỹ, xu hướng này hoàn toàn hợp lý.

Khi AI agent có thể tạo mã hiệu quả, giới hạn không còn nằm ở chi tiết thực thi nữa, mà là khả năng mô tả rõ ràng mong muốn của bạn. Scott chia sẻ quy trình làm việc của ông: phần lớn thời gian ông viết đặc tả chi tiết về cách hoạt động của một chức năng. Mỗi khi cần quyết định thiết kế, ông yêu cầu AI dựa trên đặc tả để thực hiện, rồi kiểm thử kết quả. Nếu có vấn đề, ông chỉnh sửa đặc tả, yêu cầu AI làm lại. Chu trình này diễn ra rất nhanh, vì ông không cần tự viết tất cả mã.

Cách làm việc này rất tuyệt vì bạn có thể làm “show and tell” (trình bày và thuyết trình). Trước đây, để kiểm tra ý tưởng, bạn phải viết tài liệu kỹ thuật chi tiết rồi thuyết phục nhóm xem xét. Nhưng tài liệu dù chi tiết đến đâu cũng không bằng một nguyên mẫu chạy được. Giờ đây, bạn có thể tạo ra nguyên mẫu nhanh chóng, để nhóm trải nghiệm thực tế rồi dựa trên phản hồi để chỉnh sửa nhanh. Điều này rút ngắn đáng kể vòng đời từ ý tưởng đến xác thực.

Nhưng cũng đặt ra thách thức mới. Thay vì “chúng ta có thể làm gì”, bây giờ là “chúng ta có thể đồng thuận về mong muốn không”. Scott nói, nhiều nhà phát triển, đặc biệt là những người tự cho là thông minh, nghĩ rằng họ không cần giải thích mình đang làm gì, vì mã là tài liệu tốt nhất. Nhưng trong thời đại AI, thái độ đó không còn phù hợp nữa. Bạn phải rõ ràng trong việc diễn đạt ý định, viết đặc tả để cả nhóm và AI đều hiểu. Viết lách trở thành một kỹ năng siêu phàm mới.

Điều này khiến tôi nghĩ về tương lai của việc xem xét mã. Scott đặt ra câu hỏi sắc bén: nếu hỏi đa số kỹ sư phần mềm, khi xem xét PR, họ có thực sự đọc hết toàn bộ không? Có thực sự suy nghĩ từng dòng không? Có chạy thử mã trên máy không? Hay chỉ lướt qua, xác nhận không có vấn đề rõ ràng rồi phê duyệt? Phần lớn sẽ chọn cách thứ hai. Không phải là họ thiếu trách nhiệm, mà là chi phí xem xét quá cao, lợi ích không đủ rõ ràng.

Trong đó, AI agent có thể thay đổi cuộc chơi. Chúng rất giỏi xem xét kỹ từng dòng mã, chạy thử, kiểm tra tiềm năng lỗi. Chúng không mệt mỏi, không chán nản, duy trì tiêu chuẩn nhất quán. Như vậy, con người có thể tập trung vào các vấn đề cấp cao hơn: liệu thay đổi này có phù hợp với hướng sản phẩm? Có giải quyết đúng nhu cầu người dùng không? Thiết kế kiến trúc có hợp lý không? Các chi tiết thực thi, cú pháp, lỗi tiềm năng, để AI lo.

PR và Issue: mô hình hợp tác 20 năm đã đến lúc cần đổi mới

Hệ thống Pull Request của GitHub đã trở thành tiêu chuẩn hợp tác mã nguồn mở, nhưng Scott cho rằng mô hình này có vấn đề căn bản. PR dựa trên nhánh, không dựa trên patch. Điều này dẫn đến nhiều “rác” trong các commit — như “Ôi, sửa lỗi nhỏ này”, “Quên thêm tệp này”. Vì trong mô hình PR, quan trọng là toàn bộ nhánh, chứ không phải từng commit. Do đó, người ta ít quan tâm đến chất lượng commit, mà chủ yếu là mô tả PR, và mô tả này thường không còn trong lịch sử Git sau khi merge.

Trong thời đại danh sách email, điều này không thành vấn đề. Mỗi patch đều có mô tả rõ ràng, vì đó chính là PR của bạn. Việc xem xét dựa trên patch, chất lượng patch và mô tả liên quan chặt chẽ. Nhưng trong thời đại GitHub, chúng ta đã mất đi giới hạn này. Scott cho rằng, trong tương lai, việc xem xét mã nên trở lại dựa trên patch, nhưng kết hợp lợi ích của các công cụ hiện đại. Việc xem xét nên diễn ra cục bộ, bạn có thể chạy mã, thử chức năng. AI có thể giúp chạy thử, đánh dấu lỗi tiềm năng, bạn chỉ tập trung vào những phần thực sự cần con người quyết định.

Một ý tưởng thú vị khác là về giao tiếp nhóm. Scott nói, một trong những điều chưa tốt trong phát triển phần mềm là giao tiếp theo thời gian thực giữa các nhóm. Nếu bạn đang chỉnh sửa một tệp, còn tôi cũng chỉnh sửa cùng tệp đó, cuối cùng phải hợp nhất, mới phát hiện ra xung đột, rồi một bên phải gánh toàn bộ công việc hợp nhất. Nhưng nếu chúng ta biết được đồng bộ về công việc của nhau theo thời gian thực, thì sao? Với con người, điều này có thể quá tốn kém, gây gián đoạn công việc. Nhưng với agent, đó không phải là vấn đề. Chúng có thể dùng thời gian rảnh để giao tiếp, hiểu rõ những gì nhóm hoặc các agent khác đang làm, phát hiện xung đột tiềm năng sớm, hoặc chủ động điều chỉnh chiến lược để tránh xung đột.

Hệ thống siêu dữ liệu mà GitButler đang khám phá cũng rất thú vị. Họ muốn đính kèm các cuộc trò chuyện, quá trình suy nghĩ của agent, các ngữ cảnh liên quan vào commit hoặc nhánh. Hiện tại, Git rất hạn chế trong việc hỗ trợ dữ liệu siêu này. Những thông tin này rất có giá trị để hiểu lý do tại sao quyết định như vậy, quá trình suy nghĩ đằng sau mã. Nhưng điều này cũng đặt ra vấn đề dữ liệu lớn. Scott nói, ngay cả chỉ lưu văn bản, quy mô dữ liệu này sẽ tăng nhanh chóng. Họ phải dùng các công nghệ của các kho lớn như Chrome hoặc Microsoft Office để xử lý quy mô này.

Suy nghĩ về cuộc cách mạng này

Sau khi đọc câu chuyện của GitButler và cuộc phỏng vấn Scott, tôi có một số cảm nhận sâu sắc. Phát triển phần mềm đang trải qua một cuộc chuyển đổi mô hình căn bản, và hệ thống kiểm soát phiên bản, như một hạ tầng nền tảng, cần phải thích nghi. Triết lý của Git đã rất tiên tiến 20 năm trước, nhưng giờ đã trở thành giới hạn. Chúng ta không cần “Git tốt hơn”, mà cần một hạ tầng mới phù hợp với luồng công việc hiện đại và kỷ nguyên AI.

Điều tôi đặc biệt đồng cảm là suy nghĩ của Scott về “điểm kết” logic. Ông nói, trong các dự án học ngôn ngữ, nhiều người thấy dịch thuật trực tiếp là đã chết. Nhưng ông phản bác rằng, dù có dịch giả hoàn hảo, hai bên vẫn cần đeo dịch giả, và trải nghiệm giao tiếp đó không thể bằng việc dùng chung một ngôn ngữ. Ông từng đi Nhật một tuần, dùng dịch giả rất tốt, nhưng vẫn không tốt, không thể xây dựng mối quan hệ sâu sắc hay hợp tác phức tạp. Cũng như vậy với lập trình. Dù AI agent mạnh mẽ đến đâu, chúng vẫn không thể thay thế hoàn toàn khả năng đánh giá, sáng tạo và giao tiếp của con người.

Về tương lai của GitHub, tôi nghĩ quan điểm của Scott rất hợp lý. Ưu điểm lớn nhất của GitHub là số lượng người dùng khổng lồ, còn nhược điểm là khó chuyển đổi nhanh như một công ty lớn. Hiện toàn ngành đang tìm kiếm “GitHub tiếp theo”, nhưng Scott chỉ ra rằng, vấn đề này có thể đã đặt sai câu hỏi. GitHub không phải là “đối thủ” của bất kỳ thứ gì, mà là một mô hình hợp tác hoàn toàn mới. Có thể trong tương lai sẽ xuất hiện một dạng hợp tác hoàn toàn khác, mà chúng ta còn chưa hình dung ra.

Tôi nghĩ giá trị của GitButler không chỉ nằm ở các chức năng cụ thể, mà còn ở cách họ suy nghĩ. Họ đặt câu hỏi dựa trên nguyên lý đầu tiên: tại sao chỉ làm việc trên một nhánh? Tại sao commit phải theo tuyến tính? Tại sao agent và con người phải dùng cùng một giao diện? Tại sao hợp tác phải qua PR và issue? Những suy nghĩ này dựa trên nguyên lý đầu tiên, chính là điều chúng ta cần trong thời đại biến động này.

Tôi cũng nhận thức rõ rằng, như nhà phát triển, chúng ta cần phát triển các kỹ năng mới. Viết đặc tả rõ ràng, giao tiếp hiệu quả, hiểu cách hoạt động của AI agent — tất cả có thể quan trọng hơn kỹ năng lập trình thuần túy. Điều này có thể là thử thách, đặc biệt với những người chọn lập trình để tránh giao tiếp. Nhưng cũng là cơ hội để chúng ta thoát khỏi các chi tiết thấp cấp, tập trung vào những công việc sáng tạo hơn: xác định vấn đề, thiết kế giải pháp, đưa ra quyết định có cân nhắc.

Khoản đầu tư 17 triệu USD của GitButler chỉ mới là bước khởi đầu. Tôi tin rằng trong vài năm tới, chúng ta sẽ chứng kiến nhiều nỗ lực tái thiết hạ tầng phát triển phần mềm. Quản lý phiên bản, xem xét mã, quản lý dự án, kiểm thử, triển khai — tất cả đều được thiết kế trong thời đại trước AI, cần phải được xem xét lại. Những nhóm và nhà phát triển thích nghi nhanh sẽ có lợi thế lớn trong cuộc cách mạng này.

Cuối cùng, phát triển phần mềm sẽ trở thành một công việc tập trung hơn vào giao tiếp, hợp tác và ra quyết định, chứ không chỉ chú trọng vào cú pháp và chi tiết thực thi. Nghe có thể làm một số lập trình viên truyền thống cảm thấy không yên tâm, nhưng tôi nghĩ đó là điều tốt. Nó giúp lập trình trở nên gần hơn với bản chất của việc giải quyết vấn đề, thay vì bị ràng buộc bởi các chi tiết kỹ thuật. Khi chúng ta không còn phải nhớ các lệnh Git phức tạp, không còn phải tự giải quyết xung đột merge, không còn dành nhiều thời gian viết mã lặp đi lặp lại, thì chúng ta có thể tập trung vào những điều thực sự quan trọng: hiểu rõ nhu cầu người dùng, thiết kế giải pháp tinh tế, tạo ra sản phẩm có giá trị. Đó mới là cốt lõi của phát triển phần mềm, và cũng chính là hướng mà GitButler đang giúp chúng ta hướng tới để quay trở lại.