Việc hiểu sâu về product engineering mà startup cần cũng rất tốt, nhưng tôi nghĩ con đường theo đuổi công nghệ đến cực hạn và không ngừng mài giũa nó vẫn còn rất có ý nghĩa. Việc phát triển để tạo ra các ứng dụng web đơn giản sẽ bị AI thay thế, nhưng tôi cho rằng vẫn phải có ai đó nghĩ ra Kubernetes và thiết kế ElasticSearch.
Đã được đưa vào JDK 23.
Khi thử nghiệm, tôi thấy ngay cả khi phiên bản JDK của dự án thấp hơn 23, nếu IDE hoặc công cụ EXPORT JavaDoc hỗ trợ thì vẫn hoạt động bình thường.
Linux Landlock là một mô-đun bảo mật gốc của kernel cho phép các tiến trình không đặc quyền tự sandbox chính mình - nhưng không ai dùng nó vì API thì... khó!
Điều tôi cảm nhận khi code cùng AI là, nếu chia nhỏ thành các đơn vị theo kiểu nguyên tắc trách nhiệm đơn nhất + TDD để AI có thể hiểu được ngữ cảnh ngay cả khi chỉ được đưa một phần mã, thì cần thiết kế sao cho không phải đọc bối cảnh lớn mà chỉ với ngữ cảnh cục bộ cũng đủ để nắm bắt được.
Tôi cũng đồng ý vì thứ tôi dùng AI nhiều nhất cho sở thích là làm web game. Khi quy mô vượt qua một mức nhất định, đến một lúc nào đó sẽ xuất hiện những phần mà có lẽ nên gọi là độ tập trung của AI giảm đi rõ rệt. Tôi tận dụng việc này theo cách sau: gộp toàn bộ cây thư mục và mã nguồn trong game thành một file duy nhất kèm TOC, rồi khi tạo thread mới thì tải file đó lên và tiếp tục làm việc. Và khi đặt câu hỏi, tôi luôn yêu cầu trả lời bằng cách nói rõ ràng, một cách tường minh tên của dự án hiện tại. Dù vậy vẫn còn những chỗ chưa thật sự hài lòng... nhưng tôi rất hài lòng với việc có thể hoàn thành dần sở thích mà trước đây vì quá bận với cuộc sống thực nên thậm chí không dám bắt đầu, trong một khoảng thời gian tương đối ngắn.
LLM, bao gồm cả deep research, vẫn chưa hữu ích cho việc giải quyết các vấn đề ở cấp độ cao. (Ví dụ như phát triển thuật toán ở mức bài báo học thuật)
Việc tối ưu hóa đến mức cực hạn, hay lập trình đòi hỏi phải hiểu nhiều đặc tính hệ thống và các vấn đề kỹ thuật khác nhau, cũng tương tự như vậy, hiện vẫn cần bàn tay con người. Nhà phát triển không chỉ là lập trình viên đơn thuần mà là người giải quyết vấn đề. Dù một ngày nào đó việc giải quyết vấn đề end-to-end có thể trở nên khả thi, nhưng ở thời điểm hiện tại, việc tiết kiệm thời gian cho khâu gõ code và lập trình đơn giản để đầu tư vào cách tiếp cận những vấn đề khó hơn là một tín hiệu tích cực về mặt năng suất.
Với vai trò tech lead, tôi làm những việc như thế này khá nhiều. Việc thử định lượng dựa trên story point cũng tương tự, nhưng may là công ty chưa lớn nên các thành viên, bao gồm cả ban điều hành, đều nhận thức được tôi đang đảm nhiệm vai trò gì, nên có vẻ trước mắt chưa phát sinh vấn đề nào.
Khi tổ chức lớn hơn, chắc tôi cũng sẽ phải suy nghĩ về các phương pháp định lượng.
Mình thấy khó đồng ý với ý số 1.
Mình cảm nhận điều này rất nhiều. Vì công ty nhỏ cũng đang cố gắng tuyển kỹ sư giỏi, nhưng thực sự không hề dễ.
Việc hiểu sâu về product engineering mà startup cần cũng rất tốt, nhưng tôi nghĩ con đường theo đuổi công nghệ đến cực hạn và không ngừng mài giũa nó vẫn còn rất có ý nghĩa. Việc phát triển để tạo ra các ứng dụng web đơn giản sẽ bị AI thay thế, nhưng tôi cho rằng vẫn phải có ai đó nghĩ ra Kubernetes và thiết kế ElasticSearch.
Bình luận nói rằng đây là giấc mơ của ASO, thật sự rất ấn tượng.
Tham khảo thêm, đây là trò chơi được tạo bằng vibe coding. https://www.stdy.blog/vibe-go-stone/
Đã được đưa vào JDK 23.
Khi thử nghiệm, tôi thấy ngay cả khi phiên bản JDK của dự án thấp hơn 23, nếu IDE hoặc công cụ EXPORT JavaDoc hỗ trợ thì vẫn hoạt động bình thường.
Bài viết rất sâu sắc. Cảm ơn bạn.
Phần "mức độ hiện tại" thu hút sự chú ý của tôi. Có phải chúng ta đang nhìn LLM bằng khái niệm thời gian của con người không?
Có vẻ như đã được đưa vào tiêu chuẩn rồi.
Linux Landlock là một mô-đun bảo mật gốc của kernel cho phép các tiến trình không đặc quyền tự sandbox chính mình - nhưng không ai dùng nó vì API thì... khó!
Tôi mới nghe về Landlock lần đầu, khá thú vị đấy
Điều tôi cảm nhận khi code cùng AI là, nếu chia nhỏ thành các đơn vị theo kiểu nguyên tắc trách nhiệm đơn nhất + TDD để AI có thể hiểu được ngữ cảnh ngay cả khi chỉ được đưa một phần mã, thì cần thiết kế sao cho không phải đọc bối cảnh lớn mà chỉ với ngữ cảnh cục bộ cũng đủ để nắm bắt được.
Tôi cũng đồng ý vì thứ tôi dùng AI nhiều nhất cho sở thích là làm web game. Khi quy mô vượt qua một mức nhất định, đến một lúc nào đó sẽ xuất hiện những phần mà có lẽ nên gọi là độ tập trung của AI giảm đi rõ rệt. Tôi tận dụng việc này theo cách sau: gộp toàn bộ cây thư mục và mã nguồn trong game thành một file duy nhất kèm TOC, rồi khi tạo thread mới thì tải file đó lên và tiếp tục làm việc. Và khi đặt câu hỏi, tôi luôn yêu cầu trả lời bằng cách nói rõ ràng, một cách tường minh tên của dự án hiện tại. Dù vậy vẫn còn những chỗ chưa thật sự hài lòng... nhưng tôi rất hài lòng với việc có thể hoàn thành dần sở thích mà trước đây vì quá bận với cuộc sống thực nên thậm chí không dám bắt đầu, trong một khoảng thời gian tương đối ngắn.
Đúng là tiêu đề khá câu view. Haha, tôi đồng ý~~
LLM, bao gồm cả deep research, vẫn chưa hữu ích cho việc giải quyết các vấn đề ở cấp độ cao. (Ví dụ như phát triển thuật toán ở mức bài báo học thuật)
Việc tối ưu hóa đến mức cực hạn, hay lập trình đòi hỏi phải hiểu nhiều đặc tính hệ thống và các vấn đề kỹ thuật khác nhau, cũng tương tự như vậy, hiện vẫn cần bàn tay con người. Nhà phát triển không chỉ là lập trình viên đơn thuần mà là người giải quyết vấn đề. Dù một ngày nào đó việc giải quyết vấn đề end-to-end có thể trở nên khả thi, nhưng ở thời điểm hiện tại, việc tiết kiệm thời gian cho khâu gõ code và lập trình đơn giản để đầu tư vào cách tiếp cận những vấn đề khó hơn là một tín hiệu tích cực về mặt năng suất.
Mình rất thích kiểu làm đại khái trước rồi chỉnh nốt các chi tiết còn lại.
Không chỉ cá nhân không nên sợ hãi, mà tôi cũng cho rằng tổ chức nên khuyến khích những câu hỏi ngốc nghếch (?).
Trên thực tế, nhiều người cũng dùng theo cách đó: thiết lập schema rồi nhận về.
Hóa ra vibe coding không phải là meme mà là một phương pháp phát triển mới.
Điều này có thể cũng hữu ích cho việc học các thể loại khác dùng kiểu ký pháp tương tự kinh điển. Chẳng hạn như sách của Plato...
Với vai trò tech lead, tôi làm những việc như thế này khá nhiều. Việc thử định lượng dựa trên story point cũng tương tự, nhưng may là công ty chưa lớn nên các thành viên, bao gồm cả ban điều hành, đều nhận thức được tôi đang đảm nhiệm vai trò gì, nên có vẻ trước mắt chưa phát sinh vấn đề nào.
Khi tổ chức lớn hơn, chắc tôi cũng sẽ phải suy nghĩ về các phương pháp định lượng.