Thứ quyết định nằm ở câu hỏi được gõ vào

Dạo này tôi hay nghĩ về đề bài này theo một hướng hơi khác với cách nó thường được đặt ra.

Phần lớn tranh luận đang so tốc độ. Fresher có AI làm xong trong một buổi chiều thứ mà trước đây mất ba ngày. Điều đó đúng, và đáng để công nhận.

Nhưng nhìn cách AI thực sự được dùng trong công việc hàng ngày, tôi thấy thứ tạo ra khác biệt giữa hai người không nằm ở chỗ ai lấy được câu trả lời nhanh hơn.

Nó nằm ở câu hỏi đã được gõ vào.

Và đó là phần AI không giúp được.

AI đang tốt lên rất nhanh. Tôi không nghĩ lập luận "AI hay sai" sẽ còn đứng vững lâu, nên tôi không muốn dựa vào nó.

Thứ không tự tốt lên theo là phạm vi. AI trả lời trong đúng khung được đưa ra, và không tự bước ra ngoài khung đó để hỏi những thứ chưa ai nghĩ tới.

Bạn nhờ nó viết hàm xử lý thanh toán, nó viết một hàm đúng yêu cầu. Nó không tự hỏi nếu hai request đến cùng lúc từ hai thiết bị của cùng một user thì sao. Câu đó phải có người đặt ra trước.

Senior đặt được câu đó vì họ từng đứng ở đúng chỗ đó rồi. Race condition chỉ lộ khi tải cao. Một job chạy trùng hai lần vì thiếu idempotency key. Một retry tưởng vô hại nhưng nhân đôi bản ghi.

Fresher không thiếu công cụ để tìm câu trả lời. AI chính là công cụ đó, và nó rất giỏi. Thứ họ thiếu là danh sách câu cần hỏi.

Sẽ có người nói fresher chịu khó đọc blog, đọc postmortem của công ty khác thì cũng biết. Tôi nghĩ điều đó đúng một phần. Nhưng biết một khái niệm tồn tại khác với việc tự nhiên thấy gợn ở đúng dòng code trước mắt, lúc không ai nhắc bạn phải cẩn thận. Cái sau là phản xạ, mà phản xạ thì hình thành qua lặp lại chứ không qua một lần đọc.

AI giỏi giải bài toán có ranh giới rõ. Viết hàm này. Sửa lỗi kia. Refactor đoạn này.

Hệ thống thật hiếm khi có ranh giới rõ như vậy.

Thêm cache ở đây thì mất consistency ở kia. Tách service thì scale được nhưng đổi lấy độ trễ mạng và một lớp lỗi hoàn toàn mới. Đồng bộ thì đơn giản nhưng dễ nghẽn, bất đồng bộ thì linh hoạt nhưng khó debug hơn nhiều lần khi có sự cố.

Nhận một yêu cầu, senior chạy một phép tính ngầm gần như tự động: cái này đụng vào phần nào, phần nào dễ vỡ, vỡ thì vỡ kiểu gì.

Tôi để ý phép tính đó không đến từ tài liệu. Nó đến từ những lần từng thiết kế sai, từng sửa lại kiến trúc lúc hai giờ sáng, từng ngồi họp postmortem giải thích vì sao một quyết định sáu tháng trước lại gây ra sự cố hôm nay.

AI liệt kê được năm cách thiết kế caching. Chọn cách nào cho đúng hệ thống của bạn, với đúng pattern truy cập mà đội bạn đang có, thì vẫn là việc của người ra quyết định.

Nhiều chỗ nguy hiểm nhất trong một codebase không nằm trong code. Chúng nằm trong lịch sử.

Module này viết kỳ lạ vì ba năm trước một khách hàng lớn yêu cầu tính năng đặc biệt, và chẳng ai kịp dọn lại.

Trường kia để giá trị mặc định thay vì bắt buộc nhập, vì lần trước bắt buộc, một đợt import dữ liệu lớn bị chặn ngay trước giờ chốt sổ quý.

Không tài liệu nào ghi đủ những chuyện này. Chúng sống trong đầu người có mặt lúc đó.

Nghĩa là ở đây có một loại kiến thức không nằm trên internet, không nằm trong repo, và cũng không có đường tắt nào để lấy. Nó chỉ tồn tại trong trí nhớ của người từng chịu hậu quả — và đó là người bạn phải hỏi, chứ không phải công cụ.

Tầng này ít được nhắc tới hơn, nhưng theo tôi nó quyết định nhiều thứ hơn cả hai tầng trên.

Một yêu cầu kỹ thuật luôn gắn với một lý do kinh doanh, dù thường không ai nói ra.

"Làm nhanh cái này" có thể là nhanh để kịp ra thị trường. Có thể là nhanh về hiệu năng. Có thể chỉ vì tuần sau sếp cần demo cho nhà đầu tư.

Ba lý do dẫn tới ba cách làm khác hẳn nhau. Chọn sai thì code vẫn chạy đúng, nhưng hướng đi đã lệch — và loại sai này thường phải vài tháng sau mới lộ ra, lúc sửa đã đắt.

Senior gom được bối cảnh đó qua nhiều năm ngồi họp, nói chuyện với sales, nghe khách hàng phàn nàn trực tiếp. Họ biết công ty đang ở giai đoạn nào và đang sợ điều gì nhất. Phần lớn thứ đó chưa từng được viết ra ở đâu, nó chỉ là trực giác kiểu "cái này nhìn nhỏ nhưng động vào là phòng pháp lý nhảy vào".

Fresher chưa có nó, không phải vì kém, mà vì chưa đủ thời gian để có.

Một bài kết luận rằng bên có nhiều năm hơn thì thắng rất dễ bị đọc thành lời tự khen của người đã ở trong ngành đủ lâu. Nên tôi muốn nói rõ mấy điểm, để lập luận đứng được bằng chính nó.

AI có ích thật cho fresher. Nó rút ngắn đường học, cho họ chạm vào những thứ mà trước đây mất hàng tháng mới tiếp cận được. Ai phủ nhận điều đó là không trung thực.

Khoảng cách này cũng không cố định. Có những bạn học rất nhanh, chủ động tìm việc có hậu quả thật để tự rèn, và rút ngắn được đáng kể. Nhưng khi làm vậy, họ đang đi đúng con đường senior đã đi, chỉ nhanh hơn. AI giúp đi nhanh hơn trên con đường đó chứ không thay thế nó.

Và lập luận này có một điều kiện biên rõ ràng: nó đúng chừng nào AI còn trả lời trong phạm vi được hỏi. Nếu tới ngày agent tự nêu ra được những câu hỏi chưa ai nghĩ tới, phần lớn bài này sẽ hết giá trị. Tôi chưa thấy điều đó, ít nhất là chưa.

Senior thắng. Không phải ở tốc độ, mà ở chỗ họ biết cần hỏi gì trước khi gõ, biết chỗ nào sẽ vỡ, và biết công ty thật sự đang cần gì.

Nhưng càng nghĩ tôi càng thấy có một câu hỏi nằm bên dưới đề bài này, và nó đáng bàn hơn: AI đang khuếch đại loại năng lực nào?

Nó khuếch đại rất mạnh khả năng biến một ý định rõ ràng thành kết quả. Với việc hình thành ý định đó cho đúng ngay từ đầu thì nó gần như không giúp gì.

Phần thứ hai mới là phần lâu nay quyết định ai làm việc tốt. Và nó cũng là thứ duy nhất trong toàn bộ chuỗi này không rút ngắn được bằng công cụ.

Không biết mọi người đang làm việc cùng AI mỗi ngày có thấy giống vậy không.