Quy trình phát triển phần mềm hỗ trợ bởi AI: Tăng tốc mà không đánh mất sự rõ ràng

Bạn mở một đoạn chat, mô tả những gì bạn muốn, lặp lại trên đầu ra và triển khai một thứ gì đó hoạt động hơn kém. Nó cảm thấy rất nhanh.

Về mặt kỹ thuật, các tính năng hoạt động. Nhưng không ai, kể cả tôi, thực sự hiểu rõ những gì vừa được tạo ra. Có những trường hợp ngoại lệ không ai nghĩ đến việc xử lý, kiến trúc có vẻ hợp lý vào thời điểm đó nhưng không tồn tại khi thêm tính năng mới. Một cảm giác ngày càng tăng rằng tôi đang xây dựng nhanh hơn nhưng lại hiểu ít hơn.

Vấn đề tôi liên tục gặp phải là: làm thế nào để có được lợi ích về tốc độ từ sự hỗ trợ của AI mà không làm mất đi sự rõ ràng và tính chủ định giúp phần mềm có thể bảo trì được?

Câu trả lời ngắn gọn là công việc thực sự diễn ra trước khi viết mã bắt đầu.

Ý tưởng cốt lõi: Tư duy bằng văn viết, không phải bằng mã

AI thực sự giỏi ở đâu? Ở việc triển khai (implementation). Nó thực sự kém ở đâu? Ở việc xác định bạn thực sự muốn gì, bắt gặp những giả định bạn quên làm rõ, và cho bạn biết khi mô hình tư duy của bạn về vấn đề đang sai.

Đó là công việc của bạn. Nó sẽ luôn là công việc của bạn.

Sự thay đổi giá trị nhất tôi thực hiện là coi mọi tính năng là một vấn đề tư duy trước và một vấn đề triển khai sau. Quy trình này được thiết kế để ép buộc tư duy đó xảy ra trước khi bất kỳ dòng mã nào được viết, và sử dụng AI để kiểm tra áp lực (stress-test) nó, chứ không phải để bỏ qua nó.

Quy trình này đã được điều chỉnh để làm việc với tôi từ các kỹ năng (skills) của Mark Pocock.

Quy trình làm việc

Bước 1: Kế hoạch tự do (Free-form plan)

Mọi thứ bắt đầu với một tài liệu do chính tôi viết, bằng ngôn ngữ bình thường, không có cấu trúc bắt buộc. Tôi mô tả vấn đề, tư duy ban đầu của tôi về giải pháp, các ràng buộc tôi biết đến, và những điều tôi chưa chắc chắn. Đây không phải là sản phẩm giao (deliverable), không ai đọc nó ngoại trừ tôi. Mục đích duy nhất của nó là đưa tư duy ra khỏi đầu tôi và vào một dạng mà tôi có thể kiểm tra.

Chất lượng của mọi thứ ở hạ nguồn phụ thuộc hoàn toàn vào chất lượng của bước này. Một kế hoạch mơ hồ tạo ra một PRD mơ hồ, tạo ra các vấn đề (issues) mơ hồ, tạo ra mã chạy về mặt kỹ thuật nhưng không làm những gì bạn có ý định.

Bước 2: PRD thông qua write-a-prd

Kế hoạch tự do trở thành đầu vào cho một quy trình phỏng vấn có cấu trúc. Kỹ năng (skill) này khám phá codebase để hiểu trạng thái hiện tại, sau đó phỏng vấn tôi không ngừng nghỉ về mọi khía cạnh của kế hoạch, đi xuống từng nhánh của cây thiết kế, giải quyết các phụ thuộc giữa các quyết định từng cái một.

Đây là bước nơi những ý tưởng tồi bị bắt gặp. Không phải vì AI thông minh hơn tôi, mà vì việc bị buộc phải trả lời các câu hỏi cụ thể về kế hoạch của chính bạn tiết lộ những nơi bạn đang "vung tay". "Nó hoạt động như thế nào khi người dùng chưa được xác thực?" "Chuyện gì xảy ra nếu thao tác này thất bại một phần?" "Bạn nói điều này thay thế tính năng hiện có, chuyện gì xảy ra với những người dùng phụ thuộc vào hành vi hiện tại?"

Đầu ra là một tệp PRD có cấu trúc chứa tuyên bố vấn đề, mô tả giải pháp, danh sách mở rộng các câu chuyện người dùng (user stories), quyết định triển khai (mô-đun, giao diện, thay đổi lược đồ, hợp đồng API), thiết kế mô-đun, quyết định kiểm thử và các mục rõ ràng nằm ngoài phạm vi. Mọi thứ đều rõ ràng.

Các câu chuyện người dùng là xương sống của mọi thứ theo sau. Chúng cần đủ cụ thể để tiêu chí chấp nhận có thể được dẫn xuất từ chúng một cách rõ ràng ở hạ nguồn, không phải ở giai đoạn này, mà khi phạm vi được xác định ở cấp độ vấn đề.

Bước 3: Các vấn đề (Issues) thông qua prd-to-issues

PRD trở thành một tập hợp các vấn đề sử dụng các lát cắt dọc (vertical slices), những viên đạn tracer xuyên qua mọi tầng tích hợp từ đầu đến cuối thay vì các lát cắt ngang của một lớp đơn lẻ. Một lát cắt chỉ chạm vào cơ sở dữ liệu, hoặc chỉ chạm vào UI, không phải là một lát cắt hợp lệ. Mỗi vấn đề nên cung cấp một đường hẹp nhưng hoàn chỉnh có thể demo hoặc xác minh độc lập.

Mỗi vấn đề được phân loại là AFK (AI có thể triển khai và thay đổi có thể được hợp nhất mà không cần tương tác của con người) hoặc HITL (cần quyết định của con người tại một số điểm trong quá trình triển khai). Ưu tiên AFK hơn HITL bất cứ nơi nào có thể giúp công việc tiếp diễn mà không trở thành nút thắt cổ chai đối với sự chú ý của tôi.

Trước khi bất kỳ thứ gì được viết, kỹ năng sẽ trình bày sự phân chia đề xuất và hỏi: độ chi tiết có cảm thấy đúng không, các mối quan hệ phụ thuộc có chính xác không, có gì nên được hợp nhất hoặc chia tách không? Các vấn đề được viết theo thứ tự phụ thuộc để các tham chiếu chéo giữa chúng sử dụng số thực.

Mỗi vấn đề chứa mô tả ngắn gọn về hành vi từ đầu đến cuối, một phần "cách xác minh" mô tả chính xác cách xác nhận lát cắt hoàn thành, tiêu chí chấp nhận ở định dạng Được/Khi/Thì (Given/When/Then) bao gồm cả các trường hợp lỗi, danh sách các chặn (blockers), và tham chiếu ngược lại các câu chuyện người dùng mà nó giải quyết.

Mọi thứ sống trong các tệp. Tôi làm việc trên các nền tảng khác nhau, đôi khi là GitHub, đôi khi là GitLab, và việc giữ quy trình dựa trên tệp có nghĩa là nó không phụ thuộc vào bất kỳ công cụ cụ thể nào.

Bước 4: Các nhiệm vụ (Tasks) thông qua issues-to-tasks

Mỗi vấn đề được chia nhỏ thành các nhiệm vụ cụ thể, có thứ tự, một nhiệm vụ cho mỗi phiên AI tập trung. Ràng buộc này là có chủ đích: nếu một nhiệm vụ không thể hoàn thành trong một phiên, nó quá lớn.

Kỹ năng khám phá các phần cụ thể của codebase bị ảnh hưởng bởi vấn đề, xác định các mẫu hiện có để tuân theo và tạo ra danh sách nhiệm vụ với các loại (WRITE, TEST, MIGRATE, CONFIG, REVIEW), đầu ra rõ ràng và thứ tự phụ thuộc. Lược đồ trước logic, logic trước API, API trước UI, kiểm thử xen kẽ thay vì đóng gói vào cuối.

Quyết định thiết kế chính trong các mô tả nhiệm vụ: chúng được viết dưới dạng hướng dẫn cho AI sẽ thực thi chúng, không phải dưới dạng ghi chú cho nhà phát triển con người. Mỗi nhiệm vụ chỉ định các tệp nào cần chạm vào, mẫu hiện có nào cần tuân theo và đầu ra trông như thế nào khi hoàn thành. Không có đoạn mã, chỉ có ý định, không phải triển khai.

Bước 5: Chuyển giao sang mã

Mỗi mô tả nhiệm vụ là một lời nhắc tự chứa (self-contained prompt). Khi tôi sẵn sàng triển khai một nhiệm vụ, tôi mở một phiên mới và dán mô tả nhiệm vụ cùng với vấn đề cha làm ngữ cảnh. Mô tả nhiệm vụ được viết cho mục đích này, nó chỉ định phạm vi, tham chiếu các tệp và mẫu đúng và xác định xong trông như thế nào.

Ngữ cảnh mới cho mỗi nhiệm vụ là có chủ đích. Các phiên dài với ngữ cảnh tích lũy có xu hướng trôi dạt: mô hình bắt đầu đưa ra quyết định dựa trên những gì nó đã làm thay vì những gì nhiệm vụ yêu cầu. Bắt đầu sạch sẽ với một nhiệm vụ có phạm vi tốt nhất quán tạo ra đầu ra tốt hơn nhiều so với việc tiếp tục một phiên dài.

Đối với các nhiệm vụ REVIEW, những nhiệm vụ được gắn cờ cần quyết định của con người, tôi dừng lại, đưa ra quyết định, cập nhật tệp nhiệm vụ với kết quả và tiếp tục. Đây là những khoảnh khắc nơi quy trình chứng minh giá trị của nó: quyết định được đưa ra một cách có chủ đích, trong ngữ cảnh, không bị chôn vùi trong một lần tạo dài.

Bước 6: Review mã thông qua code-review

Mỗi PR đi qua một quy trình review sáu lượt có cấu trúc trước khi hợp nhất. Các lượt này bao gồm lỗi logic, thứ tự thao tác, các thực hành xấu, bảo mật, chuỗi và giá trị "ma thuật" (magic strings/values) và cải tiến mẫu.

Thứ tự thao tác xứng đáng được chú ý đặc biệt trong mã do AI tạo ra. Các mô hình có xu hướng tạo ra mã làm những điều đúng nhưng đôi khi theo sai trình tự: gửi thông báo trước khi cam kết giao dịch, viết nhật ký kiểm tra sau khi hành động nó nên ghi lại, thay đổi trạng thái trước khi xác thực đầu vào. Những lỗi này dễ bỏ sót trong review vì mã trông đúng khi nhìn lướt.

Quy trình review chạy trên một tệp hoặc diff, không phải trên toàn bộ tính năng. Phạm vi được giữ hẹp một cách có chủ đích, bắt gặp vấn đề ở cấp độ PR rẻ hơn nhiều so với việc tìm thấy chúng sau này.

Bước 7: Kiểm toán cuối cùng thông qua final-audit

Ở cuối một tính năng, một cuộc kiểm toán cắt ngang nhìn vào những thứ chỉ có thể được đánh giá trên toàn bộ việc triển khai. Không phải các lỗi riêng lẻ, những cái đó nên đã bị bắt ở mỗi PR, mà là các vấn đề hệ thống: sự không nhất quán giữa các mô-đun, các mẫu được giới thiệu sớm và được sao chép sai ở khắp nơi, các giả định bảo mật giữ được khi cô lập nhưng phá vỡ trên toàn bộ diện tích bề mặt.

Cuộc kiểm toán đọc toàn bộ việc triển khai trước khi gắn cờ bất kỳ thứ gì, đó là điểm mấu chốt. Nó nhóm các phát hiện theo mức độ nghiêm trọng, đưa ra phán quyết tổng thể rõ ràng về việc tính năng có an toàn để để lại trong sản xuất hay không và yêu cầu phê duyệt trước khi thực hiện bất kỳ thay đổi nào. Các sửa chữa không giám sát trên mã đã hợp nhất rủi ro hơn nhiều so với các sửa chữa được thực hiện trong quá trình phát triển.

Quy trình này không phải là gì

Nó không nhanh để thiết lập. Các bước lập kế hoạch và PRD mất thời gian thực, và cám dỗ để bỏ qua chúng để ủng hộ việc đi thẳng vào mã là liên tục. Quy trình chỉ có lãi nếu bạn thực sự tin rằng thời gian tư duy trước khi viết mã rẻ hơn thời gian gỡ lỗi sau khi viết mã.

Nó cũng không phải là sự thay thế cho phán đoán kỹ thuật. AI sẽ đề xuất những điều hợp lý ở mỗi bước mà sai với tình huống cụ thể của bạn. Các bước review, nơi bạn đánh giá sự phân chia trước khi bất kỳ thứ gì được tạo ra, tồn tại chính xác vì đầu ra của AI cần được xác thực chống lại kiến thức mà nó không có: các quy ước của nhóm bạn, hành vi thực tế của người dùng của bạn, các phần của codebase có độ phức tạp ẩn.

Nguyên tắc cơ bản

Mọi bước trong quy trình này có cùng cấu trúc: AI tạo ra một cái gì đó, bạn review nó với ngữ cảnh đầy đủ, sau đó nó được tạo ra. AI tăng tốc sản xuất. Review là của bạn, luôn luôn.

Quy trình được thiết kế để làm cho review đó hiệu quả nhất có thể, bằng cách đảm bảo rằng khi bạn đánh giá một vấn đề, bạn có một PRD để kiểm tra; khi bạn đánh giá một nhiệm vụ, bạn có một vấn đề để kiểm tra; và khi bạn review mã, bạn có tiêu chí chấp nhận để kiểm tra.

Nếu bạn đã đọc bài viết này đến hết, bạn ít nhất cũng xứng đáng được nhận một liên kết đến các kỹ năng của tôi.

Hãy kiểm tra kho GitHub của tôi.