Một nhà máy phần mềm là một vòng lặp có thể lặp lại xoay quanh công việc phần mềm. Nếu bạn đang xây dựng một nhà máy phần mềm, code đủ tốt để phát hành vẫn cần gu thẩm mỹ và quyền sở hữu của con người. Chúng ta sẽ thảo luận về điều này, bao gồm cả việc liệu bạn có cần một nhà máy ngay lúc này hay không.
Nếu vậy:
- Bạn có thể sẽ cần con người tham gia ngay từ đầu để quyết định về mục đích sản phẩm, thiết kế hệ thống (nếu bạn quan tâm) và tiêu chuẩn chất lượng của bạn.
- Hãy review code (nhà máy có đèn sáng) nhưng hãy có chủ đích về nơi cần nó nhất. Tôi thấy rằng bạn muốn để ý đến nơi mà áp lực ngược tự động bị phá vỡ. Hoặc nơi cần đưa ra các đánh đổi về khả năng bảo trì.
- Hãy hướng đến việc kiểm tra chất lượng diễn ra càng sớm và liên tục càng tốt. Không phải tất cả đều phải như vậy, nhưng điều này bao gồm hệ thống kiểu dữ liệu, kiểm thử tự động, kiểm thử đột biến, máy quét bảo mật và linting cho các quy tắc kiến trúc.
- Số lượng kiểm tra != chất lượng. Bạn có thể sẽ cần thử nghiệm để xem những kiểm tra nào mang lại tỷ lệ tín hiệu trên nhiễu tốt nhất. Hãy sẵn sàng thắt chặt hoặc nới lỏng các ràng buộc của bạn một cách có chủ đích.
Bạn muốn xây dựng nhà máy của mình để một số khía cạnh của gu thẩm mỹ con người được mã hóa trong môi trường, tác nhân cung cấp cho bạn bằng chứng về công việc của nó là đúng và nơi con người vẫn "sở hữu" những gì được đưa vào sản xuất.
Bạn có thực sự cần một nhà máy phần mềm không?
Theo kinh nghiệm của tôi, bạn có thể đi xa một cách đáng ngạc nhiên với bộ công cụ code tiêu chuẩn của mình! Ví dụ: Claude Code hoặc Codex, nhiều phiên làm việc, thông số kỹ thuật tốt với xác minh tích hợp sẵn và các ràng buộc. Bạn thậm chí có thể ném một loạt các vấn đề GitHub vào chúng với các tiêu chí triển khai và sự tham gia của con người. Các quy trình Claude Code và các tác nhân đám mây Copilot/Codex đã cung cấp cho bạn một vòng lặp theo lịch trình hoặc dựa trên sự kiện mà không cần cơ sở hạ tầng tùy chỉnh.
Một nhà máy đáng giá khi bạn cần các lần chạy nhất quán có thể lặp lại, bàn giao công việc giữa các tác nhân, ngăn hai phiên làm việc cùng xử lý một vấn đề, lưu giữ bằng chứng và tạm dừng sản xuất khi việc review bị chậm lại.
Vì vậy, tôi bắt đầu bằng cách nói một nhà máy phần mềm là một vòng lặp có thể lặp lại xoay quanh công việc phần mềm. Chúng ta thực sự có thể xem xét một prompt thể hiện một vòng lặp nhà máy rất nhỏ ở đây:
Đọc vấn đề GitHub #123 và hướng dẫn kho lưu trữ trước khi thay đổi code.
Chỉ triển khai các tiêu chí chấp nhận đã nêu. Không sửa đổi xác thực, thanh toán, di chuyển hoặc các xác nhận kiểm thử hiện có. Làm việc trong một nhánh và giữ cho bản diff có thể review được.
Chạy npm run lint, npm test và npm run build. Nếu một kiểm tra bắt buộc không thể chạy, hãy dừng lại và giải thích lý do. Mở một pull request nháp với các kiểm tra bạn đã chạy, các rủi ro còn lại và bất kỳ quyết định nào con người vẫn cần đưa ra. Không merge.
Một mục tiêu có thể giữ cho việc này tiếp diễn cho đến khi các kiểm tra vượt qua và chúng ta có thể thăm dò các vấn đề GitHub để tìm bất kỳ nhãn cụ thể nào hoặc review các pull request đang mở vào mỗi buổi sáng. Bảo vệ nhánh có thể thực thi một ranh giới merge và con người có thể tiếp tục tham gia bằng cách chọn những gì đã sẵn sàng, review và đưa ra quyết định merge cuối cùng, v.v.
Hãy thêm một nhà máy phần mềm khi bạn cần một hàng đợi công việc dựa trên sự kiện (ví dụ: kích hoạt Slack, vấn đề GitHub, Linear, một backlog) để chạy trong một môi trường đám mây biệt lập nhằm xử lý phân loại, triển khai và kiểm thử với một số sự giám sát rõ ràng của con người. Một số kết thúc vòng lặp của họ bằng một tác nhân giám sát xem xét quá trình sản xuất và ghi lại các vấn đề để phân loại lại.
Theo kinh nghiệm của tôi, nhà máy trở nên hữu ích khi phần khó khăn là làm cho các lần chạy khác nhau của bạn hoạt động nhất quán, bàn giao công việc giữa các tác nhân và tránh các phiên khác nhau yêu cầu cùng một vấn đề, bảo quản bằng chứng và dừng sản xuất khi việc review của con người bị tụt lại phía sau.
Những gì giải quyết vấn đề này nghe có vẻ hơi nhàm chán. Ví dụ: Warp đề cập đến việc phân loại mọi vấn đề đến thành một trong bốn trạng thái - sẵn sàng triển khai, sẵn sàng đặc tả, cần thông tin, chờ triển khai - và nhãn là thứ kích hoạt tác nhân tiếp theo.
Nhãn này thực hiện một vài công việc cùng một lúc: nó là hàng đợi, khóa và vì một phiên chỉ nhận những gì được đánh dấu là sẵn sàng, nó là nơi con người có thể tạm dừng mọi thứ mà không cần nói không vĩnh viễn.
Về quy trình làm việc, có một vài điểm tương đồng và khác biệt so với chỉ sử dụng Claude/Codex:
- Điều hướng: tác nhân cần điều chỉnh hướng, bạn có thể đưa ra đầu vào và chuyển hướng nó
- Thông báo: cách nhà máy báo rằng nó bị chặn. Điều này có thể là do một yêu cầu không rõ ràng, nó bắt đầu một việc gì đó rủi ro hoặc nó cần đầu vào của con người (điều hướng)
- Bàn giao: di chuyển nhiệm vụ, trạng thái và ngữ cảnh của nó giữa nhà máy đám mây/một tác nhân khác/người review. Bàn giao tốt sẽ theo dõi những gì đã xảy ra, những gì còn lại phải làm và tại sao cần bàn giao.
Trong một nhà máy tốt, con người không chỉ giới hạn ở việc review và phê duyệt bản diff cuối cùng. Họ có thể định hình công việc ngay từ đầu, điều hướng nó trong quá trình triển khai, đưa nó qua một lần bàn giao hoặc ngăn nó được đưa vào sản xuất.
Xác minh là nơi một nhà máy có trách nhiệm dành nhiều thời gian. Chúng ta sẽ đề cập đến điều này sau.
Nếu bạn quyết định rằng bạn cần một nhà máy phần mềm, việc xây dựng nó không phải là lựa chọn duy nhất. Việc thiết lập cơ sở hạ tầng để mở rộng quy mô một nhà máy có thể là rất nhiều công việc và bạn có thể muốn cân nhắc việc mua so với xây dựng. Factory.ai, Devin, Warp và HumanLayer đều bán một số phần của vòng lặp này.
Nơi tôi thực sự dành sự chú ý của mình
Trải nghiệm hàng ngày của tôi về phát triển phần mềm đã thay đổi rất nhiều trong năm qua. Tôi đã nói về việc ngày càng làm nhiều công việc song song với các tác nhân, tiến tới việc có một nhà máy phần mềm có đèn sáng. Và rất nhiều người đã hỏi tôi, như là, những điều này thực sự có nghĩa là gì? Bạn đang xây dựng cái gì? Những loại dự án nào bạn đang sử dụng những thứ này? Phần lớn là những điều này:
Vì vậy, vào một ngày rất bình thường, tôi có một nhà máy phần mềm có đèn sáng đơn giản hơn. Tôi có thể có các tác vụ đang chạy trên đám mây. Một nửa số tác vụ này có thể đang làm việc trên các ứng dụng khách hàng sản xuất với các công ty nhỏ hơn mà tôi đang cộng tác. Chúng sẽ có người dùng thực. Chúng sẽ có xác thực thực, thanh toán, đăng ký thực, các rủi ro thực sự lớn mà bạn cần phải cẩn thận. Bạn không thể chỉ nói, ồ, tác nhân, hãy đi làm những thứ này mà không có kiểm tra, ràng buộc và kiểm tra chất lượng.
Tôi có thể làm việc trên các dự án mã nguồn mở của mình. Tôi có thể xây dựng các trang web đồng hành cho sách của mình. Tôi có thể làm việc trên các công cụ. Tôi có thể xây dựng các ứng dụng của riêng mình. Và tất cả đều là những loại ứng dụng rất, rất khác nhau mà tôi đang làm việc. Và đôi khi điểm chung duy nhất của chúng là công cụ tôi đang sử dụng để làm việc, phải không? Có thể tôi đang làm việc trên một bản di chuyển. Những lúc khác, tôi có thể đang làm công việc tính năng thực sự lớn. Và bán kính ảnh hưởng của công việc cũng có thể rất, rất khác nhau.
Vì vậy, khi bạn bắt đầu nghĩ đến việc đạt đến một nơi mà chúng ta ngày càng làm nhiều công việc song song, chúng ta đang cố gắng cải thiện tốc độ, năng suất và quyền tự chủ, điều đó có nghĩa là đưa hệ thống đến một nơi mà chúng ta tin tưởng nó hơn, bạn phải suy nghĩ về những nơi nào thực sự yêu cầu review code của con người, đầu vào của con người.
Và phần lớn điều đó sẽ được yêu cầu ngay từ đầu, phải không? Khi bạn đang xác định đặc tả, yêu cầu của mình, thiết kế sản phẩm sẽ như thế nào? Mục đích của sản phẩm sẽ như thế nào? Và sau đó, làm thế nào để bạn xác minh rằng các tác nhân thực sự đã hoàn thành công việc một cách chính xác? Làm thế nào để bạn xác minh rằng chúng không phá vỡ hệ thống hiện có? Làm thế nào để bạn đảm bảo rằng nó đáp ứng tiêu chuẩn chất lượng của bạn?
Và vì vậy, việc tạo ra code không nhất thiết là phần bạn cần lo lắng nhất. Với đủ ngữ cảnh, các tác nhân có thể viết code triển khai, chạy kiểm tra, kiểm tra lỗi và sửa đổi code cho chúng ta. Chúng ta cần đạt đến một nơi mà chúng ta cảm thấy có đủ gu thẩm mỹ của con người được mã hóa trong môi trường để chúng ta có thể tin tưởng vào những gì đang được xây dựng, để sự chú ý của con người có thể tập trung vào những nơi cần nó nhất.
Bây giờ, có sự phản đối từ một số người nói rằng, này, tôi không tin rằng bạn có thể tự động hóa hoàn toàn nhiều thứ này. Không phải là chúng ta đang tự động hóa tất cả, phải không? Nhưng với khối lượng code đang được tạo ra, tôi không nghĩ rằng việc con người đọc tất cả là thực tế, đặc biệt là khi chúng ta không xây dựng tên lửa phần lớn thời gian, phải không? Chúng ta đang xây dựng UI, chúng ta đang xây dựng các ứng dụng full stack.
Khả năng phán đoán, gu thẩm mỹ của chúng ta được tập trung tốt nhất vào những nơi cần nó nhất. Ví dụ, đâu là những phần rủi ro nhất của hệ thống? Chúng ta cần áp dụng gu thẩm mỹ của con người ở đâu? Và điều đó có thể ở front end. Điều đó có thể ở cách hệ thống hoạt động. Nó không nhất thiết phải là 100%.
Băng thông nhận thức của tôi không mở rộng quy mô cùng với các tác nhân
Thực tế là, vâng, bây giờ chúng ta có thể khởi động hàng chục, hàng trăm, hàng nghìn tác nhân song song, nhưng băng thông nhận thức của riêng bạn không mở rộng quy mô theo cùng một cách. Điều này có thể dẫn đến nợ nhận thức hoặc hiểu biết mà tôi đã nói đến trước đây.
Nếu bạn nhớ lại chỉ năm, mười năm trước, đã có rất nhiều cuộc thảo luận trong cộng đồng kỹ thuật về chuyển đổi ngữ cảnh và chi phí của nó. Chúng ta đã nói về việc mọi người ghét như thế nào khi một đồng nghiệp hoặc ai đó bước đến bàn làm việc của bạn khi bạn đang ở giữa một nhiệm vụ. Sau đó, bạn sẽ mất rất nhiều thời gian để quay lại trạng thái tập trung vì bạn phải bắt kịp lại, như kiểu, tôi đang ở đâu? Tôi đang làm gì? Ngay cả khi bạn có một chút dư âm ở đó, nó vẫn tốn thời gian của bạn.
Bây giờ chúng ta còn chuyển đổi ngữ cảnh nhiều hơn trước đây. Vào bất kỳ ngày nào, nếu tôi làm việc bên ngoài một nhà máy phần mềm, tôi có thể làm việc trên năm hoặc mười dự án khác nhau với các tác nhân cùng một lúc, hoặc năm hoặc mười tính năng khác nhau trên một dự án duy nhất cùng một lúc. Tôi có thể có năm hoặc mười phiên làm việc khác nhau, bạn có thể nói như vậy.
Điều đó có nghĩa là tôi phải có khả năng theo dõi ít nhất một vài trong số đó. Có thể tôi sẽ có thể tăng mức độ tự chủ mà tôi dành cho một số tác vụ nếu tôi tin tưởng rằng tôi đã xác định nhiệm vụ đủ tốt, tôi đã xác định kết quả, cách nó sẽ xác minh rằng nó đã được thực hiện đủ tốt. Nhưng sau đó sẽ có những tác vụ mà có thể tôi không nhất thiết cảm thấy như vậy và có nhiều rủi ro hơn hoặc nhiều sắc thái hơn. Tôi sẽ phải chú ý.
Hãy cân nhắc tối ưu hóa nhà máy phần mềm cho người review của bạn. Với mỗi cách tiếp cận đó vẫn chuyển hướng đầu ra của nó đến sự chú ý của một người, bạn nên tự hỏi nhà máy làm cho các quyết định bạn vẫn phải đưa ra rẻ hơn bao nhiêu.
Một sai lầm sai dự án
Tôi nhớ khi tôi đã làm việc trên nhiều dự án song song với các tác nhân của mình, và đã có những lần tôi vô tình làm những việc như, có thể tôi đang làm việc trên một ứng dụng web mà tôi muốn thêm chế độ tối, và vì vậy tôi đã nghĩ trong đầu, được rồi, đây là hình dạng của việc này cần trông như thế nào. Nhưng tôi vô tình vào phiên làm việc cho một dự án khác, và tôi bắt đầu đưa ra cùng một prompt đó.
Vì vậy, tôi bắt đầu triển khai chế độ tối cho một thứ hoàn toàn không cần nó. Và vì vậy tôi có thể mắc sai lầm đó. Tôi không muốn nhà máy phần mềm của mình mắc phải loại sai lầm đó.
Bạn cần suy nghĩ về điều này thực sự dưới góc độ một hệ thống. Bạn đang cố gắng mã hóa một văn hóa kỹ thuật phần mềm, một văn hóa nhóm, vào một hệ thống để nó có những hành vi tương tự, để nó có quyền sở hữu thuộc về một nơi nào đó, để ai đó vẫn chịu trách nhiệm về những gì xảy ra, và bạn đang rất rõ ràng về cách bạn nghĩ về những điều đó.
Khi màu xanh lá cây gây hiểu lầm
Ngay cả trong các hệ thống này, bạn muốn rất cẩn thận, phải không? Nhiều người trong chúng ta đã thấy rằng khi bạn yêu cầu AI giúp bạn vượt qua một bài kiểm tra, như chúng ta đang nói về một bài kiểm tra lập trình, một bài kiểm tra đơn vị, nó có thể thay đổi bài kiểm tra đơn vị để đáp ứng điều kiện đó, hoặc nó có thể thay đổi logic của code để vượt qua điều kiện đó. Điều đó không có nghĩa là nó thực sự tuân theo ý định của bạn để căn chỉnh cả hành vi chức năng và những gì bài kiểm tra được cho là đang kiểm tra, phải không?
Chỉ vì một nhà máy phần mềm hiển thị rằng mọi thứ đều xanh lá cây không có nghĩa là nó thực sự xanh lá cây, đặc biệt là khi bắt đầu thiết lập những thứ này. Bạn cần phải chú ý nhiều để đảm bảo rằng các kiểm tra, xác minh của bạn, tất cả đều được định hình đúng cách. Chúng đang làm những gì bạn mong đợi chúng làm. Bạn không muốn chúng gây hiểu lầm.
Bạn không muốn một tình huống mà bạn có các bài kiểm tra nói rằng, này, thực ra, tôi đã đi và thay đổi những nhà cung cấp xác thực nào được hỗ trợ. Bạn yêu cầu tôi thêm GitHub chẳng hạn, như một nhà cung cấp xác thực, nhưng này, UI của tôi chỉ có chỗ cho ba, vì vậy tôi đã đi và loại bỏ một trong những cái khác. Và này, nhân tiện, đó lại là cái mà khách hàng của bạn thực sự muốn. Vì vậy, bạn chỉ cần phải rất rõ ràng về cách bạn muốn các hệ thống này hoạt động.
Nhân tiện, bảo mật cũng cực kỳ quan trọng và nếu nhà máy của bạn đọc đầu vào không đáng tin cậy như một vấn đề GitHub/tin nhắn Slack, nó có thể mang tính đối kháng và bao gồm các vấn đề như tấn công chuỗi cung ứng. Một số sản phẩm xoay quanh nhà máy phần mềm, như Vercel Sandbox/AI ADK Factory, chạy các tác nhân của chúng trong các sandbox biệt lập chỉ chứa những bí mật mà một tác vụ cần. Bằng cách đó, một lần chạy bị xâm phạm không thể tiếp cận những gì công việc không cần. Hệ thống phòng thủ của bạn cuối cùng sẽ có nhiều lớp.
Những dự án cũ nào xứng đáng có một cuộc sống khác?
Tôi cũng nghĩ rằng một phần lớn trong cách chúng ta làm việc ngày nay là quyết định những gì nên tồn tại. Nếu bạn nhớ lại nhiều năm trước đây trước khi có AI, đã có rất nhiều dự án kỹ thuật phần mềm bị bỏ hoang, rất nhiều dự án cuối tuần bị bỏ hoang, các dự án cá nhân mà chúng sẽ không bao giờ ra mắt vì chúng ta không có thời gian để hoàn thành chúng. Chúng ta không có băng thông để ưu tiên đưa chúng ra ngoài vì chúng không quan trọng với chúng ta hoặc chúng ta không thể tìm thấy thời gian.
Bây giờ, việc hoàn thành các dự án đó khá dễ dàng đối với chúng ta, nhưng cùng một câu hỏi về phán đoán của con người lại xuất hiện. Những dự án đó có xứng đáng tồn tại không? Chúng có nên được ra mắt không? Bởi vì bạn đưa chúng ra thế giới và ngay cả khi nó chỉ có năm người dùng, có thể bạn phải duy trì nó. Có thể bây giờ bạn có một tiêu chuẩn chất lượng mà bạn muốn duy trì.
Tôi biết rằng tôi đã có rất nhiều dự án GitHub từ nhiều năm qua, nơi mà bây giờ tôi có một tác nhân, điều đầu tiên tôi làm là làm cho nó build được. Bởi vì, tất nhiên, bạn clone nó và bây giờ nó không build được vì tất cả các phụ thuộc đã thay đổi. Một nửa số thứ đã lỗi thời hoặc có lỗ hổng bảo mật khắp nơi, vì vậy bạn phải cập nhật chúng.
Sau đó, bạn phải thêm các bài kiểm tra nếu bạn chưa có để bạn biết rằng hành vi đó ít nhất sẽ tồn tại nếu bạn đang nâng cấp dự án theo một cách nào đó, hoặc nếu bạn đang di chuyển nó sang một ngôn ngữ hoặc framework hiện đại hơn hoặc những thứ tương tự.
Sau đó, bạn bắt đầu tự hỏi, có thể, một ví dụ ngớ ngẩn, nhưng có thể tôi đã sử dụng Twitter Bootstrap ngày xưa cho việc này, nhưng bây giờ mọi người đều sử dụng Tailwind và shadcn, vì vậy tôi phải triển khai lại UI. Và điều bạn sẽ nhận thấy là đột nhiên việc này tốn nhiều thời gian hơn của bạn, phải không? Vâng, tác nhân có thể hoàn thành nhiều việc này nhanh hơn, nhưng bây giờ bạn phải tính đến cảm nhận sản phẩm và gu thẩm mỹ và tất cả những thứ này.
Bạn vẫn tự hỏi, này, nó dành cho ai? Nó có thị trường không? Nó dành cho tôi? Hay cho người khác? Nếu tôi đưa nó ra thế giới, nó có còn thú vị không khi bây giờ bất kỳ ai cũng có thể tạo ra những thứ này nhanh chóng?
Vì vậy, tôi nghĩ rằng câu hỏi của con người về việc liệu những thứ này có xứng đáng tồn tại không? Làm thế nào để chúng ta tính đến gu thẩm mỹ và phán đoán của mình? Tôi cảm thấy rằng những điều đó tiếp tục cực kỳ quan trọng. Đó là nơi nguồn lực khan hiếm của sự chú ý của con người thực sự phát huy tác dụng. Ngày xưa, chúng ta chỉ có một số giờ hữu hạn trong ngày. Chúng ta có các cuộc họp. Chúng ta phải dành thời gian cho thiết kế và code, v.v.
Bây giờ chúng ta có các tác nhân để giúp đỡ, tôi nghĩ rằng bạn thực sự phải rất rõ ràng về nơi bạn dành thời gian và lý do tại sao.
Điều gì đã xảy ra khi tôi xây dựng một mẫu thử
Vì vậy, tôi sẽ nói về lần chạy nhà máy kéo dài 82 phút. Mọi người đã hỏi tôi khá lâu rồi, bạn biết đấy, "Làm thế nào để tôi xây dựng một nhà máy phần mềm?" Hoặc, "Tôi đã quen với việc sử dụng Claude Code hoặc Codex. Làm thế nào để tôi phát triển thiết lập của mình để sử dụng một nhà máy phần mềm?"
Vì vậy, điều đầu tiên tôi đã nói là, "Bạn có thể ổn. Công việc của bạn thực sự có thể hoàn toàn ổn mà không cần một nhà máy." Nhưng tôi muốn cung cấp cho mọi người một thiết lập tham khảo mà họ có thể xem qua. Vì vậy, những gì tôi đã tập hợp là một kho lưu trữ có tên là Factory mà bạn có thể xem qua. Tôi cũng đã tập hợp một ứng dụng demo và hội thảo.
Bây giờ, trong vài năm qua, ứng dụng demo ưa thích của tôi cho nhiều thứ là một ứng dụng phim. Tôi là một người rất hâm mộ phim ảnh. Tôi thích xem phim. Tôi xem phim mọi lúc, và vì vậy tôi có một ứng dụng demo, thực sự bắt đầu như một ứng dụng phim rất đơn giản. Và những gì tôi muốn nhà máy có thể làm là triển khai một số tính năng. Có một vài tính năng khác nhau. Tôi muốn một tính năng yêu thích. Tôi muốn nó có thể tìm kiếm, và có thể cũng muốn có một chủ đề tối ở đó nữa, những loại thứ đó.
Vì vậy, tôi đã để nhà máy của mình bắt đầu làm việc với những thứ này. Bạn có thể xem qua quá trình triển khai. Một trong những lợi ích của nó là thực sự phát hiện ra các vấn đề thực tế. Những vấn đề này có thể không phải là những thứ tôi sẽ phát hiện ra nếu tôi chỉ yêu cầu nó thực hiện một lần triển khai duy nhất.
Có thể vào khoảng phút thứ 60, tôi cảm thấy, "Chà, việc này đang diễn ra chậm một cách bất thường." Tôi đã hỏi bộ công cụ của mình bằng cách sử dụng nhà máy, "Tại sao mọi thứ lại chậm?" Nó nói, "Điều này thực sự hoàn toàn ổn. Tất cả các bộ xác minh vẫn đang chạy."
Bạn có thể đã mong đợi các tác vụ riêng lẻ mất 10 phút, 15 phút, 20 phút, nhưng chúng có thể mất gấp hai đến bốn lần thời gian khi bạn bắt đầu bao gồm xác minh, thử lại, kiểm tra trình duyệt, review của con người, bất kỳ sự chậm trễ bổ sung nào.
Tôi nghĩ rằng những điều này có thể dẫn đến chất lượng tốt hơn và sự tin cậy tốt hơn trong hệ thống. Từ góc độ đo lường, bạn có thể xem xét các số liệu như chi phí cho mỗi PR đã merge và tuổi thọ code như các chỉ số nợ hiểu biết.
Bạn cũng cần suy nghĩ về sự chậm trễ hữu ích so với chi phí chung của nhà máy. Các bộ xác minh, trong trường hợp của tôi, đã phát hiện ra một số vấn đề thực tế. Một chút thời gian có thể đã bị chìm vào việc tạo ra bằng chứng mà tôi muốn. Một số là chi phí chung trong việc chạy nhà máy. Tôi đã không thực sự dành thời gian để tối ưu hóa nó, nhưng một nhà máy chỉ chạy rất nhiều kiểm tra mà bạn không thấy có giá trị không có nghĩa là nó có chất lượng cao.
Bạn muốn nghiên cứu xem, đối với bất kỳ kiểm tra lặp đi lặp lại nào, chúng có không liên quan không? Chúng có ồn ào không? Chúng có thực sự làm cho hệ thống an toàn hơn không?
Xác minh cần một ngân sách
Cách tôi nghĩ về ngân sách cho xác minh, về cơ bản đây là những gì chúng ta đang nói đến. Chúng ta đang nói về một ngân sách xác minh. Tôi nghĩ về nó theo cùng một cách mà tôi đã từng nghĩ về ngân sách hiệu suất.
Sẽ có một số loại kiểm tra nhất định mà bạn có thể chạy sớm trong vòng đời phát triển phần mềm của mình, và sẽ có một số thứ nặng nề đến mức, nhưng chúng mang lại nhiều giá trị đến nỗi bạn sẽ muốn chạy chúng sau đó. Có một số loại kiểm tra nhanh, linting chẳng hạn, kiểm tra kiểu dữ liệu. Đây là những kiểm tra tương đối nhanh mà bạn có thể chạy sớm.
Bộ kiểm tra đầy đủ của chúng ta có thể được chạy gần hơn ngay trước khi một PR nháp được tạo ra hoặc sau đó. Điều đó có thể bao gồm kiểm thử đột biến, kiểm thử trình duyệt, kiểm tra bảo mật, bất cứ thứ gì tương tự.
Tôi nghĩ rằng bạn không nhất thiết muốn thay thế những thứ này bằng các bản tóm tắt. Bạn muốn các bài kiểm tra thực sự, nhưng bạn chỉ cần đảm bảo rằng bạn đang lập ngân sách cho chúng ở đúng nơi vì bạn không muốn làm chậm vòng lặp phát triển của mình. Tôi chắc chắn không bao giờ muốn làm chậm vòng lặp phát triển của mình. Có một vòng lặp lặp nhanh là quan trọng đối với tôi, nhưng tôi cũng muốn vẫn có những kiểm tra và cân bằng đó.
Khi một lần chạy không được phát hành
Phần lớn những gì tôi đã viết ở trên liên quan đến các kiểm tra.
Trong nhà máy phần mềm của họ, Vercel đánh dấu mọi lần chạy tác nhân là "thành công", "có lỗi", "bị chặn" hoặc "thủ công" và chỉ "thành công" mới được đưa vào sản xuất. Phần còn lại quay trở lại hệ thống. Tôi đã suy nghĩ về các lần chạy theo các thuật ngữ tương tự.
"Có lỗi" ở đây có nghĩa là điều sai đã được triển khai hoặc có thể nó không có đầy đủ ngữ cảnh, vì vậy điều đó phải được sửa. Bị chặn có nghĩa là môi trường có thể đã thiếu thông tin xác thực, vì vậy bạn phải cung cấp nó. Thủ công là một ranh giới mà nhà máy có thể chưa được phép vượt qua.
Hai trong số ba điều ở đây có thể có các bản sửa lỗi cơ học và điều cuối cùng là về sự tin cậy.
Mặc dù điều này rất tuyệt, nhưng việc phân loại không cho bạn thấy chi phí. Quay lại quá trình triển khai nhà máy của tôi với ứng dụng TMDB, công cụ tìm nhanh không có từ chối mất 7 phút. Tính năng yêu thích, với hai lần từ chối và một quyết định của con người ở giữa, mất 56 phút. Cùng một nhà máy. Vì vậy, tôi sẽ ghép phân loại với thời gian theo từng giai đoạn, nếu không bạn biết một lần chạy đã quay lại có lỗi mà không biết việc phát hiện ra nó đã tốn kém bao nhiêu. Một điều khác tôi sẽ sửa là bàn giao tại ranh giới: nhà máy mẫu của tôi đã dừng vấn đề đầu tiên và chuyển nó sang factory:needs-info, điều đó đúng, nhưng tôi không biết đặt câu trả lời của mình ở đâu. Một lần chạy thủ công không kết thúc khi nhà máy dừng lại mà khi con người biết phải làm gì tiếp theo.
Quyền tự chủ không phải là một cài đặt duy nhất
Tôi đã viết một bài báo cách đây vài tuần về mức độ tự chủ của tác nhân và cách suy nghĩ về quyền tự chủ bởi vì quyền tự chủ sẽ không phải là một cài đặt duy nhất cho mọi dự án.
Xác minh mang lại cho bạn sự tin cậy và nó mang lại khả năng cấp nhiều quyền tự chủ hơn cho các tác nhân của bạn. Vì vậy, nếu, ví dụ, tôi đang làm việc trên một thay đổi không tầm thường, nhưng tôi có một số kiểm tra tại chỗ, mọi thứ đều được xác minh chính xác, và có thể tôi đã tự kiểm tra bằng tay. Lần tới khi tôi làm một nhiệm vụ tương tự trong cùng một dự án, có thể tôi sẽ cảm thấy thoải mái khi cho tác nhân nhiều quyền tự chủ hơn một chút.
Đó là điều bạn nghĩ đến khi xây dựng các nhà máy phần mềm này. Xác minh của bạn sẽ thay đổi theo rủi ro. Mục tiêu của bạn là tỷ lệ tín hiệu trên nhiễu tốt nhất. Bạn không chỉ muốn có một danh sách kiểm tra lớn mà bạn đang chạy.
Tính năng tôi đã phải học lại
Có một tính năng mà tôi đã trì hoãn vào một ngày khi tôi đang sử dụng nhiều phiên với Claude, và tôi đang làm việc trên một vài dự án khác nhau cùng một lúc, một vài tính năng khác nhau mỗi lần cho mỗi dự án. Và vì vậy Claude đã triển khai tính năng mà tôi đang làm việc. Có vẻ như các bài kiểm tra đã vượt qua. Tôi đã không dành nhiều suy nghĩ cho việc xác minh, nhưng các bài kiểm tra đã vượt qua, và vì vậy tôi nghĩ nó hoạt động. Tôi đã merge nó.
Và vì vậy đây là một tính năng yêu thích. Tôi nghĩ rằng điều này thực sự khá tốt. Tôi đã cố gắng kiểm tra nó trong trình duyệt. Nó có vẻ ổn, nhưng một vài ngày sau, tôi thực sự quay lại code vì có một số điều chỉnh mà tôi nghĩ tôi có thể thực hiện cho việc này.
Tôi không muốn chỉ đơn giản là yêu cầu agent của mình thực hiện các thay đổi, bởi vì đó chỉ là một cách tinh tế mà nó hoạt động. Bạn chạm vào biểu tượng, và nó sẽ không hiển thị hiệu ứng đúng khi chạm, và vì vậy tôi muốn chỉnh sửa nó một chút. Tôi muốn hiểu cách nó hoạt động để có thể hướng dẫn agent của mình một cách chính xác.
Tôi đã quay lại với code, và tôi không thể giải thích cho bạn cách tính năng đó hoạt động. Kho lưu trữ này là của tôi, phải không? Tôi đã phê duyệt thay đổi. Tôi hiểu cách nhiều phần của nó hoạt động, nhiều phần của repo hoạt động, nhưng sự hiểu biết của tôi đã không theo kịp với tất cả code đang được xây dựng lên.
Điều tôi đã không thể tiếp thu được là cách tính năng được thêm vào này thực sự hoạt động, cách UI hoạt động, cách hiệu ứng trên nó hoạt động. Tôi đã phải làm lại tính năng này và thực sự đi từng bước một, "Cái này hoạt động thế nào? Làm sao tôi có thể hiểu nó?"
Công việc song song ảnh hưởng đến sự hiểu biết như thế nào
Khi bạn đang làm việc song song, nó sẽ khuếch đại vấn đề tổng thể này, và nó càng trở nên khuếch đại hơn khi bạn đang làm việc đó trong một software factory. Khi bạn đang thực hiện năm hoặc mười phiên làm việc, chúng tạo ra nhiều hơn chỉ là một vấn đề về khối lượng review. Chúng tạo ra một số mô hình tinh thần mà cuối cùng có thể trở nên khá lạnh nhạt trong khi bạn đang làm việc ở nơi khác.
Trước đây chúng ta đã từng nói về những thách thức với việc chuyển đổi ngữ cảnh, và ngay khi chat bị nén lại, bạn từ bỏ một số cách tiếp cận, bạn thử những thứ khác nhau, bạn đang kết hợp với agent, bạn sẽ gặp khó khăn trong việc nhớ mọi thứ đã xảy ra trong phiên làm việc của mình.
Bạn có thể cuộn lên, và khi quá trình nén đã diễn ra, bạn sẽ không có mọi thứ ở đó, và bạn sẽ không thể lưu trữ tất cả trong đầu mình. Code thường lưu giữ một quyết định đã được đưa ra, nhưng không phải lý do tại sao quyết định đó được đưa ra.
Đây là điều mà tôi nghĩ có thể là một bài học hữu ích cho bạn, nơi nó quan trọng, hãy cân nhắc yêu cầu agent của bạn thực sự lưu trữ thông tin về quỹ đạo của nó, hoặc những bài học thú vị về cách nó tiếp cận một vấn đề để bạn có thể quay lại với nó sau này.
Điều này có thể hoặc không thể là thứ bạn quyết định commit vào một repo. Bạn có thể giữ nó ở local nếu muốn, bạn có thể chia sẻ nó với nhóm nếu muốn, nhưng đó có thể là thứ sau đó có thể được tham khảo lại. Thay vì bạn dựa vào việc nó có thể có trong một phiên làm việc, hoặc bạn có thể nhớ về nó sau này.
Nó thực sự tạo ra cái gì?
@threepointone và @bentlegen đã đăng một số quan điểm về software factory mà tôi hoàn toàn đồng ý:
Thật dễ dàng để bị mê hoặc bởi cỗ máy của việc thực hiện, tối ưu hóa cỗ máy, và quên mất nó được cho là sẽ sản xuất ra cái gì. Nếu factory của bạn chủ yếu sản xuất ra một factory tốt hơn, bạn đã xây dựng một phần mềm mà sản phẩm của nó là chính nó.
Tôi nghĩ đầu tư vào vòng lặp là ổn và nó sẽ tích lũy. Thất bại xảy ra khi vòng lặp đóng lại, khi mọi thứ factory sản xuất ra đều bị factory tiêu thụ và không ai bên ngoài sẽ nhận thấy nếu bạn tắt nó đi. Bài kiểm tra tôi sẽ áp dụng là sự kéo. Một thứ gì đó bên ngoài phải đang yêu cầu sự cải tiến. Nếu bạn không thể đặt tên cho ai đang kéo, bạn đang đánh bóng.
Quyền sở hữu không biến mất
Có một nguyên tắc rộng hơn bên dưới tất cả những điều này.
Tỷ lệ phần trăm code được gõ vật lý bởi con người có thể giảm mạnh. Tôi không nghĩ quyền sở hữu của con người cần phải giảm theo.
- Ai đó vẫn chọn vấn đề.
- Ai đó vẫn chọn kiến trúc.
- Ai đó vẫn đặt ra tiêu chuẩn chất lượng.
- Ai đó quyết định tín hiệu xác minh nào đáng tin cậy.
- Ai đó quyết định khi nào bằng chứng đủ để phát hành.
Và khi hệ thống kết quả thất bại, "agent đã viết nó" không phải là lý do chấp nhận được. Đây là lý do tại sao tôi không nghĩ tương lai của kỹ thuật phần mềm được mô tả tốt nhất là con người rời khỏi vòng lặp. Thay vào đó, phán đoán của con người đang được di dời.
Chúng ta nên loại bỏ con người khỏi những phần của vòng lặp nơi máy móc có thể tạo ra các tín hiệu mạnh hơn, nhanh hơn, mang tính quyết định hơn. Đồng thời, chúng ta nên tập trung con người vào những nơi mà ngữ cảnh, gu thẩm mỹ, rủi ro và quyền sở hữu dài hạn là quan trọng nhất.
Các software factory tốt nhất sẽ không được định nghĩa bởi mức độ hoàn toàn loại bỏ sự tham gia của con người.
Chúng sẽ được định nghĩa bởi cách chúng đặt sự tham gia đó một cách thông minh.
Giữ phán đoán của con người ở thượng nguồn về ý định, hình dạng hệ thống và tiêu chuẩn chất lượng. Review code nơi áp lực ngược tự động trở nên yếu hoặc hậu quả trở nên chủ quan. Đẩy mọi tín hiệu mang tính quyết định vào vòng lặp càng sớm và liên tục càng tốt. Thắt chặt và nới lỏng các ràng buộc một cách có chủ ý khi hệ thống kiếm được hoặc mất đi lòng tin.
Một con người vẫn phải sở hữu code cuối cùng được phát hành. Code đủ tốt để phát hành vẫn bắt đầu từ một người quan tâm liệu nó có nên tồn tại hay không.
