Machikoba no Techo

Chỉ người tự viết được mới nhìn ra chỗ nguy hiểm.

Tháng chín. Mùa câu mực ống ban đêm — một trong những dấu hiệu của mùa hè ở đây — đang dần khép lại. Những người vẫn cho thuyền ra khơi trong đêm đang lặng lẽ chuyển sang thứ chúng tôi gọi là budouika, "mực chùm nho". Chúng tôi chân thành cảm ơn quý vị đã luôn ủng hộ.

Và tháng chín còn một điều nữa: đây là mùa mực lá tụ về. Khi nhiệt độ nước lắng xuống sau đỉnh điểm mùa hè, đàn cá mồi bỗng sôi động hẳn lên. Mực đổi theo chúng, và những đàn mực con kéo vào vùng nước nông — cần câu cong xuống dọc các kè chắn sóng trong những khoảng ngắn ngủi lúc rạng đông và chiều tà. Có lẽ đây là quãng thời gian hào hứng nhất trong năm. Với những ai đang nghĩ đến chuyện bắt đầu chơi eging, đây cũng là mùa dễ vào nhất.

Tháng này, xin lại viết về phía sau của nhà xưởng. Tháng trước tôi đã viết rằng dù AI có viết thay, việc dừng lại để kiểm tra vẫn là phần của con người. Đây là phần tiếp theo. Suốt một năm qua, khi dùng thật nhiều cái gọi là "vibe coding" ngay tại xưởng, tôi cảm nhận được cả sức mạnh của nó lẫn một mối nguy đúng bằng chừng ấy. Và tôi vấp phải câu hỏi mà tôi ngờ rằng nhiều người cũng đang đối diện: mã do AI sinh ra có thể đưa vào xưởng như một hộp đen, không cần nhìn vào bên trong, hay không?

■ Chỉ cần nói "tôi muốn đại loại thế này", và nó chạy

Vibe coding nghĩa là bỏ qua bản đặc tả chi tiết: bạn mô tả điều mình muốn bằng ngôn ngữ đời thường, để AI viết, rồi nhận lại một thứ chạy được. Suốt năm qua, chúng tôi đã dựng khá nhiều công cụ nhỏ cho xưởng đúng theo cách ấy. Hay nói đúng hơn, chúng tôi sinh ra công cụ tự nhiên như hít thở.

Xin nói trước rằng đây là thứ thật sự mạnh mẽ. Những gì trước kia bị xếp lại với câu "muốn lắm, nhưng không có thời gian tìm hiểu" nay chạy được ngay trong ngày mình nghĩ ra. Những gì lẽ ra phải bắt đầu bằng một bản báo giá từ công ty bên ngoài nay thành hình trong một giờ nghỉ trưa. Với một xưởng nhỏ như chúng tôi, không có thay đổi nào đáng mừng hơn.

■ Chạy được và đúng là hai chuyện khác nhau

Vậy mà điều đáng sợ nhất trong năm nay lại chính là ở chỗ nó chạy thật. Thứ sinh ra thường là chạy được. Màn hình trông gọn gàng, các con số hiện lên. Chính vì nó chạy nên từ bên ngoài không thể biết nó lành hay nguy hiểm.

Một phép làm tròn hơi khác đi ở một chỗ nào đó. Hành vi không xác định khi có giá trị rơi ra ngoài khoảng dự kiến. Lỗi bị nuốt lặng lẽ để mọi thứ vẫn trôi đi như chưa từng có chuyện gì. Nhìn chằm chằm vào một màn hình đang chạy thì chẳng thấy được gì trong số đó. Người duy nhất nhìn ra là người đã từng tự tay viết loại mã ấy và từng bị nó làm cho bỏng tay.

Rốt cuộc, chưa lần hết toàn bộ đoạn mã sinh ra thì vẫn chưa thể yên tâm. Thời gian tưởng đã tiết kiệm được nhờ giao phó lại quay về nguyên vẹn dưới dạng thời gian đọc. Ngưỡng để dựng nên một thứ gì đó đã hạ xuống rất nhiều; ngưỡng để nhận ra sự nguy hiểm thì không. Sự bất đối xứng ấy là điều rõ ràng nhất tôi học được trong năm nay. Nói theo ngôn ngữ của chúng tôi, nó cũng như đứng trước một chiếc machining center 40 triệu yên rồi bảo "nó chạy rồi, vậy là ổn". Điều đó thì không bao giờ được phép.

■ Trong một xưởng nhỏ không có phôi lý tưởng

Vậy đây có phải một công cụ không dùng được không? Hoàn toàn không. Ở một số phần trong công việc của chúng tôi, nó hợp hơn bất cứ thứ gì. Nhưng để giải thích điều đó, tôi cần đi vòng qua thực tế của một xưởng nhỏ.

Riêng tôi thì vẫn thường làm một việc hơi lạ: tôi sinh NC — ngôn ngữ của máy — bằng vibe coding. Để viết mã xuất ra NC, Python thường được chọn mặc định; trong phần lớn trường hợp tôi thay bằng Ruby. Đó là kiểu của tôi.

Máy công cụ NC ngày nay chính xác đến phi thường. Đưa cho nó vật liệu lý tưởng, hình dạng lý tưởng và kích thước lý tưởng, nó sẽ cắt ra một bề mặt hoàn thiện khiến ta kinh ngạc. Nhưng trong xưởng chúng tôi, những cái lý tưởng ấy hầu như không bao giờ có sẵn. Phải xoay xở cho xong với những gì đang có trong tay. Vật liệu không đồng đều; hình dạng và kích thước lần nào cũng khác. Ngay cả tiền đề "đúng như bản vẽ" cũng không nằm trước mặt chúng tôi.

Tôi gọi đó là "tinh thần xoay xở cho xong với những gì đang có". Đó là thế mạnh của một xưởng nhỏ và cũng là niềm tự hào của chúng tôi, nhưng dưới con mắt người viết chương trình thì nó thật sự phiền. Vì kích thước lần nào cũng khác, không thể viết một quy trình với những con số ghi cứng. Thay vì "cắt hình này theo kích thước này", phải viết lại thành "đo thứ đang nằm trước mặt rồi suy ra đường cắt từ giá trị đó". Nói cách khác, mức trừu tượng phải được nâng lên đáng kể. Đó là phần khó nhất của việc lập trình trong một xưởng nhỏ.

■ Rất hợp để bám theo phôi thật, và để dịch ngược

Và cách làm việc này — bám theo chính vật đang có — giống vibe coding đến mức đáng ngạc nhiên. Không có bản đặc tả hoàn hảo từ đầu; ta áp sát vào vật nằm trước mặt, cắt rồi ướm, ướm rồi lại cắt. Bảo nó tạo ra một thứ chạy được, chỉ vào chỗ sai, bảo nó sửa, rồi thử lại. Vì có thể động tay trước khi bản đặc tả ngã ngũ, nó hợp lạ thường với một nhà xưởng "xoay xở cho xong với những gì đang có".

Hơn hết, vibe coding bù đắp rất tốt cho phần khó nhất: nâng mức trừu tượng lên. Đưa cho nó một bản ghi cứng rồi yêu cầu một bản vẫn chạy được khi kích thước thay đổi, nó sẽ chỉ ra đâu là thứ nên trở thành biến. Phần khái quát hoá mà một người phải mất nhiều ngày — việc tìm ra góc tiếp cận — được dọn sạch trong một nhát. Đó đúng là năng lực mà nhà xưởng "xoay xở với những gì đang có" của chúng tôi còn thiếu.

Chỗ hợp thứ hai là dịch ngược: chọc vào một cơ cấu mà mình không hiểu, từ bên ngoài, rồi dựng lại logic phía sau nó. Để đọc những định dạng dữ liệu lạ, hay những đoạn mã dài ai đó viết từ lâu, và lần ra nó làm gì, thì nó đáng tin đến kinh ngạc. Đây vốn là địa hạt chúng tôi không hiểu ngay từ đầu, nên một sai sót cũng chẳng tốn kém bao nhiêu. Có được góc tiếp cận rồi thì phần còn lại con người kiểm chứng được.

Gần gũi hơn: những chương trình NC do chính các hãng máy xuất ra. Thành thật mà nói, tôi không ưa chúng lắm. Không thụt lề, chú thích chẳng giúp được gì, không có cách nào đọc ra chúng đang làm gì. Một chương trình không đọc được là một chương trình không thể dừng lại để kiểm tra. AI lấp vào khoảng trống đó. Bảo nó thêm thụt lề và chú thích vì mã khó đọc, nó trả lại đúng như vậy. Nói rằng mức trừu tượng còn thấp và yêu cầu tách thành các chương trình con, nó chia mã thành những khối có ý nghĩa. Cùng một hành vi, được sắp lại thành hình hài mà con người đọc được — có lẽ đó là cách dùng chúng tôi với tới thường xuyên nhất lúc này.

Điều làm chúng tôi khổ sở nhất là chẳng chỗ nào ghi rằng một chương trình con gây tác dụng phụ lên những biến nào. Gọi nó thì có gì đó thay đổi. Nhưng thay đổi cái gì thì không biết được cho tới khi đọc hết toàn bộ. Cho AI đọc rồi yêu cầu nó liệt kê, trong một chú thích ở đầu, những biến bị ghi bên trong — và nó nhặt ra được. Đó là công việc mà một người phải mất nửa ngày.

Một ví dụ cụ thể. Chúng tôi thường nhờ AI chỉnh lại các chương trình NC cho máy cắt dây EDM. Tiện đến mức suýt làm tôi chảy máu mũi. Trong thế giới NC, dù ai cũng gọi chung là "G-code", mỗi hãng lại có thói quen viết riêng — thực chất là những phương ngữ. Đời máy này viết thế này; đời máy kia cần lệnh kia. Với con người thì đó là chuyện đối chiếu tài liệu hướng dẫn và học ngay tại xưởng.

AI đọc ra điều đó từ chính văn phong của chương trình mà ta đưa cho nó. Nó cảm được đoạn mã đang theo quy ước của hãng nào, rồi viết phần thêm vào theo đúng quy ước ấy. Đưa cho nó cả tài liệu hướng dẫn của hãng, nó bắt đầu dùng những macro riêng của đời máy đó mà chẳng cần ai bảo. Nó đọc ra rằng "cỗ máy này có lệnh này" rồi viết ra với vẻ mặt tỉnh bơ. Cái tri thức ngầm tích tụ nhiều năm dài trên các sàn xưởng lại có thể moi ra được như thế — thành thật mà nói, tôi thấy ớn lạnh.

Nhưng chúng tôi không bao giờ đưa thẳng một chương trình sinh ra như thế vào máy. Chúng tôi gỡ lỗi. Bao giờ cũng chạy trên máy thật, đi từng dòng một, mắt theo dõi giá trị của các biến và chuyển động của sợi dây cắt. Đây chính là lúc M01 (optional stop) mà tôi viết tháng trước phát huy tác dụng. Sản phẩm có trông đẹp đến đâu, nếu thiếu năng lực gỡ lỗi trên máy thật thì không dùng được công cụ này. Hay đúng hơn, tôi tin là không được phép dùng. Coi nó như công cụ sinh ra đáp án đúng thì nguy hiểm; coi nó như công cụ tìm ra góc tiếp cận thì lợi hại. Nhưng xác nhận góc tiếp cận ấy bao giờ cũng thuộc về phía con người.

■ Có nên để nó là một hộp đen không?

Điều đó đưa chúng ta trở lại câu hỏi mở đầu. Mã do AI sinh ra có thể đưa vào xưởng mà không nhìn vào bên trong hay không? Thành thật mà nói, chúng tôi phân biệt trường hợp được phép và trường hợp không được phép. Hiện tại, lằn ranh chúng tôi vạch ra là theo chỗ nó nằm. Nơi mà sai sót còn có thể phát hiện và sửa lại sau, nơi thứ duy nhất mất đi là thời gian, thì chúng tôi dùng mà không lần hết toàn bộ. Nơi máy chuyển động, kích thước được ấn định và vật liệu bị tiêu hao — nơi không có lần thử thứ hai — thì có người đọc hết, dù đường vòng có dài đến đâu.

Chỗ khó xử là hộp đen không chỉ nằm ở phần AI viết. Phần mềm ngày nay được dựng lên bằng cách gọi vào rất nhiều thành phần — những thư viện do ai đó, ở đâu đó, công bố trên GitHub và những nơi khác. Mới đây thôi đã có một sự cố lớn trong thế giới JavaScript. (Thực ra, cửa hậu gần như ngày nào cũng xuất hiện.) Một thư viện mà vô số phần mềm dựa vào đã bị chiếm quyền và bị cài vào một cơ chế chạy ngay khi cài đặt rồi tự lan tiếp sang gói kế tiếp. Có vẻ hàng trăm gói đã bị nhiễm chỉ trong vài giờ. Không lâu trước đó còn có những vụ chặn giữa đường để đánh tráo địa chỉ nhận thanh toán — tức là can thiệp vào chính phần xử lý tiền bạc.

Nhờ AI làm "đại loại thế này", nó sẽ tự nhiên chọn và đưa vào những thành phần tiện lợi. Một phần lý do nó nhanh là vì nó không tự viết những thành phần ấy. Thứ chúng ta nhận về, vì vậy, có cấu trúc hai lớp: bên trong chiếc hộp do AI viết, nó lại đang gọi đến chiếc hộp của người khác. Không người thợ nào cắt vật liệu mà không biết trong đó pha những gì. Tôi nghĩ phần mềm cũng vậy.

Câu hỏi này — liệu có thể tin chiếc hộp của người khác hay không — không hề mới. Giữa những năm 1990, D. J. Bernstein, người viết chương trình chuyển thư qmail (chính chúng tôi cũng từng vận hành nó hơn mười năm trước), thậm chí còn không tin cả thư viện chuẩn của C — những thành phần đi kèm với ngôn ngữ mà ai cũng dùng chẳng chút hoài nghi. Trong các ghi chú thiết kế, ông nói rằng mình gần như đã từ bỏ thư viện chuẩn, và thay những chỗ dễ xảy ra tai nạn nhất, như xử lý chuỗi và quản lý bộ nhớ, bằng những thành phần nhỏ do chính ông phát triển qua nhiều năm. Ông không đi xa đến mức dựng lại cả hệ điều hành, nhưng ở một điểm thì ông triệt để: hãy đặt những phần nguy hiểm dưới quyền kiểm soát của chính mình.

Điều xuyên suốt qmail là ý tưởng giảm đến mức thấp nhất những thứ mình buộc phải tin. Không chỉ tự viết lấy các thành phần, ông còn chia bên trong chương trình thành những phần nhỏ theo vai trò, dựng sao cho ngay cả các phần của chính ông cũng không tin lẫn nhau. Nếu một phần bị chiếm quyền, nó cũng không đi xa hơn được. Ba mươi năm trước đã có người nghĩ thấu đến vậy. Dĩ nhiên chúng tôi không thể bắt chước chuyện tự viết mọi thư viện. Nhưng ý tưởng — hãy vạch ranh giới với giả định rằng những thứ không đáng tin sẽ lẫn vào — thì chuyển thẳng sang thời nay.

Và điều đáng sợ là nếu chiếc hộp quá lớn thì không còn đường lui. Ôm nguyên một khối lớn mà bên trong mình không hiểu, thì đến khi có chuyện cũng không tách nó ra được. Vì vậy, biện pháp phải được lo ngay từ khâu thiết kế: hãy giữ nó ở dạng lúc nào cũng có thể thay ra. Phần này thay bằng thứ khác được; bỏ thành phần này đi thì toàn bộ vẫn chạy. Dựng như thế thì đến ngày có chuyện, ta chỉ việc vứt đúng chiếc hộp đó đi.

Điều đó đòi hỏi năng lực thiết kế theo nghĩa hướng đối tượng. Coi cái gì là một đơn vị, phơi ra bên ngoài những gì, giấu đi bao nhiêu phần bên trong? Vạch ranh giới ở đâu? Thứ trước kia vẫn được xem là "viết cho đẹp" nay đã thành một nhu cầu thiết thực để không rước thứ nguy hiểm vào trong. Chính vì AI viết phần nội dung, nên cái cần đến là năng lực quyết định ranh giới.

Và lằn ranh này sẽ tự xê dịch nếu cứ để mặc nó. Sau một chuỗi những lần trót lọt, người ta không tránh khỏi muốn làm chiếc hộp lớn hơn. Tệ hơn nữa, năng lực nhận ra nguy hiểm cùn đi đúng theo tỷ lệ với việc mình tự viết ít đi. Công cụ này có đặc tính là càng dùng nhiều thì càng nhìn xuyên qua được ít. Vì vậy, lằn ranh phải được vạch lại ở phía con người, chứ không phải phía công cụ.

■ Kỹ thuật hệ thống, hơn là viết mã

Nhìn lại cả năm, đây là chỗ cảm nhận của tôi thay đổi nhiều nhất: thứ thật sự không thể thiếu từ đây trở đi không phải là bản thân việc viết mã, mà là kỹ thuật hệ thống.

Quyết định dựng cái gì và không dựng cái gì. Vạch ranh giới giữa phần giao cho máy và chỗ phán đoán của con người tiếp quản. Chuẩn bị sẵn, từ trước khi dựng, cách quay về khi nó ngừng chạy. Quyết định dữ liệu nằm ở đâu và ai chịu trách nhiệm về nó. AI có thông minh đến đâu cũng sẽ không quyết những điều này thay bạn — bởi quyết được chúng đòi hỏi phải hiểu công việc ngay tại xưởng.

Khi thời gian ngồi viết mã giảm đi, chúng tôi bắt đầu dành thời gian cho thiết kế, cho vận hành, và cho việc phán đoán lúc nào nên dừng. Trớ trêu thay, chính việc công sức viết lách biến mất lại làm cho sức nặng của những công việc đến trước khi viết trở nên dễ thấy hơn nhiều.

■ Toàn bộ công đoạn làm tại chỗ, ở Arita

Trong một công ty nhỏ, người dựng nên nó cũng là người dùng nó, và khi nó hỏng thì chính người ấy sửa. Vì vậy, "chúng ta có dựng được không?" quan trọng kém xa "cái này có nằm trong tầm chúng ta tự chăm sóc được không?" Hãy giữ nó ở quy mô mà đến ngày nó dừng lại, mình có thể tự sức mình khôi phục. Không hào nhoáng, nhưng tôi tin đây chính là ý nghĩa của một cuộc DX vừa vặn với cỡ của mình.

Chuyện này giống hệt chuyện làm egi. Mẫu thử nay ra đời nhanh hơn trước rất nhiều. Nhưng bước xác nhận chúng ngoài biển thì không cách nào rút ngắn được. Thứ quyết định hay dở, rốt cuộc, bao giờ cũng là biển. Dựng càng nhanh thì chúng tôi càng dồn thêm thời gian cho việc xác nhận — đó là cách dùng mà chúng tôi đã chọn.

Ở một thị trấn nhỏ nơi tỉnh lẻ — Arita, tỉnh Saga, Nhật Bản — chúng tôi vẫn làm egi tại chỗ qua toàn bộ công đoạn, từ thiết kế đến cắt khuôn, sản xuất hàng loạt và bán ra. Đó là điều tháng tám đã khiến tôi suy nghĩ. Những thành phần do ai đó ở đâu đó trên thế giới viết ra đang chạy bên trong chính xưởng của chúng tôi, và một AI đang đọc các phương ngữ của những cỗ máy nhà chúng tôi. Giữa tất cả những điều đó, cái gì nên được giữ lại trong tay con người? Câu trả lời còn chưa đi được nửa đường, nhưng tôi định sẽ không ngừng nghĩ về nó.

■ Ra biển trong tháng này

Tháng chín mang đến cho chúng tôi một loạt màu mới và sản phẩm mới. Akazamurai Meteor Glow Orange là một sắc cam đổi vẻ giữa ánh lân quang và ánh đèn UV; dự kiến phát hành trong tháng này. JetChaser Purple Edition, hướng đến shore tip-run, cũng ra trong tháng này. Ngoài ra, JetChaser cỡ 3.0 và cỡ 3.1 sẽ được bán rộng rãi, dự kiến giao hàng vào cuối tháng chín.

Năm nay cũng là năm thứ mười lăm kể từ khi màu "Akazamurai" của EgiSharp ra đời. Cuối tháng trước, chúng tôi đã công bố hình ảnh của một màu kỷ niệm mười lăm năm. Việc nó vẫn được chọn suốt mười lăm năm không phải là sự tự tin của chúng tôi — đó là câu trả lời do chính những người đã dùng nó đưa ra.

Công cụ có thông minh đến đâu, người phán đoán sau cùng vẫn là con người, và thứ quyết định hay dở vẫn là biển. Chúng tôi sẽ ghi nhớ điều đó và tiếp tục làm ra đồ vật, từng bước một. Tháng này cũng mong tiếp tục nhận được sự ủng hộ của quý vị.

Tháng 9 năm 2026
KeyStone Corporation
Nobuhide Kanagawa, Giám đốc đại diện