Nhà sáng lập Nuanced: Tại sao 'Chế độ lập kế hoạch' trong lập trình đã lỗi thời?

Đầu năm nay, tôi tin rằng lập kế hoạch sẽ trở thành phần quan trọng nhất trong việc xây dựng phần mềm với AI.

Niềm tin của tôi vào ý tưởng này mạnh mẽ đến mức tôi đã xây dựng và ra mắt hẳn một ứng dụng lập trình trên máy tính xoay quanh nó. Nuanced được thúc đẩy bởi quan sát rằng AI đã làm tăng tốc độ và khối lượng tạo mã một cách triệt để, nhưng các giao diện hỗ trợ cho nhịp độ làm việc mới này vẫn chưa bắt kịp.

Cách tiếp cận lập kế hoạch của Nuanced đã thất bại, nhưng nó cũng cho tôi thấy rằng các chế độ lập kế hoạch (plan modes) nhìn chung không còn hữu ích như trước nữa. Trong lịch sử, các chế độ lập kế hoạch phục vụ hai mục đích: (1) chúng chỉ định các hướng dẫn đủ chính xác cho một tác nhân (agent), và (2) chúng giúp con người hiểu những gì họ đang xây dựng.

Tôi nghĩ mục #1 đang nhanh chóng trở nên lỗi thời khi các mô hình ngày càng tốt hơn. Tôi nghĩ mục #2 quan trọng hơn bao giờ hết, nhưng các chế độ lập kế hoạch lại là một sự trừu tượng hóa sai lầm cho mục đích này, đặc biệt là khi số lượng các tác nhân chạy song song mà chúng ta sử dụng ngày càng tăng.

Tại sao tôi xây dựng Nuanced

Sản phẩm mà tôi có động lực để xây dựng cuối cùng đã trả lời một câu hỏi mà tôi nghĩ vẫn còn phù hợp, và sẽ luôn phù hợp, đó là: làm thế nào để con người duy trì một mô hình tư duy mạch lạc về một hệ thống phần mềm trong khi máy móc đang thay đổi nó nhanh hơn mức con người có thể kiểm tra các thay đổi đó?

Các mô hình có thể viết hàng ngàn dòng mã trong vài phút, nghĩa là bạn sẽ phải gánh chịu một khối lượng công việc bảo trì khổng lồ trước khi kịp suy nghĩ thấu đáo về những gì mình đang xây dựng hoặc tại sao lại xây dựng nó. Điều này khiến việc suy luận về hành vi và gỡ lỗi các giả định sai lầm đã bị "cứng hóa" thành mã từ sớm trở nên khó khăn.

Mặc dù việc tạo mã dễ dàng theo cách này mang lại phần thưởng dopamine lớn hơn, nhưng nó lại làm lu mờ công việc khó khăn là hiểu tại sao việc xây dựng một thứ gì đó lại quan trọng, liệu nó có thực sự quan trọng hay không, và đánh giá nghiêm ngặt các quyết định về sản phẩm, thiết kế và cơ sở hạ tầng. Tôi thường có một sản phẩm trước khi thực sự đưa ra bất kỳ quyết định sản phẩm nào một cách có ý thức. Nếu tôi mô tả kiến trúc không đầy đủ, tác nhân sẽ tự ý lấp đầy những khoảng trống đó, ngay cả khi cách nó phân chia ranh giới trừu tượng tạo ra vấn đề cho tôi sau này. Những hiểu lầm về hành vi và thiết kế dự định này sẽ lan truyền qua nhiều tệp tin nằm sâu dưới bề mặt của đoạn chat và rất dễ bị bỏ sót. Việc loay hoay tìm kiếm các vấn đề khó hiểu bên dưới bề mặt này cảm thấy kém hiệu quả hơn so với việc thiết kế mọi thứ đúng đắn ngay từ đầu.

Có điều gì đó trong trải nghiệm này khiến tôi cảm thấy mất kết nối về mặt tinh thần và giống như một thây ma, đặc biệt là khi các ứng dụng lập trình như Conductor và Codex cho phép chạy nhiều tác nhân song song hơn. Tôi cảm thấy mình không thể thực sự tập trung và đạt được chiều sâu hay sự hiểu biết về những gì mình đang làm như trước đây. Điều này cũng khiến tôi khó xác minh xem kết quả được tạo ra có chính xác hay không.

Không có dấu vết rõ ràng, dễ hiểu nào cho thấy mối liên hệ giữa yêu cầu của người dùng → quyết định của tác nhân → mã → hành vi sản phẩm. Điều này không có nghĩa là tôi muốn quay lại những ngày xưa cũ của việc nhìn vào các dòng mã hay các tệp tin. Tôi thực sự cảm thấy rằng việc suy luận về các ý tưởng bằng ngôn ngữ tự nhiên dễ dàng và hiệu quả hơn. Tôi muốn tự tin lướt trên mã nguồn mà không phải hy sinh sự hiểu biết của mình về cách hệ thống hoạt động.

Các chế độ lập kế hoạch hiện có không đủ tính cộng tác

Tôi cảm thấy rằng mặc dù các chế độ lập kế hoạch đã tồn tại, nhưng sự trừu tượng hóa phù hợp để lập kế hoạch tốt lại không tồn tại. Khi tôi luân phiên sử dụng Claude Code CLI, Conductor và cuối cùng là Codex khi nó ra mắt, tôi thấy mình tỉ mỉ định hình và gọt giũa các kế hoạch mà không có một nơi rõ ràng để lặp lại chúng. Tôi thường làm điều này bằng cách sử dụng chat rồi sao chép các phần của kế hoạch vào các tin nhắn mới để sửa đổi (trước khi có các tính năng chú thích của Codex). Quy trình cắt-dán này tạo cảm giác cồng kềnh và khiến việc xử lý một ý tưởng trong khi vẫn theo dõi kế hoạch hiện tại trở nên gian nan.

Tôi muốn cung cấp cho các kế hoạch của mình một ngôi nhà, gắn chúng vào quy trình làm việc tổng thể của mình và biến chúng từ những khối văn bản phù du biến mất vào lịch sử trò chuyện, thành một tài liệu sống động, bền vững. Tôi muốn biến chế độ lập kế hoạch thành một nguyên thủy hạng nhất (first-class primitive) hướng dẫn phát triển vì một vài lý do:

• Tôi cần suy nghĩ về những việc cần làm.
• Tôi cần đảm bảo mình mô tả nó đủ chính xác.
• Tôi cần hiểu những gì đã được thực hiện.
• Tôi cần hiểu khi nào mọi thứ đi chệch hướng và tại sao.

Xây dựng giấc mơ

Tôi đã nghĩ về quy trình làm việc mơ ước của mình và quyết định hiện thực hóa nó bằng cách mã hóa vào một sản phẩm. Nuanced cho phép bạn tạo các luồng (threads), trong đó mỗi luồng là một cuộc trò chuyện. Bạn sẽ thảo luận về những gì bạn muốn xây dựng, và hệ thống sẽ làm nổi bật các điểm mơ hồ và các quyết định cần sự đóng góp của bạn, và cùng nhau, bạn sẽ đi đến một kế hoạch bền vững trước khi bắt đầu triển khai. Sau đó, Nuanced sẽ thực hiện kế hoạch của bạn, đảm bảo rằng mã được tạo ra tuân thủ các yêu cầu của bạn. Tôi muốn một quy trình end-to-end bắt đầu từ ý định, xuyên suốt đến triển khai, đánh giá và xác minh. Tôi coi nó như một bộ phận giả cho trí tuệ con người (hoặc trí tuệ ADHD của tôi) hơn là chỉ đơn thuần là một ứng dụng lập trình khác, vì nó được thiết kế để hướng dẫn cũng như giúp tôi theo dõi những gì đang diễn ra.

Tại sao tôi sai

Không hẳn là những ý tưởng của tôi về các lỗ hổng trong các công cụ hiện có hoặc cách SDLC đang thay đổi là không chính xác, mà là việc triển khai của chúng tôi đã không mang lại giải pháp như chúng tôi mong đợi. Điều này là do:

• Tôi đã đánh đồng việc lập kế hoạch với một bản kế hoạch
• các mô hình đã trở nên thực sự tốt
• không ai muốn đọc văn bản do AI tạo ra
• chúng tôi đã tách biệt việc lập kế hoạch khỏi việc xây dựng theo cách gây gián đoạn

Lập kế hoạch!= Bản kế hoạch

Điều đầu tiên chúng tôi học được là chúng tôi đã đánh đồng việc lập kế hoạch với một bản kế hoạch. Đó thực sự không phải là một. Giả định của tôi là việc có không gian để suy nghĩ thấu đáo về một thứ gì đó trước khi nó được triển khai là rất có giá trị. Tôi cũng nghĩ rằng việc lưu giữ tư duy đó trong một cấu trúc lớn sẽ có giá trị khi dự án phát triển. Nhưng những người dùng đầu tiên lại có rất ít hứng thú với bản đặc tả đó.

Các mô hình đã trở nên thực sự tốt

Khi các mô hình trở nên tốt hơn trong việc hiểu các cơ sở mã lớn thông qua ngữ cảnh và bộ nhớ, chúng đã xuất sắc trong việc khám phá kho lưu trữ và đưa ra các giả định hợp lý. Nhu cầu phải hướng dẫn chúng một cách rõ ràng để tạo ra một kết quả được suy nghĩ kỹ lưỡng đã giảm đi.

Ban đầu tôi không nghĩ khả năng của mô hình lại cạnh tranh với việc thiết kế một giao diện tốt hơn cho tư duy con người, nhưng theo nhiều cách, nó lại là như vậy. Điều này là do mỗi quyết định mà mô hình có thể tự đưa ra một cách đáng tin cậy là một quyết định ít hơn cần phải được hiển thị.

Văn bản do AI tạo ra rất khó đọc

Bản đặc tả chứa nhiều thông tin hơn mà không tạo ra sự rõ ràng hơn. Điều này là do các bản đặc tả của chúng tôi quá dài. Chúng nắm bắt các quyết định quan trọng và chứa rất nhiều ngữ cảnh có vẻ hữu ích nhưng vấn đề là: chúng do AI tạo ra. Có điều gì đó về nhịp độ và bản chất quá cấu trúc của văn bản do AI tạo ra khiến nó rất khó đọc. Mắt tôi cứ lờ đờ đi.

Thay vì phản ứng với phát hiện này bằng cách loại bỏ spec, chúng tôi đã xây dựng Spec Tour để giải quyết vấn đề. Chúng tôi nghĩ rằng thay vì yêu cầu ai đó phải đọc toàn bộ tài liệu, Spec Tour có thể hướng dẫn họ đi qua những phần quan trọng. Nhưng điều đó chỉ tạo thêm một lớp phức tạp, với nhiều văn bản hơn trên màn hình đòi hỏi sự chú ý. Nếu chúng ta cần tạo ra một bản tóm tắt ngắn gọn hơn để làm cho spec trở nên hữu dụng, thì ngay từ đầu, tài liệu đầy đủ đó có ý nghĩa gì?

Chúng tôi đã chia nhỏ một quy trình vốn cần sự liền mạch.

Quy trình làm việc của chúng tôi quá tuyến tính và tuần tự. Quy trình của chúng tôi trông giống như thế này:

chat → làm rõ bằng cách trả lời câu hỏi → tạo spec → xem xét spec → sửa đổi spec → phê duyệt → triển khai → xem xét code

Tư duy thực sự không diễn ra theo cách này, và sự tách biệt giữa các phần đó tạo cảm giác gượng ép và thiếu tự nhiên. Thông thường, bạn sẽ hiểu một phần của vấn đề, thử nghiệm một cái gì đó, kết quả tạo ra ban đầu sẽ dạy cho bạn điều mới, điều này có thể khiến bạn thay đổi ý định và thử một cách khác. Mỗi bước lại mở ra một câu hỏi mới. Việc lập kế hoạch và xây dựng đan xen vào nhau và nảy sinh một cách tự nhiên hơn so với các chế độ lập kế hoạch cho phép, đặc biệt là cách chúng tôi xây dựng nó trong Nuanced. Giao diện của chúng tôi buộc người dùng phải "ngừng suy nghĩ" sớm để họ có thể bắt đầu xây dựng. Khi quá trình triển khai đã bắt đầu, việc quay lại suy luận dựa trên chat trước đó giống như đi ngược lại quy trình làm việc. Không có đường quay lại phía trên thác nước.

Khi bạn nhìn vào cách Codex hiện đang hoạt động, ranh giới giữa lập kế hoạch và thực thi đang dần biến mất khi chúng hợp nhất làm một. Trước đây, các tác nhân lập trình (coding agents) được hưởng lợi từ quy trình làm việc mà con người thực hiện như sau:

lập kế hoạch → phê duyệt → thực thi

Hồi đó, cái giá phải trả cho việc đi sai hướng là cao hơn đáng kể. Nhưng khi các tác nhân ngày càng hiểu rõ hệ thống hơn, chúng cũng trở nên giỏi hơn trong việc hành động tự chủ và tự kiểm tra công việc của mình. Chúng cũng rất giỏi trong việc sửa đổi cách tiếp cận sau khi kiểm tra kết quả. Điều này cho phép một vòng lặp khác:

hiểu → hành động → kiểm tra → làm rõ → điều chỉnh → hành động lại

Vẫn có một lượng lớn công việc lập kế hoạch diễn ra bên trong vòng lặp đó, nhưng nó không nhất thiết phải xuất hiện dưới dạng một tài liệu gọi là "kế hoạch". Tôi nghĩ sai lầm lớn nhất mà tôi mắc phải là biến kế hoạch thành một sản phẩm hữu hình thay vì thiết kế một quy trình để cải thiện sự hiểu biết của con người.

Bài gốc còn tiếp — xem tiếp tại bài gốc ↗