Mã Nguồn Đang Trở Nên Rẻ Mạt, Và Điều Đó Thay Đổi Mọi Thứ

Mã Nguồn Đang Trở Nên Rẻ Mạt, Và Điều Đó Thay Đổi Mọi Thứ

Vào tháng 4 năm 2023, Kent Beck — cha đẻ của Lập trình cực hạn (Extreme Programming) và người phổ biến Phát triển hướng kiểm thử (Test-Driven Development) — đã đăng một dòng tweet đáng báo động lên Twitter:

90% kỹ năng của tôi vừa rớt giá xuống 0 đô la. 10% kỹ năng còn lại vừa tăng giá gấp 1000 lần.

Hai năm sau, trong một buổi podcast vào tháng 11 năm 2025, ông đã làm rõ về 10% đó thực sự là gì: "Có tầm nhìn, khả năng đặt ra các cột mốc để hiện thực hóa tầm nhìn đó, theo dõi thiết kế để duy trì hoặc kiểm soát mức độ phức tạp khi tiến triển. Đó là những kỹ năng có đòn bẩy khổng lồ hiện nay so với việc biết đặt dấu và, dấu sao hay dấu ngoặc ở đâu trong Rust."

Nếu bạn để ý, bạn đã biết 90% kia là gì. Còn nếu chưa, bài viết này dành cho bạn.

Dự án cuối tuần giá 350.000 USD

Paul Ford, cựu CEO của Postlight và một trong những quan sát viên sắc sảo nhất của ngành công nghệ, đã mô tả những gì đã xảy ra khi Anthropic tặng cho người dùng gói Pro 1.000 USD tín dụng Claude Code miễn phí vào tháng 11 năm 2025. Ford, người tự mô tả mình là "một lập trình viên khá hiệu quả và một tay nghiệp dư khủng khiếp", đã quyết định tiêu 100 USD mỗi ngày cho các dự án phụ đã nằm im trong thư mục suốt một thập kỷ.

Ford có thể đưa ra những con số cụ thể vì ông đã dành nhiều năm làm một chuyên gia ước tính chi phí phần mềm chuyên nghiệp. Ông biết chính xác mọi thứ tốn bao nhiêu để xây dựng. Chính Claude Code cũng ước tính chi phí dự án và những ước tính đó, theo lời của Ford, "rất chính xác — nếu là vào năm 2022." Nhưng vào năm 2025, ta chỉ cần gõ "làm tất cả những thứ đó; nghe có vẻ hời" và mọi thứ sẽ hoàn thành trong mười lăm phút với chi phí khoảng 50 xu.

Trong suốt cuối tuần, ông đã chuyển đổi blog cũ của mình từ một định dạng dữ liệu "kỳ quặc và đáng sợ" mà ông tạo ra năm 1999 sang một CMS gọn gàng mới. Ông đã xây dựng một dự án trực quan hóa dòng thời gian với frontend TypeScript và backend mới. Ông đã tạo ra một bản sao chức năng của OwnCast. Tổng chi tiêu: khoảng 150 USD.

Mô tả của Ford về trải nghiệm này rất đáng để ngẫm nghĩ: "Lập trình bằng Claude Code giống như chơi với một con Tamagotchi, nếu con Tamagotchi đó là một đội ngũ kỹ sư và sản phẩm gồm 40 người, và thay vì sản xuất những 'phân' kỹ thuật số, nó có thể triển khai các ứng dụng web backed-by database với giao diện API type-safe và frontend React."

Với tỷ lệ bán lẻ năm 2021, riêng việc chuyển đổi dữ liệu đã sẽ tốn 350.000 USD: một quản lý sản phẩm, một nhà thiết kế, hai kỹ sư (bao gồm một người cấp cao), bốn đến sáu tháng thiết kế, coding và kiểm thử, cộng với bảo trì. Và Ford đã làm được tất cả, vào cuối tuần và buổi tối, chỉ với giá của những khoản tín dụng khuyến mãi thừa.

Đây không phải là một thí nghiệm tư duy giả định về tương lai. Đây là một người, ngay lúc này, đang thực hiện công việc mà trước đây cần một đội ngũ nhỏ và nửa năm trời.

Ràng buộc đã định hình mọi thứ

Mã nguồn (code) luôn luôn đắt đỏ. Vài trăm dòng code sạch và được kiểm thử có thể mất hết cả ngày của hầu hết các lập trình viên. Đây không phải là một chi tiết nhỏ, mà là ràng buộc cốt lõi đã định hình gần như mọi thói quen và tổ chức trong ngành của chúng ta.

Tại sao chúng ta lại ước tính các story (yêu cầu)? Vì thời gian của lập trình viên đắt đỏ và ai đó phải lập ngân sách cho nó. Tại sao chúng ta lại ưu tiên các tính năng trong backlog? Vì chúng ta không thể xây dựng mọi thứ và cần chọn những gì đáng giá chi phí đó. Tại sao chúng ta đau đầu việc có nên tái cấu trúc (refactor) module này hay viết giao diện debug kia? Vì thời gian dành cho việc này là thời gian không dành cho việc kia.

Lập kế hoạch. Ước tính. Ưu tiên tính năng. Review code. Review kiến trúc. Lập kế hoạch Sprint. Tất cả đều là hệ quả của giả định rằng viết code là phần đắt đỏ nhất.

Các tác nhân coding vừa làm giảm chi phí của phần đó xuống mức sàn.

Trong bài tiểu luận "Programming Deflation" (Lạm phát mã nguồn) vào tháng 9 năm 2025, Beck đã khám phá điều gì sẽ xảy ra khi chi phí sản xuất mã nguồn giảm liên tục. Kết luận của ông không phải là chúng ta sẽ cần ít lập trình viên hơn, mà là mã nguồn rẻ hơn sẽ giải phóng nhu cầu tiềm ẩn. Có hàng triệu vấn đề không ai bother giải quyết vì chi phí giải pháp phần mềm vượt quá giá trị của nó. Khi chi phí mã nguồn giảm sút, những vấn đề đó trở nên đáng để giải quyết. Tổng lượng phần mềm trên thế giới sẽ tăng lên, không phải giảm xuống.

Simon Willison, người tạo ra Datasette và một trong những người thực hành sâu sắc nhất viết về phát triển hỗ trợ bởi AI, đã nắm bắt tốt sự thay đổi này trong hướng dẫn về các mẫu kỹ thuật tác nhân (Agentic Engineering Patterns). Heuristic của ông rất đơn giản và đẹp: bất cứ khi nào bản năng nói "đừng xây cái đó, không đáng tốn thời gian", hãy gửi một prompt anyway trong một phiên tác nhân bất đồng bộ. Trường hợp xấu nhất là mười phút sau bạn kiểm tra và thấy nó không đáng tốn tokens.

Heuristic đó chỉ có ý nghĩa trong một thế giới nơi mã nguồn rẻ. Sáu tháng trước, nó sẽ là điều vô lý.

Những gì "Code Tốt" vẫn tốn kém

Trước khi ai đó buộc tội tôi là cho rằng chất lượng không quan trọng: nó quan trọng. Thực tế, nó còn quan trọng hơn bao giờ hết.

Willison định nghĩa "code tốt" là code hoạt động, chúng ta biết nó hoạt động, giải quyết đúng vấn đề, xử lý lỗi một cách khéo léo, đơn giản và tối thiểu, được bảo vệ bởi các bài kiểm thử (tests), được tài liệu hóa phù hợp, cho phép thay đổi trong tương lai và đáp ứng các tiêu chuẩn "-ilities" liên quan: khả năng truy cập, khả năng kiểm thử, độ tin cậy, bảo mật, khả năng bảo trì, khả năng quan sát, khả năng mở rộng, khả năng sử dụng.

Các công cụ tác nhân có thể giúp với hầu hết danh sách đó. Nhưng vẫn còn một gánh nặng lớn đè lên lập trình viên để đảm bảo mã được tạo ra thực sự tốt. Tính ngẫu nhiên (stochastic) của các Mô hình Ngôn ngữ Lớn (LLM) có nghĩa là bạn không thể chỉ tin vào đầu ra. Từ "ngẫu nhiên" ở đây quan trọng: nó có nghĩa là cùng một đầu vào có thể tạo ra các đầu ra khác nhau mỗi lần. Một bài test pass không có nghĩa là nó là một bài test tốt. Code biên dịch được không có nghĩa là nó đúng.

Đây một cách nghịch lý, là điều khiến LLM trở nên mạnh mẽ cho lập trình so với các lĩnh vực khác. Chúng ta có trình biên dịch: hoặc là nó biên dịch được hoặc không. Chúng ta có bộ test: hoặc là test pass hoặc fail. Chúng ta có hệ thống kiểu, linter, phân tích tĩnh. Phần mềm cung cấp cho chúng ta các công cụ xác minh mà hầu hết các lĩnh vực khác không có.

Nhưng xác minh đòi hỏi phải biết "đúng" trông như thế nào. Và đó là nơi 10% kỹ năng tăng giá 1000 lần sinh sống.

Báo cáo DORA năm 2024 của Google đã xác nhận nghịch lý này từ một hướng khác: 75% lập trình viên báo cáo cảm thấy năng suất hơn với các công cụ AI, nhưng mỗi 25% tăng trưởng trong việc áp dụng AI lại cho thấy sự giảm 1,5% trong tốc độ giao hàng và giảm 7,2% trong độ ổn định của hệ thống. Trong khi đó, 39% người trả lời báo cáo có ít hoặc không có sự tin tưởng vào mã do AI tạo ra. Các công cụ khiến chúng ta cảm thấy nhanh hơn. Dữ liệu gợi ý chúng ta không nhanh, trừ khi chúng ta thay đổi cách làm việc. Chúng ta sẽ nói kỹ hơn về điều này trong các chương sau.

Ẩn dụ chiếc súng bắn đinh

AI giống như một chiếc súng bắn đinh. Trong tay người không có kỹ năng, nó nguy hiểm. Trong tay một chuyên gia, nó giúp họ nhanh hơn rất nhiều. Và cuối cùng, tất cả những gì ai đó quan tâm là có một chiếc đinh ở vị trí đó.

Bạn có thể cảm thấy đây là sự đơn giản hóa. Tôi sẽ lập luận rằng nó chính xác hơn bạn nghĩ.

Người dùng không quan tâm đến chỉ số SonarQube của bạn. Họ không quan tâm bạn dùng phong cách functional hay object-oriented, kiến trúc là hexagonal hay layered, bạn chọn Rust hay TypeScript. Họ quan tâm ứng dụng làm được những gì nó quảng cáo, đủ nhanh, không làm mất dữ liệu của họ và có sẵn khi họ cần.

Tất nhiên, có một rủi ro lớn ở đây. Nếu bạn không xác minh tiến độ, nếu bạn chỉ để tác nhân tạo ra code mà không hiểu nó đang sản xuất cái gì, bạn có thể kết thúc với một cục "bùn nhão" (slop) chìm dưới trọng lượng của chính nó. Chúng ta đều đã đọc những câu chuyện kinh dị đó. Đó là lý do tại sao điều này không chỉ là về công cụ. Nó là về hệ thống.

Hệ thống mới là tài sản

Hãy nhìn vào các hệ thống đã tồn tại lâu dài vì chúng hoạt động. Điều tồn tại không phải là chi tiết triển khai. Điều tồn tại là hành vi được hiểu rõ và ý thức rõ ràng về những gì không được phép phá vỡ.

Một ví dụ cụ thể hơn: hãy xem xét một thị trường cho doanh nghiệp bán lẻ cho người tiêu dùng (C2C). Hệ thống là gì? Nó không phải là ngôn ngữ, microservices, hay topology triển khai. Hệ thống là SLA: độ trễ, tính sẵn sàng. Hệ thống là dữ liệu: audit trails, tài khoản, hồ sơ giao dịch. Hệ thống là các hợp đồng: cái gì đi vào, cái gì đi ra. Hệ thống là các bất biến (invariants): chỉ một giá thầu cho mỗi món đồ của mỗi người dùng, tối đa N món đồ đang bán của mỗi người dùng.

Nếu bạn có tất cả những thứ đó được định nghĩa chi tiết, bạn có thể tái tạo hệ thống đi tái tạo lại nhiều lần. Công cụ khác, kiến trúc khác, đội khác, tác nhân khác. Và người dùng sẽ không nhận ra sự khác biệt.

Tôi có thể nghe thấy phản biện rồi: Waterfall đã chỉ ra rằng chúng ta rõ ràng bỏ sót các bất biến và chi tiết, rằng kinh doanh phát triển và chúng ta cần cập nhật các định nghĩa hệ thống này liên tục. Tôi không đang ủng hộ việc làm nó một lần hoàn hảo. Điều đó chưa bao giờ hoạt động và sẽ không bao giờ.

Nhưng tôi đang ủng hộ việc tập trung vào định nghĩa hệ thống như hoạt động kỹ thuật chính. Nếu code của bạn tuân thủ các hợp đồng, pass các bài test, đáp ứng các SLA, có quan trọng nó là code bạn tự viết không?

Điều này kết nối tự nhiên với khả năng quan sát (observability). Ngày càng nhiều, chúng ta đang chuyển sang các hệ thống được debug trong môi trường production. Một hệ thống với các hợp đồng ổn định, đánh giá mạnh mẽ, giám sát liên tục và các đường rollback rõ ràng có thể an toàn chịu đựng nhiều thay đổi, với ít giám sát của con người hơn, ở quy mô lớn hơn. Đó là thách thức của kỷ nguyên mới.

Điều này, tất nhiên, trong một lĩnh vực mà các công ty đã cố gắng "linh hoạt" (agile) và thất bại (hoặc áp dụng SAFe) trong 25 năm qua, có nghĩa là sẽ có nhiều đau đớn trong tương lai gần.

Sự thay đổi tư duy

Bộ kỹ năng cần thiết để sử dụng các tác nhân AI tốt hóa ra lại là sự kết hợp giữa quản lý sản phẩm và quản lý đội ngũ phát triển. Bạn cần biết xây dựng cái gì, tại sao nó quan trọng, "hoàn thành" trông như thế nào, và cách xác minh kết quả. Bạn cần chỉ định kết quả, không phải cách triển khai. Phát triển dạng khai báo (declarative development), "đây là cái tôi muốn, tự tìm cách đi", luôn đánh bại vi mô quản lý dạng mệnh lệnh (imperative) mọi khi.

Các lập trình viên cố gắng vi mô quản lý đầu ra của tác nhân sẽ gặp khó khăn. Các lập trình viên học cách chỉ định, xác minh và lặp lại sẽ thịnh vượng. 10% tăng giá 1000 lần là phán xét, chỉ định và xác minh. 90% rớt giá xuống 0 là việc gõ phím.

Ford đã nắm bắt hoàn hảo sự phức tạp cảm xúc của khoảnh khắc này: "Tất cả những người tôi yêu thích đều ghét thứ này, và tất cả những người tôi ghét đều yêu thích nó." Ma sát xã hội là có thật. Các lập trình viên áp dụng công cụ AI thường gặp phải sự phản đối từ chính cộng đồng chuyên nghiệp của họ. Nó thêm một lớp tâm lý vào những gì về cơ bản là một sự thay đổi kinh tế.

Nhưng điều này thực sự không phải là về sự nhiệt tình với AI hay hoài nghi về AI. Nó là về công nghiệp hóa. Nó đã xảy ra lặp đi lặp lại trong mọi lĩnh vực, và mô hình luôn giống nhau: những người công nghiệp hóa sẽ cạnh tranh thắng lợi những người không. Bạn có thể mua gốm thủ công từ Etsy, hoặc bạn có thể mua nó sản xuất hàng loạt từ cửa hàng. Mỗi đề xuất giá trị những thứ khác nhau. Nhưng nếu bạn đang chạy một doanh nghiệp phụ thuộc vào gốm, bạn tốt nhất nên hiểu kinh tế học.

Ngay cả sau khi chu kỳ cường điệu kết thúc, và nó sẽ kết thúc, các LLM mã nguồn mở cục bộ sẽ vẫn còn. Bất kỳ trạm làm việc của lập trình viên nào cũng đã có thể chạy chúng với kết quả khá tốt. Đường cong chi phí chỉ đi theo một hướng.

Còn một con số nữa đáng nhắc đến. Tính đến đầu năm 2026, khoảng 4% các commit trên GitHub được viết bởi Claude Code một mình. Đó không phải là dự báo. Đó là trạng thái hiện tại. Tỷ lệ phần trăm đó chỉ sẽ tăng lên.

Hãy ngừng tối ưu hóa cho việc sản xuất code. Hãy bắt đầu tối ưu hóa cho việc định nghĩa hệ thống.

Đó là nơi giá trị sinh sống ngay bây giờ.