Bao nhiêu kiến thức kĩ thuật là đủ trong thời đại AI?
Lovable và Cursor giúp bạn tạo sản phẩm trong vài phút, nhưng đến phiên bản thứ hai thì sao? Những kiến thức kỹ thuật tối thiểu bạn cần nắm.
Thuật ngữ trong bài viết
AI - Artificial Intelligence: Trí tuệ nhân tạo, cụ thể hơn là trí tuệ nhân tạo tạo sinh
PM - Product manager: Quản lý sản phẩm
BA - Business analyst: Chuyên viên phân tích nghiệp vụ
Designer: Người thiết kế sản phẩm
Query: Câu truy vấn (tìm, xem hoặc thao thác) dữ liệu
Data analytics: Phân tích dữ liệu
Prototype: Nguyên mẫu sơ bộ
1. AI không/chưa thể thay thế kiến thức nền tảng
Tới thời điểm này (tháng 3 năm 2026), không còn ai nhắc đến bong bóng AI nữa… vì hóa ra nó là quả tạ thật. Tưởng như AI đã tác động tích cực tới thị trường lao động, nhưng hóa ra nó cũng kéo theo nhiều hệ quả tiêu cực:
Thị trường việc làm suy giảm (không phủ nhận một phần do các yếu tố địa chính trị)
Mỗi người phải gánh nhiều đầu việc hơn trước
Và chính vì bận rộn kiêm nhiệm nhiều thứ, các kỹ năng chuyên sâu bị bỏ ngỏ khi định hướng con đường sự nghiệp
Từ những công ty lớn cho đến những công ty mới thành lập mà mình biết, quy trình làm sản phẩm dường như đã biến đổi chóng mặt và trở nên vô cùng đa dạng. PM và QA bắt đầu tập tành viết mã nguồn Front-end, BA phải làm interactive prototype (nguyên mẫu có thể tương tác), Designer phải kiêm luôn công việc của BA… Với xu hướng này, mình tạm đoán rằng phần lớn nhân sự liên quan trực tiếp đến khâu sản xuất trong ngành sản phẩm/phần mềm đều phải động tay vào phần lập trình, ít nhất là những vị trí mình vừa nhắc tới. Với giả thuyết đó, mình viết bài này để bàn xem: bao nhiêu kiến thức kỹ thuật là đủ để chuẩn bị cho tương lai, từ góc nhìn của những vị trí vốn không mang nền tảng kỹ thuật.
Có một lầm tưởng phổ biến của những người không có nền tảng kỹ thuật: họ hoàn toàn có thể tạo ra một sản phẩm bằng Lovable hay Cursor. Điều đó có thể đúng khi chỉ cần vài lần prompt là đã có phiên bản đầu tiên. Nhưng trong bối cảnh làm sản phẩm thật, có rất nhiều ràng buộc không dành cho người thiếu kiến thức kỹ thuật, một trong số đó là đảm bảo khả năng mở rộng. Đến phiên bản thứ hai, thứ ba, có thể bạn sẽ phải để con AI sửa lỗi một cách mù quáng cả ngày mà không hiểu nguyên nhân vì sao. Lý do không chỉ nằm ở giới hạn trong việc tìm và sửa lỗi, mà còn ở chỗ: khi tạo ra những chức năng mà mình không hiểu rõ, bạn đã vô tình sinh ra nhiều logic rác, khiến việc sửa lỗi càng trở nên khó khăn hơn.
Trong bối cảnh làm sản phẩm thật, có rất nhiều ràng buộc không dành cho người thiếu kiến thức kỹ thuật, một trong số đó là đảm bảo khả năng mở rộng. Đến phiên bản thứ hai, thứ ba, có thể bạn sẽ phải để con AI sửa lỗi một cách mù quáng cả ngày mà chưa tìm ra nguyên nhân.
2. Cơ sở dữ liệu
Lưu ý: Do giới hạn của một bài blog và khả năng trả lời vô tận của AI, mình sẽ chỉ nhắc đến và giải thích sơ qua mối liên hệ giữa chúng. Phần khám phá sâu hơn, mình sẽ cung cấp một vài gợi ý để các bạn có thể tự tìm hiểu cùng AI.
Một trong những kiến thức nền tảng đầu tiên mà bạn nên trang bị chính là cơ sở dữ liệu. Dữ liệu như dòng máu của một phần mềm, phần lớn các chức năng được xây dựng ra đều xoay quanh việc lưu trữ và xử lý dữ liệu. Nếu không nắm được những kiến thức cơ bản về cơ sở dữ liệu, sản phẩm mà bạn tạo ra có thể tăng độ phức tạp lên gấp nhiều lần, do không tận dụng lại những dữ liệu đã có hoặc thiết kế không hợp lý, khiến việc chỉnh sửa qua lại trở nên vô cùng khó khăn. Đối với những bối cảnh mà bạn là người trực tiếp đề xuất giải pháp, bạn sẽ có nguy cơ dính red flag từ đội developer khá cao khi không cân nhắc đến sự thay đổi trên cơ sở dữ liệu.
Tất nhiên là bạn có thể dùng AI thiết kế một database cho một giải pháp mà bạn mới nghĩ ra. Từ trải nghiệm chấm bài cho những học viên dùng AI thiết kế cơ sở dữ liệu mình quan sát được những lỗi điển hình như sau:
Thiết kế bảng nhìn có vẻ đúng, nhưng lệch hoàn toàn với ngữ cảnh của giải pháp
Đúng với ngữ cảnh của giải pháp nhưng không chỉ ra việc giải pháp chưa cân bằng giữa cơ sở dữ liệu hiện tại và vấn đề muốn giải quyết
Tạo ra những trường/bảng thông dụng nhưng không cần thiết, làm cồng kềnh thêm giải pháp
Vậy nắm được kiến thức này thì bạn có lợi thế gì? Mỗi lần thiết kế giải pháp, bạn sẽ có một bộ lọc cực nhạy để loại sớm những phương án chưa hiệu quả. Khi thấy một giải pháp ảnh hưởng lên tận 3 - 4 bảng dữ liệu, bạn biết chắc rằng việc triển khai về sau sẽ rất phức tạp, và có thể chuyển sang cân nhắc ý tưởng khác ngay. Thay vì mất thêm nửa tiếng để kiểm tra xem nó có thực sự phức tạp hay không.
Ngược lại với những hệ quả được nhắc tới bên trên, nắm được kiến thức về cơ sở dữ liệu sẽ giúp bạn thiết kế giải pháp tận dụng được những dữ liệu đang có, thay vì phát minh lại cái bánh xe (thành ngữ trong tiếng Anh chứ không phải do AI nhen 😂). Vì một giải pháp cỡ vừa cũng không có quá nhiều cách thiết kế cơ sở dữ liệu nên bạn không nhất thiết phải xin team dev cơ sở dữ liệu hiện tại của sản phẩm mới có thể thiết kế giải pháp.
Ngoài ứng dụng vào thiết kế giải pháp, việc làm data analytics ở giai đoạn sau cũng đòi hỏi kỹ năng này. Dù AI có thể viết giúp bạn những câu query, bạn vẫn cần biết những giới hạn của việc query đến đâu. Một vài tư duy cơ bản là:
Liệu có đủ dữ liệu để trả lời câu hỏi này không?
Phải nối khoảng bao nhiêu bảng mới có thể trả ra được kết quả?
Nếu bạn vẫn còn phải hỏi cả AI những câu hỏi này thì thực sự bạn nên dành thời gian học nghiêm túc. Vì AI không phải lúc nào cũng đủ sáng suốt để phản biện lại mà thường coi bối cảnh trong prompt bạn cung cấp là một đề bài chuẩn xác, sau đó cố viết những câu query trên một câu hỏi sai.
Sau đây là một số cụm từ cho các bạn tự học: Relational Database (Cơ sở dữ liệu quan hệ), các dạng chuẩn hóa dữ liệu cơ bản.
3. ReactJS - Thư viện xây dựng giao diện
Như mình đã nhắc tới trong phần trước, tạo ra được một prototype cho phép tương tác cơ bản hoàn toàn là có thể với khả năng của AI hiện nay. Nhưng với một bối cảnh xây dựng giao diện của một sản phẩm thật, bạn còn cần quan tâm đến việc nhận dữ liệu từ Back-end, tập trung những hành vi/thành phần giao diện được tái sử dụng, xây dựng chức năng mới mà không bị ràng buộc quá chặt với những chức năng khác. Trang bị những kiến thức này không chỉ giải quyết được những vấn đề trên mà còn giúp bạn chủ động hơn rất nhiều trong việc đánh giá những giải pháp, thu thấp được đa dạng các cách tiếp cận cho một vấn đề người dùng. Và cũng là một cách học thụ động, thu gom những cách tiếp cận hay trong thiết kế giao diện. Ví dụ như trong lúc tìm hiểu thư viện Material UI, mình đã phát hiện ra những animation khá gọn gàng để áp dụng vào một tình huống cất gọn một trường thông tin trong trường hợp không dùng đến.
Dù việc tạo ra một giao diện đòi hỏi bạn phải biết tới nhiều khái niệm như HTML, CSS, JS, nhưng từ góc nhìn thực dụng, các bạn có thể bắt đầu ngay với ReactJS. Những kiến thức còn lại khi được học trong một bối cảnh ứng dụng thực tế sẽ dễ tiếp cận hơn nhiều so với việc đi học từ dưới lên. Hơn nữa, khi đã làm quen với JS rồi thì việc học thêm NodeJS (một framework phổ biến ở Back-end) cũng không quá khó khăn. Kết hợp với kiến thức về cơ sở dữ liệu, khả năng kiểm soát toàn bộ product của bạn sẽ dễ dàng hơn rất nhiều.
Đây là một cách mà mình đánh giá là khá dễ để bắt đầu. Hãy nghĩ ra một ý tưởng về ứng dụng phục vụ mục đích cá nhân đơn giản, ví dụ như ứng dụng tập cầu lông, đồng hồ đếm rep cho người tập gym,… Sau đó yêu cầu ChatGPT tạo ngay cho bạn một ứng dụng để dùng thử. Từ ví dụ trực quan đó, bạn có thể bắt đầu tìm hiểu từng thành phần trong đó là gì bằng cách hỏi ChatGPT ngay trong cuộc trò chuyện. Việc chỉnh sửa và vá lỗi có thể hơi chậm, nhưng vậy là đủ cho một khởi đầu dễ dàng. Bạn có thể tham khảo ý tưởng về ứng dụng luyện tập phản xạ cầu lông của mình ở đây:
```
Context: Build a visual reaction training tool for badminton.
Instruction: Generate a React app with:
UI:
- A dynamic grid of square cells (user-configurable rows and columns)
- Default cells are black; at any time, exactly one random cell turns green, then returns to black
Controls:
- Number inputs to set rows and columns
- Number input to set duration (ms) for how long a cell stays green
- Two preset buttons:
- "Fast drive" (300ms)
- "Movement" (800ms)
Behavior:
- Only one cell is active (green) at a time
- Cycle: green → black → wait → next random green (all based on the same duration)
- Updates to duration or grid size must take effect immediately without breaking the loop
Technical:
- React functional components + hooks
- TailwindCSS
- Clean, minimal implementation
```4. Kết luận
Và như tiêu đề ở phần đầu, mình vẫn kiên định với quan điểm rằng AI chưa thể thay thế kiến thức nền tảng, trừ khi đến một ngày nó thực sự tự động và đáng tin hơn một senior software engineer dù chất lượng của mô hình và agent đã cải thiện rất xa so với khi bắt đầu rồi. Còn ở thời điểm hiện tại, nếu cùng sử dụng một công cụ, bạn nghĩ người có nền tảng hay người học vẹt sẽ tạo ra hiệu suất lớn hơn?
Thêm nữa, việc thiếu kiến thức nền tảng sẽ giới hạn khả năng tư duy giải pháp của bạn rất nhiều. Bạn cần phải biết về mặt kỹ thuật có thể thực hiện được chức năng nào thì AI mới có thể giúp bạn phần việc chân tay. Mình tin ai cũng đã từng có trải nghiệm đưa cho AI một yêu cầu cực kỳ "miên" rồi kết quả nhận lại thì thậm chí không đánh giá nổi là đúng hay sai. Lý do là AI không phải lúc nào cũng đủ sáng suốt để phản biện, mà thường mở đầu câu trả lời bằng "You're absolutely right" ("Bạn là bố đẻ của sự thật"). Chúng sẽ coi lời của bạn là tối thượng, và một câu trả lời dựa trên một câu hỏi sai thì chắc chắn cũng sai.
Dù niềm tin của mình vào việc xây dựng sản phẩm một cách sâu sắc có phần suy giảm trước những bất định mà AI mang đến cho ngành phần mềm, mình vẫn tin vào việc nắm chắc kiến thức cốt lõi và phát triển những kiến thức liên quan, thay vì chỉ biết rộng mà toàn ở tầng bề mặt. Nếu bạn có ý kiến khác, hãy cho mình biết ở phần bình luận bên dưới nhé.