Tác giả: Học Trò và Claude AI.
Cửa sổ dòng lệnh cho ta cái gì mà cái khung gợi ý bên hông trình soạn thảo không cho được — chuyện kể cho người không phải dân thảo chương
Viết ngày 1 tháng Tám, 2026. Bài này viết lại từ một quyển sách dài hơn và riêng tư hơn, kể về một năm trời làm việc chung với một trợ tá AI, trong khuôn khổ một gói thuê bao thường thường bậc trung, có giới hạn mức xài. Quyển sách đó viết cho người đã sống qua cái năm ấy. Bài này thì viết cho một người khác hẳn: một người đi làm, đã và đang xài trợ tá AI ngay trong trình soạn thảo mã (code editor) của mình, không phải dân thảo chương và cũng không có ý trở thành dân thảo chương, và đã nghe loáng thoáng đâu đó rằng "cái terminal" mới là chỗ có chuyện hay ho — mà chưa ai chịu nói cho nghe cái đó thực sự nghĩa là gì, và mắc gì phải chịu cực đi học nó. Mọi chuyện trong bài đều rút ra từ một năm làm thiệt, việc thiệt. Không nêu tên file, không nêu tên công cụ, không nói tới tính năng của sản phẩm nào — chỉ có ý tưởng, và cái giá phải trả để học được từng ý một.
Ghi chú riêng cho bản tiếng Việt: nguyên tác viết cho người đọc bên Mỹ, vốn đã xài AI hằng ngày ở sở làm, nên nhiều khái niệm tác giả chỉ nói lướt qua một câu là người ta hiểu. Bản này có nới rộng ra ở những chỗ đó — thêm câu, thêm thí dụ, thêm phần cắt nghĩa mấy chữ nhà nghề — để bạn đọc ở nhà không phải vừa đọc vừa đoán. Chữ tiếng Anh nào cần thiết thì tôi để trong ngoặc, vì đằng nào bạn cũng sẽ gặp lại nó trên màn hình.
Một lời thú nhận làm đảo ngược cả bài
Xin bắt đầu bằng cái chi tiết đá giò lái ngay chính người viết.
Người mà cái năm làm việc của họ được kể lại trong bài này là một kỹ sư nhu liệu (software engineer). Làm về xây dựng và kết cấu, làm tự động hóa cho các nhu liệu vẽ kỹ thuật (CAD), trên 30 năm xài nhiều ngôn ngữ thảo chương thiệt (C, C++, AutoLisp, Java, Vidual Basic 6, VB.NET, C#, v.v) để làm ra sản phẩm thiệt cho hãng xưởng — chớ không phải kiểu tài tử, học chơi cho biết. Vậy mà trong một thư mục làm việc sau này chứa tới mấy trăm chương trình lớn nhỏ — nào là công cụ đọc cao độ nốt nhạc trên bản nhạc scan bằng cách đo từng chấm ảnh (pixel), nào là mấy đoạn mã đi rà soát để bắt cho ra một cái link sai lạc giữa mấy trăm cái link đúng, nào là cả một dây chuyền dịch nguyên quyển sách năm trăm trang, dịch từng đoạn một theo số thứ tự — ông ta không tự tay gõ lấy một dòng nào trong đó hết.
Chuyện này không phải khoe khoang kiểu "tôi biết giao việc cho người khác", mà cũng không phải thú nhận là mình làm biếng. Nó chính là cái lý lẽ của cả bài, nói trước ra ngay từ đầu. Nếu một người thừa sức viết tay từng chương trình đó, mà viết còn nhanh hơn là ngồi tả cho máy nghe, vậy mà suốt một năm trời vẫn cố tình chọn không viết — thì câu hỏi đáng bàn không còn là "AI có viết được mã hay không". Chuyện đó ai cũng biết rồi. Câu hỏi đáng bàn là: khi phần việc gõ phím đã dọn ra khỏi tay người kỹ sư hết, thì cái còn lại trong sự phán đoán của ông ta là cái gì — và cái phần còn lại đó, một người không biết thảo chương có học được không?
Câu trả lời mà bài này bênh vực là: học được. Và cửa sổ dòng lệnh (terminal) chính là chỗ để học, bởi vì đó là nơi duy nhất mà phần việc máy móc thực sự nằm ngoài tay bạn.
Cũng nên nói cho rõ điều đó có nghĩa gì với bạn, nếu bạn hoàn toàn không phải dân kỹ thuật. Cái phần bị lấy đi là phần gõ: cú pháp, tra cứu thư viện hàm, cái công đoạn máy móc để dịch một ý tưởng trong đầu thành mã chạy được. Cái phần ở lại — mà thiệt ra còn nặng thêm — là: quyết định cho thật chính xác món đồ này phải làm được cái gì, kiểm lại coi nó có làm đúng vậy thiệt không, và định trước rằng lần tới nếu nó sai theo một kiểu chẳng ai ngờ tới thì mình sẽ xử ra sao. Cái danh sách thứ nhì đó không phải là thảo chương. Đó là mô tả của một người làm nghề đàng hoàng, trong bất cứ ngành nghề nào, và mỗi ngày bạn đã đang làm một phiên bản của nó rồi. Thí dụ cụ thể nhất là bài cùng ra ngày hôm nay https://hoctroviet.blogspot.com/2026/08/ten-cac-tac-gia-tung-cong-tac-voi-tap.html , tôi làm nó mà không viết tới một dòng mã Python.
Chương Một — Cái trợ tá AI trong trình soạn thảo của bạn thực sự đang làm gì, và nó ngừng ở đâu
Trước hết xin tả lại cho rõ cái ta đang so sánh, kẻo nói qua nói lại mà hai người hiểu hai kiểu.
Cái trợ tá AI nằm trong trình soạn thảo — cái khung gợi ý hiện lên bên hông, hoặc hiện lên chữ mờ mờ ngay chỗ con trỏ, đề nghị nốt phần câu bạn đang gõ dở — cực kỳ giỏi ở đúng một dạng bài: bạn đang ngó vô một chỗ, bạn đã lờ mờ biết cái gì phải tới kế tiếp, và nó đỡ cho bạn cái công gõ. Nó đọc cái file bạn đang mở, có khi đọc thêm vài file lân cận. Nó đề nghị. Bạn nhận, hoặc bạn bỏ. Vòng quay đó nhanh, thua thiệt cũng nhẹ, và gói gọn hoàn toàn trong cái màn hình trước mặt bạn.
Cái đó quý thiệt, và bài này không hề có ý can bạn đừng xài. Nhưng xin để ý cái hình dáng của bức tường bao quanh nó, vì mọi giới hạn kể sau đây đều từ đó mà ra. Cái trợ tá đó chỉ thấy cái bạn đang mở. Nó không thấy bốn trăm file còn lại trong dự án. Nó không chạy thử được cái gì rồi coi kết quả ra sao. Nó không có cách nào để tới thứ Năm còn nhớ cái bạn dạy nó hôm thứ Ba. Nó không mang theo một bộ luật lệ thường trực nói rằng công việc trong dự án này phải làm theo lối nào. Và đơn vị công việc của nó là một lời gợi ý mà bạn sẽ nhận hay bỏ trong vòng hai giây — nghĩa là nó chỉ giúp được những việc nhỏ tới mức phán đoán xong trong hai giây.
Cái ràng buộc cuối đó mới là cái trần thiệt sự, và hồi bạn còn đang ở bên trong nó thì bạn không thấy nó đâu. Một công cụ chỉ giúp được những quyết định hai giây, lâu ngày nó lặng lẽ dạy bạn chỉ đem tới cho nó những bài toán hai giây. Rồi bạn hết còn để ý tới đống việc mình không đem tới cho nó nữa: cái bảng tính cần lặp lại cùng một phép sửa trên mười một cái tab; cái thư mục hai trăm cuốn PDF scan mà từ trước tới giờ chưa ai lập mục lục; cái bản báo cáo lẽ ra tháng nào cũng nên dựng lại tự động từ đúng sáu nguồn dữ kiện đó, mà rốt cuộc tháng nào cũng ngồi ráp tay; cái vụ chuyển nguyên bộ tài liệu từ định dạng này qua định dạng khác mà ai cũng đồng ý là nên làm, và không ai có nổi ba ngày rảnh liên tiếp để làm.
Mấy cái đó không phải bài toán thảo chương. Đó là bài toán công việc, và cái nào cũng cùng một cấu trúc: lớn quá, ôm hết trong đầu một lần không nổi; lặp đi lặp lại nhiều quá, làm tay không xuể; mà lại lẻ tẻ thất thường quá, mướn hẳn một người thảo chương thì không đáng. Đó đúng y cái hình dáng mà terminal kham được, còn cái khung gợi ý bên hông thì không.
Chương Hai — Dời qua terminal thì thực sự đổi cái gì
Chỗ khác nhau về mặt máy móc thì chẳng có gì hào nhoáng. Thay vì một cái hộp gợi ý nằm cạnh dòng mã của bạn, bạn có một cuộc đối thoại với một thứ có thể: nhìn được nguyên thư mục của bạn, mở bất cứ file nào trong đó, viết ra file mới, chạy chương trình, đọc coi chương trình đó in ra cái gì, rồi sửa và làm lại. Toàn bộ chỗ khác nhau về khả năng chỉ có bấy nhiêu. Mọi thứ còn lại trong bài này đều từ đó mà suy ra.
Nói thêm cho bạn nào chưa từng đụng tới: "terminal" chỉ là một cửa sổ chữ đen chữ trắng, bạn gõ câu vô đó bằng tiếng người bình thường, và cái trợ tá trả lời ngay trong cửa sổ đó. Nó không hề đòi bạn phải biết mấy câu lệnh cổ lỗ sĩ kiểu dir, cd, grep. Bạn cứ viết như viết cái email dặn việc cho một người phụ tá mới vô làm. Cái khác duy nhất — và là cái khác quan trọng — là người phụ tá này có chìa khóa vô nguyên cái thư mục, chớ không phải chỉ được ngó qua vai bạn coi một trang giấy.
Nhưng cái khác về mặt thực dụng thì lớn hơn cái khác về mặt máy móc, và nên gọi tên ra làm bốn phần.
Đơn vị công việc trở thành một việc, chớ không còn là một cú gõ phím. Bạn thôi nói "viết nốt dòng này" mà bắt đầu nói "đi hết mọi tài liệu trong thư mục này, rút cái mục lục của từng cuốn ra, rồi gom lại cho tôi một bảng tra cứu duy nhất đã sắp thứ tự". Đó là một câu mà bất cứ người đi làm nào cũng nói được. Nó không đòi cú pháp, không đòi bạn biết cái chương trình sắp được viết ra sẽ viết bằng ngôn ngữ gì — thậm chí không đòi bạn biết rằng sẽ có một chương trình được viết ra.
Có một vòng kiểm tra và sửa sai mà bạn không đứng ở giữa. Khi cái trợ tá viết ra một thứ, đem chạy, và nó chạy hỏng, thì nó đọc cái lời báo lỗi rồi tự sửa, không cần tới bạn. Đây là lý do lớn nhất khiến terminal với tới được những bài toán mà cái khung bên hông không với tới: một lời gợi ý bên hông là một phỏng đoán không có cách nào tự kiểm chứng, còn một việc giao trong terminal là một phỏng đoán cộng một lần kiểm cộng một lần sửa, lặp đi lặp lại cho tới khi kiểm lọt. Bạn không còn là cái lớp phiên dịch giữa "lời báo lỗi" và "cách sửa" nữa. Bạn là người quyết định cái thứ cuối cùng chạy lọt đó có đúng là cái mình muốn hay không.
Sản phẩm làm ra không nhất thiết phải là mã. Chỗ này quan trọng ghê gớm với người đọc mà bài này nhắm tới, mà cũng là chỗ đa số người ta bỏ sót. Suốt cái năm có thiệt đằng sau bài này, sản phẩm làm ra là: bài viết, sách dịch qua bốn thứ tiếng, mục lục tra cứu cho mấy ngàn bài báo trong tạp chí cũ, danh sách đường dẫn nhạc đã kiểm chứng từng cái, bản ký âm chép lại từ bản thảo viết tay, và sách in ra giấy đàng hoàng. Mã thì có, mà có rất nhiều — nhưng có với tư cách đồ nghề dùng rồi bỏ, dựng lên để làm ra mấy thứ kia, chẳng ai đọc tới, giữ lại chỉ vì biết đâu có bữa cần chạy lại. Bạn không cần trở thành người biết đọc mã mới trở thành người biết đặt hàng người ta viết mã.
Lời dặn dò nằm lại được. Ở cái khung bên hông, mọi thứ bạn biết đều bốc hơi giữa hai phiên làm việc. Trong một dự án làm ở terminal, bạn viết xuống được rằng ở đây công việc phải làm theo lối nào — viết bằng tiếng người bình thường, trong một tờ giấy bình thường nằm ngay cạnh chỗ làm việc — và tờ đó được đọc trước khi bất cứ việc gì bắt đầu. Đây chính là cái tính năng biến "một năm xài AI" thành "một năm tích lũy được cái gì đó", và một nửa những chuyện kể sau đây đều xoay quanh nó.
Chương Ba — Bốn cái trần, nói cho cụ thể
Câu "AI thì có giới hạn của nó" nói ra thì mơ hồ quá, không dựa vô đó mà tính toán gì được. Trên một gói thuê bao thường của người tiêu dùng — không phải trương mục hạng doanh nghiệp với ngân sách co giãn thoải mái, cũng không phải tiền tài trợ nghiên cứu — mấy cái giới hạn đó có bốn hình dáng rất cụ thể. Và mọi cái hàng rào an toàn nhắc trong bài này đều có mặt vì một trong bốn cái trần đó đã bị đụng ít nhất một lần, và phải dựng cái gì đó lên để đừng đụng y như vậy lần thứ nhì.
Cái đồng hồ đo mức xài. Công việc không hề miễn phí như người ta tưởng khi buông câu "thì cứ nhờ AI làm chớ gì". Mỗi lần đọc một file, mỗi lần chạy một câu lệnh, mỗi lần thả thêm một "thợ phụ" ra làm song song, đều trừ vô cùng một cái hạn mức chung. Cho chạy một lượt bốn thứ thì cái đồng hồ quay nhanh gấp bốn — nghe thì có vẻ lợi, cho tới lúc nó cạn ngay giữa chừng và không thứ nào trong bốn thứ đó xong.
Cái khung trí nhớ tạm có mép cứng. Chữ nhà nghề gọi là context window. Xin hình dung nó như cái mặt bàn: một cuộc đối thoại chỉ trải ra được chừng đó giấy tờ cùng một lúc, và cái mặt bàn đó không nới ra được. Một dự án bốn trăm file, hay một quyển sách dài, không cách nào nằm hết trên bàn một lượt. Cái gì lớn hơn cái bàn thì phải cố ý chia nhỏ ra, kèm theo một cách để làm tiếp từ chỗ đứt — bằng không thì công việc lặng lẽ rơi mất, mà lại rơi mất không kêu một tiếng nào.
Không có trí nhớ giữa hai phiên làm việc, trừ khi bạn tự dựng lấy một cái. Mỗi cuộc đối thoại mới đều bắt đầu từ con số không. Một bài học ba tuần trước phải trả giá đắt mới học được thì nay đơn giản là không còn nữa, trừ phi có người đã viết nó xuống ở một chỗ mà phiên sau được dặn là phải đọc.
Các hạng model, tức là cái vụ đánh đổi giữa tiền và chất lượng, mà đúng lúc đánh đổi thì mình không thấy. Nói cho dễ hiểu: cùng một hãng AI thường có nhiều "đời máy", cái nhanh và rẻ, cái chậm và mắc. Hai cái đó không thay thế cho nhau được, và chỗ khác nhau thì không chịu tự khai ra bằng một thông báo lỗi. Có khi nó hiện ra dưới dạng mấy trăm chữ trôi chảy, tự tin, câu cú đàng hoàng — mà sai, sai theo cái kiểu bạn đọc lướt sẽ không bắt được.
Bốn thứ này, nói trên lý thuyết thì chẳng có gì đáng ngạc nhiên. Cái đáng nói cho thật thà là: không cái nào trong bốn cái được tính trước hết. Mọi luật lệ kể ở dưới đều được viết ra sau khi đã đụng trần. Mà đó cũng là bài học hữu ích nhất của bài này: bạn sẽ không nghĩ ra được một lối làm việc hay ho trước khi bắt tay vô làm đâu. Bạn sẽ sai trước cái đã, rồi mới viết xuống được là mình đã sai chính xác ở chỗ nào.
Chương Bốn — Chạy song song là cái bẫy, khi cái đồng hồ tính tiền là của chung
Một buổi chiều, đang làm tới một bộ nhạc lớn cần tách ra rồi chép lại từng bài, có bốn "thợ phụ" chạy ngầm được thả ra một lượt. Nhìn thì đúng bài bản sách vở: bốn khúc việc độc lập, bốn người làm, xong trong một phần tư thời gian.
Trương mục đụng trần mức xài ngay giữa chừng. Cả bốn thợ phụ đều hỏng dở dang. Hai đứa quay về tay không, chỉ đưa ra mấy cái file rỗng — file thì có đó, mở ra thì bên trong không có lấy một chữ việc thiệt. Nhưng mất công việc chưa phải là chỗ tệ nhất; chỗ tệ nhất là sự mập mờ: đứng ngoài không có cách nào biết được đứa nào trong bốn đứa đã lặng lẽ hết tiền trước khi làm xong và đứa nào thiệt sự làm trọn. Thành ra không có cái kết quả nào tin được hết. Phải làm lại từ đầu, làm tuần tự từng cái một, làm ngay trong cuộc đối thoại chính, chỗ mà mỗi bước đều nhìn thấy được.
Cái luật rút ra từ bữa đó nay nằm ở dòng đầu tiên trong tờ nội quy của dự án, đứng trên hết mọi thứ khác: ở đây đừng giao việc cho mấy thợ phụ chạy ngầm song song; cứ làm thẳng, làm ngay trong dòng, dù có phải làm nhiều bước và mất nhiều thì giờ.
Chỗ nghịch lý nằm ở chỗ cái luật đó đang nhắm giữ cho được cái gì. Bốn thợ phụ cảm giác là nhanh hơn, và nếu cái đồng hồ tính tiền không có trần thì đúng là nhanh hơn thiệt. Nhưng khi có trần, cái giá của việc làm lại sau một lần hỏng đã ăn hết phần lời; mà một cái hỏng xảy ra tuốt trong một luồng chạy ngầm thì khó bắt sớm hơn nhiều so với cái hỏng xảy ra ngay trước mắt bạn. Làm tuần tự nhưng nhìn thấy được, rốt cuộc lại là con đường nhanh thiệt, một khi đã đếm cho sòng phẳng cái giá của kiểu hỏng nửa chừng mà im ru.
Đây không phải một lời tuyên bố chung về mấy "tác tử" AI (agent), và hiểu theo nghĩa đó là hiểu sai. Đây là một lời tuyên bố rất riêng về cái giá của việc chạy song song khi cái đồng hồ tính tiền là của chung và có giới hạn — mà đó chính là mô tả của mọi gói thuê bao cá nhân, tức là mô tả của bạn.
Chương Năm — Việc lớn thì phải chia đợt, đừng bao giờ cho chạy một lèo
Cái trần thứ nhì im hơn một lời báo lỗi: có những việc lớn quá, không nhét vô một lượt được, và cách phản ứng ngây thơ nhất — "thì cứ cho nó làm nguyên cục một hơi cho rồi" — hỏng theo kiểu lặng thinh chớ không hỏng theo kiểu la làng.
Thí dụ rõ nhất là một quyển sách năm trăm trang, viết lai rai trong hai chục năm, cần dịch ra thành ba ấn bản tiếng Anh, tiếng Pháp và tiếng Ý, hay đủ để đem in. Quăng nguyên bản thảo vô một cuộc đối thoại thì không đời nào xong — không phải vì máy báo "quá cỡ", mà vì một lần chạy dài thượt và không có kết cấu như vậy thì không cho bạn cách nào kiểm phần đã làm được, cũng không cho cách nào nối lại cho gọn sau khi bị đứt ngang. Cái thay cho câu "thì cứ dịch đi" là: rút hết từng đoạn văn trong bản gốc ra thành một danh sách có đánh số; dịch theo đợt, mỗi đợt năm chục tới chín chục đoạn; ráp lại; rồi ghi từng đoạn đã dịch trở vô đúng vị trí số thứ tự cũ của nó trong tài liệu gốc.
Mấy tháng sau, một lần rà soát lại ấn bản tiếng Anh đã hoàn tất phát hiện ra ba khúc đã lặng lẽ biến mất — nội dung mất tiêu kể từ sau một trang nọ trong bản in thử. Nhờ công việc có đánh số, cách chữa chỉ là vá đúng ba khúc đó. Không phải làm lại cái gì đã đúng, và cũng không phải đi dò lại từ đầu coi phần nào thì đã xong rồi.
Cái hình dáng đó — đánh số công việc, làm theo từng khúc có giới hạn, ghi tình trạng xuống đĩa sau mỗi khúc, dựng lại cái bản kết quả nhìn thấy được sau mỗi lần — lặp lại ở mọi việc lớn trong năm đó: một dây chuyền đi tìm rồi kiểm chứng, rốt cuộc chạy qua hơn một ngàn món trong ba bộ sưu tập khác nhau; và một đợt rút mục lục từ mấy trăm số tạp chí scan. Chạy tới chừng đó lần thì đúc ra được bốn câu bỏ túi, và cả bốn đều đem qua xài thẳng được cho bất cứ việc số lượng lớn nào bạn định đem tới terminal.
Luôn luôn chạy thử một lô nhỏ trước. Cho chạy cách làm đó trên năm tới mười món thôi, chạy đồng bộ ngay trước mắt mình, tự tay đọc kết quả, rồi đối chiếu với những gì mình đã biết chắc là đúng, xong rồi mới nhân lên. Mọi con bọ (bug) thiệt sự trong mấy dây chuyền của năm đó đều bị bắt theo kiểu này, hồi vết thương còn có năm dòng chớ chưa phải sáu trăm dòng.
Mỗi lần chỉ cho một người ghi. Hai tiến trình cùng cập nhật một cái file theo dõi sẽ đè lên nhau và làm mất dòng một cách im ru. Chuyện này chán ngắt, nó không phải chuyện của riêng AI, và nó sẽ cắn bạn đúng một lần.
Món nào không chạy trót lọt thì đánh dấu rồi đi tiếp. Trong đám tạp chí scan có mấy số không hề có trang mục lục xài được. Cái phản xạ tự nhiên — dừng lại, ngồi chép tay nguyên cuốn này, dựng lại cái đáng lẽ chỉ là một cú tra cứu năm giây — đúng là cái phản xạ ngốn sạch ngân sách của cả một phiên làm việc cho một cuốn, trong khi chín mươi chín cuốn khác ngồi chờ. Cứ ghi một dòng tạm, đề "cuốn này cần người coi lại", rồi đi tiếp.
Làm tới đâu lưu tới đó. Nếu một phiên làm việc dài có thể đứt trước khi công việc xong, thì mấy phần đã xong phải nằm sẵn trên đĩa rồi. Soạn hết trong đầu rồi cuối cùng mới ghi ra một lượt, nghĩa là khi đụng trần bạn mất trọn gói thay vì mất số không.
Cái nguyên tắc nằm dưới cả bốn câu, nói gọn một lần: đừng bao giờ cho một việc chạy một lèo không ai kiểm, khi nó có thể chia thành một chuỗi các đợt có chốt và có thể làm tiếp từ tình trạng đã ghi xuống đĩa. Kiểu hỏng mà một lần chạy dài không kết cấu sinh ra không phải là "nó ngừng và báo lỗi". Nó là "nó đẻ ra một thứ trông y như đã xong mà lặng lẽ chưa xong" — và cái đó phát hiện trễ thì tốn kém hơn nhiều lắm.
Chương Sáu — Chọn model theo mức dễ thấy của cái sai, chớ đừng theo độ khó của việc
Chuyện đáng học nhất trong năm đó lại là một chuyện nhỏ, máy móc, và hơi quê: nguyên một bài viết đã hoàn tất phải bị coi là đáng ngờ, chỉ vì cái model viết ra nó thuộc hạng không đúng.
Công việc làm bằng tiếng Việt, một thứ tiếng mà dấu không phải đồ trang trí — dấu đổi thì chữ đổi luôn. Một model nhanh hơn và rẻ hơn đẻ ra bài viết với dấu bị lột sạch. Cái đó không phải máy sập. Không phải máy từ chối. Nó là văn xuôi trôi chảy, câu cú đàng hoàng, giọng tự tin, mà sai chánh tả theo cái kiểu đọc lướt cả đời cũng không bắt được — và nó lọt lưới cho tới khi đã xảy ra ít nhất một lần rồi mới có người thấy.
Cái luật viết ra sau đó dùng ngôn từ gắt nhất trong cả tờ nội quy của dự án — việc này phải xài hạng cao nhất, mà nếu phát hiện đang chạy bằng hạng thấp hơn thì ngưng và báo ngay lập tức — nhưng cái đáng giá không nằm ở cái luật. Nó nằm ở câu hỏi đẻ ra cái luật.
Sức hút về phía cái model nhanh hơn, rẻ hơn thì lúc nào cũng có, và thường thường là đúng. Đa số công việc là máy móc và tự nó kiểm được nó, trả giá cao cho mấy việc đó là phí của. Câu hỏi làm đổi câu trả lời không phải là việc này khó cỡ nào, mà là: nếu model sai ở chỗ này, cái sai đó có nhìn thấy được không?
Một chương trình chạy sập, một file mở không ra, một dòng dữ kiện méo mó — mấy thứ đó tự khai ra. Bạn tìm ra trong vài giây, không tốn đồng nào. Còn dấu tiếng Việt bị lột im ru, một mệnh đề dịch trật một chút, một con số đọc lệch qua hàng bên cạnh trên trang scan, một bản tóm tắt bỏ mất đúng cái ý quan trọng nhất — mấy thứ đó không tự khai. Và mỗi giờ trôi qua trước khi bạn bắt được nó, cái giá lại đắt thêm, bởi vì đã có thêm việc khác chồng lên trên nó.
Vậy thì: xài model mắc tiền đúng ngay những chỗ mà một câu trả lời sai sẽ trông rất ổn, và để dành model rẻ cho cái phần việc lớn hơn nhiều, nơi cái sai tự nó lòi ra và bắt lại ở lượt sau chẳng tốn gì. Đây là một phán đoán về chuyện phân bổ tiền bạc, không phải một phán đoán kỹ thuật — và bạn đã đủ tư cách để phán đoán chuyện đó rồi.
Chương Bảy — Trí nhớ là thứ mình phải tự xây
Cái trần thứ ba — hết phiên là chẳng còn gì sống sót — chính là thứ làm cho mọi bài học trong bài này đều mau hư. Một cái luật hôm thứ Ba phải trả giá mới học được thì tới thứ Năm chẳng đáng gì hết, nếu không có cái gì mang nó qua.
Cách chữa được dựng lên cho chuyện này là: một tờ mục lục, cộng với một thư mục đựng từng tờ ghi nhớ riêng lẻ, mỗi tờ ngắn thôi, mỗi tờ có dán nhãn cho biết nó thuộc loại gì, và mỗi tờ dựng quanh hai câu hỏi mà rốt cuộc mới là toàn bộ vấn đề: tại sao chuyện này xảy ra, và lần tới nó phải làm đổi cách làm việc ra sao.
Xin kể năm tờ, tả theo nội dung chớ không theo tên gọi, vì cái nội dung mới là cái đem qua chỗ khác xài được:
Vụ bốn thợ phụ chạy song song ở Chương Bốn, kèm ngày tháng và kiểu hỏng chính xác, để cái cơn thèm "thì cứ cho chạy bốn cái một lượt" vừa ló ra là đã có sẵn câu trả lời.
Một luật buộc mọi cao độ nốt nhạc chép ra đều phải được gọi đích danh tên nốt, không được tả bằng hình dáng lên xuống — luật này viết sau khi nguyên một đợt hai mươi hai bài hát được chép xong mà trong đó không có lấy một cái tên nốt nào; mà bắt được cũng chỉ nhờ đem một file dựng cạnh một file làm đàng hoàng của một bộ sưu tập khác rồi hỏi tại sao bên này có nốt còn bên kia chỉ có tính từ.
Một luật nói rằng một kết quả tìm kiếm có khớp cái tên thì chưa phải là một kết quả đúng bài đó, đúng người đó — viết sau khi 136 trong số 776 đường dẫn đã "kiểm chứng" hóa ra là sai, dù về mặt chữ nghĩa thì khớp.
Một luật cấm dựng bất cứ khẳng định thống kê hay tần suất nào trên một lần đọc nhanh, làm ẩu — viết sau khi đúng chuyện đó xảy ra, và đã neo cả cái luận điểm chính của một bài viết vô một con số đếm không những sai mà còn ngược. Câu đáng mang theo từ vụ đó: một cách đọc dở mà nhất quán với chính nó thì không phải là bằng chứng rằng cách đọc đó đúng.
Một luật cấm trích lời ca hay tài liệu gốc theo trí nhớ — luôn luôn phải chép lại từ bản đã kiểm chứng — viết sau khi có một câu trích lọt lưới, mà câu đó một nửa là nhớ lộn, một nửa là bịa trắng.
Không có cái nào trong đó là chuyện lý thuyết viết sẵn từ trước. Mỗi cái là một vết thẹo có ghi ngày, giữ lại đúng để cái lỗi đó không cần phải xảy ra lần thứ nhì mới học được. Và cái công viết mấy tờ đó không phải giấy tờ hành chánh dư thừa — nó chính là cái biến "một năm xài một công cụ" thành "một năm càng ngày càng xài giỏi hơn".
Đây là chỗ khác thật sự so với kinh nghiệm ở cái khung bên hông, và cũng nên nói thẳng: không có cái này, bạn sẽ có một năm gồm nhiều phiên làm việc từng phiên đều ổn, mà cuối năm chẳng còn gì trong tay. Mấy bài học sẽ sống trong đầu bạn, mờ dần đi, rồi bị học lại từ đầu. Có cái này, bạn có một cuốn cẩm nang vận hành do chính những lần thất bại viết ra.
Chương Tám — Một tờ nội quy thường trực, được đọc trước cả khi bạn kịp hỏi
Mấy tờ ghi nhớ riêng lẻ bắt được từng cái lỗi riêng lẻ. Nằm trên chúng là một thứ rộng hơn: một tờ giấy viết bằng tiếng người bình thường, nằm ngay cạnh dự án, ghi rõ ở đây công việc làm theo lối nào, và được đọc vào đầu mỗi phiên làm việc, trước khi bất cứ chuyện gì khác xảy ra.
Đây là món không hề có món tương đương ở cái khung bên hông trình soạn thảo, và nó cũng là món làm đổi nhiều nhất cái khả năng của công cụ. Một phần nội dung trong đó là mấy điều cấm sinh ra từ thất bại — ở đây đừng chạy song song; việc này đừng xài model rẻ; đừng kết bài bằng đúng cái câu kết đó nữa, vì nó đã xài rồi và nay cho về hưu. Một phần là chuyện chỉ đường: đây là chỗ để tài liệu tham khảo, đây là thứ tự phải tra, và khi hai nguồn cãi nhau thì nguồn nào thắng. Một phần là văn phong của nhà, tả kỹ tới mức kiểm được: viết thành đoạn văn xuôi chớ đừng gạch đầu dòng, vì gạch đầu dòng đọc ra giống biên bản họp hơn là giống văn; bài dài chừng này chữ; bố cục theo kiểu này.
Và một phần trong đó là một luật thường trực về sự thành thật, mà rốt cuộc lại quan trọng hơn hết thảy phần còn lại. Trong lúc làm một khối bài viết lớn về văn hóa, một lượt kiểm tra dữ kiện phát hiện ra mấy câu nghe rất giống ca dao tục ngữ, đã được trích như là của dân gian, mà kỳ thực chẳng dân gian chút nào — bịa ra, bịa rất trôi chảy, để chống đỡ cho một luận điểm. Cái luật viết ra sau đó nói: đừng bao giờ trích một câu tục ngữ hay ca dao trừ khi nó có mặt trong một nguồn in ra giấy; khi không chắc thì cứ tả cái ý đó ra bằng lời mình, đừng đóng ngoặc kép; và nếu một câu nghe hợp với lập luận của mình một cách đáng ngờ, thì hãy coi đó là dấu hiệu báo động chớ đừng coi là hên.
Cái lý lẽ đằng sau luật đó vượt xa khỏi một dự án riêng lẻ, và nó là điều quan trọng nhất trong cả bài này, nếu công việc của bạn sẽ có người đọc mà người đó không đứng bên cạnh nhìn bạn làm: người đọc chỉ tin một công việc có AI nhúng tay vô nếu mọi câu trích, mọi con số, mọi lời ghi nguồn đều tra lại được — và chỉ cần một chi tiết bịa là mọi thứ chung quanh nó mất giá theo. Toàn bộ giá trị của một trăm bài viết cẩn thận có thể tan tành vì một câu trích bịa nằm ở bài thứ mười. Cái đó không phải lý do để đừng xài công cụ. Đó là lý do để cắm luôn phần kiểm chứng vô tờ nội quy thường trực, để nó xảy ra bất kể bạn có nhớ dặn hay không.
Chương Chín — Đúc phần việc máy móc thành công cụ mà bạn không bao giờ phải đọc
Làm tay cùng một việc chừng hai ba lần là cái khuôn của nó lộ ra: một phần là phán đoán, một phần thuần túy máy móc và rất dễ sai. Cái phần máy móc đó nên thôi để cho mô hình ngôn ngữ làm.
Đó là hình dáng của mọi thủ tục dùng lại được, dựng lên trong năm ấy. Cái nào cũng gồm hai vế: một bản mô tả cách làm viết bằng lời — phần phán đoán — đi kèm một chương trình chạy được thiệt, làm cái phần máy móc y hệt nhau mỗi lần. Đo vị trí chấm ảnh trên một trang scan để biết chính xác một nốt nhạc nằm chỗ nào. Định dạng một bản ký âm đã xong thành kết quả đồng nhất. Chuyển một tài liệu thành một trang trình bày coi được. Đi tìm, đối chiếu, rồi rà soát trên mấy trăm món.
Có một lý do rất riêng khiến chuyện này quan trọng hơn cả chuyện nhanh chậm, và đó là bài học nhỏ mà sắc nhất của cả năm. Tờ nội quy của dự án đó có một điều cấm tuyệt đối — không ngoại lệ, không có màn "thôi lần này thôi" — cấm nhờ model gom nhiều tài liệu dài lại thành một, hoặc đổi một tài liệu dài từ định dạng này qua định dạng khác, bằng cách đọc rồi chép lại nội dung. Việc đó bắt buộc phải để cho một chương trình làm. Không phải vì model dở chuyện đó, mà vì một model được nhờ chép lại một tài liệu dài thì có lúc sẽ lặng lẽ tóm tắt thay vì chép lại — và cái kết quả trông y như đúng, cho tới khi có người ngồi đếm. Một chương trình năm dòng giữ nguyên từng ký tự, không xen vô một chút phán đoán nào. Xài model cho phán đoán và xài chương trình cho sự trung thực từng chữ, và đừng bao giờ để hai vai đó đổi chỗ cho nhau.
Cũng cái bản năng đó cắt nghĩa vì sao một thủ tục viết ra giấy ăn đứt một thủ tục nhớ trong đầu. Cái gì lặp lại quá hai lần đều được viết xuống thành một cách làm có tên, có các bước đánh số, để phiên sau chạy đúng cái đó chớ không tự chế lại một phiên bản hơi khác. Một đoạn văn nhớ lại rồi kể lại thì trôi dạt. Một thủ tục viết ra giấy thì không.
Mà điều đó dẫn thẳng tới cái thất bại tinh vi nhất trong cả bài này.
Chương Mười — Nói lại bằng lời khác thì nó trôi mất, và chuyện phải rà soát lượt thứ hai
Một đợt hai mươi hai bản chép nhạc được làm theo một tờ ghi chú cách làm, viết riêng cho đợt đó. Tờ ghi chú ấy diễn lại cái lối đọc của thủ tục thường trực bằng lời hơi khác đi một chút — tả cái lối đọc nhanh đó là "lấy dáng nhạc chung làm chính". Thủ tục thường trực xưa nay đòi chặt hơn nhiều: mỗi tiếng hát đều phải có một tên nốt gọi đích danh, và đánh dấu khi không chắc. Chẳng ai có ý làm nhẹ cái luật đó đi hết. Câu diễn lại kia được viết ra với thiện chí, bởi một người đang cố nói cho gọn và cho dễ hiểu.
Cả hai mươi hai file đẻ ra không có lấy một cái tên nốt. Chỉ toàn văn xuôi tả hình dáng — "đi ngang đều", "ngân dài một nốt". Không file nào xài được cho bất cứ lập luận nào về cao độ, mà đó lại đúng là lý do làm ra chúng. Cái trôi dạt đó vô hình suốt hai ngày, và bắt được cũng chỉ nhờ đem một file trong đám đó so với một file làm đàng hoàng ở một bộ sưu tập khác.
Cái luật viết sau đó: đừng bao giờ nói lại một luật thường trực bằng lời mới. Hãy chỉ thẳng vô câu chữ gốc, y nguyên. Một câu diễn nôm của bản đặc tả (spec) chính là một bản đặc tả mới, viết ra một cách vô tình, bởi một người tưởng mình đang tiết kiệm công.
Chỗ này đáng ngồi ngẫm một chút, nếu bạn đi lên từ cái khung bên hông, bởi vì đây là một dạng thất bại chỉ tồn tại khi bạn đã bắt đầu đưa cho AI những chỉ thị viết ra giấy có tính thường trực — nghĩa là chỉ tồn tại khi bạn đã bắt đầu làm đúng cái chuyện khiến terminal đáng công xài. Cái hỏng không nằm ở chỗ model ngu. Ai dính vô cũng làm đúng y cái mình được dặn. Chỉ có điều cái lời dặn đã lặng lẽ đổi.
Và đó cũng là lý do bài học tổng quát đắt tiền nhất của năm đó là câu này: một lượt kiểm chỉ bắt được những kiểu hỏng mà bạn đã nghĩ tới trước để mà kiểm.
Cái dây chuyền đi tìm rồi kiểm chứng nói ở trên chạy hai lượt rà, và hai lượt cố ý khác hình dáng nhau. Lượt đầu thuần máy móc: cái tên mình đang tìm có thực sự xuất hiện như một từ trọn vẹn trong chính cái tựa của kết quả đó không? Lượt thứ nhì dựa trên phán đoán, nhắm thẳng vô đúng cái mà lượt đầu về mặt cấu tạo không thể thấy — một cái tên có mặt đó thiệt, mà là tên của cái phòng trà chớ không phải tên ca sĩ; hoặc là tên nhà thơ làm bài thơ gốc chớ không phải tên người hát; hoặc một cái tựa chỉ đơn giản là nối dài cái tựa mình cần thành ra một bài khác hẳn ("Thành Phố Buồn" hiện ra khi đang tìm "Phố Buồn"). Trên một bộ sưu tập, riêng lượt thứ nhì bắt được 136 kết quả sai trên 776 — mà cái nào cũng đã qua lượt đầu, cái lượt máy móc kia, một cách sạch sẽ.
Vụ chép nhạc kể ở trên là cùng bài học đó nhìn từ phía ngược lại: nó không bị bắt bởi bất cứ lượt kiểm tự động nào hết, bởi vì chẳng có lượt kiểm nào được viết cho câu hỏi "file này có thực sự chứa tên nốt hay không". Nó bị bắt bởi một hành động rất người: đem hai thứ đặt cạnh nhau mà ngó.
Nói gọn một lần: một lượt rà soát thứ nhì, cố ý làm cho khác hình dáng với lượt đầu, không phải là làm dư. Nó là thứ duy nhất bắt được cái loại hỏng mà lượt đầu ngay từ khi thiết kế đã không được làm để thấy. Còn chuyện đem hai thứ đặt cạnh nhau mà so — kết quả cạnh kết quả, kết quả cạnh bản gốc — cho tới nay vẫn là cách rà soát rẻ nhất mà loài người từng nghĩ ra.
Chương Mười Một — Đọc kỹ cái sổ sách trước khi tin nó
Còn hai cái thất bại nữa đáng gọi tên, vì đó là loại thất bại mà một người thông minh vẫn mắc trong lúc đang rất cẩn thận, và vì cả hai đều là chuyện về bằng chứng chớ không phải chuyện về AI.
Cái thứ nhất: một bản kiểm kê toàn dự án được dựng lên bằng cách quét một thư mục rồi sắp mọi thứ theo ngày tạo, để dựng lại một dòng thời gian. Kết luận là không có gì có trước một tháng Giêng nọ. Kết luận đó sai, mà sai vì một lý do rất tầm thường — cái lệnh quét bị chỉ vô sâu hơn một tầng, thành ra nguyên một thư mục anh em nằm bên cạnh chưa hề được ngó tới lần nào. Khi đem ra coi thẳng, nó đẩy cái ngày bắt đầu thiệt lùi lại ba tháng. Mấy cái ngày tháng đã thu thập được thì đúng hết. Chỉ là có nguyên một vùng của thế giới chưa từng lọt vô khung hình.
Không thấy bằng chứng chỉ là bằng chứng của sự không có, khi và chỉ khi bạn nói được chính xác cuộc tìm kiếm của mình đã bao trùm tới đâu. Mọi kết luận phủ định mà AI đưa cho bạn đều đáng bị hỏi thêm một câu: rốt cuộc bồ đã ngó vô những chỗ nào?
Cái thứ nhì: cũng trong bản kiểm kê đó, hơn phân nửa số file mang y hệt một cái mốc ngày giờ tạo. Không phải vì nửa dự án được viết ra trong một ngày, mà vì bữa đó nguyên đống file được chép hàng loạt qua chỗ mới, và hệ điều hành đóng dấu cái giờ chép đè lên cái giờ viết. Cuốn sổ trông thì chính xác mà kỳ thực là chuyện phịa. Bài viết ra đời từ đó rốt cuộc phải nói rõ ra: khẳng định nào dựa trên ngày tháng tin được, và khẳng định nào dựng lại từ lời kể — một chỗ phân biệt mà đa số bài tổng kết sẽ lặng lẽ ủi bằng cho êm.
Cái thói quen đó đáng bưng nguyên về mà xài, vì nó chính là thứ làm cho công việc có AI nhúng tay vô đứng vững được trước người đọc khó tính: hãy nói rõ khẳng định nào là đo được và khẳng định nào là suy ra; và khi hai nguồn cãi nhau thì nói thẳng là chúng cãi nhau, kèm theo mình đã cân nhắc ra sao — chớ đừng âm thầm chọn một cái rồi trình bày như thể đã ngã ngũ. Cái luật thường trực mà dự án đó dùng cho chuyện này chỉ có bốn chữ: bằng chứng trước, kết luận sau.
Trong cùng họ với nó có một kỷ luật nhỏ nữa: khi một thông số có tính hệ thống bị sai, thì mọi thứ nằm phía sau nó sai cùng một lượt. Đọc một trang bản nhạc thì cái bộ khóa (key signature, tức mấy dấu thăng giáng ghi ở đầu dòng nhạc) chính là loại thông số đó — đếm lộn một dấu thôi là mọi nốt bị ảnh hưởng trong cả bài đều sai, sai im ru và sai đều đặn. Cái luật thành hình: hãy kiểm cho ra cái thông số đầu độc mọi thứ, kiểm một cách rõ ràng và kiểm mỗi lần, trước khi làm bất cứ phần việc nào dựa trên nó. Cái thông số tương đương của bạn có thể là một khoảng ngày tháng, một đơn vị đo, một loại tiền tệ, một tỷ giá hối đoái, một sơ đồ ánh xạ cột trong bảng tính, hay là chuyện trong hai file gốc tên na ná nhau thì file nào mới là file hiện hành. Nó là gì cũng được — cứ kiểm nó trước, kiểm có chủ ý, ngay cả khi nó có vẻ hiển nhiên.
Chương Mười Hai — Tại sao chọn tiếng người, chớ không chọn tự tay dựng một bộ khung
Có một con đường mà năm đó cố ý không đi, và nó lại đúng là con đường thiên hạ đang rùng rùng kéo nhau đi: tự tay dựng lấy một "tác tử" (agent). Nghĩa là viết một chương trình biết lập kế hoạch, biết gọi công cụ, và biết chạy vòng lặp cho tới khi xong việc — viết theo lối cổ điển: một lớp điều phối, một cái máy trạng thái tường minh, mấy câu dặn dò cắm cứng vô từng nhánh mã, dựa trên một bộ khung (framework) có sẵn hoặc một vòng lặp tự chế. Thứ mã mà sau đó phải dò lỗi, phải đánh số phiên bản, phải bảo trì theo đúng cái cách nhu liệu vẫn được bảo trì xưa nay: một con người ngồi đọc nó và sửa nó mỗi lần nó hư.
Ván bài đặt ngược lại là: con đường đó chậm hơn chớ không nhanh hơn. Lý lẽ: bản thân model đã giỏi viết mã và dò lỗi hơn cái đống mã mà người ta định đấu dây cho nó điều phối, và nó còn giỏi thêm theo một nhịp mà không cá nhân nào theo kịp bằng cách ngồi chỉnh tay từng file. Một bộ khung dựng tay là tấm hình chụp lại cái gì có vẻ đúng vào cái ngày nó được viết. Còn một bản mô tả bằng tiếng người về chuyện gì nên xảy ra — một tờ nội quy thường trực, một thủ tục viết ra giấy, một tờ ghi nhớ chép lại một lần hỏng có ghi ngày — là thứ mà cái model đời sau, giỏi hơn, đọc vô và thi hành hay hơn đời trước, mà không ai phải quay lại sửa một dòng điều phối nào hết. Đặt cửa vô mấy cái giàn giáo viết tay để mong nó không lỗi thời, tức là đặt cửa ngược với chính cái đà tiến của model. Đặt cửa vô một bản đặc tả viết ra giấy thì mỗi lần model lên đời là một lần công việc bạn đã tả một lần bỗng nhiên tốt lên miễn phí.
Đây không phải linh cảm riêng của một người, và cũng nên biết rằng nhiều người nhìn vô ruột mấy hệ thống này rõ hơn ta nhiều đã công khai lập luận y như vậy:
- Cách nói của Andrej Karpathy — "ngôn ngữ thảo chương nóng nhất hiện nay là tiếng Anh" — về sau ông nói rõ thêm trong bài thuyết trình "Software 3.0", coi mấy mô hình ngôn ngữ lớn (LLM) như một loại máy điện toán mới, được thảo chương bằng tiếng người y như mấy cỗ máy đời trước được thảo chương bằng C hay Python, với bản thân cái model đóng vai trình thông dịch. (Karpathy trên X; ghi chú về bài nói Software 3.0)
- Bài "The Bitter Lesson" (Bài học cay đắng) của Rich Sutton — rút từ bảy chục năm nghiên cứu AI qua cờ vua, cờ vây, thị giác máy và nhận diện tiếng nói — nhận xét rằng những hệ thống dựng trên tri thức do con người gò tay vô, về lâu về dài đều thua những phương pháp tổng quát biết lớn theo sức tính toán và theo lượng học được. Bài đó không nói về mấy bộ khung tác tử, nhưng nó là phiên bản xưa nhất và được thử lửa kỹ nhất của cùng một lập luận: hãy đặt cửa vô cái hệ thống tự nó khá lên, thay vì cái hệ thống chỉ khá lên khi có người ngồi sửa. (bản chép lại bài của Sutton; một bài nhìn lại có phê bình, nhắc luôn chuyện chính Sutton sau này cũng dè dặt về việc mô hình ngôn ngữ có khớp gọn vô cái khuôn đó hay không)
- Bài của Marc Brooker về thành tích thực tế của lối "thảo chương bằng tiếng người" nói thẳng vô khía cạnh bền lâu: ngôn ngữ, cộng với một sự phân vai rành mạch, không bị lỗi thời theo kiểu một công cụ chuyên dụng hay một bộ khung bị lỗi thời, bởi vì nó không bị buộc chặt vô một thế hệ đồ nghề nào. ("On the success of 'natural language programming'")
- Và một cách nói huỵch toẹt hơn về chuyện gì còn sống sót sau một dự án có AI nhúng tay, một khi đồ nghề chung quanh nó đã thay đổi hết: cái ADN thì ở lại còn mã thì chết, và mấy cái quyết định mới là phần còn sống. ("Code Is Dead. Specs Are Dying. What Survives?")
Chuyện này chưa hề ngã ngũ, và trình bày nó như đã ngã ngũ là vi phạm ngay cái luật thành thật ở hai chương phía trên. Chính Sutton cũng đã phản biện lại chuyện mô hình ngôn ngữ có khớp với luận đề của ông tới đâu. Nhiều người làm nghề khác thì cãi ngược hẳn, ít ra là trong ngắn hạn — rằng mã đã sinh ra rồi thì chính nó mới là bản ghi chính xác duy nhất về việc một hệ thống thực sự làm cái gì, và rằng tiếng người dở hơn một bản đặc tả hình thức cho bất cứ chuyện gì đòi hỏi sự đúng đắn ngặt nghèo. Ở đây xin nêu tên cả hai phía, chớ không phải chỉ nêu cái nửa tiện cho mình.
Cái mà năm đó làm, là đặt một ván bài có làm việc thiệt lên một bên của một câu hỏi còn đang mở thiệt. Và cách để biết bên nào đúng thì không bao giờ là ngồi cãi suông. Nó là một năm gồm những thư mục có ghi ngày, giữ lại đúng để sau này đem ván bài ra đối chiếu với cái đã xảy ra, chớ không đối chiếu với cái người ta đã tiên đoán.
Với bạn, phiên bản thực dụng của ván bài đó nhỏ hơn và an toàn hơn nhiều: hãy tả cái bạn muốn ra giấy, giữ cái bản tả đó lại, và coi mã như đồ dùng rồi bỏ. Nếu mã ngưng chạy vì đồ nghề chung quanh đổi, thì bản tả sẽ đẻ lại nó. Còn nếu mất bản tả, thì bao nhiêu mã cũng không trả lại cho bạn được.
Chương Mười Ba — Từ chỗ xin một món đồ, tới chỗ đặt hàng luôn cả cách làm
Đem mấy lời dặn việc hồi đầu năm đó đọc cạnh mấy lời dặn hồi cuối năm, chỗ khác nhau không nằm ở tham vọng. Cả hai đều với tới những sản phẩm lớn. Chỗ khác nằm ở chuyện cái gì được nói rõ ra trước khi bắt tay vô làm.
Một lời dặn hồi đầu, tóm lại, đọc như vầy: viết cho tôi một bài về người này.
Một lời dặn hồi cuối đọc như vầy: xài model hạng này; nhắm chừng này chữ; tra ba nguồn tài liệu này theo đúng thứ tự này trước khi viết một chữ nào; bản in thắng về mặt dữ kiện còn hồi ký thắng về mặt bối cảnh, và nếu hai bên cãi nhau thì nói ra ngay trong bài chớ đừng lặng lẽ chọn một bên; tránh đúng cái lỗi đã xảy ra lần trước; và đừng kết bằng cái câu kết đó, vì nó cho về hưu rồi.
Cái bước chuyển ấy chính là toàn bộ câu chuyện, và nó không phải chuyện hình thức bề ngoài. Nó là kết quả cộng dồn của việc mỗi cái trần trong bài này đều đã bị đụng một lần, được gọi tên, rồi được đổi thành một lời dặn không bao giờ phải nghĩ lại từ đầu nữa. Một luật kiểu "ở đây đừng chạy song song" hay "việc này chỉ hạng cao nhất" không phải một lời khuyên để AI cân nhắc. Nó là một bản đặc tả, và nó ra đời theo đúng cái cách mọi bản đặc tả kỹ thuật tử tế ra đời: từ một lần hỏng có ghi chép, chớ không từ chuyện ngồi đoán trước xem cái gì có thể hỏng.
Và tới đây, cuối cùng, là câu trả lời cho câu hỏi mở đầu bài — một người không biết thảo chương thực sự học được cái gì khi làm việc trong terminal.
Bạn không học thảo chương. Bạn sẽ lượm được ít nhiều từ ngữ nhà nghề theo kiểu thẩm thấu, và sau một năm bạn sẽ hiểu về cách nhu liệu được ráp lại nhiều hơn bạn tưởng — nhưng đó là tác dụng phụ chớ không phải cái đích. Cái bạn thực sự học được chính là cái còn sót lại sau khi phần gõ phím đã bị lấy đi: cách nói cho thật chính xác cái mình muốn, cách kiểm coi mình có được đúng cái đó không, và cách ghi câu trả lời xuống để không ai phải mò lại lần nữa. Việc của bạn không phải là hỏi cho hay hơn. Việc của bạn là đặc tả cho hay hơn — mà chất lượng của một bản đặc tả chỉ khá lên bằng cách sai trước, rồi viết xuống chính xác mình đã sai chỗ nào.
Cái tài đó không dính gì tới AI và cũng không hết hạn khi đồ nghề đổi đời. Nó vẫn là cái tài phân biệt một bản yêu cầu công việc xài được với một bản yêu cầu vô dụng, một tờ dặn việc rõ ràng với một tờ mù mờ, một lượt duyệt bài bắt được chuyện với một lượt duyệt chỉ để đóng mộc. Nếu bạn từng là cái người trong phòng họp nhận ra rằng cái bản yêu cầu ai cũng gật đầu kia thực ra có tới ba cách hiểu, thì bạn đã sẵn có cái tạng cho việc này rồi. Terminal chỉ đơn giản là môi trường đầu tiên mà đa số người không phải dân thảo chương sẽ gặp, nơi cái tạng đó là toàn bộ công việc, còn chuyện gõ phím thì thiệt sự đã là việc của người khác.
Chương Mười Bốn — Bắt đầu cách nào cho cụ thể
Xin nói cụ thể, đúng tinh thần mọi chuyện phía trên.
Hãy lấy một việc thiệt mà bạn vẫn né, chớ đừng lấy một bài tập cho vui. Một việc số lượng lớn, chán ngắt, mà bạn thiệt lòng muốn có người làm giùm cho xong: một thư mục tài liệu chưa ai lập mục lục, một bản báo cáo tháng nào cũng phải ráp tay, một xấp file cần lặp lại cùng một phép sửa cho hết. Mấy bài tập cho vui không dạy bạn được gì hết, vì bạn không có cách nào biết kết quả nó ra đúng hay sai.
Hãy tự tay làm năm món đầu, hoặc ngồi coi kỹ năm món đầu. Đây chính là cái luật chạy thử lô nhỏ. Bạn không phải đang kiểm coi AI có làm nổi hay không. Bạn đang khám phá ra mình đã quên nói cái gì — mà lần nào cũng sẽ có ít nhất hai cái.
Hãy viết tờ nội quy của bạn ngay khi bạn phải sửa cùng một chuyện tới lần thứ hai. Đừng viết sớm hơn. Cái bản đầu tiên của tờ nội quy đó, trong suốt cả năm ấy, mà viết trước khi bắt tay vô làm thì cũng vô dụng thôi, vì lúc đó chưa ai biết mấy cái lỗi nào sẽ là lỗi đi tới đi lui. Mỗi dòng trong đó đều xứng đáng có mặt vì nó đã thực sự xảy ra.
Hãy đòi một lượt kiểm có hình dáng khác với công việc. Đừng hỏi "làm đúng chưa" — câu trả lời lúc nào cũng là rồi. Hãy hỏi cái gì có cấu trúc: cho tôi số món đã làm và số món ra kết quả rỗng, kèm lý do tại sao mấy cái rỗng lại rỗng. Chỉ tôi coi ba món mà bồ ít chắc bụng nhất. So kết quả với bản gốc rồi liệt kê mọi chỗ hai bên không khớp.
Hãy đòi cho bằng được rằng chỗ nào không chắc thì phải thấy được là không chắc. Cái quy ước có giá trị nhất trong cả năm làm việc đó là đánh một cái dấu vô mọi chỗ đọc mà mình không chắc, để người đọc sau này thấy chính xác chỗ nào đáng tin và chỗ nào chưa. Một kết quả không có dấu ngờ vực nào hết thì không phải là đáng tin hơn cái có dấu. Nó kém đáng tin hơn, bởi vì bây giờ bạn không còn biết phải ngó vô đâu.
Và hãy đính cái "tại sao" vô mỗi luật bạn viết ra. Một cái luật không có câu chuyện nào đứng sau, sớm muộn gì cũng bị một người rất biết điều nới lỏng ra, vì người đó không thấy được nó đang che chắn cho cái gì — mà nhiều phần người đó là chính bạn, ba tháng nữa, trong lúc đang cố làm cho lẹ.
Kết — Cái hạ tầng mới là thành tựu thiệt
Cuối năm đó, cái đáng chỉ tay vô không phải một bài viết nào, một chương sách dịch nào, hay một cuốn mục lục nào đã làm xong. Mỗi thứ đó chỉ là một tấm hình chụp: khoảnh khắc mà một bộ luật lệ, thủ tục và bài học nhớ được tình cờ đang chĩa vô một đề tài nào đó.
Mấy cái luật thì không phải hình chụp. Mấy thủ tục viết ra giấy không phải hình chụp. Mấy tờ ghi ngày, chép lại chính xác một chuyện đã hỏng ra sao, không phải hình chụp. Mấy thứ đó được đem ra xài lại, xài lặng lẽ, mỗi lần có bất cứ cái gì mới được làm ra sau này. Mấy ngàn tài liệu hoàn tất tồn tại được không phải vì mỗi cái đều được đắp tay một lần, mà vì một số ít cách làm viết ra giấy và một số ít chương trình nhỏ được đem ra xài đi xài lại — và một người kỹ sư nhu liệu đang hành nghề đã không tự tay gõ lấy một chương trình nào trong số đó.
Nếu bạn chỉ mang theo một điều từ bài này: chỗ khác nhau giữa "một năm xài trợ tá AI" và "một năm ngày càng giỏi hơn trong việc xài nó" nằm trọn ở chuyện bạn có giữ lại được cái gì hay không. Cái khung bên hông cho bạn một ngàn cú tăng tốc nhỏ và cuối cùng chẳng còn gì trong tay. Terminal cho bạn cũng chừng đó cú tăng tốc, cộng thêm một chỗ để cất cái bạn đã học được — và chính cái chỗ để cất đó mới là cái sinh lợi kép.
Bạn không cần phải là dân thảo chương mới xây được cái đó. Bạn chỉ cần chịu sai một cách có ghi ra giấy, có ghi ngày, về một chuyện cụ thể — rồi giữ lại tờ giấy đó.
Phụ Lục — Cẩm nang bỏ túi
Mọi luật trong bài, mỗi luật một dòng, theo đúng thứ tự xuất hiện:
- Hãy đem tới cho công cụ những việc, đừng đem tới mấy cú gõ phím. Nếu bạn chỉ đem tới cho nó những bài toán hai giây, bạn sẽ không bao giờ để ý tới những bài toán nó thiệt sự giải được.
- Đừng thả thợ phụ chạy song song khi cái đồng hồ tính tiền có giới hạn. Làm tuần tự mà thấy được thì ăn đứt chạy song song mà không truy được, một khi đã đếm sòng phẳng cái giá của việc làm lại sau một lần hỏng im ru.
- Chia đợt, chốt lại, nối tiếp được — đừng bao giờ cho chạy một lèo không ai kiểm. Đánh số công việc, làm từng khúc có giới hạn, ghi tình trạng xuống đĩa, giữ cho phần đã làm luôn nhìn thấy được.
- Chạy thử năm món trước khi nhân lên năm trăm. Mọi con bọ thiệt sẽ bị bắt ở đây, rẻ; hoặc bị bắt sau đó, mắc.
- Mỗi lần chỉ một người ghi lên cùng một chỗ. Hai tiến trình cùng cập nhật một file sẽ nuốt việc của nhau mà không kêu tiếng nào.
- Món nào không chạy trót lọt thì đánh dấu rồi đi tiếp. Đừng đem cái ngân sách của chín mươi chín món đổ vô một món.
- Làm xong phần nào thì lưu phần đó. Một phiên đứt sớm chỉ nên làm mất phần chưa xong, chớ đừng làm mất hết.
- Chọn hạng model theo mức dễ thấy của cái sai, đừng chọn theo độ khó của việc. Xài cái mắc tiền đúng chỗ mà một câu trả lời sai sẽ trông rất ổn.
- Viết xuống mọi bài học, kèm ngày, kèm nguyên do, kèm cách nó phải làm đổi công việc lần sau — viết trước khi hết phiên. Một cái luật không viết ra sẽ phải học lại với giá đầy đủ.
- Giữ một tờ nội quy thường trực nằm cạnh dự án, được đọc trước khi bất cứ việc gì bắt đầu, gồm điều cấm, thứ tự ưu tiên của nguồn tài liệu, văn phong của nhà, và mấy đòi hỏi về sự thành thật.
- Đừng bao giờ để lọt một chi tiết bịa. Một câu trích bịa làm mất giá mọi thứ chung quanh nó; không kiểm chứng được thì cứ tả cái ý ra, đừng đóng ngoặc kép.
- Xài chương trình cho sự trung thực từng chữ, xài model cho phán đoán, và đừng bao giờ đổi vai — một model được nhờ chép lại tài liệu dài có thể lặng lẽ tóm tắt nó.
- Đừng bao giờ nói lại một luật thường trực bằng lời mới. Một câu diễn nôm của bản đặc tả chính là một bản đặc tả mới, viết ra một cách vô tình.
- Chạy lượt rà thứ hai có hình dáng khác lượt đầu. Lượt đầu bắt cái bạn đã lường trước; chỉ có lượt sau mới bắt được cái bạn không lường.
- Đem hai kết quả đặt cạnh nhau mà ngó. Cách rà soát rẻ nhất từ trước tới nay, và là cách bắt được cái mà chẳng có lượt kiểm tự động nào được viết ra để bắt.
- Hỏi coi một kết luận phủ định thực sự đã tìm những đâu. Không thấy bằng chứng mà không nói rõ được phạm vi đã tìm thì chẳng có nghĩa gì hết.
- Kiểm cái thông số đầu độc mọi thứ phía sau nó — kiểm trước, kiểm rõ ràng, kiểm mỗi lần, kể cả khi nó có vẻ hiển nhiên.
- Nói rõ khẳng định nào là đo được, khẳng định nào là suy ra, và nói thẳng khi hai nguồn cãi nhau. Bằng chứng trước, kết luận sau.
- Giữ bản tả viết ra giấy, coi mã như đồ dùng rồi bỏ. Bản tả đẻ lại được mã; mã không đẻ lại được bản tả.
- Đặc tả luôn cả cách làm, đừng chỉ đặc tả món đồ — nguồn nào, thứ tự nào, cái lỗi nào phải tránh, và kết quả không được trông ra làm sao — nói trước khi bắt tay vô làm, chớ đừng nói sau khi đã hỏng.
No comments:
Post a Comment