Vì sao Software Fundamentals quan trọng hơn bao giờ hết trong thời AI?

1. Ý tưởng trung tâm

Trong thời AI coding tools như ChatGPT, Claude Code, Cursor, GitHub Copilot, nhiều người nghĩ rằng:

“AI viết code được rồi, vậy học nền tảng lập trình còn cần gì nữa?”

Nhưng thông điệp là ngược lại:

AI càng mạnh, người dùng càng cần hiểu nền tảng phần mềm để biết mình đang yêu cầu gì, đánh giá code ra sao, sửa lỗi thế nào và thiết kế hệ thống bền vững.

AI có thể giúp viết code nhanh hơn, nhưng không tự đảm bảo code đúng, sạch, dễ bảo trì, an toàn và phù hợp với business logic.

Nói đơn giản:

AI giống như một nhân viên rất nhanh tay, nhưng nếu người quản lý không hiểu nghề, sản phẩm làm ra rất dễ thành “đống code chạy được nhưng không ai dám sửa”.

2. Software Fundamentals là gì?

Software Fundamentals là những nguyên lý nền tảng giúp một người không chỉ “viết được code”, mà còn xây được phần mềm tốt.

Nó bao gồm:

3. Vì sao AI không thay thế được nền tảng?

3.1. AI có thể viết code, nhưng không luôn hiểu mục tiêu thật

AI thường phản hồi dựa trên prompt. Nếu prompt mơ hồ, nó sẽ tự suy diễn.

Ví dụ bạn nói:

“Build cho tôi hệ thống CRM đơn giản.”

AI có thể tạo ra một app chạy được, nhưng nó chưa chắc hiểu:

• CRM này dùng cho ngành nào?
• Lead có bao nhiêu trạng thái?
• Ai được quyền xem dữ liệu?
• Dữ liệu có cần đồng bộ với ads report không?
• Có cần tracking lịch sử chăm sóc khách hàng không?
• Có cần phân quyền sales/marketing/admin không?

Nếu người dùng không có nền tảng hệ thống, họ dễ nhầm “app chạy được” với “app dùng được lâu dài”.

3.2. Code rẻ hơn, nhưng bad code đắt hơn

Một luận điểm rất quan trọng từ hệ sinh thái của Matt Pocock là: code không hề rẻ nếu nó là code tệ. AI Hero cũng nhấn mạnh rằng software fundamentals không lỗi thời mà trở nên thiết yếu trong thời AI.  

Vì AI giúp tạo code rất nhanh, vấn đề mới xuất hiện là:

Chúng ta có thể tạo ra nhiều code tệ hơn, nhanh hơn.

Bad code gây ra chi phí ở các tầng sau:

Trong thời AI, tốc độ tạo code tăng lên. Nhưng nếu thiếu nền tảng, tốc độ tạo nợ kỹ thuật cũng tăng theo.

4. Sự khác nhau giữa “vibe coding” và “real engineering”

Vibe coding là cách viết phần mềm bằng cách mô tả bằng ngôn ngữ tự nhiên rồi để AI sinh code. Khái niệm này thường gắn với việc người dùng không nhất thiết hiểu sâu code bên dưới. Một số nguồn cũng ghi nhận rủi ro của vibe coding là người dùng có thể không hiểu đầy đủ logic, lỗi hoặc vấn đề bảo mật trong code do AI tạo ra. 

Nhưng real engineering thì khác.

Một câu dễ nhớ:

Vibe coding giúp bạn tạo bản demo. Software fundamentals giúp bạn xây sản phẩm sống được ngoài đời.

5. Vai trò mới của lập trình viên trong thời AI

Trước đây, lập trình viên chủ yếu là người viết code.

Trong thời AI, vai trò chuyển dần thành:

Người thiết kế hệ thống, đặt yêu cầu, kiểm định đầu ra và dẫn dắt AI.

AI có thể là “tay viết code”, nhưng con người vẫn cần là:

• Architect: quyết định cấu trúc hệ thống.
• Reviewer: kiểm tra code có đúng không.
• Debugger: hiểu lỗi đến từ đâu.
• Product thinker: hiểu business logic.
• Security gatekeeper: tránh rủi ro bảo mật.
• Maintainer: đảm bảo hệ thống sống được lâu dài.

6. Những nền tảng quan trọng nhất cần học

6.1. Đọc hiểu code

Không cần tự viết mọi dòng code, nhưng phải đọc được:

• Hàm này làm gì?
• Dữ liệu đi từ đâu đến đâu?
• Có xử lý lỗi không?
• Có case nào bị bỏ sót không?
• Có hard-code gì nguy hiểm không?
• Có phần nào AI tự bịa logic không?

Bài tập học:
Lấy một đoạn code AI viết ra và tự giải thích từng dòng bằng ngôn ngữ đời thường.

6.2. Thiết kế dữ liệu

Phần mềm sống bằng dữ liệu.

Nếu thiết kế data sai, app sẽ nhanh chóng rối.

Ví dụ với một phần mềm trợ lý Marketing:

Các loại dữ liệu có thể gồm:

• Campaign
• Channel
• Ads report
• Lead
• Customer insight
• Content asset
• Meeting note
• Sales feedback
• Budget
• KPI

Nếu không có schema rõ, AI có thể lưu dữ liệu lung tung. Sau này muốn phân tích sẽ rất khó.

Câu hỏi nền tảng cần đặt:

• Entity chính là gì?
• Mỗi entity có field nào?
• Quan hệ giữa các entity là gì?
• Dữ liệu nào là raw?
• Dữ liệu nào là clean?
• Dữ liệu nào cần versioning?
• Dữ liệu nào cần cập nhật thường xuyên?

6.3. Testing

AI viết code nhanh, nhưng vẫn có thể sai.

Testing là lớp bảo vệ.

Có 3 tầng dễ hiểu:

Ví dụ:

Khi upload file Excel ads report, hệ thống phải đọc đúng dữ liệu, chuẩn hóa đúng cột, lưu vào PostgreSQL, rồi trả về báo cáo đúng.

Đây không chỉ là “code chạy”, mà là workflow đúng từ đầu đến cuối.

6.4. Debugging

Người không có nền tảng thường debug bằng cách:

“Copy lỗi đưa cho AI sửa tiếp.”

Cách này có thể hiệu quả lúc đầu, nhưng dễ thành vòng lặp:

sửa lỗi A → sinh lỗi B → sửa lỗi B → vỡ lỗi C.

Người có nền tảng sẽ hỏi:

• Lỗi xuất hiện ở input, logic hay output?
• Lỗi do data sai hay code sai?
• Lỗi do environment, API, quyền truy cập hay dependency?
• Có log không?
• Có tái hiện lỗi được không?
• Root cause là gì?

Nghiên cứu về các AI coding tools như Claude Code, Codex và Gemini CLI cho thấy nhiều lỗi thực tế liên quan đến chức năng, API, tích hợp, cấu hình, terminal và command execution. Điều này củng cố ý rằng người dùng vẫn cần hiểu hệ thống để kiểm soát lỗi, không thể chỉ tin AI tự sửa mọi thứ.  

6.5. Architecture

Architecture là cách chia hệ thống thành các phần.

Ví dụ một app Marketing OS có thể chia thành:

Input Layer → Raw File Storage → Data Extraction → Data Cleaning → PostgreSQL → Knowledge Base → AI Agent → Reporting Dashboard → User Interface

Nếu không có kiến trúc, AI có thể viết mọi thứ dính vào nhau:

Một file xử lý upload + đọc Excel + gọi AI + lưu database + tạo report + trả kết quả + xử lý lỗi

Ban đầu chạy được. Nhưng sau này sửa rất khó.

Nguyên tắc đơn giản:

Mỗi phần nên có một trách nhiệm rõ ràng.

7. Bóc về nguyên lý gốc

Hãy đặt câu hỏi:

Phần mềm thật ra là gì?

Phần mềm là một hệ thống nhận input, xử lý logic, lưu hoặc biến đổi dữ liệu, rồi tạo output.

Input → Logic → Data → Output

AI chỉ giúp ta viết nhanh phần “logic/code”. Nhưng ta vẫn phải hiểu:

• Input có đúng không?
• Logic có phản ánh đúng thực tế không?
• Data có được lưu đúng không?
• Output có đáng tin không?

Nếu không hiểu 4 phần này, dùng AI càng mạnh càng nguy hiểm.

8. Mô hình học Software Fundamentals trong thời AI

Không cần học như sinh viên ngành Computer Science từ đầu đến cuối. Anh có thể học theo hướng thực chiến:

Giai đoạn 1: Hiểu code và hệ thống

Mục tiêu:

• Đọc được code AI sinh ra.
• Hiểu được file nào làm gì.
• Biết app chạy từ đâu.
• Biết data đi qua các bước nào.

Học:

• JavaScript/TypeScript hoặc Python cơ bản
• JSON
• API
• SQL căn bản
• Git căn bản

Giai đoạn 2: Hiểu dữ liệu và database

Mục tiêu:

• Biết thiết kế bảng.
• Biết quan hệ dữ liệu.
• Biết query để kiểm tra dữ liệu.
• Biết phân biệt raw data và clean data.

Học:

• PostgreSQL
• Table, row, column
• Primary key, foreign key
• Index
• Normalization căn bản
• ETL / ELT

Giai đoạn 3: Hiểu backend workflow

Mục tiêu:

• Biết cách dữ liệu đi từ file/report vào database.
• Biết cách API hoạt động.
• Biết cách log lỗi.
• Biết cách tách module.

Học:

• Backend basics
• REST API
• Authentication
• Error handling
• Background jobs
• Logging

Giai đoạn 4: AI-assisted engineering

Mục tiêu:

• Dùng AI như co-engineer.
• Biết viết prompt kỹ thuật.
• Biết bắt AI giải thích trade-off.
• Biết yêu cầu AI viết test.
• Biết review output.

Học cách prompt:

Trước khi viết code, hãy phân tích kiến trúc. Nêu các module cần có. Nêu schema database. Nêu rủi ro. Sau đó mới viết code từng phần. Mỗi phần phải có test.

9. Checklist khi dùng AI để viết code

Trước khi bảo AI code, hãy hỏi:

A. Về mục tiêu

• Tính năng này giải quyết vấn đề gì?
• Ai là người dùng?
• Input là gì?
• Output là gì?
• Thành công được đo bằng gì?

B. Về dữ liệu

• Dữ liệu đến từ đâu?
• Có format chuẩn không?
• Có dữ liệu lỗi không?
• Có cần lưu bản gốc không?
• Có cần log quá trình xử lý không?

C. Về kiến trúc

• Tính năng này nằm ở module nào?
• Có nên tách service không?
• Có phụ thuộc API ngoài không?
• Nếu lỗi thì fallback thế nào?

D. Về kiểm thử

• Có test cho case bình thường chưa?
• Có test cho case lỗi chưa?
• Có test cho dữ liệu thiếu/sai format chưa?
• Có log để debug chưa?

E. Về bảo trì

• Người khác đọc có hiểu không?
• Có documentation không?
• Có đặt tên biến/hàm rõ không?
• Có hard-code thông tin quan trọng không?

10. Những hiểu lầm cần tránh

Hiểu lầm 1: “AI viết code rồi, không cần học code nữa”

Sai.

Đúng hơn là:

Không nhất thiết phải nhớ cú pháp nhiều như trước, nhưng càng cần hiểu logic, kiến trúc và cách kiểm tra.

Hiểu lầm 2: “Code chạy được là xong”

Sai.

Code chạy được chỉ là tầng thấp nhất.

Một phần mềm tốt cần:

• Đúng logic
• Dễ sửa
• Dễ mở rộng
• Có test
• Có bảo mật
• Có log
• Có documentation
• Có cấu trúc rõ

Hiểu lầm 3: “Cứ để AI tự sửa lỗi”

Sai.

AI có thể hỗ trợ sửa lỗi, nhưng người dùng cần biết:

• Lỗi nằm ở đâu
• Vì sao lỗi xảy ra
• Sửa như vậy có tạo lỗi mới không
• Có test lại chưa

11. Bộ câu hỏi Socrates để tự học

Khi học hoặc build bằng AI, hãy tự hỏi:

1. Vấn đề gốc mình đang giải quyết là gì?
2. Có cách nào đơn giản hơn không?
3. Dữ liệu đi từ đâu đến đâu?
4. Nếu AI viết sai, mình phát hiện bằng cách nào?
5. Nếu 6 tháng sau sửa tính năng này, mình có hiểu lại được không?
6. Có phần nào đang bị AI tự suy diễn không?
7. Mình có đang build prototype hay production system?
8. Nếu người khác vào dự án, họ có hiểu cấu trúc không?
9. Nếu dữ liệu tăng gấp 10 lần, hệ thống có chịu nổi không?
10. Nếu API ngoài bị lỗi, hệ thống phản ứng thế nào?

12. Tóm tắt 10 dòng dễ nhớ

1. AI làm code nhanh hơn, nhưng không tự làm code tốt hơn.
2. Software fundamentals không lỗi thời; nó quan trọng hơn trong thời AI.
3. Người không hiểu nền tảng dễ tạo ra nhiều bad code rất nhanh.
4. Code chạy được chưa chắc là phần mềm dùng được.
5. AI cần người dẫn dắt có tư duy hệ thống.
6. Nền tảng quan trọng nhất: data, architecture, testing, debugging, security.
7. Vibe coding phù hợp demo; real engineering cần nền tảng.
8. Người dùng AI giỏi phải biết review, test và đặt yêu cầu rõ.
9. Trong dự án thật, bad code là chi phí dài hạn.
10. Tương lai không loại bỏ engineer; nó nâng cấp engineer thành người thiết kế và kiểm định hệ thống.

Bài học lớn nhất:

Trong thời AI, lợi thế không còn nằm ở người gõ code nhanh nhất. Lợi thế nằm ở người hiểu hệ thống đủ sâu để biết phải build cái gì, build như thế nào, kiểm tra ra sao và duy trì nó lâu dài.