Có một nghịch lý đang diễn ra trong ngành phần mềm.
Trí tuệ nhân tạo đang trở nên cực kỳ giỏi ở việc tạo ra code phức tạp. Nó có thể viết hàng nghìn dòng trong vài giây. Nó nhớ mọi bộ công cụ, mọi mẫu thiết kế, mọi thông lệ từng được publish.
Vậy mà các engineer giá trị nhất trong thời đại AI không phải người dùng AI để tạo nhiều code hơn. Là người dùng AI để tạo ít code hơn — code đơn giản hơn, kiến trúc rõ ràng hơn, hệ thống dễ thay đổi hơn.
Lý do nằm ở chỗ hai nguyên tắc cũ vừa trở thành kỹ năng quan trọng nhất của thập kỷ tới.
Nguyên lý đầu
Tư duy từ nguyên lý đầu đơn giản là: thay vì áp dụng câu trả lời có sẵn, quay lại các sự thật cơ bản của tình huống và tự xây câu trả lời từ đó.
Năm 2016, tôi cần một MQTT client cho ESP32. Các thư viện có sẵn lúc đó được viết cho hệ thống có nhiều bộ nhớ. Port một thư viện như vậy xuống sẽ kế thừa các giả định không còn đúng.
Thay vì, tôi quay lại các sự thật cơ bản — MQTT thật sự là gì, ESP32 thật sự có gì, IoT thật sự cần gì, API thật sự phải trông như thế nào. Viết từ các sự thật đó, kết quả là một client gọn, tối ưu, đơn giản đến mức dùng được trong 10 phút. Client đó trở thành esp-mqtt, component MQTT chính thức của ESP-IDF. Các quyết định thiết kế ban đầu vẫn đúng sau gần 10 năm.
Sự khác biệt không phải ở kỹ năng coding. Là ở chỗ từ chối câu trả lời có sẵn và quay lại sự thật cơ bản.
Đây là loại phán đoán mà AI sẽ tăng tốc cần thiết — không phải giảm. Vì AI sẽ luôn cho bạn thông lệ phổ biến nhất, bài viết được đọc nhiều nhất, framework được star nhiều nhất. AI là máy tổng hợp consensus. Nó không biết bối cảnh của bạn.
Người duy nhất biết bối cảnh của bạn là bạn. Dùng bối cảnh đó để từ chối câu trả lời có sẵn — đó là tư duy nguyên lý đầu.
KISS — không phải khẩu hiệu, là toán học
KISS — Keep It Simple, Stupid — bị giảm xuống thành sticker đặt trên màn hình từ những năm 1960. Người ta đã quên ý nghĩa thật của nó.
Ý nghĩa thật: sự phức tạp có chi phí phi tuyến. Mỗi component thêm vào hệ thống không tăng chi phí cộng — tăng theo cấp số nhân.
Một hệ thống 10 component không phức tạp gấp đôi hệ thống 5 component. Nó phức tạp gấp 4-8 lần — vì số tương tác giữa các component tăng theo bình phương.
Đây là lý do hệ thống doanh nghiệp 5 năm tuổi thường không thể bảo trì được. Không phải vì code xấu. Vì độ phức tạp tích lũy đã vượt qua khả năng nhận thức của bất kỳ ai có thể giữ trong đầu cùng lúc.
KISS không phải lời khuyên về phong cách. Là bảo hiểm chống lại chính cấp số nhân của độ phức tạp.
esp-mqtt chính nó là một bài tập về KISS. MQTT spec có rất nhiều tính năng tùy chọn — retained messages, will messages, các mức QoS, session persistence, keep-alive negotiation, multi-level wildcards, và hàng chục tính năng khác. Một thư viện mở hết tất cả chúng ra sẽ không thể vừa với một chip embedded có RAM hạn chế. Kỷ luật ngược lại: xác định những tính năng mà thiết bị IoT thật sự cần trong production, làm tốt những cái đó, bỏ lại phần còn lại. Thư viện nhỏ vì phần lớn của nó đã được cố ý không viết.
Engineer giỏi nhất tôi từng làm cùng có một câu: "Bất kỳ ai cũng có thể thêm tính năng. Người giỏi biết cắt cái gì."
Trong thời đại AI, câu này quan trọng hơn bao giờ hết. AI làm việc thêm dễ dàng kinh khủng. Một prompt, hàng trăm dòng code. Một câu hỏi, mười tính năng được đề xuất.
Người không có KISS trong đầu sẽ dùng AI để xây hệ thống quá phức tạp. Sáu tháng sau, không ai bảo trì được — kể cả AI, vì AI không hiểu hệ thống đó hơn bạn.
Người có KISS trong đầu dùng AI để làm ít hơn. AI viết function, họ xóa một nửa. AI đề xuất framework, họ chọn không dùng. AI tạo lớp trừu tượng, họ inline trở lại.
Cộng hưởng — tại sao hai nguyên tắc này cùng nhau mạnh hơn AI
Nguyên lý đầu giúp bạn từ chối câu trả lời sai từ AI. KISS giúp bạn cắt giảm khi AI tạo ra quá nhiều.
Hai nguyên tắc này cộng lại tạo ra điều AI không có: phán đoán.
AI có thể tạo ra mọi giải pháp khả dĩ. Nó không thể chọn giải pháp đúng cho bối cảnh của bạn. Đây không phải vấn đề mô hình mạnh hơn sẽ giải quyết — đây là vấn đề cấu trúc của thông tin.
Để chọn giải pháp đúng, cần biết:
- Bối cảnh cụ thể (chỉ bạn biết)
- Ràng buộc thực tế (chỉ bạn biết)
- Mục tiêu dài hạn (chỉ bạn biết)
- Đánh đổi bạn sẵn sàng chấp nhận (chỉ bạn biết)
AI không bao giờ có đủ context này, dù mô hình lớn đến đâu. Vì context này nằm trong đầu bạn, trong văn hóa team bạn, trong lịch sử khách hàng của bạn, trong các quyết định nhỏ mà không ai write down.
Engineer dùng AI hiệu quả không phải người prompt giỏi nhất. Là người có phán đoán tốt nhất để biết khi nào không nghe AI.
Khả năng thích ứng — kỹ năng định nghĩa thập kỷ tới
Có một thuộc tính nữa kết nối nguyên lý đầu và KISS với AI: khả năng thích ứng.
Hệ thống được xây với nguyên lý đầu + KISS có một đặc tính mà hệ thống phức tạp không có: chúng có thể thay đổi.
Khi MQTT 5.0 ra đời nhiều năm sau bản đầu tiên của esp-mqtt, việc thêm support không phải viết lại — chỉ là mở rộng kiến trúc đã có. Nền tảng đơn giản hấp thụ được protocol mới mà không gãy.
Khi yêu cầu thay đổi — và sẽ thay đổi, mỗi 6 tháng trong thời AI — hệ thống đơn giản có thể được tái cấu trúc. Hệ thống phức tạp phải được viết lại hoặc bỏ.
Tốc độ đang tăng. Mô hình AI tốt nhất hôm nay sẽ không phải tốt nhất sau 6 tháng. Framework đang lên hôm nay sẽ bị thay thế. Câu hỏi không phải "công nghệ nào để đặt cược" — mà "làm sao xây hệ thống có thể thích ứng với bất kỳ công nghệ nào tiếp theo".
Câu trả lời: xây hệ thống đơn giản nhất có thể giải quyết vấn đề hiện tại, với các giả định được làm rõ và có thể thách thức được.
Hệ thống như vậy không phải khoản đầu tư cho hôm nay. Là khoản đầu tư cho 5 năm tới, khi bạn sẽ phải tái cấu trúc nó bốn lần với bốn công nghệ mới.
Vì sao AI sẽ thưởng cho cách suy nghĩ này
Có một nghịch lý nữa: AI hoạt động tốt nhất với code đơn giản.
Cho AI một codebase phức tạp với hàng nghìn lớp trừu tượng — AI sẽ tạo bug. Cho AI cùng codebase đó với cấu trúc rõ ràng và ít layer — AI sẽ tạo code chính xác.
Engineer build hệ thống KISS không chỉ giúp con người bảo trì. Họ build hệ thống mà AI có thể hỗ trợ.
Trong 5 năm tới, các team có hệ thống đơn giản sẽ ship nhanh gấp 10 lần các team có hệ thống phức tạp — không phải vì họ giỏi hơn, mà vì AI của họ có thể giúp nhiều hơn.
Đây là cấp số nhân thật của thời đại AI: không phải ai dùng nhiều AI nhất, mà ai có codebase mà AI có thể hiểu nhất.
Một câu hỏi để kiểm tra
Trước khi bạn viết function tiếp theo, hỏi:
Function này tồn tại vì sự thật cơ bản nào trong bối cảnh của tôi?
Nếu không có câu trả lời rõ — function đó là code thừa.
Có cách nào đơn giản hơn để giải vấn đề này không?
Nếu có — dùng cách đơn giản hơn.
Một engineer mới có thể hiểu hệ thống này trong bao lâu?
Nếu hơn một tuần — hệ thống đang vượt ngưỡng KISS.
Ba câu hỏi này không phải triết học. Là toán học của cấp số nhân độ phức tạp gặp tốc độ thay đổi của AI.
Engineer không hỏi ba câu này sẽ xây nhiều code hơn bao giờ hết trong 5 năm tới. Và sẽ bảo trì ít hệ thống nhất bao giờ hết.
Engineer hỏi ba câu này sẽ xây ít code hơn. Và sẽ ship sản phẩm có ảnh hưởng nhất.
Kết
Hai nguyên tắc cũ — nguyên lý đầu và KISS — vừa trở thành kỹ năng định nghĩa engineer trong thời đại AI.
Không phải vì chúng mới. Vì chúng cuối cùng có bộ khuếch đại.
AI khuếch đại phán đoán tốt. AI cũng khuếch đại phán đoán xấu. Sự khác biệt giữa hai cái không phải kỹ năng prompt — là khả năng quay lại sự thật cơ bản và biết khi nào đủ rồi.
Engineer giỏi nhất 10 năm tới sẽ không phải người biết nhiều framework nhất. Là người có phán đoán để dùng AI mà không bị AI lái.
Đó là engineer thực sự — không phải người viết code, mà người quyết định code nào không nên viết.
