Code giờ đã là đất sét: Kỷ nguyên lập trình mềm dẻo

Trong nhiều thập kỷ, viết phần mềm giống như đẽo đá: đã tạc vào đá thì rất khó sửa, mỗi thay đổi lớn đều kéo theo tháo dỡ và làm lại. Lập trình tác tử (agentic coding) đang thay đổi điều đó — mã nguồn trở nên dễ nặn, dễ tạo hình, và chi phí thay đổi gần như sụp đổ. Vậy chúng ta nên làm việc với "đất sét" này như thế nào?

Code giờ đã là đất sét

Từ "đá" đến "đất sét"

Tác giả Alberto Denia gọi giai đoạn trước tháng 11/2025 là "thời Trung cổ của lập trình". Khi đó, lập trình viên giống như thợ đẽo đá: cẩn thận tạc từng dòng mã thành phẩm hoàn chỉnh. Đá không dễ tha thứ — dù công cụ ngày càng tốt hơn, việc sửa đổi vẫn luôn khó khăn. Chỉnh nhỏ thì tạm ổn, nhưng thay đổi lớn đồng nghĩa với tháo dỡ, dựng giàn giáo và một kế hoạch chi tiết treo trên tường.

Với lập trình tác tử, bức tranh đảo ngược hoàn toàn. Mã nguồn vẫn được làm từ cùng chất liệu nền tảng, nhưng chi phí tạo ra một thay đổi đã sụp đổ. Điều đó khiến nó hành xử như một vật liệu hoàn toàn khác: mã nguồn giờ là đất sét.

Làm việc với đất sét

Khi mã nguồn là đất sét, bạn có thể bắt đầu "nặn" nó. Đắp những khối lớn vào hình dạng thô mà bạn muốn rồi xem cảm giác ra sao. Không thích? Chỉnh lại một phần hoặc bóp nát toàn bộ và bắt đầu lại — đều rất dễ.

Khi cấu trúc tổng thể đã ổn, bạn tinh chỉnh theo cách của nhà điêu khắc: từ khối lớn, đến các chi tiết trung bình, rồi đến tiểu tiết.

Cách làm này có thể áp dụng ở mọi tầng của sản phẩm:

• Một lập trình viên độc lập khám phá sản phẩm mới có thể phác thảo toàn bộ phần lõi trong một ngày để xem hướng nào khả thi trước khi đi vào chi tiết.
• Một nhóm phụ trách tính năng đang èo uột có thể dành vài ngày đưa nó sang hướng hoàn toàn mới để biết liệu cú xoay này có đáng giá hay không.

Không bản kế hoạch hay bản mockup nào sánh được với việc xem sản phẩm thật vận hành.

Tuy vậy, khả năng phán đoán của bạn vẫn quan trọng. Thay đổi giờ gần như miễn phí, nhưng biết thay đổi nào là đúng thì không. Nếu chỉ chồng chất các khối đất lên nhau, sản phẩm sẽ đổ sụp thành một vũng lầy lộn xộn nhanh hơn bạn kịp gõ prompt để thoát ra. Gu thẩm mỹ, bối cảnh, rào chắn, kiến trúc… chính là bộ khung và lò nung của bạn.

Con đường của người nghệ nhân

Người nghệ nhân muốn nằm trong vòng lặp. Vòng phản hồi nhanh là điểm tuyệt vời nhất của mã nguồn mềm dẻo, và là lý do nhiều người trong chúng ta nghiện nó.

Trong khoảng thời gian đi pha một ly cà phê, bạn có thể nghĩ ra một tính năng, lên kế hoạch với tác tử trên điện thoại và quay lại bàn làm việc với bản sẵn sàng để review. Thêm vài vòng tinh chỉnh, bạn đã nén cả chu trình sản phẩm – kỹ thuật – kiểm thử vào một người và ba mươi phút.

Khi bạn chính là người dùng của mình, vòng lặp này trở nên cực kỳ thỏa mãn.

Tác giả dẫn ví dụ: anh đang xây một trình soạn thảo Markdown và dùng nó mỗi ngày. Nhìn vào file danh sách chi tiêu, anh ước "giá mà tự cộng tổng được" — và chỉ sau nửa lon nước ngọt, phiên bản đầu tiên của "khối tính toán" đã chạy được và có ích ngay. Đó là phát triển phần mềm theo thời gian thực.

Vậy đây có phải chỉ là "vibe coding"? Không hẳn. Con đường nghệ nhân là ở lại trong vòng lặp và áp dụng phán đoán ở mọi vòng lặp. Khi bạn chỉ đánh giá bề mặt người dùng thấy, đó là vibe coding. Khi bạn đánh giá cả mã nguồn — ít nhất là hình dạng của nó — đó là kỹ thuật phần mềm. Chỉ có điều vòng lặp giờ nhanh hơn.

Con đường của nhà máy

Ở thái cực còn lại, bạn muốn tách mình ra khỏi vòng lặp. Đó là con đường của nhà máy: xây dựng hệ thống biến đất sét mã nguồn thành những viên gạch khớp gọn vào một cấu trúc lớn hơn.

Hãy hình dung một pipeline gồm đặc tả, bộ sinh mã và bộ kiểm chứng (test, eval, rào chắn, tác tử review) chạy trong vòng lặp, chỉ đẩy lên con người khi thực sự bí. Cách này phát huy tốt nhất trong codebase có cấu trúc tốt, với các mẫu lặp lại đóng vai trò khuôn đúc và tiêu chí kiểm chứng rõ ràng.

Nhà máy rất hiệu quả với những việc như thêm endpoint CRUD thứ mười một hay xử lý hàng trăm lỗi nhỏ. Phán đoán vẫn tồn tại, chỉ là được chuyển lên thượng nguồn hoặc nhúng vào pipeline. Việc có thể nhúng và tự động hóa bao nhiêu vẫn còn bỏ ngỏ, nhưng nhiều khả năng thiết lập nhà máy để cho ra kết quả đáng tin cậy sẽ là phần lớn công việc kỹ thuật trong thời gian tới.

Nghệ nhân hay nhà máy?

Trong cả hai trường hợp, phán đoán của con người vẫn là bánh lái. Khác biệt nằm ở thời điểm áp dụng:

• Nghệ nhân áp dụng ở mọi vòng lặp — tuyệt vời để khám phá ý tưởng và tinh chỉnh các tính năng cần "đúng cảm giác".
• Nhà máy áp dụng ở khâu đầu, khi xây pipeline, và càng ít càng tốt trong lúc vòng lặp chạy.

Cả hai đều không thể bỏ qua phán đoán. Nhiều người lầm tưởng nhà máy chỉ thuộc về codebase doanh nghiệp lớn, còn nghệ nhân là các indie hacker ngồi bên bãi biển Thái Lan. Thực tế, hai cách này bổ trợ cho nhau và nhiều quy trình thực tế là sự pha trộn.

Sản phẩm lớn, lâu năm cần sự nghệ nhân để giải bài toán mới hoặc thêm tính năng phải thật "đúng". Ngược lại, cả lập trình viên độc lập cũng sẽ muốn vận hành nhà máy cho những phần nhàm chán, lặp đi lặp lại — và để đạt quy mô mà trước đây một người khó tưởng tượng nổi.

Điểm mấu chốt là chọn đúng cách cho đúng bài toán. Hóa ra đó chính là điều kỹ thuật phần mềm vẫn luôn hướng tới.

Điều này có ý nghĩa gì với lập trình viên Việt Nam?

Với cộng đồng lập trình viên Việt Nam — nơi nhiều người vừa làm outsource vừa tự phát triển sản phẩm — vật liệu mới này mở ra cơ hội đáng kể. Các nhóm nhỏ có thể dựng thử nghiệm sản phẩm nhanh hơn nhiều lần, trong khi những codebase dự án truyền thống có thể tận dụng nhà máy để tự động hóa các tác vụ bảo trì và sửa lỗi lặp lại.

Nhưng bài học cốt lõi vẫn là: tốc độ không thay thế được phán đoán. Đầu tư vào kiến trúc, bộ test và tiêu chí rõ ràng chính là cách để "nung" đất sét thành sản phẩm bền vững thay vì một mớ hỗn độn.

Chúng ta đang cầm trong tay một vật liệu mới. Mã nguồn giờ là đất sét. Câu hỏi còn lại là: chúng ta sẽ xây gì từ nó?