daily-digest

Có nhiều cảm xúc tiêu cực về AI trong cộng đồng phát triển phần mềm hiện nay.
Một số lo ngại về AI là hợp lý, nhưng không nên xem nhẹ giá trị của nó đối với lập trình viên.
Salvatore Sanfilippo nhận định rằng những vấn đề tài chính của các công ty AI không quan trọng, vì lập trình đã thay đổi vĩnh viễn.
Việc AI có thể giúp viết phần mềm tốt hơn và nhanh hơn, cho phép các nhóm nhỏ cạnh tranh với công ty lớn.
LLMs có thể được coi là sự tiếp nối của việc dân chủ hóa mã nguồn, hệ thống, và kiến thức.
Bài viết này đã gây tranh cãi trên Hacker News và Lobste.rs.

Tác giả đã chuyển đổi JustHTML từ Python sang JavaScript trong vài giờ sử dụng Codex CLI và GPT-5.2 (tháng 12 năm 2025).
Một số câu hỏi về tính hợp pháp và đạo đức trong việc phát triển mã nguồn mở được nêu ra và đã được tác giả trả lời.
Tác giả giữ lại giấy phép mã nguồn mở và tuyên bố bản quyền của tác giả thư viện Python, coi đây là một tác phẩm phái sinh hợp pháp.
Tác giả cho rằng việc xây dựng thư viện này là hợp đạo đức nếu có tín dụng rõ ràng và giấy phép được xem xét cẩn thận.
Mặc dù có sự phản đối từ một số nhà phát triển mã nguồn mở, tác giả tin rằng sự phát triển nhanh chóng của công nghệ AI có thể tạo cơ hội cho nhiều cá nhân tham gia đóng góp hơn.
Tác giả lo ngại về tác động của AI đến nhu cầu mã nguồn mở, ví dụ như sự giảm lưu lượng truy cập vào tài liệu Tailwind do khả năng tạo phiên bản tương tự dễ dàng hơn.
Tác giả không chắc chắn về việc khẳng định bản quyền cho tài liệu do LLM tạo ra, nhưng tin rằng mình vẫn duy trì đủ sự kiểm soát sáng tạo.
Tác giả cảm thấy việc công bố các thư viện phần mềm xây dựng theo cách này là có trách nhiệm, miễn là có thông tin rõ ràng về điều kỳ vọng từ phần mềm.

Công cụ visualizer Python được phát triển chủ yếu bởi vibe-coding.
Người viết có kiến thức về bộ lọc analog, nhưng hạn chế về Python.
Quá trình ban đầu của việc lập trình liên quan đến việc tìm kiếm thông tin trên Google.
Cuối cùng, tác giả sử dụng Google Antigravity để thực hiện visualizer audio sample.

Việc viết tài liệu mã là khó khăn, nhưng không viết dẫn đến khó khăn lớn hơn vì không thể hiểu mã.
Việc viết tài liệu rồi quên cập nhật gây nhầm lẫn, dẫn đến “đau đớn” tối đa.
Đề xuất cấm hoàn toàn tất cả các chú thích để giảm thiểu những vấn đề này.
Sử dụng LLM để giải thích ý định của mã thay vì phụ thuộc vào chú thích.
Nếu LLM không thể giải thích mã, thì sẽ tự động thất bại và trách nhiệm thuộc về tác giả mã.
Giới thiệu chỉ số khả năng giải thích mã (Code Interpretability Score - CIS) trong quy trình xây dựng.
Xây dựng chỉ thành công khi CIS đạt ngưỡng đủ cao.
Các chú thích thường không rõ ràng và không cập nhật với sự thay đổi của mã.
Việc tự động sinh chú thích từ LLM luôn đảm bảo tính thời gian của tài liệu.
Cần loại bỏ các chú thích thủ công vì chúng có thể gây ra mâu thuẫn với mã.
LLM có khả năng hiểu ngôn ngữ lập trình và sẽ là công cụ tối ưu để đánh giá khả năng giải thích mã.
Mục tiêu là xây dựng một ngôn ngữ hướng đối tượng hạn chế, như EO, trong đó chỉ số CIS là yêu cầu bắt buộc.

Newsletter này được tài trợ bởi Astronomer, cung cấp hướng dẫn chi tiết về việc phối hợp LLM và Agents với Airflow.
Có nhiều vai trò lead khác nhau trong ngành kỹ thuật, định nghĩa mỗi vai trò phụ thuộc vào công ty.
Các vai trò lead phổ biến bao gồm: Tech Lead, Team Lead, Engineering Manager và Architect.
Sự khác biệt chính giữa các vai trò là sự chú trọng vào quản lý con người so với định hướng kỹ thuật.
Tech Lead thường là vai trò lãnh đạo đầu tiên cho Kỹ sư phần mềm, chịu trách nhiệm về kỹ thuật cho dự án cụ thể.
Tech Lead tạo tài liệu kỹ thuật, hợp tác với quản lý sản phẩm và ước lượng thời gian phản hồi cho dự án.
Các công ty nhỏ thường gọi Tech Lead là Lead Engineer, trong khi các công ty lớn thường không dùng thuật ngữ này.
Staff Engineer là vai trò thường được kết hợp với Tech Lead trong nhiều đội hình, mặc dù đây chỉ là một trong nhiều hình mẫu của Staff Engineer.

AI tools như Copilot và ChatGPT giúp tăng tốc độ làm việc của kỹ sư phần mềm.
Sự nhanh chóng trong phát sinh mã tạo ra nhiều khoảng dừng nhỏ trong công việc hàng ngày.
Chờ IDE phát sinh mã dẫn đến những gián đoạn ngắn có thể khiến người dùng mất tập trung.
Năng suất của kỹ sư phụ thuộc vào việc duy trì sự tập trung và suy nghĩ kiến trúc.
Giai đoạn 5 đến 30 giây khi chờ AI là khoảng thời gian nguy hiểm cho sự tập trung.
Khi gặp độ trễ của AI, não có xu hướng tìm kiếm sự phân tâm qua các kênh giao tiếp như Slack hoặc email.
Việc chuyển đổi giữa các ngữ cảnh tiêu tốn nhiều thời gian và năng lượng.
Nhiều kỹ sư mắc phải sai lầm khi nghĩ rằng họ có thể kiểm tra tin nhắn nhanh chóng và quay lại công việc mà không mất nhiều thời gian.
Tìm hiểu về các kiểu chuyển đổi ngữ cảnh khác nhau rất quan trọng để tối ưu hóa năng suất.
Kỹ sư không nên phân tâm bằng việc kiểm tra các tin nhắn không liên quan trong quá trình làm việc với mã nguồn.
Cần đưa ra các chiến lược làm việc cụ thể như định nghĩa ngữ cảnh rõ ràng và thực hiện kiểm tra thường xuyên.
Sự mệt mỏi tinh thần gia tăng khi có quá nhiều tác vụ diễn ra đồng thời trong quá trình làm việc với AI.