Quan điểm
Vấn đề không nằm ở code của AI, mà là sự thiếu hụt tư duy kiến trúc và thấu hiểu mục tiêu
(giờ Việt Nam)
Tóm tắt AI
Các kỹ sư cảnh báo về nguy cơ khi đội ngũ quá phụ thuộc vào Claude Code, dẫn đến việc không ai còn thực sự hiểu kiến trúc hệ thống hay ý đồ thiết kế ban đầu, biến công việc lập trình thành những cuộc đối thoại máy móc với AI.
Chính văn · Bản dịch AI

Cập nhật lần cuối: 28/09/2026 · Tạo ngày: 26/09/2026 · 4 phút đọc · cập nhật gần đây · 882 từ
Nếu chúng ta nghĩ Viết code đã chết, và AI đang tạo ra toàn bộ các codebase, tôi vẫn cho rằng vấn đề lớn hơn nằm ở chỗ con người hoặc cả đội ngũ không còn biết bất cứ điều gì về kiến trúc hệ thống hay mục đích đằng sau lý do tại sao các lựa chọn nhất định được đưa ra.
Một bình luận trong cuộc thảo luận mà tôi đã tham gia:
Tôi nghĩ AI có lẽ viết code ở mức trung bình (tùy thuộc vào tác vụ và quy mô). Vì vậy, nếu codebase của bạn dưới mức trung bình, AI có thể dễ dàng cải thiện nó lên mức trung bình. Ít nhất đó là những gì tôi quan sát được ở đây.
Đối với tôi, vấn đề không phải là code do AI viết, mà là việc không ai biết gì cả, và mọi người chỉ hỏi Claude. Kết quả là bạn chẳng có bất kỳ kế hoạch nào cả.
# Tình trạng hiện tại ở các Startup phát triển nhanh
Tweet này tóm tắt khá tốt tình trạng hiện tại ở các startup phát triển nhanh, hoặc các công ty lớn hơn, hay những nơi mà quản lý cấp trung đang thúc đẩy AI mạnh mẽ:
Tôi chịu đựng đủ rồi. Thế là xong. Tình trạng kỹ thuật hiện tại thật kinh khủng. Đã nửa tháng kể từ khi tôi bắt đầu vai trò mới tại một công ty lớn. Ở đây chẳng ai biết gì cả. Các thông số kỹ thuật, code, kiểm thử, PRD, ticket, cách giải quyết ticket, báo cáo, v.v., mọi thứ đều do Claude Code tạo ra. Không ai trong nhóm tôi thích điều này. Họ bị ép phải xuất xưởng càng nhiều càng tốt. Tôi đã nghe nhiều lần từ cấp quản lý cao hơn rằng việc đẩy code không phải là nút thắt cổ chai, vậy tại sao chúng ta lại chậm? Mọi người đang làm việc 12 đến 13 tiếng một ngày chỉ để nhấn phím Enter. Không ai đọc bất cứ thứ gì. Con người trong môi trường doanh nghiệp không tự làm bất cứ điều gì. Mọi người, thực sự là tất cả mọi người, từ kỹ sư L1 đến L7 ở đây đều đang làm cùng một việc. Nói chuyện với Claude. Không có cảm giác chiến thắng. Không ai giải quyết lỗi. Thực tế là không ai còn suy nghĩ nữa. Mọi thứ đều được thực hiện bởi các LLM. Nó thật sự bào mòn tâm hồn. Thành thật mà nói, tôi sẽ không bận tâm nếu chúng tôi ít nhất được cho thời gian để kiểm tra code và xem cái gì đang đi đâu. Nhưng không, mục tiêu chỉ là xuất xưởng. Bất kể chuyện gì xảy ra. Voxium
# Kỹ thuật dữ liệu (Data Engineering) có khác biệt không?
Hoyt Emerson đề cập rằng kỹ thuật dữ liệu có sự khác biệt:
Tôi nghĩ dân làm dữ liệu thì khác. Chúng tôi đã phải biết mọi thứ về sản phẩm/kinh doanh ngay từ ngày đầu tiên. AI giờ đây chỉ giúp loại bỏ ma sát cho chúng tôi mà thôi. Tweet
Tôi nghĩ những người làm dữ liệu trưởng thành trước thời đại AI thực sự đã phải biết mọi thứ (hoặc rất nhiều, hoặc phải làm việc với các chuyên gia trong ngành) để tìm ra giải pháp. Nhưng AI khiến điều này trở nên lỗi thời, hoặc có vẻ như lỗi thời.
Đó là lý do tại sao những người bắt đầu từ hôm nay, hoặc ngay cả bản thân tôi, nếu tôi bắt đầu hôm nay bằng cách đặt câu lệnh (prompt) trong một lĩnh vực mới, thì đột nhiên, kiến thức đó bị thiếu hụt.
# Một Giám đốc sản phẩm (PM) giờ đây có thể xây dựng bất cứ thứ gì họ muốn
Quan điểm hay từ Sean Behan:
Tôi luôn ngưỡng mộ những người làm sản phẩm không biết code nhưng có thể quản lý một đội ngũ để có được phần mềm họ muốn. Biết mình muốn gì luôn là phần khó nhất.
Có thể nói một giám đốc sản phẩm giỏi giờ đây có thể xây dựng bất cứ thứ gì họ muốn, tìm kiếm thị trường, làm cho nó trông đẹp mắt, v.v. Nhưng rồi, nếu bạn không biết code, về cơ bản bạn sẽ xây dựng một nền tảng rất tệ cho một sản phẩm rất khó bảo trì (mặc dù AI cũng đang làm tốt hơn ở khoản đó, đặc biệt là khi bạn lặp lại thường xuyên, nhưng dù sao đi nữa, nếu bạn chọn sai ngôn ngữ hoặc sai mô hình tư duy, bạn đã có một khởi đầu sai lầm ngay từ đầu).
Dù sao thì việc biết các nguyên tắc cơ bản vẫn hữu ích: cho việc lập trình và thiết kế sản phẩm, và cho một PM giỏi, người biết những gì cần thiết nhưng cũng hiểu về thiết kế hệ thống và kiến trúc.
# Trùm cuối vẫn là bảo trì
Tư duy theo hệ thống, hoặc kiến trúc, hoặc có mục đích và thiết kế - tất cả đều giúp trở thành một kỹ sư phần mềm giỏi hơn. Ngày nay, Viết code bằng tay có thể đã chết, nhưng nó chắc chắn vẫn hữu ích, và Có gu thẩm mỹ (với AI) quan trọng hơn bao giờ hết.
Nhưng trùm cuối vẫn là, và sẽ luôn là, khả năng bảo trì. Càng dễ dàng tạo ra một pipeline, ứng dụng hoặc bảng điều khiển BI nhanh chóng, thì bạn càng phải bảo trì nhiều hơn. Và nếu không ai biết gì cả, điều đó có thể trở nên thực sự khó khăn.
# AI không thể tự vận hành
Đúng vậy, AI không thể tự đặt câu lệnh cho chính nó, phải không? Tại sao chúng ta thậm chí cần con người? Đối với tôi, đó là dấu hiệu rõ ràng cho thấy con người vẫn cần thiết để chỉ đạo và điều phối nó. Đó cũng là lý do tại sao mục đích, gu thẩm mỹ, thiết kế và kiến trúc đều là những tính năng "sát thủ" trong thế giới ngày nay.
Nhưng một khi những thứ này vắng bóng, hoặc tệ hơn là những nguyên tắc cơ bản bị mất đi, thì thực sự rất nguy hiểm. Tôi đọc được hôm nay rằng đây là vấn đề do chúng ta tự gây ra, và nếu chúng ta vẫn thuê nhân viên cấp dưới (juniors), thì vấn đề sẽ không xảy ra. Nhưng vâng, điều đó không hề dễ dàng.
# Đọc thêm
- Kris Jenkins nói về nỗi lo của quản lý cấp trung, không phải kiểu "vibe coding" tại Danger of AI hay các LLM
- Nếu được tiêu thụ bởi con người, thì nên được viết bởi con người
- Những gì tôi học được khi viết cùng AI
Nguồn gốc: video của primagen và Những hạn chế của LLM và AI Tài liệu tham khảo: Những gì tôi học được khi viết cùng AI
Bài viết được AI dịch và tổng hợp tự động từ Hacker News: AI bài nổi bật. Liên kết bài gốc ở phía trên. Dữ liệu đồng bộ qua API công khai được ghi nguồn tại AI HOT (canonical) ↗. AIHOT.vn luôn dẫn nguồn đầy đủ — nếu bạn thấy điểm cần chỉnh sửa, hãy gửi ý kiến tại trang phản hồi.