Từ Prompt-Driven Development đến Contract-Driven Development
Khi AI coding mới bùng lên, một phong cách phát triển phần mềm xuất hiện rất nhanh và rất tự nhiên: viết prompt, nhận code, chỉnh một chút rồi commit. Cảm giác này cực kỳ hấp dẫn. Nó làm nhiều developer có cảm giác như vừa mở khóa chế độ tăng tốc cho nghề nghiệp của mình. Câu chuyện từ “ý tưởng” sang “code chạy được” bỗng ngắn lại đáng kể.
Cách làm đó được gọi khá hợp lý là prompt-driven development. Tức là prompt đóng vai trò điểm khởi đầu chính của quá trình tạo phần mềm. Viết prompt tốt, AI sẽ sinh ra code tốt hơn. Sửa prompt thêm một chút, code thay đổi theo. Ở giai đoạn prototype hoặc khi khám phá ý tưởng, đây là một workflow rất mạnh.
Nhưng khi dự án lớn dần, nhiều team bắt đầu nhận ra rằng việc để prompt trở thành “nguồn chân lý ngầm” của hệ thống có một số giới hạn. Lúc đó một workflow khác dần xuất hiện: contract-driven development. Thay vì bắt đầu từ prompt để tạo code trực tiếp, team bắt đầu từ contract để mô tả hệ thống một cách có cấu trúc, rồi để compiler hoặc generator sinh code từ đó.
Nói ngắn gọn, đây không chỉ là thay đổi công cụ. Đây là thay đổi điểm bắt đầu của engineering workflow.
Prompt-driven development là gì?
Prompt-driven development là cách phát triển phần mềm bằng cách mô tả yêu cầu cho AI và để AI tạo code trực tiếp từ mô tả đó. Ví dụ rất quen thuộc:
Tạo API quản lý user bằng Node.js, có create, list, update và delete.
AI sẽ có thể sinh ra:
- controller
- service
- model
- validation
- test skeleton
Developer sau đó chỉnh sửa một chút rồi commit. Workflow này nhanh, tiện và rất hợp với lúc ta chưa chắc mình muốn hệ thống trông như thế nào. Nó tối ưu cho việc khám phá. Prompt tốt có thể thay cho hàng loạt thao tác khởi tạo thủ công. Với nhiều người, đây là lần đầu tiên cảm giác “mô tả bằng lời rồi ra code” trở nên thực dụng đến vậy.
Vì sao prompt-driven development hấp dẫn đến thế?
Bởi vì nó giảm ma sát ban đầu cực mạnh. Bạn không cần ngồi dựng từng file từ đầu. Bạn không cần nhớ hết boilerplate. Bạn không cần mất nửa ngày cho một tính năng nhỏ chỉ để tạo khung. AI làm rất nhiều phần công việc mở đầu một cách nhanh chóng. Điều này mang lại ít nhất bốn lợi ích rõ rệt:
- prototype ra nhanh
- ý tưởng được kiểm chứng sớm
- developer tiết kiệm thời gian khởi tạo
- rào cản thử nghiệm giải pháp mới thấp hơn
Nói vui một chút, prompt-driven development giống như có một thực tập sinh siêu nhanh và không biết mệt, chỉ cần bạn mô tả đủ rõ thì bạn đã có bản nháp chạy được rất sớm.
Những giới hạn của prompt-driven development khi dự án lớn dần
Khi codebase nhỏ, workflow này hoạt động khá ổn. Nhưng khi hệ thống lớn dần, vài vấn đề bắt đầu xuất hiện và thường xuất hiện cùng lúc.
Git diff lớn
AI có thể thay đổi nhiều file để hoàn thành một task. Chỉ một thay đổi business nhỏ nhưng diff lan qua controller, service, DTO, test, helper và đôi khi cả những chỗ không thật sự cần thiết. Pull request trở nên khó review hơn rất nhiều.
Code structure không nhất quán
Mỗi prompt có thể tạo ra một style code khác nhau. Prompt hôm nay sinh ra structure kiểu A, prompt mai sinh ra kiểu B. Nếu team không có kỷ luật kiến trúc đủ mạnh, codebase sẽ dần trở nên khó đọc và khó đoán hơn.
Architecture drift
Khi AI chỉnh sửa code trực tiếp qua nhiều vòng lặp, kiến trúc hệ thống có thể thay đổi theo thời gian mà không ai thực sự chủ động thiết kế sự thay đổi đó. Business logic bắt đầu rò sang sai layer, naming dần lệch nhau, abstraction mọc theo lịch sử chứ không theo ý đồ.
Nguồn chân lý bị phân tán
Đây là điểm ít được nói hơn. Trong prompt-driven development, ý định hệ thống thường nằm một phần ở prompt, một phần ở code AI sinh ra, một phần ở các sửa tay sau đó. Tức là nguồn chân lý bị tản mát. Đến lúc cần hiểu vì sao hệ thống trông như hiện tại, team phải lần lại lịch sử rất mệt.
Contract-driven development là gì?
Contract-driven development thay đổi cách bắt đầu viết code. Thay vì bắt đầu bằng prompt để tạo code trực tiếp, developer bắt đầu bằng contract. Contract mô tả hệ thống ở mức có cấu trúc hơn, ví dụ:
- API và endpoint
- data schema
- workflow hoặc interaction shape
- error model
- auth hoặc policy metadata
Sau đó code được sinh từ contract.
contract → validate → compile → code
Điểm quan trọng là contract trở thành nơi mô tả sự thay đổi chính của hệ thống. Code chỉ là đầu ra ổn định của quá trình đó.
Sự khác nhau giữa hai workflow
| Tiêu chí | Prompt-Driven | Contract-Driven |
|---|---|---|
| Bắt đầu từ | Prompt | Contract |
| Cách tạo code | AI sinh trực tiếp | Compiler hoặc generator sinh code |
| Nguồn chân lý | Phân tán giữa prompt và implementation | Tập trung ở contract |
| Git diff | Thường lớn | Nhỏ hơn và rõ hơn |
| Phù hợp | Khám phá, prototype | Production, scale dài hạn |
Vai trò của AI trong contract-driven development
AI vẫn đóng vai trò rất quan trọng. Nhưng thay vì viết code trực tiếp vào repo ở quy mô lớn, AI giúp:
- thiết kế API
- viết contract
- mô tả workflow
- gợi ý schema và error case
- soát consistency giữa các phần mô tả
Code sau đó được sinh ra bởi compiler hoặc generator. Điều này giữ được hai lợi ích cùng lúc: tốc độ tư duy và mô tả của AI, cùng với sự ổn định của đầu ra do compiler bảo đảm. Đây là lý do ngày càng nhiều team backend không muốn bỏ AI, mà chỉ muốn đổi chỗ đứng của AI trong pipeline.
Vì sao nhiều team chuyển từ prompt-driven sang contract-driven?
Bởi vì khi hệ thống bắt đầu có tuổi đời, những bài toán quan trọng nhất không còn là “code ra nhanh được không”, mà là:
- có review nổi không
- có giữ được kiến trúc không
- có onboarding người mới được không
- có rollback và refactor an toàn không
- có dùng AI mà không tăng nợ kỹ thuật quá nhanh không
Prompt-driven development trả lời rất tốt câu hỏi về tốc độ khởi động. Contract-driven development trả lời tốt hơn các câu hỏi về tính bền vững. Khi dự án lớn dần, team buộc phải quan tâm nhiều hơn tới tính bền vững đó.
Có phải prompt-driven development là sai?
Không hề. Nó cực kỳ hữu ích trong giai đoạn đầu, khi ta cần khám phá nhanh, thử nhiều hướng, chưa chắc boundary nào là đúng và chưa muốn đầu tư formalism quá sớm. Vấn đề chỉ xảy ra khi team mang workflow tối ưu cho khám phá sang dùng nguyên xi cho production lâu dài.
Đây là chỗ nhiều đội bị nhầm. Cái giúp ta khởi động nhanh chưa chắc là cái giúp ta scale khỏe. Prompt-driven development rất giỏi làm mồi lửa. Contract-driven development giỏi xây hệ thống bền hơn quanh ngọn lửa đó.
Một lộ trình chuyển đổi thực dụng
Đa số team không nhảy từ prompt-driven sang contract-driven trong một đêm. Họ thường đi theo lộ trình mềm hơn:
- Dùng prompt để khám phá giải pháp và nhanh chóng tạo bản nháp.
- Chọn những pattern lặp lại nhiều nhất trong repo.
- Đưa các pattern đó vào contract hoặc DSL.
- Dùng generator sinh phần code lặp lại từ contract.
- Giữ business logic đặc thù ở phần code viết tay.
Cách làm này giúp team không phải đập bỏ mọi thứ. Họ chỉ chuyển dần nguồn chân lý từ prompt rời rạc sang contract có cấu trúc. Nói kiểu đời thường: không phải đổi xe giữa đường, mà là thay dần các bộ phận quan trọng để xe chạy ổn hơn.
Kết luận
Từ prompt-driven development đến contract-driven development là một bước trưởng thành rất tự nhiên trong thời đại AI coding. Prompt-driven giúp developer đi nhanh ở giai đoạn khám phá. Contract-driven giúp hệ thống ổn định hơn khi dự án lớn dần và bước vào production nghiêm túc.
Nhiều team hiệu quả nhất hiện nay không chọn một trong hai theo kiểu trắng đen. Họ kết hợp cả hai: dùng prompt để khám phá ý tưởng, nhưng dùng contract để xây cấu trúc có thể sống lâu trong repository. Đó là cách vừa giữ được tốc độ, vừa không biến repo thành một bộ sưu tập của những prompt đẹp mà khó duy trì. Nói theo kiểu hơi CTO một chút: khởi động nhanh là tốt, nhưng đi đường dài mới là chỗ thể hiện bản lĩnh của workflow.
Một câu rất đáng nhớ khi chọn workflow
Prompt-driven development tối ưu cho việc trả lời câu hỏi “có thể làm được không?”. Contract-driven development tối ưu cho câu hỏi “làm thế nào để thứ này sống khỏe trong production?”. Nếu team nhớ được hai câu hỏi này, việc chọn workflow cho từng giai đoạn sẽ sáng sủa hơn rất nhiều.
Không phải chuyển đổi để bớt dùng AI, mà để dùng AI đúng chỗ
Nhiều người nghe contract-driven development rồi nghĩ team đang “quay lưng với AI”. Thực ra ngược lại. Đây là cách dùng AI trưởng thành hơn: dùng AI ở tầng mô tả, nơi nó rất mạnh, và giao phần tạo output ổn định cho compiler hoặc generator. Chuyển workflow không phải để chậm lại. Chuyển workflow là để đi nhanh mà ít để lại hiện trường hơn.
Chọn workflow theo giai đoạn, không theo niềm tin
Team mạnh thường không tôn thờ prompt hay contract như tôn giáo. Họ chọn công cụ theo giai đoạn. Cần khám phá nhanh thì dùng prompt-driven. Cần chuẩn hóa và scale production thì chuyển dần sang contract-driven. Khi nhìn workflow như một phổ liên tục thay vì hai phe đối lập, quyết định kỹ thuật sẽ bớt cảm tính hơn rất nhiều.
Điểm mấu chốt để không chuyển đổi nửa vời
Nếu đã bắt đầu đi theo hướng contract-driven, team nên thật sự xem contract là nơi cần review nghiêm túc. Nhiều đội thất bại không phải vì contract-driven development tệ, mà vì họ vẫn review contract như review tài liệu phụ. Trong khi đó, implementation lại vẫn bị soi quá kỹ ở phần lặp. Đảo đúng trọng tâm review là một bước nhỏ nhưng tác động rất lớn đến hiệu quả của cả workflow.
Khi team hiểu điều đó, việc chuyển từ prompt-driven sang contract-driven sẽ không còn mang cảm giác bỏ cái mới để quay về cái cũ. Nó mang cảm giác lớn lên trong cách dùng cái mới.
Và khi một workflow vừa giữ được tốc độ khám phá, vừa bảo vệ được production, đó thường là dấu hiệu bạn đang đi đúng hướng.
Khám phá bằng prompt, ổn định bằng contract. Nhiều team khỏe nhất hiện nay đang đi đúng công thức rất thực tế đó.
Khi chọn đúng workflow cho đúng giai đoạn, AI không còn là nguồn gây tranh cãi quá nhiều. Nó trở thành công cụ mà ai cũng biết nên dùng ở đâu để tạo ra nhiều giá trị nhất.
Nói cách khác, trưởng thành trong AI coding không phải bỏ prompt. Đó là biết khi nào prompt nên nhường vai chính cho contract.
Đó cũng là lúc AI không còn là món tăng tốc nhất thời, mà trở thành một phần trưởng thành của quy trình phát triển phần mềm.
Một kết luận rất thực dụng cho team backend
Nếu team của bạn còn đang ở giai đoạn cần thử thật nhanh, prompt-driven development vẫn là đồng minh rất mạnh. Nhưng nếu repo đã bắt đầu có tuổi, có nhiều người cùng sửa và mỗi thay đổi đều cần sống khỏe qua code review, QA và production, thì contract-driven development gần như là bước tiến tự nhiên tiếp theo. Đó không phải đổi phe. Đó là nâng cấp cách làm việc.
