Tessl giới thiệu 'Nhà máy hướng ngữ cảnh': Cách mạng hóa quy trình phát triển phần mềm bằng AI

Các nhà máy phần mềm (software factories) là biên giới mới của phát triển phần mềm bằng tác nhân (agentic software development). Chúng hứa hẹn một quy trình phát triển có tính tích lũy, ngày càng rẻ hơn, nhanh hơn và tốt hơn mỗi tuần. Tuy nhiên, hầu hết các đội ngũ đều gặp khó khăn trong việc xây dựng những nhà máy mang lại kết quả tích lũy như vậy. Quá trình xây dựng của họ bị đình trệ, hoặc các cải tiến chỉ dừng lại ở mức gia tăng nhỏ lẻ.

Chúng ta đã từng thấy mô hình này trước đây. Khi các tác nhân lập trình (coding agents) mới xuất hiện, việc tạo ra các tính năng trở nên dễ dàng đột ngột, nhưng cũng dễ dàng tạo ra những sản phẩm kém chất lượng. Những đội ngũ đạt được giá trị thực sự đã học cách tách biệt việc lập kế hoạch khỏi quá trình triển khai và ghi lại bối cảnh (context) mà một tác nhân cần trước khi để nó bắt đầu xây dựng. Các nhà máy cũng đang đi theo con đường tương tự. Bước đi đầy cám dỗ là lao ngay vào tự động hóa, nhưng chúng tôi thường xuyên thấy điều này thất bại vì ba lý do:

Câu trả lời của chúng tôi là các nhà máy dựa trên bối cảnh (context-driven factories), một phương pháp tập trung vào việc xác định quy trình làm việc và tiêu chuẩn của đội ngũ trong các tệp văn bản thuần túy, chạy trên hạ tầng đơn giản và minh bạch. Bài viết này mô tả hình thái của phương pháp đó, lý do tại sao các giải pháp thay thế phổ biến lại gặp khó khăn và cách để bắt đầu.

Các nhà máy dựa trên bối cảnh trong thực tế

Một nhà máy dựa trên bối cảnh có hai nguyên tắc được thiết kế để loại bỏ việc ra quyết định khỏi mã nguồn, cho phép tri thức luân chuyển giữa các công cụ và giúp bối cảnh kinh doanh trở nên dễ dàng để cộng tác trên toàn đội ngũ.

Định nghĩa quy trình làm việc nằm trong bối cảnh, không phải trong mã nguồn. Tác nhân đọc mô tả về công việc và tiêu chuẩn hoàn thành, sử dụng các công cụ cần thiết và tự quyết định bước tiếp theo. Mã nguồn vẫn tồn tại dưới dạng các tập lệnh (scripts), CLI và các công cụ MCP mà tác nhân có thể gọi, nhưng nó không nằm trong vòng lặp ngoài để quyết định cách tác nhân thực hiện nhiệm vụ hoặc những gì nó được phép nhìn thấy.

Mọi quy trình làm việc và tiêu chuẩn đều nằm trong một plugin. Các plugin đó được kiểm soát trong kho lưu trữ (repo) của bạn và chia sẻ giữa các dự án thông qua một registry bối cảnh. Chỉ cần đọc một plugin là bạn biết nhà máy hoạt động như thế nào. Thay đổi một plugin là bạn đã thay đổi nhà máy.

Khi đội ngũ của bạn bắt đầu nắm bắt các quy trình làm việc và tiêu chuẩn của họ dưới dạng các kỹ năng (skills), bạn sẽ tự động hóa chúng bằng các vòng lặp (loops). Một vòng lặp là một kỹ năng mà bạn đã triển khai để chạy tự động, một kỹ năng cải thiện theo thời gian khi nó vận hành. Một nhà máy kết hợp các kỹ năng và vòng lặp thành một vòng đời phát triển phần mềm (SDLC) hoàn chỉnh bằng tác nhân. Con đường này đã trở thành một phương châm tại Tessl: từ kỹ năng, đến vòng lặp, đến nhà máy.

Các nhà máy dựa trên bối cảnh giúp hành trình này dễ dàng hơn vì hai lý do. Các tệp bối cảnh thuần túy rất dễ để tác nhân đọc và thay đổi một cách an toàn, vì vậy bước tự cải thiện trở nên khả thi và các vòng lặp có thể chạy với sự tự chủ cao hơn. Và vì bối cảnh có tính di động và được tái sử dụng trên nhiều bề mặt, các vòng lặp thu thập tín hiệu từ mọi nơi mà kỹ năng được sử dụng và phân phối các cải tiến một cách rộng rãi tương đương.

Dưới đây, chúng tôi trình bày một nhà máy dựa trên bối cảnh trên ba bề mặt chính của nhà máy:

Từ ticket đến PR

Triển khai một ticket là một nhiệm vụ mơ hồ đòi hỏi khả năng phán đoán cao. Một tính năng có thể liên quan đến một hoặc ba repo. Một thay đổi lớn có thể được vận chuyển tốt hơn dưới dạng vài PR xếp chồng (stacked PRs). Một bản sửa lỗi nội dung (copy fix) nên bỏ qua quy trình đánh giá nặng nề. Các kỹ sư tiếp nhận những biến thể này mà không cần suy nghĩ, và một nhà máy phải mô hình hóa được sự mơ hồ tương tự.

Trong một nhà máy dựa trên bối cảnh, quy trình từ ticket đến PR là một tập hợp các kỹ năng:

Khi ai đó ủy quyền một vấn đề (issue) cho nhà máy, không có logic bổ sung hay định tuyến ma thuật nào cả. Một tác nhân bắt đầu với kỹ năng triage-issue (phân loại vấn đề) được tải sẵn. Kỹ năng này mô tả cách đội ngũ phân loại: cần xem xét những gì, trả lời những câu hỏi nào và chuyển sang các kỹ năng liên quan nào tiếp theo. Khi một PR tồn tại, pr-shepherd sẽ tiếp quản theo cùng một hình thức: giải quyết CI, xử lý đánh giá, hợp nhất khi các tiêu chí được đáp ứng. Khi có ngoại lệ, tác nhân có thể xử lý chúng một cách linh hoạt.

Đánh giá mã nguồn (Code review)

Đánh giá mã nguồn tốt giúp tất cả các kỹ sư của bạn giỏi hơn. Đánh giá là nơi các tiêu chuẩn của đội ngũ được áp dụng sắc bén nhất, và nếu những bài học đó không lan tỏa khắp SDLC của bạn, nhà máy của bạn sẽ không bao giờ tích lũy được giá trị.

Trong một nhà máy dựa trên bối cảnh, việc chia sẻ này là mặc định, vì các tiêu chuẩn đánh giá mã nguồn của bạn nằm trong các kỹ năng có thể được tái sử dụng ở nơi khác. Chỉ cần thêm một plugin đánh giá mã nguồn và trỏ điểm truy cập đánh giá vào đó.

Lưu ý rằng hệ thống thiết kế (design system), hướng dẫn thương hiệu và bộ não công ty không nằm trong repo. Chúng là các phụ thuộc (dependencies), được giải quyết từ registry của Tessl. Bộ phận thiết kế sở hữu hệ thống thiết kế và xuất bản nó. Mỗi dự án cần nó sẽ khai báo một phụ thuộc và nhận phiên bản hiện tại.

Khi quá trình đánh giá liên tục gắn cờ một kiểu giãn cách và hướng dẫn của hệ thống thiết kế được sửa chữa, lần triển khai tiếp theo sẽ thực hiện đúng ngay từ đầu. Đánh giá đã cải thiện quá trình tạo mã mà không cần ai phải kết nối hai thứ đó lại với nhau, bởi vì chúng luôn đọc cùng một tệp. Đây là một vòng lặp ở dạng đơn giản nhất: một kỹ năng trở nên tốt hơn mỗi khi nó chạy, với sự cải tiến được áp dụng ở mọi nơi mà kỹ năng đó được sử dụng.

Tự động hóa

Một số công việc chạy theo lịch trình hoặc kích hoạt bên ngoài luồng ticket-to-PR:

Một mục schedules trong tessl.json biến một plugin thành một vòng lặp. Bất kỳ ai cũng có thể mở kỹ năng để xem cách một changelog được viết hoặc những gì được tính là một bài kiểm tra không ổn định (flaky test). Bất kỳ ai cũng có thể đề xuất thay đổi quy trình làm việc trong một pull request, và đội ngũ có thể thảo luận ở đó trước khi nó được thực thi. Quy trình thuộc về đội ngũ và dễ dàng đánh giá như một đội ngũ.

Hạ tầng đơn giản, minh bạch

Các nhà máy dựa trên bối cảnh yêu cầu ít hạ tầng hơn, vì hầu hết công việc là bài tập tạo và cải thiện các plugin. Hạ tầng còn lại (sandbox, secrets, trình lập lịch, v.v.) là vô hình, vì nó không chứa logic.

Kết hợp lại, toàn bộ nhà máy chỉ là một vài plugin, được quản lý phiên bản trong git hoặc theo dõi như các phụ thuộc từ registry bối cảnh của bạn. Vì nhà máy được điều khiển bởi các kỹ năng, nên rất dễ thay đổi mà không làm “hỏng nhà máy”. Vì mỗi vòng lặp chỉ là một kỹ năng trong repo, nhà máy rất dễ tự tối ưu hóa khi nó chạy. Và vì các kỹ năng có tính di động, những gì một vòng lặp học được sẽ được tái sử dụng bởi mọi vòng lặp khác sử dụng các kỹ năng đó.

Cách hầu hết mọi người xây dựng nhà máy và lý do họ thất bại

Hầu hết các nhà máy bắt đầu từ một bản năng khác. Các kỹ sư tìm đến mã nguồn trước, vì mã nguồn là thứ chúng ta biết và nó có vẻ là lựa chọn dễ dự đoán. Xu hướng là xây dựng nhanh và làm cho thứ gì đó hoạt động, vì vậy công việc chậm hơn là viết quy trình xuống và thống nhất với đội ngũ đã bị bỏ qua. Mỗi trong ba thất bại dưới đây đều bắt nguồn từ đó.

Quy trình làm việc được định nghĩa trong mã nguồn rất dễ vỡ

Mọi quy trình làm việc đều có sự mơ hồ. Bất kỳ quy tắc nào được ghi trong mã nguồn mang tính quyết định (deterministic code) đều sẽ có ngoại lệ, và mã nguồn xử lý chúng rất tệ. Tệ hơn nữa, các rào cản bảo vệ (guardrails) vốn thận trọng cho một thế hệ mô hình này lại trở thành chiếc áo khoác vô hình cho thế hệ tiếp theo, và không ai quay lại để loại bỏ những giàn giáo không còn hiệu quả.

Luồng ticket-to-PR cho thấy cả hai vấn đề này. Nó gần như luôn được mô hình hóa như một đường ống (pipeline) với mã nguồn làm cốt lõi. Mã nguồn kéo repo và chạy thiết lập. Một tác nhân được giao nhiệm vụ, thường bị khóa chặt trong những gì nó có thể truy cập và thực hiện. Mã nguồn đẩy PR. Webhook kích hoạt các tác vụ tác nhân cụ thể: sửa CI, phản hồi đánh giá. Sau một cổng kiểm soát, mã nguồn hợp nhất nhánh.

Nhưng đường ống này nhanh chóng trở thành một mớ hỗn độn của các ngoại lệ và trường hợp đặc biệt. Các tính năng lớn liên quan đến nhiều repo. Một ticket cần các PR xếp chồng. Một thay đổi nội dung tầm thường xứng đáng với một đánh giá nhẹ nhàng hơn. Mỗi thứ trở thành một nhánh trong đường ống, và đường ống trở nên cứng nhắc xung quanh những gì các mô hình có thể làm khi nó được viết.

Các nhà máy dựa trên bối cảnh mặc định ưu tiên khả năng thích ứng. Tác nhân đọc quy trình và thực hiện phán đoán, đồng thời nó đạt được hiệu quả và tính quyết định từ các công cụ mà nó gọi thay vì từ một đường ống quyết định thay cho nó. Bối cảnh thúc đẩy công việc và các công cụ là những người hỗ trợ, giống như đối với con người, chứ không phải ngược lại.

Tri thức bị cô lập

SDLC ngày nay hoạt động hiệu quả vì kỹ sư đánh giá PR mang cùng kiến thức đó vào quá trình phát triển của chính họ. Các tác nhân phá vỡ luồng đó, vì một tác nhân khác nhận mỗi nhiệm vụ và biến mất khi nó kết thúc. Các công cụ có tính năng ghi nhớ giúp ích, nhưng chúng giữ việc học của mình trong trạng thái riêng tư. Một công cụ đánh giá đã học được sở thích của bạn sẽ đánh giá tốt hơn, nhưng các PR của bạn không đến nơi một cách sạch sẽ hơn.

Những bài học được chia sẻ đó là bánh đà mà một nhà máy phải tạo ra, và phần thưởng là rất lớn. Khi những bài học đánh giá phản hồi ngược lại quá trình tạo mã, các PR sẽ đến nơi chính xác ngay từ lần đầu tiên. Điều đó có nghĩa là ít vòng triển khai hơn và đánh giá rẻ hơn, nhẹ nhàng hơn. Các tiêu chuẩn tương tự sau đó có thể cung cấp năng lượng cho các tác nhân bảo trì quét codebase theo lịch trình và bắt kịp sự sai lệch lọt qua bất kỳ PR cá nhân nào. Các đội ngũ không đóng được vòng lặp này sẽ đối mặt với một tương lai khó khăn: các kỹ sư kiệt sức dưới khối lượng PR của tác nhân, hoặc tụt hậu so với các đối thủ cạnh tranh đã làm cho quy trình này tích lũy giá trị.

Các nhà máy dựa trên bối cảnh giải quyết vấn đề này bằng cách giữ các tiêu chuẩn trong các plugin mà mọi bề mặt đều đọc. Các tác nhân đánh giá, tạo mã và bảo trì đều dựa trên cùng các tệp, vì vậy những bài học ở một nơi sẽ tự động lan tỏa khắp mọi nơi.

Công cụ đi trước thiết kế quy trình, ngăn cản sự đồng thuận của đội ngũ

Gần như mọi quá trình xây dựng nhà máy đều bắt đầu bằng hạ tầng và công cụ. Kết nối một vài thứ lại với nhau và xem các quy trình làm việc chạy có vẻ như là một siêu năng lực. Nhưng cách tiếp cận này làm phân tán các quyết định và bối cảnh kinh doanh trên các công cụ, bị mắc kẹt trong các màn hình cấu hình, hoặc ẩn trong mã nguồn kết dính mà chỉ một nửa đội ngũ hiểu. Không có nơi nào để trình bày nó ra để đội ngũ có thể nói đồng ý, đây là cách chúng ta làm việc này.

Chúng tôi đã học được bài học này từ chính đội ngũ GTM của mình. Ai đó đã xây dựng một bộ tự động hóa thu thập các cuộc gọi khách hàng, tạo ra thông tin chi tiết và đưa chúng vào một chuỗi các công cụ khác để thúc đẩy việc ưu tiên. Không ai biết chính xác các thông tin chi tiết được tạo ra như thế nào, vì vậy bất cứ khi nào mọi người không đồng ý, họ đều bác bỏ quy trình. Tác động bị hạn chế vì đội ngũ chưa bao giờ được tham gia vào. Khi chúng tôi quyết định làm lại quy trình, chính sách nằm trong một loạt các hộp văn bản gợi ý khó cộng tác, và các tự động hóa khác dựa vào đầu ra của nó, vì vậy chúng tôi đang di chuyển một đường ống thay vì chỉnh sửa một tài liệu.