Bảo trì app tạo bằng AI: điều không ai kể với bạn về tuần thứ hai

Cuối tuần đầu tiên với Proyecta, bạn ra mắt một thứ thật. Nó chạy được. Người dùng của bạn (hoặc đội của bạn, hoặc chính bạn trong tương lai) bắt đầu dùng nó. Rồi đến thứ Hai và một khách hàng gửi email: “Thêm một cái dropdown để lọc theo khu vực được không?”

Chào mừng đến với việc bảo trì. Đây là phần của việc xây app bằng AI mà chẳng ai nói tới, và là phần mà phần lớn dự án hoặc trở thành một tài sản lâu dài hoặc lặng lẽ rơi khỏi vách đá. Tin tốt là bảo trì một app tạo bằng AI là một trải nghiệm khác với bảo trì code truyền thống. Tin thật thà là “khác” không có nghĩa là “miễn phí”.

Bảo trì thực sự có nghĩa là gì

Khi các lập trình viên chuyên nghiệp nói “bảo trì”, họ ý nói đến bốn việc, đại khái:

1. Thêm các tính năng nhỏ mà người ta xin sau khi ra mắt.
2. Sửa những thứ bị hỏng hoặc sai ngay từ đầu.
3. Theo kịp những thay đổi bên ngoài app của bạn — một nhà cung cấp thanh toán cập nhật API của họ, một trình duyệt mới ra mắt, hình dạng dữ liệu của bạn thay đổi.
4. Dọn dẹp để cơ sở mã không từ từ biến thành một đầm lầy.

Với một app tạo bằng AI, cả bốn việc vẫn xảy ra. Cái thay đổi là ai làm chúng và công việc đó cảm giác thế nào.

Tin tốt: bạn có thể trò chuyện với nó

Đây là phần mà chẳng ai nói cho bạn hồi bạn còn copy-paste code từ các hướng dẫn cũ. Với một công cụ tạo app bằng AI, bạn bảo trì app theo đúng cách bạn đã xây nó: bằng cách mô tả điều bạn muốn.

Một ví dụ thật. Một nhà sáng lập chúng tôi biết đã xây một CRM nhỏ cho hoạt động huấn luyện của cô — khách hàng, các buổi, theo dõi thanh toán, đủ cả. Ba tuần sau khi ra mắt, một khách hàng nhắc rằng họ rất muốn xem mình đã làm bao nhiêu buổi trong năm. Cô mở app lên, nói: “Thêm một bộ đếm ‘số buổi trong năm nay’ vào từng thẻ khách hàng, lấy từ bảng buổi học nơi ngày nằm trong năm 2026.” Mười hai phút sau, nó đã chạy. Cô quay lại với việc huấn luyện.

Câu chuyện đó nghe bình thường cho đến khi bạn nhớ ra giải pháp thay thế: nhắn một freelancer, đợi hai ngày, trả 300 đô, rà soát một PR mà cô không hiểu hết, và cầu mong không có gì khác hỏng theo. Vòng lặp bảo trì nhanh hơn không phải vì AI thông minh hơn freelancer. Nó nhanh hơn vì vòng lặp có ít con người hơn ở trong đó.

Tin khó hơn: những thứ nhỏ tích tụ lại

Đây là phần khiến người ta vấp. App tạo bằng AI trông dễ thay đổi vì việc thêm thắt thì dễ. Cái không dễ là giữ cho toàn bộ thứ đó mạch lạc khi nó lớn lên.

Vài kiểu chúng tôi thấy hay đi chệch:

• Sự rối rắm vô tình. Bạn yêu cầu “thêm một trường giảm giá vào phần thanh toán”. Sáu lần chỉnh sửa sau, logic giảm giá nằm ở ba chỗ, và chỉ một trong số đó đúng. Chưa có gì hỏng, nhưng thay đổi tiếp theo sẽ rối tung.
• Yêu cầu bị quên. Bạn thêm “miễn phí ship cho đơn trên 50 đô” hồi tháng Ba. Đến tháng Năm, bạn yêu cầu AI “làm lại phần thanh toán để hỗ trợ thẻ quà tặng”. Nó làm. Quy tắc miễn phí ship biến mất. Hai tuần không ai để ý.
• Sự trôi dạt. App của bạn khởi đầu như “một công cụ cho riêng tôi”. Giờ đội của bạn dùng nó. Mô hình tư duy mà AI đang dựa vào vẫn là “cho riêng tôi”, vì đó là điều bạn nói ban đầu. Các tính năng mới có cảm giác lệch lạc một cách kỳ lạ, và bạn không chỉ ra được vì sao.

Không cái nào trong số này là thất bại của các công cụ tạo app bằng AI. Chúng là thất bại của trí nhớ và ngữ cảnh chung — đúng những vấn đề mà một đội lập trình viên con người gặp phải, chỉ ở một hình dạng khác.

Cách chuẩn bị cho mình

Những đội làm tốt việc bảo trì chia sẻ vài thói quen. Phần lớn không phải thói quen kỹ thuật. Chúng là thói quen về cách bạn mô tả app của mình là gì và điều gì đã thay đổi.

Giữ một tài liệu “app này là gì”. Một trang thôi. Đối tượng, mục tiêu, các quy tắc (“miễn phí ship cho đơn trên 50 đô”, “chúng tôi không bao giờ email người dùng vào Chủ nhật”, “số điện thoại là khóa chính, không phải email”). Khi bạn yêu cầu AI thay đổi điều gì, hãy dán quy tắc liên quan vào lời mô tả. Bạn không qua mặt trí thông minh của AI; bạn đang cấp cho nó ngữ cảnh mà nó không thể nào nhớ nổi.

Mô tả thay đổi theo hành vi, không phải theo code. “Tôi muốn người dùng thấy bộ lọc khu vực của họ được nhớ giữa các phiên” là một yêu cầu tốt hơn nhiều so với “thêm localStorage vào bộ lọc”. Câu đầu mô tả điều bạn muốn; câu sau chỉ định một trong mười lăm cách để làm, và có lẽ không phải cách tốt nhất.

Thay đổi từng cái một. Hai thay đổi trong một lời mô tả nghĩa là một trong số đó có thể âm thầm thất bại mà bạn không biết là cái nào. Cách nhanh nhất để bảo trì một app AI là giữ cho mỗi lần lặp đủ nhỏ để bạn có thể nhận ra ngay, chỉ bằng một cái liếc, rằng kết quả có đúng hay không.

Nhìn xem cái gì đã thay đổi. Phần lớn công cụ tạo app bằng AI cho bạn xem bản xem trước. Hãy dùng nó. Ba mươi giây bạn bỏ ra để bấm thử quanh đó xác nhận tính năng mới chạy được và các tính năng cũ vẫn còn chạy là khoản bảo hiểm rẻ nhất bạn sẽ mua trong năm nay.

Những gì bạn không thể làm (và có lẽ cũng không nên)

Có một cám dỗ, một khi đã xây app bằng AI, là nghĩ rằng nó cũng có thể vận hành app thay bạn. Nó không thể, và khoảng cách là có thật:

• Nó sẽ không báo cho bạn khi có thứ gì đó âm thầm hỏng. Nhật ký, giám sát, lịch trực — đó vẫn là những mối lo riêng. Phần lớn công cụ tạo app bằng AI không theo dõi app trên môi trường thật của bạn theo cách một kỹ sư backend làm.
• Nó không biết về thế giới bên ngoài app của bạn. Nếu một nhà cung cấp thanh toán ngừng dùng một API, AI không biết cho đến khi bạn nói. Hãy đăng ký nhận thông báo thay đổi của các nhà cung cấp. Hãy đọc email của bạn.
• Nó không thể ra quyết định về sản phẩm thay bạn. Có nên thêm một tính năng hay không, chọn đánh đổi nào, người dùng thật sự muốn gì — đó vẫn là việc của bạn. AI là một đôi tay rất nhanh; còn bộ não là của bạn.

Bức tranh thực tế

Sau sáu tháng với một app tạo bằng AI, phần lớn người chúng tôi nói chuyện cùng đều rơi vào đâu đó như thế này: họ bỏ ra cỡ hai đến bốn giờ một tháng cho các thay đổi, gần như toàn bộ là qua trò chuyện. Những đợt làm lại lớn mà họ từng sợ hãi — “tôi muốn thêm cả một mục mới” — có cảm giác như một buổi chiều làm tốt. Những thứ nhàm chán — “định dạng ngày bị sai ở bản xuất” — có cảm giác như một lời mô tả tốt.

Cái họ không phải gánh là tiếng ồn nền liên tục của một cơ sở mã truyền thống: cập nhật phụ thuộc, di trú framework, vá lỗi bảo mật, cấu hình build. Tiếng ồn đó đã được nền tảng hấp thụ hết. Bạn trả tiền cho nền tảng để nó lo việc đó, và đó là một thương vụ tốt hơn nhiều so với trả tiền cho một lập trình viên để lo.

Nếu bạn sắp xây app đầu tiên của mình, bài viết về app đầu tiên bạn tạo bằng AI nên là gì đáng đọc trước khi bắt đầu. Và nếu bạn đã đi được vài tuần và đang cảm nhận được một vài kiểu mẫu kể trên, thì điều đó là bình thường. Hãy viết tài liệu “app này là gì” của bạn vào cuối tuần này. Bạn-trong-tương-lai, ba tháng nữa, lúc yêu cầu một bảng điều khiển mới, sẽ rất mừng vì bạn đã làm.