Mời bạn thưởng thức Newsletter #108.
Lập trình đã được giải quyết? Phần mềm thì chưa
Mở đầu bằng câu nói của Boris Cherny (người tạo ra Claude Code) rằng việc viết mã “về cơ bản đã được giải quyết”, tác giả Gao của Arcplane lập luận rằng nhận định này đúng nhưng chưa đủ. Viết mã chỉ là biến hướng dẫn thành mã nguồn, còn phát triển phần mềm là biến ý định mơ hồ thành hệ thống đáng tin cậy — một quá trình giảm dần độ hỗn loạn (entropy). Nghịch lý là AI viết mã nhanh lại có thể làm tăng hỗn loạn: bộ kiểm thử đồ sộ nhưng chỉ xác nhận cách triển khai agent đã chọn, kế hoạch nghe hợp lý nhưng bỏ ngỏ quyết định sản phẩm. Mã đến sớm hơn, nhưng nhóm không tin tưởng kết quả sớm hơn — nút thắt cổ chai dịch chuyển sang review, dựng lại ý định của agent và diễn giải bằng chứng nhiễu.
Từ kinh nghiệm vận hành một sản phẩm xác thực quản lý hàng triệu danh tính, tác giả chỉ ra bốn điều cần thay đổi. Thứ nhất, ngữ cảnh phải được chọn lọc có chủ đích, và phản hồi từ review cần được lưu lại cho các lần chạy sau. Thứ hai, đặc tả phải đi cùng công việc và được cập nhật khi phát hiện trường hợp biên mới, vì agent sẵn sàng triển khai trọn vẹn một yêu cầu mơ hồ. Thứ ba, bằng chứng kiểm chứng phải đủ rõ để người review biết agent đã chạy gì, lỗi gì, sửa ra sao. Thứ tư, con người cần điểm kiểm soát đúng chỗ, nhất là trước khi triển khai, bởi “mã sạch không thể cứu một bản đặc tả tồi”; mức độ review nên tương xứng với rủi ro.
Ideas — Bộ sưu tập mô hình tư duy của Noah Zender
Đây không phải một bài viết đơn lẻ mà là trang mục lục của Noah Zender, tập hợp gần 500 mô hình tư duy, khuôn mẫu và khung suy nghĩ được chắt lọc từ hàng trăm cuốn sách, podcast và video. Các ý tưởng được chia thành 11 nhóm: mô hình tư duy và ra quyết định, tri thức và học tập, sáng tạo và viết lách, sản phẩm và khởi nghiệp, thương hiệu và marketing, đổi mới công nghệ và AI, đầu tư và kinh tế, tâm lý và phát triển bản thân, công việc và lãnh đạo, triết học và thế giới quan, cùng một nhóm chưa phân loại. Mỗi mục dẫn tới một trang ngắn riêng, giống một kho tri thức cá nhân hơn là một bài đọc liền mạch.
Một ví dụ tiêu biểu là ý tưởng “Leveraged Expert” (chuyên gia có đòn bẩy), cho rằng thời điểm chuyên môn hóa quan trọng không kém bản thân chuyên môn. Đường cong áp dụng của mọi công nghệ đều có một điểm uốn, nơi tăng trưởng hoặc đi vào đại chúng, hoặc suy giảm nhanh. Nếu bạn đã là chuyên gia trong một lĩnh vực sắp chạm điểm uốn đó, khi nó trở nên phổ biến, đòn bẩy của bạn tự tăng lên mà không cần thêm nỗ lực nào. Theo tác giả, chuyên môn hóa quá sớm trong một ngành còn quá non trẻ mang lại đòn bẩy thấp hơn, và thời điểm tốt nhất là đầu giai đoạn những người dùng sớm bắt đầu đón nhận — nơi tiềm năng gặp may mắn là cao nhất. Với lập trình viên trẻ, đây là gợi ý hữu ích khi cân nhắc nên đầu tư học sâu vào công nghệ nào.
Tranh luận về năng suất AI
Bài viết từ bản tin Engineering Enablement của DX tổng hợp phiên thảo luận khép lại hội nghị DX Annual, với các lãnh đạo kỹ thuật và nhà nghiên cứu đến từ Etsy, Twilio, GitHub, Google và DX. Với câu hỏi AI có khiến cần ít kỹ sư hơn không, đa số phản đối: nhu cầu phần mềm tăng trong khi chi phí xây dựng giảm, nên tổng số người tạo ra sản phẩm sẽ không giảm, dù định nghĩa về kỹ sư có thể thay đổi. Về nợ kỹ thuật, ý kiến chia rẽ: đại diện Twilio xem AI là bộ khuếch đại (đầu vào tồi thì đầu ra tồi), còn Brian Houck cảnh báo các tổ chức đang tối ưu tốc độ tạo PR thay vì sự gọn gàng, kèm theo “nợ nhận thức” — hiểu hệ thống ngày càng ít khi AI viết phần lớn mã nguồn.
Các chuyên gia không ủng hộ việc bắt buộc dùng AI từ trên xuống: Twilio chỉ cài sẵn công cụ và hướng dẫn cơ bản mà mức độ sử dụng vẫn tăng mạnh, còn ép buộc dễ dẫn tới áp dụng hời hợt. Việc dùng mức độ sử dụng AI làm chỉ số đánh giá cá nhân bị các kỹ sư phản đối. Về nút thắt cổ chai, lập trình viên chỉ dành khoảng 14% thời gian để viết mã, nên vấn đề thật nằm ở ra quyết định, ưu tiên và thiết kế sản phẩm; cảm giác review chậm đi phần nhiều là do mã được viết nhanh hơn. Cuối cùng, phần lớn trở ngại là vấn đề con người và văn hóa: lãnh đạo cần cho nhân viên thời gian học, và học nhóm hai tuần hiệu quả hơn hẳn tự học riêng lẻ.
Cảm biến bảo trì cho AI coding agent
Birgitta Böckeler (Thoughtworks) chia sẻ thử nghiệm thực tế với các sensor (cảm biến) giúp cả con người lẫn AI coding agent nhận biết khả năng bảo trì của mã nguồn, tiếp nối khái niệm “harness engineering”. Ứng dụng thử nghiệm là một dashboard viết bằng TypeScript, Next.js và React, dựng lại hoàn toàn bằng AI và gần như không có tài liệu hướng dẫn về chất lượng mã, để xem agent làm tốt đến đâu chỉ nhờ phản hồi từ sensor như type checker, ESLint, Semgrep, dependency-cruiser, bộ kiểm thử và mutation testing. Với ESLint, tác giả bật các quy tắc giới hạn số tham số, độ dài tệp, độ dài hàm và độ phức tạp cyclomatic, đồng thời viết lại thông báo lỗi thành hướng dẫn tự sửa, cho phép agent bỏ qua cảnh báo kèm lý do để dễ review.
Dependency-cruiser giúp agent tuân thủ cấu trúc phân lớp module và tự sửa khi vi phạm. Ngược lại, dữ liệu coupling thô khá nhiễu và AI diễn giải chưa tốt, vì “tốt” hay “xấu” ở đây phụ thuộc vào ngữ cảnh; trong khi review tính module hóa bằng AI với prompt mạnh lại phát hiện nhiều vấn đề đáng giá như mã route trùng lặp hay đặt trách nhiệm sai chỗ. Với bộ kiểm thử do AI sinh ra, độ bao phủ cao không đảm bảo chất lượng: có tệp đạt 100% statement coverage nhưng không hề có unit test, và mutation testing mới làm lộ các assertion còn thiếu. Kết luận của tác giả là sensor tính toán hiệu quả nhất ở cấp tệp và hàm, còn các vấn đề xuyên module cần AI bổ sung phần diễn giải ngữ nghĩa. Sensor tăng niềm tin vào kết quả nhưng chưa thể thay thế con người.
Bài viết đã được viết lại bởi Claude Code với Opus 5.5 vào ngày 27/09/2026.