Thật sự đồng cảm ở nhiều khía cạnh luôn lol. Vì bực quá nên cứ buông xuôi, chuyển sang chế độ chỉ làm đúng bằng số tiền mình nhận thì ngược lại còn thích vì công việc trôi chảy mượt hơn. Thực ra là dù nhìn ra hướng phát triển có rủi ro thì cũng thành trạng thái không còn bận tâm nữa thôi.
Quan điểm: AI xử lý nhanh các công việc nhàm chán nên ngược lại còn tiếp thêm năng lượng, đồng thời giảm chi phí học các tech stack mới nên nhìn chung là tích cực.
Ví dụ: Khi dùng ngôn ngữ hoặc framework lạ, nhờ AI agent mà có thể bỏ qua giai đoạn học tập tẻ nhạt và tập trung ngay vào việc triển khai.
2. "Tranh cãi về định nghĩa của vibe coding" (sự hỗn loạn về thuật ngữ)
Tranh luận: Có nhiều ý kiến khác nhau về việc "vibe coding" chỉ đơn thuần là nhận trợ giúp từ AI, hay là chỉ kiểm tra kết quả mà không review đoạn code được tạo ra.
Điểm đồng thuận: Ban đầu đây là một thuật ngữ mang sắc thái tiêu cực, ám chỉ "không review code", nhưng hiện nay ý nghĩa đã được mở rộng thành thuật ngữ chỉ việc coding có AI hỗ trợ nói chung.
3. "Tốc độ không kiểm chứng là nợ kỹ thuật" (phe thận trọng)
Phê phán: Tin vào sản phẩm do AI tạo ra mà không hiểu code là rất nguy hiểm. Bug phát sinh về sau hoặc chi phí bảo trì (nợ kỹ thuật) sẽ còn lớn hơn.
Ẩn dụ: "Giống như ngồi trên xe tự lái mà tài xế không biết nó đang đi đâu", việc triển khai mà không hiểu bản chất rốt cuộc sẽ làm suy giảm năng lực giải quyết vấn đề.
4. "Mệt mỏi vì chuyển đổi ngữ cảnh" (phe đồng cảm)
Đồng ý: Trong lúc AI tạo code, việc chuyển đổi ngữ cảnh (Context Switching) diễn ra thường xuyên khiến tải nhận thức của não bộ tăng vọt.
Triệu chứng: Quá trình lặp đi lặp lại giữa review và chỉnh sửa kết quả của AI gây hao mòn tinh thần hơn cả khi tự code. Làm 4 tiếng mà thấy mệt như đã làm cả ngày.
5. "Đánh mất niềm vui của việc code" (thiếu dopamine)
Trải nghiệm: Cảm giác thành tựu (dopamine) khi tự mình giải quyết vấn đề đã biến mất. Giống như chỉ nhìn sản phẩm hoàn thiện thay vì tận hưởng niềm vui tự tay lắp Lego, nên cảm thấy hụt hẫng.
Kết quả: Công việc chỉ nhanh chóng cho ra sản phẩm mà không có niềm vui trong quá trình thực hiện sẽ khiến developer kiệt sức.
6. "Thuốc độc với người mới, thuốc bổ với người thành thạo" (khác biệt theo trình độ)
Phân tích: Developer giàu kinh nghiệm có thể nhanh chóng phát hiện và sửa lỗi của AI nên năng suất cao hơn, nhưng người mới dễ dùng nguyên xi code sai, đánh mất cơ hội học hỏi và có nguy cơ tạo ra hàng loạt code kém chất lượng.
7. "Bị ép chuyển sang vai trò quản lý" (thay đổi vai trò)
Hiện tượng: Developer bị buộc phải chuyển từ vai trò "người sáng tạo" trực tiếp viết code sang "người quản lý/reviewer" chuyên xem xét và sửa code do AI liên tục tạo ra.
Gánh nặng: Điều này gây ra áp lực cực lớn, chẳng khác nào một mình phải review code do 5 junior developer (AI) viết trong thời gian thực.
8. "Thiếu sự thấu hiểu business logic" (chỉ ra giới hạn)
Vấn đề: AI có thể viết code tốt, nhưng không hiểu bối cảnh kinh doanh hay kiến trúc tổng thể.
Thực tế: Cuối cùng, những công việc phức tạp như điều chỉnh yêu cầu kinh doanh cho phù hợp với code và xử lý edge case vẫn là phần việc của con người, và nút thắt cổ chai cũng phát sinh ở chính quá trình này.
9. "Sự biến mất của nghỉ ngơi và khoảng thở" (thời gian máy móc)
Ẩn dụ: Giống như công nhân nhà máy trước đây phải làm việc theo tốc độ của máy móc, con người nay bị AI kéo lê theo tốc độ tạo sinh quá nhanh và mắc kẹt trong "thời gian máy móc".
Sự cần thiết: Những "khoảng nghỉ bắt buộc" như thời gian chờ compile đã biến mất, khiến não bộ không còn thời gian để xử lý thông tin và nghỉ ngơi. Việc chủ động nghỉ ngơi là điều bắt buộc.
10. "Vấn đề chuyển tiếp của công cụ" (triển vọng tương lai)
Chẩn đoán: Cảm giác mệt mỏi hiện tại xuất phát từ sự lệch nhịp khi các công cụ kiểm chứng (test, lint, v.v.) không theo kịp tốc độ tạo sinh của AI.
Giải pháp: Nếu các công cụ có thể phát triển đến mức tự động hóa việc kiểm chứng với tốc độ tương đương tốc độ tạo sinh, vấn đề mệt mỏi này có thể được giải quyết.
1. Mức độ thích/không thích về hình thức ("vibe LinkedIn à?")
Phê bình chiếm ưu thế: Nhiều ý kiến chê định dạng xuống dòng sau mỗi câu trông như "bài viết màu mè của influencer LinkedIn" hoặc "văn bản do AI tạo ra". Họ chỉ ra rằng phần trình bày thì ồn ào nhưng nội dung lại thiếu chiều sâu.
Một số ý kiến bênh vực: Có người cho rằng đây là cách sắp xếp dễ đọc, có tính đến khả năng tập trung ngắn của người hiện đại, hoặc là văn phong có chủ ý tạo nhịp điệu như thơ.
2. Chia sẻ trải nghiệm thực hành 'ham muốn dày'
Trường hợp thành công: Nhiều người chia sẻ việc vượt qua cảm giác trầm uất và làm đầy mật độ cuộc sống thông qua các sở thích mang tính vật lý, tốn thời gian như điêu khắc (sculpting), thiết kế mạch analog, viết bưu thiếp.
Tranh luận về làm bánh mì: Từ ví dụ "làm bánh mì kém hiệu quả" trong bài gốc, các kỹ sư lại chia sẻ mẹo "tối ưu hóa thời gian ủ" bằng lò nướng, tạo ra một cuộc thảo luận phụ đầy nghịch lý.
3. Phân tích nguồn gốc triết học và tôn giáo
Đổi thương hiệu cho trí tuệ cũ: Có ý kiến cho rằng đây chỉ là việc đóng gói lại bằng thuật ngữ hiện đại (Thin/Thick) những khái niệm đã có từ lâu như "Ngạ quỷ (Hungry Ghosts)" trong Phật giáo hay các chủ đề cổ điển của triết học phương Tây (Augustine, v.v.).
Giá trị của nhận định: Dù không phải nội dung mới, nhiều người vẫn đồng ý rằng đây là một tập hợp nhận định được hệ thống hóa tốt cho bối cảnh xã hội hiện đại.
4. Giới hạn của lối lập luận nhị nguyên
Cảnh giác với sự đơn giản hóa khái niệm: Công thức "tiêu thụ = hời hợt, sáng tạo = dày" là nguy hiểm. Đọc sâu (một hình thức tiêu thụ) cũng có thể rất dày, còn sáng tạo mang tính thương mại cũng có thể hời hợt.
Giá trị của nghỉ ngơi: Có người chỉ ra rằng bài viết đã bỏ qua khả năng những hoạt động "trông có vẻ hời hợt" như ngồi thẫn thờ hay chơi game cũng có thể là sự nghỉ ngơi cần thiết cho phục hồi.
5. Chỉ ra nguyên nhân mang tính cấu trúc và môi trường
Không phải lỗi của cá nhân: Vấn đề gốc rễ là hệ thống phần thưởng dopamine do các công ty IT cố ý thiết kế.
Ràng buộc thực tế: Có ý kiến phản bác tiền đề "chúng ta đã đủ sung túc". Chi phí nhà ở, y tế và các mối đe dọa sinh tồn khác (nghèo khó kinh tế) khiến việc theo đuổi "ham muốn dày" một cách thong thả trở nên khó khăn.
Chẳng phải đây là kiểu mù công nghệ ở mức “màu trắng là code, màu đen là terminal” hay sao? Cũng giống như trạng thái hoàn toàn không thể làm dev nếu không biết xem log hoặc không có copy-paste vậy.
Khi đọc những thứ như thế này, tôi chỉ nhìn vào tầm quan trọng của system prompt của công cụ. Hiện tại khi dùng trong Cursor, cá nhân tôi nghĩ opus >= gpt 5.2 > gemini 3. Còn Sonnet hay 5.1 các kiểu... thì cá nhân tôi không dùng nữa. Tuy vậy... gpt5.2 khác biệt theo từng mức effort khá nhiều.. Nhưng không phải lúc nào effort cao cũng tốt hơn.. Vì thế tôi dùng opus và gemini làm chủ lực. Thỉnh thoảng khi gặp bài toán khó, tôi cho cả 3 con cùng code, để chúng đánh giá code của nhau, rồi tôi kiểm tra và áp dụng.
Thấy hơi khó để đăng thành một chủ đề nên mình viết ở đây dưới phần bình luận.
Trước hết thì mình cực kỳ thích.
Việc có đóng dấu thời gian cũng rất ổn,
và với người từng xóa ghi chú rồi hối hận rất nhiều như mình, điều mình thích nhất là trong chương trình không thể xóa ghi chú.
Nhưng mình nghĩ sẽ tốt hơn nếu phần việc cần làm và thẻ có thêm ví dụ cách viết trong phần hướng dẫn.
Cá nhân mình thì khá tiếc vì do môi trường làm việc dùng mạng nội bộ tách biệt nên không thể sử dụng được.
Có lẽ chúng ta cần sự tỉnh táo để tự hiểu câu nói “X là tương lai” theo nghĩa “mong rằng X sẽ là tương lai”.
Thật sự đồng cảm ở nhiều khía cạnh luôn lol. Vì bực quá nên cứ buông xuôi, chuyển sang chế độ chỉ làm đúng bằng số tiền mình nhận thì ngược lại còn thích vì công việc trôi chảy mượt hơn. Thực ra là dù nhìn ra hướng phát triển có rủi ro thì cũng thành trạng thái không còn bận tâm nữa thôi.
JavaScript의 간략한 역사
Nếu đọc cùng với bài này thì sẽ rất hay.
Hiện tại đã được hỗ trợ.
https://code.visualstudio.com/updates/v1_107/…
1. "Tốc độ là nguồn sinh lực" (phe tích cực)
2. "Tranh cãi về định nghĩa của vibe coding" (sự hỗn loạn về thuật ngữ)
3. "Tốc độ không kiểm chứng là nợ kỹ thuật" (phe thận trọng)
4. "Mệt mỏi vì chuyển đổi ngữ cảnh" (phe đồng cảm)
5. "Đánh mất niềm vui của việc code" (thiếu dopamine)
6. "Thuốc độc với người mới, thuốc bổ với người thành thạo" (khác biệt theo trình độ)
7. "Bị ép chuyển sang vai trò quản lý" (thay đổi vai trò)
8. "Thiếu sự thấu hiểu business logic" (chỉ ra giới hạn)
9. "Sự biến mất của nghỉ ngơi và khoảng thở" (thời gian máy móc)
10. "Vấn đề chuyển tiếp của công cụ" (triển vọng tương lai)
1. Mức độ thích/không thích về hình thức ("vibe LinkedIn à?")
2. Chia sẻ trải nghiệm thực hành 'ham muốn dày'
3. Phân tích nguồn gốc triết học và tôn giáo
4. Giới hạn của lối lập luận nhị nguyên
5. Chỉ ra nguyên nhân mang tính cấu trúc và môi trường
Chẳng phải đây là kiểu mù công nghệ ở mức “màu trắng là code, màu đen là terminal” hay sao? Cũng giống như trạng thái hoàn toàn không thể làm dev nếu không biết xem log hoặc không có copy-paste vậy.
Bài này là Phần 1 phân tích vì sao các kỹ sư cấp cao rời đi, và còn có cả bài Phần 2 là The Economic Intervention That Stops Engineer Attrition nữa.
https://codegood.co/writing/…
Hôm qua tôi cũng thấy một bài đăng trên Facebook nói rằng việc giải phóng toàn bộ dung lượng trên Mac (bảo Claude tự xóa) rất tiện mà...
Không thể để các lãnh đạo nhìn thấy bài này sao..
Tuyệt vời.
Khi đọc những thứ như thế này, tôi chỉ nhìn vào tầm quan trọng của system prompt của công cụ. Hiện tại khi dùng trong Cursor, cá nhân tôi nghĩ
opus >= gpt 5.2 > gemini 3. Còn Sonnet hay 5.1 các kiểu... thì cá nhân tôi không dùng nữa. Tuy vậy...gpt5.2khác biệt theo từng mức effort khá nhiều.. Nhưng không phải lúc nào effort cao cũng tốt hơn.. Vì thế tôi dùngopusvàgeminilàm chủ lực. Thỉnh thoảng khi gặp bài toán khó, tôi cho cả 3 con cùng code, để chúng đánh giá code của nhau, rồi tôi kiểm tra và áp dụng.Không có gì sai cả.
Ừ nhưng ngược lại thì mình cũng từng thấy có junior viết ra đống code kỳ quặc rồi lấy GPT ra làm lá chắn, đổ là do GPT làm, nên chắc cũng tùy người.
Agent sử dụng công cụ thực sự rất nguy hiểm. Cứ chỉ nghe nó nói thôi.
Đúng vậy. Tôi không biết vì không hay dùng ứng dụng Notepad tích hợp sẵn của Windows 11. Cảm ơn bạn.
Chỉ cần nhấn F5 trong Notepad thôi.
Thấy hơi khó để đăng thành một chủ đề nên mình viết ở đây dưới phần bình luận.
Trước hết thì mình cực kỳ thích.
Việc có đóng dấu thời gian cũng rất ổn,
và với người từng xóa ghi chú rồi hối hận rất nhiều như mình, điều mình thích nhất là trong chương trình không thể xóa ghi chú.
Nhưng mình nghĩ sẽ tốt hơn nếu phần việc cần làm và thẻ có thêm ví dụ cách viết trong phần hướng dẫn.
Cá nhân mình thì khá tiếc vì do môi trường làm việc dùng mạng nội bộ tách biệt nên không thể sử dụng được.
Anh Beok, em muốn tôn anh làm đại ca.