Startup này giữ Claude và Codex, chuyển việc giấy tờ sang AI cục bộ

Một lập trình viên nhờ tác tử lập trình sửa lỗi trong một dịch vụ. Trước hết tác tử phải tìm phiếu báo lỗi ban đầu, truy xuất một số quyết định về sản phẩm và xác định yêu cầu nào còn hiệu lực. Sau bản vá, cần có người chuyển phần còn lại thành các phiếu công việc để nhà thiết kế hoặc trưởng nhóm hỗ trợ có thể xem. Sửa mã chỉ là một phần, nhưng cả chuỗi công việc có thể dồn lên cùng một mô hình trả phí.

Trong bản thảo công bố ngày 5 tháng 11 năm 2026, Grayhat Developers, công ty phần mềm có dưới 40 người, kể lại điều xảy ra khi họ tách các việc ấy. Các kỹ sư đã thử mô hình tự lưu trữ cho công việc phát triển và nhận thấy thay tác tử lập trình thương mại khiến một số tác vụ trong kho mã chậm hoặc khó hơn. Họ giữ các tác tử đó cho thay đổi phức tạp và chuyển một phần việc truy xuất, chuẩn bị tài liệu và đồng bộ phiếu sang dịch vụ cục bộ.

Câu hỏi thú vị với một nhóm nhỏ khác là nên chuyển phần nào trước. Trải nghiệm của Grayhat đem đến điểm xuất phát cụ thể, một ước tính đáng xem kỹ và một sai lầm khi hướng dẫn người mới có thể làm hỏng thử nghiệm trước khi nhóm học được gì về chất lượng mô hình.

Sửa lỗi đã tốn công thu thập bối cảnh trước khi chạm vào mã

Grayhat dùng Outline cho tài liệu, Plane để theo dõi việc và ERPNext cho thông tin tổ chức. Nhóm đã đặt các dịch vụ đó trên một máy tại văn phòng và kết nối hệ thống danh tính qua Authentik. Họ cũng lưu trữ các bộ kết nối Model Context Protocol, hay MCP, trên cùng máy. Máy thứ hai chạy suy luận mô hình. Cách tách này có lý do thực tế. Hệ thống tài liệu và phiếu vẫn phục vụ các giao diện thông thường trong khi tác vụ mô hình tiêu thụ tài nguyên tính toán ở máy khác.

Quy trình trong bài báo có các bước bàn giao do con người thực hiện. Một thành viên dùng mô hình nội bộ để lấy và cô đọng tài liệu từ wiki hoặc hệ thống theo dõi vấn đề. Những phần liên quan có thể đưa vào tệp trong kho mã cho tác tử lập trình. Sau khi làm việc trong kho mã, một thành viên có thể đưa các bước tiếp theo về trợ lý nội bộ, soạn phiếu nháp rồi gửi lên hệ thống theo dõi. Bài báo coi việc các tác tử giao tiếp trực tiếp là hướng phát triển sau này. Hiện tại con người đã có thể thấy thông tin tại điểm bàn giao và quyết định điều gì nên chuyển qua.

Các điểm bàn giao trong quy trình Grayhat. Minh họa do Telli.sh thực hiện dựa trên nghiên cứu tình huống ngày 5 tháng 11.

Giả sử khách hàng báo tệp xuất bị lặp dòng. Báo cáo gốc có mã tham chiếu tài khoản riêng tư và bản chép lời không liên quan đến lỗi. Trợ lý cục bộ có thể tìm quy tắc xuất hiện hành, người phụ trách dịch vụ và cách khắc phục tạm trước đó. Kỹ sư có thể viết bản tóm tắt với ví dụ giả lập và số dòng dự kiến. Tác tử lập trình nhận đủ thông tin để tái hiện lỗi. Dữ liệu nhạy cảm ở lại hệ thống nội bộ vì con người quyết định nội dung được chuyển qua.

Giữ đường dẫn gốc trong bản nháp nội bộ. Khi các yêu cầu bất đồng, người duyệt có thể thấy quy tắc được đề xuất đến từ quyết định mới hay cách khắc phục cũ. Bản tóm tắt tạo cục bộ mà bỏ mất nguồn vẫn tái tạo phần nào vấn đề nó cần giải quyết. Người tiếp nhận kế tiếp lại phải đoán mô tả nào đáng tin.

Nhóm mua năng lực xử lý rồi ước tính phần có thể chuyển

Các tác giả báo cáo mức chi AI thương mại khoảng 325 USD mỗi tháng, gồm khoảng 175 USD cho bảy suất Claude, 140 USD cho bảy thuê bao Codex và 10 USD tín dụng. Họ cũng báo cáo hơn 25,93 tỷ token được ghi nhận trên các dịch vụ. Bài báo chưa xác định số token ghi nhận thuộc cùng kỳ thanh toán với khoản 325 USD. Hãy dùng mỗi con số theo đúng thứ nó đo, thay vì chia hai số để suy ra đơn giá token.

Grayhat ước tính việc chuyển bối cảnh, làm tài liệu và điều phối dự án chiếm 30–40% khối lượng việc AI thương mại. Các tác giả cho rằng hệ thống cục bộ có thể tiếp nhận khoảng 90% nhóm việc này. Nhân các tỷ lệ cho kết quả 27–36% tổng khối lượng việc thương mại. Quy tỷ lệ đó theo mức 325 USD cho kết quả khoảng 88–117 USD mỗi tháng. Đây là ước tính khối lượng và chi phí tương đương trong nghiên cứu ngày 5 tháng 11. Bài báo chưa thực hiện thí nghiệm có kiểm soát so sánh hóa đơn trước và sau.

Ước tính của Grayhat bắt đầu từ tỷ lệ công việc và kết thúc ở chi phí tương đương. Minh họa do Telli.sh thực hiện.

Sự phân biệt này quan trọng khi tính tiền theo người dùng. Nếu bảy lập trình viên vẫn cần thuê bao để làm việc phức tạp, mức sử dụng giảm có thể không ảnh hưởng hóa đơn tiếp theo. Lợi ích có thể là dư sức làm thêm một loạt bản vá, bớt áp lực hạn mức hoặc giảm mua thêm dung lượng. Nhóm trả theo yêu cầu có thể thấy thay đổi sớm hơn, nhưng các lần thử lại và hàng đợi chậm có thể làm mất một phần lợi ích. Nếu phải mua GPU mới và trả công người giữ hệ thống hoạt động, hãy đưa cả hai vào so sánh.

Chọn đơn vị đo mà bạn có thể kiểm tra. Số phiếu đã soạn dễ đếm, nhưng phiếu bị trưởng dự án viết lại từ đầu hầu như không chứng minh được khoản tiết kiệm. Hãy đếm bản tóm tắt và phiếu được chấp nhận, đồng thời ghi các chỉnh sửa làm đổi ý nghĩa công việc. Khi người duyệt đã nhận diện nhất quán đầu ra đạt yêu cầu, hãy theo dõi công sức bỏ ra để tạo chúng.

Giao diện thứ hai chuyển trách nhiệm thiết lập

Đợt triển khai đầu dùng LobeHub. Kỹ sư nhận hướng dẫn để tự kết nối giao diện của mình với công cụ nội bộ. Các tác giả cho biết bản demo đầy triển vọng không dẫn đến sử dụng thường xuyên. Người dùng phải biết chọn bộ kết nối nào, nó nằm ở đâu và xác thực ra sao. Mỗi lựa chọn thêm đều cản đường đến câu trả lời hữu ích đầu tiên.

Giao diện thứ hai của Grayhat đã cấu hình tập trung công cụ làm việc. Hình 2 từ “Create Your Own Work Stack” của Saad Ahmed Bazaz, Talha Amjad, Abdurrehman Subhani, Sohaib Ahmed Bazaz và Abdullah Aamir, CC BY 4.0.

Nhóm chuyển sang bản LibreChat được cấu hình tập trung. Người dùng nhìn thấy các công cụ đã cấu hình và xác thực khi truy cập. Các tác giả đếm được tám nhận xét về thiết lập và làm quen từ 11 cuộc phỏng vấn có cấu trúc về bản đầu. Bản thứ hai ghi nhận ba nhận xét cùng nhóm qua phản hồi không theo mẫu trên Discord. Hai con số đến từ hai cách thu thập riêng. Chúng giúp nhận diện vấn đề làm quen, nhưng không cho biết tỷ lệ sử dụng tăng bao nhiêu hay bao nhiêu nhân viên không còn gặp vấn đề.

Thiết kế lần dùng đầu xoay quanh tác vụ thật nhỏ nhất. Trưởng dự án đăng nhập để tra tiêu chí nghiệm thu của một vấn đề nên thấy hệ thống theo dõi đã kết nối chưa và tài khoản nào đang hoạt động. Kỹ sư muốn soạn ba phiếu nên có thể xem lại trước khi đăng. Một nhóm bắt người dùng học cấu hình kết nối trước khi tìm được việc của mình có nguy cơ đo lòng kiên nhẫn thay vì tính hữu ích.

Thiết lập tập trung đem đến trách nhiệm mới. Cần có người duy trì danh sách kết nối đã duyệt, xoay vòng thông tin xác thực và giải thích ai được đổi quyền. Nếu thiếu vai trò đó, một cấu hình sai có thể thành vấn đề của cả nhóm. Lợi ích là nhóm chỉ cần sửa một lần cho lỗi thiết lập lặp lại và áp dụng bản sửa cho mọi người dùng dịch vụ.

Giao hệ thống cục bộ công việc có người chịu trách nhiệm đầu ra

Phân loại vấn đề là ứng viên thực tế để bắt đầu. Trợ lý nội bộ có thể gom các báo cáo trùng và đề xuất bản tóm tắt kèm liên kết phiếu nguồn. Chủ dự án quyết định hai báo cáo thực sự trùng hay mô tả hợp nhất bỏ sót điều kiện. Trợ lý có thể soạn bình luận giải thích vì sao gom. Con người biết điều gì xảy ra vì bản cập nhật có người chịu trách nhiệm rõ ràng.

Bảo trì tài liệu là dạng việc khác. Giả sử một thay đổi chuyển mục cài đặt từ màn hình này sang màn hình khác. Trợ lý có thể tìm trang trợ giúp đã cũ, xác định phiên bản sản phẩm chúng mô tả và soạn đề xuất sửa. Biên tập viên kiểm tra điều hướng hiện tại rồi xuất bản thay đổi đúng. Mô hình từ xa mạnh hơn đem lại ít giá trị nếu phần khó là truy cập đúng trang nội bộ mới nhất và giữ phạm vi của từng bài.

Lập trình phức tạp là trường hợp ngược lại. Một đợt di chuyển cơ sở dữ liệu có thể đòi hỏi đọc hợp đồng dữ liệu lịch sử, sửa nhiều dịch vụ và xác minh khả năng hoàn tác. Grayhat nhận thấy hệ thống cục bộ họ thử gặp khó khi xử lý công việc lớn hơn trong kho mã, nhất là khi mô hình cần bối cảnh rộng và suy luận kịp thời. Nghiên cứu mô tả phần cứng, mô hình và trải nghiệm của nhóm. Điều đó ủng hộ việc thử cục bộ trên khối lượng việc của chính bạn trước khi mở rộng.

Dùng luồng có giới hạn với tác vụ kết hợp định dạng đơn giản và dữ liệu nhạy cảm. Gửi bản nháp ra ngoài mạng vẫn có thể lộ thông tin dù công cụ gốc chạy tại chỗ. Nếu cần bàn giao từ xa, hãy duyệt đích đến và tạo tài liệu tối thiểu cho đích đó. Nếu kết quả nội bộ chưa được duyệt, hãy giữ trong hàng chờ nội bộ. Khi hết thời gian chờ, hãy hiện lỗi rõ ràng để tránh dữ liệu bị chuyển đi bất ngờ.

Thử nghiệm ngắn giúp tách công việc hữu ích khỏi việc trông hạ tầng

1. Xác định ba đầu ra. Chọn bản tóm tắt có liên kết phiếu, một chỉnh sửa tài liệu và một vấn đề nháp. Với mỗi loại, viết một câu chỉ rõ ai nghiệm thu và cần bằng chứng nào. Giữ một ví dụ không đạt bên cạnh ví dụ đạt, kể cả lỗi dễ bỏ qua.
2. Đo quy trình hiện tại. Trong một tuần làm việc bình thường, đếm ví dụ đã xong, chỉnh sửa quan trọng và thời gian tìm bối cảnh. Ghi mức dùng thương mại theo quy trình khi có thể. Ghi xem bỏ tác vụ có thực sự đổi số suất trả phí hay khoản vượt mức không. Theo dõi riêng việc nhóm đã tránh phải làm.
3. Kết nối một công cụ nội bộ. Bắt đầu với quyền đọc và một dự án cụ thể. Xác nhận nhân viên có quyền lấy được một vấn đề đã biết và người ngoài dự án thì không. Giới hạn thử nghiệm ở nhóm nhỏ đang làm những việc đã chọn. Cho họ đường hoàn tất thủ công khi công cụ lỗi.
4. So sánh bản nháp trước khi cho ghi. Nhờ cùng một người duyệt chấp nhận hoặc từ chối theo cùng tiêu chí. Ghi lại liên kết trỏ sai vấn đề, dữ kiện cũ và kết luận thiếu căn cứ. Thêm bước xem trước, phê duyệt và lưu vết bền vững trước khi cấp quyền cập nhật hệ thống theo dõi thật.
5. Kiểm tra việc đã chuyển. So sánh khối lượng được chấp nhận, thời gian duyệt, mức sử dụng thực và hóa đơn. Cộng thời gian bảo trì máy, gián đoạn và thay đổi bộ kết nối. Tính cả hỗ trợ thiết lập trực tiếp. Nếu ứng dụng chỉ dùng được sau khi chuyên gia hướng dẫn từng người mười phút, chi phí làm quen vẫn tồn tại.

Nếu đã chạy mô hình cục bộ cho lập trình viên, hãy thử song song với lưu lượng bình thường. Hàng đợi xuất hiện khi nhiều người bắt đầu cùng lúc. Dịch vụ xử lý một yêu cầu nhanh vẫn có thể khiến ba người phải chờ. Cho công việc gấp cách hiển thị tiến độ và đường quay về quy trình thủ công thông thường. Nhờ vậy nhóm vẫn sử dụng được trong lúc tìm hiểu việc nào phù hợp.

Phụ lục Grayhat cung cấp quy mô tham chiếu. Máy chạy công cụ có 16 GB bộ nhớ hệ thống, còn máy suy luận riêng có 32 GB cùng RTX 4080 với 16 GB VRAM. Nhóm báo cáo đã thêm giám sát mạng, lập lịch và bộ lưu điện khi nhu cầu vận hành trở nên rõ ràng. Đây là dữ liệu hữu ích để lập ngân sách thử nghiệm. Chúng phản ánh việc vận hành dịch vụ mà đồng nghiệp phụ thuộc, bên cạnh chi phí cho mô hình trả lời.

Chọn nơi dành giờ làm việc tiếp theo của AI

Ý tưởng có thể áp dụng lại là tách chuẩn bị bối cảnh khỏi suy luận chuyên sâu và giao mỗi điểm bàn giao cho một người chịu trách nhiệm. Bắt đầu với việc lặp lại thường xuyên và tạo đầu ra nhóm đã biết cách duyệt. Đo công sức nghiệm thu đầu ra ấy rồi quyết định có giao thêm việc cho luồng cục bộ hay không. Trải nghiệm của Grayhat cho bạn cách ra quyết định đó trong khi vẫn giữ các công cụ lập trình còn đem lại giá trị.

Nguồn

• Bản thảo Grayhat Developers ngày 5 tháng 11 năm 2026
• Toàn văn, gồm ước tính khối lượng công việc, hạ tầng và Hình 2
• Ảnh gốc Hình 2
• Giấy phép CC BY 4.0 cho hình trong bài báo

---

Để lưu các trao đổi đằng sau một lần bàn giao dưới dạng có thể tìm kiếm, hãy tạo tài khoản Telli.sh.