Rốt cuộc đây là câu chuyện về việc con người muốn thuốc giảm đau (dopamine) hay vitamin (ham muốn dày). Nhưng có vẻ xu hướng gần đây là vế trước. Nhìn về mặt lịch sử cũng có cảm giác vế trước chiếm ưu thế, rồi như một phản động nào đó thì vế sau thỉnh thoảng mới lác đác xuất hiện.
Đây không phải là câu chuyện về công nghệ mà là một chủ đề mang tính triết học, nên ngược lại càng thấy hay.
Đặc biệt, câu "tương lai" không phải là thứ bị áp đặt, mà là kết quả của lựa chọn tập thể. <-- nội dung này thực sự thực sự rất tuyệt. Xin cảm ơn.
Nếu lặng lại, bình tĩnh dừng chân và nhìn quanh, thì thứ tạo ra trào lưu của thời đại một cách nhân tạo lúc nào cũng là con người (doanh nghiệp).
Trong đầu chỉ cần có logic và kiểm tra xem mã do AI viết có đúng hay không, chẳng phải không cần phải tự viết mã trong đầu nữa sao? Chỉ cần tập trung nghĩ xem phải đưa dữ liệu chính xác đến mức nào vào prompt là được, nên ngược lại tốc độ xử lý công việc đã nhanh hơn rất nhiều.
Chẳng phải khi quá trình tạo ra mã trở thành một chiếc hộp đen thì sẽ cần thời gian để đồng bộ giữa mã và những gì đang có trong đầu sao?
Việc viết mã theo cách truyền thống đảm bảo rằng mã và ý nghĩ trong đầu là giống nhau, nhưng với coding thông qua LLM thì điều đó không được đảm bảo.
Ngay cả giữa con người với nhau, vấn đề này cũng thường xảy ra.
Nếu người suy nghĩ chậm là quản lý,
thì sẽ nói: “Công việc diễn ra quá nhanh nên rất mệt, khó làm việc cùng.”
Còn nếu người đó là cấp dưới,
thì sẽ nói: “Vì không hiểu ý người khác cho lắm nên rất khó làm việc cùng.”
Cuối cùng, để có thể làm việc cùng nhau, hai bên phải hợp cạ với nhau.
Ngoại trừ các dự án cá nhân, tôi chỉ dùng vibe coding ở mức hạn chế. Với tính năng tự động hoàn thành của Cursor, tôi chỉ dùng cho ideation hoặc những đoạn code lặp lại cùng một mẫu. Trong các dự án dài hạn, cố giải quyết mọi thứ bằng vibe coding thì tôi cho rằng đó là hành động thiếu trách nhiệm với tư cách là một lập trình viên.
Có vẻ như những người hiểu mã của kết quả đã được tạo ra và làm công việc xác minh/kiểm tra sẽ cảm thấy mệt mỏi hơn so với những người chỉ viết prompt rồi chỉ lấy kết quả.
Điều này cũng có trong bài gốc.
Vấn đề có lẽ không nằm ở cú pháp SQL của câu truy vấn, mà là trong một hệ thống đã vận hành gần 20 năm có hàng nghìn bảng chẳng rõ ai tạo từ lúc nào, nên ngoài người phụ trách ra thì không ai biết dữ liệu nào nằm ở bảng nào. PTSD tràn về...
Có lẽ vì tôi quen viết SQL hơn là viết prompt, nên so với việc lấy SQL bằng prompt thì việc viết thẳng SQL cho dữ liệu mình muốn ngay trong đầu có vẻ nhanh hơn nhiều.
Nếu nhắm đến những người không thể tự viết SQL thì có thể sẽ có nhu cầu, nhưng vì vấn đề ảo giác nên nếu dữ liệu trả ra bị sai thì cũng khiến tôi băn khoăn là phải kiểm chứng điều đó như thế nào.
Tôi chỉ nghĩ là “May quá, nhờ AI mà việc tôi phải làm đã giảm đi”, nên chưa từng trải qua kiểu mệt mỏi này lần nào. Tôi dùng zed + claude, đôi khi giữa chừng ngữ cảnh bị đổi nên nó hoạt động kỳ lạ, nhưng những lúc đó chỉ cần hoàn tác code trong git rồi bảo nó “hãy tổng hợp nội dung ở trên và viết lại”, thì nó lại làm ra phiên bản gọn gàng hơn. Chẳng phải chỉ là quá trình biến những ý nghĩ trong đầu thành code đã thay đổi, chứ không còn là tự tay gõ từng dòng để viết code nữa thôi sao? Thậm chí trong lúc nhập prompt, suy nghĩ còn được sắp xếp lại rõ ràng hơn nữa.
Trước đây, dù viết code cả ngày thì khi kết thúc công việc vẫn thường có cảm giác rất mãn nguyện, nhưng giờ đây phần lớn công việc trong ngày lại được xử lý bằng hội thoại, đến mức nhiều ngày tôi không trực tiếp viết nổi một dòng code nào mà vẫn bị burnout.. Tôi hoàn toàn đồng cảm
Rốt cuộc đây là câu chuyện về việc con người muốn thuốc giảm đau (dopamine) hay vitamin (ham muốn dày). Nhưng có vẻ xu hướng gần đây là vế trước. Nhìn về mặt lịch sử cũng có cảm giác vế trước chiếm ưu thế, rồi như một phản động nào đó thì vế sau thỉnh thoảng mới lác đác xuất hiện.
Đây không phải là câu chuyện về công nghệ mà là một chủ đề mang tính triết học, nên ngược lại càng thấy hay.
Đặc biệt, câu
"tương lai" không phải là thứ bị áp đặt, mà là kết quả của lựa chọn tập thể.<-- nội dung này thực sự thực sự rất tuyệt. Xin cảm ơn.Nếu lặng lại, bình tĩnh dừng chân và nhìn quanh, thì thứ tạo ra trào lưu của thời đại một cách nhân tạo lúc nào cũng là con người (doanh nghiệp).
Giữa opus trong Antigravity và opus trong Claude Code, cái nào tốt hơn?
Tôi nghe nói cả mô hình mặc định dành cho người dùng phổ thông trên web cũng sẽ thay đổi.
Có lẽ điều này cũng có thể khác nhau tùy vào mức độ prompt cụ thể đến đâu. Nếu giao cho LLM ở mức pseudocode thì tôi hiểu ý bạn nói.
Thực ra, không có nhiều công ty đặt mục tiêu kinh doanh là theo đuổi kỹ thuật tốt...
Trong đầu chỉ cần có logic và kiểm tra xem mã do AI viết có đúng hay không, chẳng phải không cần phải tự viết mã trong đầu nữa sao? Chỉ cần tập trung nghĩ xem phải đưa dữ liệu chính xác đến mức nào vào prompt là được, nên ngược lại tốc độ xử lý công việc đã nhanh hơn rất nhiều.
Chẳng phải khi quá trình tạo ra mã trở thành một chiếc hộp đen thì sẽ cần thời gian để đồng bộ giữa mã và những gì đang có trong đầu sao?
Việc viết mã theo cách truyền thống đảm bảo rằng mã và ý nghĩ trong đầu là giống nhau, nhưng với coding thông qua LLM thì điều đó không được đảm bảo.
Ngay cả với mấy việc đơn giản, tôi vẫn thấy thoải mái hơn nếu cứ tạo hẳn một cái macro...
Giữa con người với nhau cũng vậy.
Ngay cả giữa con người với nhau, vấn đề này cũng thường xảy ra.
Nếu người suy nghĩ chậm là quản lý,
thì sẽ nói: “Công việc diễn ra quá nhanh nên rất mệt, khó làm việc cùng.”
Còn nếu người đó là cấp dưới,
thì sẽ nói: “Vì không hiểu ý người khác cho lắm nên rất khó làm việc cùng.”
Cuối cùng, để có thể làm việc cùng nhau, hai bên phải hợp cạ với nhau.
Một bài viết thực sự quý giá vì có đưa ra giải pháp. Cảm ơn bạn.
Đã sửa. Cảm ơn bạn đã thông báo.
Nỗi khổ khi bị tước mất việc viết mã, chỉ còn phải làm code review và kiểm thử...
Ngoại trừ các dự án cá nhân, tôi chỉ dùng vibe coding ở mức hạn chế. Với tính năng tự động hoàn thành của Cursor, tôi chỉ dùng cho ideation hoặc những đoạn code lặp lại cùng một mẫu. Trong các dự án dài hạn, cố giải quyết mọi thứ bằng vibe coding thì tôi cho rằng đó là hành động thiếu trách nhiệm với tư cách là một lập trình viên.
Có vẻ như những người hiểu mã của kết quả đã được tạo ra và làm công việc xác minh/kiểm tra sẽ cảm thấy mệt mỏi hơn so với những người chỉ viết prompt rồi chỉ lấy kết quả. Điều này cũng có trong bài gốc.
Vấn đề có lẽ không nằm ở cú pháp SQL của câu truy vấn, mà là trong một hệ thống đã vận hành gần 20 năm có hàng nghìn bảng chẳng rõ ai tạo từ lúc nào, nên ngoài người phụ trách ra thì không ai biết dữ liệu nào nằm ở bảng nào. PTSD tràn về...
Có lẽ vì tôi quen viết SQL hơn là viết prompt, nên so với việc lấy SQL bằng prompt thì việc viết thẳng SQL cho dữ liệu mình muốn ngay trong đầu có vẻ nhanh hơn nhiều.
Nếu nhắm đến những người không thể tự viết SQL thì có thể sẽ có nhu cầu, nhưng vì vấn đề ảo giác nên nếu dữ liệu trả ra bị sai thì cũng khiến tôi băn khoăn là phải kiểm chứng điều đó như thế nào.
Gemini 3 Flash: trí tuệ tiên phong được thiết kế cho tốc độ
Hãy tham khảo cả phần tóm tắt của GN+ và các bình luận trên Hacker News~
Tôi chỉ nghĩ là “May quá, nhờ AI mà việc tôi phải làm đã giảm đi”, nên chưa từng trải qua kiểu mệt mỏi này lần nào. Tôi dùng zed + claude, đôi khi giữa chừng ngữ cảnh bị đổi nên nó hoạt động kỳ lạ, nhưng những lúc đó chỉ cần hoàn tác code trong git rồi bảo nó “hãy tổng hợp nội dung ở trên và viết lại”, thì nó lại làm ra phiên bản gọn gàng hơn. Chẳng phải chỉ là quá trình biến những ý nghĩ trong đầu thành code đã thay đổi, chứ không còn là tự tay gõ từng dòng để viết code nữa thôi sao? Thậm chí trong lúc nhập prompt, suy nghĩ còn được sắp xếp lại rõ ràng hơn nữa.
Trước đây, dù viết code cả ngày thì khi kết thúc công việc vẫn thường có cảm giác rất mãn nguyện, nhưng giờ đây phần lớn công việc trong ngày lại được xử lý bằng hội thoại, đến mức nhiều ngày tôi không trực tiếp viết nổi một dòng code nào mà vẫn bị burnout.. Tôi hoàn toàn đồng cảm