Hôm nay tôi muốn nói về AI, nhưng không phải để ca ngợi nó như một phép màu.
Là một người làm việc tại nhà (WFH) toàn thời gian, tôi hiểu rõ giá trị của sự tự giác và cạm bẫy của sự buông thả. Khi không có ai nhìn vào màn hình của bạn, ranh giới giữa “làm việc hiệu quả” và “làm cho xong chuyện” trở nên rất mong manh. Và AI, trớ trêu thay, đang khiến ranh giới đó mờ nhạt hơn bao giờ hết.
Thực tế cho thấy nhiều lập trình viên đang dùng AI để trốn tránh việc tư duy, chứ không phải để tăng năng suất.
1. Sự lạm phát của những dòng code rác
Trước đây, khi chúng ta viết một đoạn code, chúng ta phải “trả giá” cho nó bằng thời gian suy nghĩ. Cái giá đó khiến chúng ta cân nhắc: Liệu có cách nào ngắn gọn hơn không? Liệu logic này có thừa thãi không?
Bây giờ, với một cú Tab hay Enter, AI có thể mớm cho bạn 50 dòng code trong tíc tắc. Cảm giác rất “phê”, rất năng suất. Nhưng hãy tỉnh táo lại.
Code là nợ (Liability), không phải tài sản (Asset).
Càng nhiều code sinh ra mà không qua sự thấu hiểu sâu sắc, khoản nợ kỹ thuật (technical debt) càng chồng chất. Tôi đã từng mất cả buổi chiều chỉ để debug một function do AI viết. Về mặt cú pháp, nó hoàn hảo. Về mặt logic, nó chạy được. Nhưng về mặt hiệu năng, nó là thảm họa khi chạy trên production với lượng người dùng lớn.
Sự lười biếng mà tôi luôn theo đuổi là để tối ưu hóa: Làm ít nhất để đạt hiệu quả cao nhất. Còn sự lười biếng mà AI đang nuôi dưỡng là sự thụ động: Làm nhiều nhất (sinh ra nhiều code nhất) với ít nỗ lực não bộ nhất.
Đó là hai con đường hoàn toàn trái ngược.
2. Mất dần khả năng “cảm” hệ thống
Có những vấn đề trong hệ thống không nằm ở dòng code, mà nằm ở kiến trúc.
Khi bạn gõ từng dòng lệnh cấu hình server, bạn hiểu tại sao port này đóng, port kia mở. Khi bạn tự tay viết một câu truy vấn SQL phức tạp, bạn hình dung được cách database index dữ liệu. Đó là cái “cảm”, hay còn gọi là trực giác kỹ thuật.
Lạm dụng AI khiến chúng ta trở thành những người lắp ghép (assemblers) thay vì những kiến trúc sư (architects). Chúng ta paste lỗi vào chatbox, nhận về câu trả lời, copy ngược lại vào IDE. Nó chạy. Chúng ta vui mừng. Nhưng chúng ta không hiểu tại sao nó chạy.
Đến khi hệ thống sập (downtime) vào lúc 3 giờ sáng và con AI không thể đưa ra câu trả lời vì vấn đề nằm ở tầng vật lý hay network sâu bên dưới, ai sẽ là người cứu hệ thống? Chắc chắn không phải là các vibe-coder.
3. Bảo mật: Sự ngây thơ chết người
Nguyên tắc quan trọng mà một lập trình viên càng làm lâu năm sẽ càng “thấm”: Không bao giờ tin tưởng tuyệt đối, kể cả code của chính mình.
Nhưng với AI, tôi thấy một sự tin tưởng ngây thơ đến lạ lùng. Tôi đã thấy những đoạn code chứa API Key, những logic xác thực (auth) lỏng lẻo, hay những thư viện “ma” (hallucinated packages) được AI gợi ý và lập trình viên cứ thế đưa vào dự án.
AI không phải là chuyên gia bảo mật. Nó là một con vẹt học nói xác suất thống kê. Nó không chịu trách nhiệm khi dữ liệu khách hàng của bạn bị lộ. Bạn mới là người chịu trách nhiệm.
4. Vậy dùng AI thế nào cho “đúng chất”?
Đừng dùng AI để thay não. Hãy dùng nó để mở rộng não. Quy tắc của tôi rất đơn giản:
Đối xử với AI như là nhân viên của bạn, không phải thầy của bạn!
Bạn phải là người có kiến thức vững vàng trước (nếu chưa vững hãy dùng AI để học). Hãy ra lệnh cho nhân viên AI làm những thứ bạn biết rõ, chứ không phải nhờ thầy AI làm hộ những thứ bạn không biết. Một số best practice thực tế:
Biến AI thành “Red Team” (Đội tấn công) Thay vì bảo nó viết code, hãy bắt nó phá code của bạn.
- Audit bảo mật: “Đây là logic xác thực tao viết. Hãy đóng vai hacker tìm 3 cách để bypass nó (SQLi, XSS, Race Condition).”
- Tìm Edge Cases: “Hàm này xử lý thanh toán. Hãy liệt kê 10 trường hợp input quái dị nhất (số âm, null, unicode, overflow) có thể làm nó crash.”
- Tối ưu hiệu năng: “Đoạn query này chạy mất 2s. Tại sao nó chậm và index thế nào để xuống dưới 100ms?”
Dùng AI để làm những việc “tay chân” (Monkey Work) Dành năng lượng não bộ cho logic nghiệp vụ, ném phần rác cho AI.
- Regex: Đừng bao giờ tự viết Regex. Hãy mô tả, để AI viết, rồi bắt nó giải thích ngược lại.
- Boilerplate Code: Các class DTO, model mapping, config file nhàm chán.
- Mock Data: “Tạo cho tao file JSON 1000 dòng dữ liệu user giả lập, bao gồm cả các trường hợp tên tiếng Việt có dấu và ký tự đặc biệt.”
- Unit Test cơ bản: “Viết khung test cho function này, cover đủ các nhánh if/else.”
Dùng AI làm “Sách giáo khoa” tương tác Đừng copy paste giải pháp. Hãy bắt nó giải thích bản chất.
- Giải mã Legacy Code: Paste đoạn code spaghetti của người tiền nhiệm vào: “Giải thích luồng chạy của đống này cho một đứa trẻ 5 tuổi.”
- Đọc tài liệu (RTFM): Paste đoạn Documentation khó hiểu của AWS/Linux vào: “Tóm tắt 3 ý chính và giải thích tại sao tham số A lại xung đột với tham số B.”
- So sánh kỹ thuật: “Tao đang phân vân giữa RabbitMQ và Kafka cho dự án nhỏ này. Đừng lôi lý thuyết, hãy so sánh dựa trên chi phí vận hành và độ phức tạp khi setup.”
Nguyên tắc 3 KHÔNG khi dùng AI:
- Không tin tưởng tuyệt đối vào kiến trúc hệ thống hay library nó gợi ý (kiểm tra xem package đó có tồn tại hay đã chết 5 năm trước).
- Không paste API Key, mật khẩu, dữ liệu thật của công ty lên chat. Luôn dùng mock/sample data.
- Không commit code của AI mà chưa đọc hiểu từng dòng (Review code của AI kỹ hơn review code của thực tập sinh). Nếu chưa hiểu đoạn code nào hãy bắt AI giải thích riêng đoạn đó.
Tóm lại, dùng AI để tư duy sâu hơn, tiết kiệm thời gian hơn, làm thay bạn những việc nhàm chán máy móc.
Lời kết
Với lập trình viên, kỷ luật luôn quan trọng hơn động lực. Khi AI xuất hiện, kỷ luật trí tuệ (intellectual discipline) lại càng quan trọng hơn. Đừng dùng AI để để che đậy sự lười biếng trong tư duy. Hãy dùng AI để thách thức giới hạn của bản thân.
Theo tôi nghĩ, dù cho công nghệ thay đổi và AI có phát triển tới mức nào đi nữa thì tư duy giải quyết vấn đề (problem-solving mindset) mới là thứ giữ cho bạn không bị đào thải.
