Newsletter #108

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

Tác giả phản biện lại quan điểm cho rằng AI hỗ trợ lập trình đã “giải quyết” xong việc phát triển phần mềm. Theo tác giả, viết mã (biến hướng dẫn thành mã nguồn cụ thể) khác hẳn với phát triển phần mềm (biến ý định mơ hồ thành hệ thống đáng tin cậy). AI có thể tăng tốc việc sinh mã, nhưng không thể xóa bỏ phần công việc rối rắm bao quanh nó.

Tác giả mô tả phát triển phần mềm như một quá trình giảm dần độ hỗn loạn (entropy): hiểu vấn đề, thu hẹp phạm vi, thiết kế hành vi, triển khai thay đổi, rồi kiểm chứng kết quả. Nghịch lý là khi viết mã quá nhanh, ta lại có thể làm tăng độ hỗn loạn — sinh ra kết quả trông như đã hoàn chỉnh nhưng thực chất che giấu các quyết định và ý định phía sau. Khi việc triển khai trở nên nhanh hơn, các quy trình xung quanh mới lộ ra là nút thắt cổ chai thực sự: đọc lại mã để review, dựng lại lý do AI đưa ra quyết định, và diễn giải các bằng chứng nhiễu loạn.

Điểm chính:

Viết mã và phát triển phần mềm là hai việc khác nhau; AI mới chỉ tăng tốc phần viết mã.
Viết mã nhanh có thể làm tăng độ hỗn loạn thay vì giảm nó.
Khi triển khai nhanh hơn, các quy trình xung quanh (review, kiểm chứng) trở thành nút thắt mới.
Bốn yếu tố còn thiếu: chọn lọc ngữ cảnh có chủ đích, đặc tả bền vững và tiến hóa theo công việc, bằng chứng kiểm chứng đáng tin, và các điểm kiểm soát chiến lược của con người.
“Mã sạch không thể cứu một bản đặc tả tồi” — một số quyết định cần phán đoán của con người trước khi triển khai.

Ideas — Bộ sưu tập mô hình tư duy của Noah Zender

Đây là trang mục lục tập hợp hơn 500 ý tưởng, mô hình tư duy và khung suy nghĩ, được sắp xếp thành 11 nhóm chủ đề: mô hình tư duy & ra quyết định, tri thức & học tập, sáng tạo & viết lách, sản phẩm & khởi nghiệp, thương hiệu & marketing, đổi mới & công nghệ & AI, đầu tư & thị trường, tâm lý & bản sắc, công việc & lãnh đạo, triết học & thế giới quan. Mỗi mục là một liên kết dẫn tới trang ý tưởng riêng — giống một hệ thống quản lý tri thức hơn là một bài viết truyền thống.

Ý tưởng nổi bật là “Leveraged Expert” (Chuyên gia có đòn bẩy): 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. Tác giả cho rằng thời điểm tốt nhất để trở thành chuyên gia là trong giai đoạn đầu của một ngành mới nổi, trước khi nó phổ biến đại trà. Khi công nghệ/ý tưởng đó đạt mức phổ biến, đòn bẩy của bạn tăng lên “mà không cần thêm nỗ lực nào”. Chuyên môn hóa quá sớm lại tạo ra đòn bẩy thấp hơn so với việc tham gia đúng điểm uốn của đường cong áp dụng.

Điểm chính:

Trang là kho ý tưởng (500+ khái niệm) chia thành 11 nhóm chủ đề, không phải một bài viết đơn lẻ.
Đường cong áp dụng (adoption curve) có những điểm uốn quyết định việc tăng tốc hay suy giảm.
Chuyên môn hóa trước khi ngành phổ biến đại trà mang lại lợi thế đòn bẩy độc nhất.
Đòn bẩy tăng tự nhiên khi ý tưởng/công nghệ chạm mức phổ biến.
Vào quá sớm (giai đoạn áp dụng ban đầu) cho đòn bẩy thấp hơn so với vào đúng điểm uốn.

Tranh luận về năng suất AI

Bài viết tổng hợp cuộc tranh luận tại DX Annual giữa các lãnh đạo kỹ thuật và nghiên cứu từ Etsy, Twilio, GitHub, Google và DX về tác động thực tế của AI đến năng suất phát triển phần mềm. Các chủ đề được đưa ra dưới dạng các phát biểu gây tranh cãi, và mỗi chuyên gia đưa ra quan điểm riêng.

Về câu hỏi “AI có nghĩa là ít kỹ sư hơn?”, đa số phản đối — nhu cầu phần mềm tăng lên, chi phí xây dựng giảm, nên tổng số “người tạo ra sản phẩm” không giảm, dù định nghĩa về kỹ sư phần mềm có thể thay đổi. Về nợ kỹ thuật, ý kiến chia hai: một bên cho rằng AI khuếch đại năng lực hiện có (kỹ sư giỏi vẫn viết mã tốt), bên kia cảnh báo rằng tối ưu tốc độ PR mà không hiểu hệ thống sẽ tạo ra “nợ nhận thức”. Về việc AI nên được áp dụng từ trên xuống hay từ dưới lên, các chuyên gia đồng thuận cần kết hợp cả hai: lãnh đạo tạo điều kiện và hạ tầng, còn sự áp dụng thực sự phải đến từ chính các kỹ sư.

Điểm chính:

Nhu cầu phần mềm tăng → AI không giảm số lượng kỹ sư, mà thay đổi vai trò của họ.
AI là bộ khuếch đại: kỹ sư giỏi thêm giỏi, kỹ sư yếu tạo thêm nợ kỹ thuật.
“Nợ nhận thức” (cognitive debt) — hiểu hệ thống ít hơn khi AI viết nhiều mã hơn — là rủi ro mới.
Áp dụng AI cần cả chiến lược từ lãnh đạo lẫn sự tự nguyện từ kỹ sư.
Đo lường năng suất AI nên dựa trên kết quả kinh doanh, không chỉ số lượng PR.

Cảm biến bảo trì cho AI coding agent

Birgitta Böckeler (Thoughtworks) chia sẻ kinh nghiệm thực tế về việc thiết lập các sensor (cảm biến) giúp AI coding agent tự kiểm tra và duy trì chất lượng mã nguồn. Bài viết là phần tiếp nối của khái niệm “harness engineering” — hệ thống hướng dẫn và cảm biến giúp tăng xác suất AI tạo ra mã tốt và tự sửa lỗi trước khi đến tay con người.

Tác giả thử nghiệm trên ứng dụng TypeScript/Next.js/React, sử dụng nhiều loại sensor: ESLint (với các rule tùy chỉnh cho lỗi AI thường mắc), dependency-cruiser (kiểm tra quy tắc phụ thuộc giữa module), phân tích coupling, AI modularity review, bộ kiểm thử hồi quy, và mutation testing. Điểm đặc biệt là sensor không chỉ phát hiện lỗi mà còn cung cấp hướng dẫn sửa lỗi — giúp agent tự sửa mà không cần can thiệp thủ công.

Điểm chính:

Sensor là công cụ tính toán (linting, kiểm thử, phân tích phụ thuộc) chạy song song với AI agent để phản hồi nhanh.
ESLint rule tùy chỉnh cho lỗi AI thường gặp (import sai, trùng lặp, vi phạm kiến trúc) rất hiệu quả.
Dependency-cruiser giúp giữ ranh giới module rõ ràng — AI agent hay vi phạm ranh giới kiến trúc.
Mutation testing đánh giá chất lượng thực sự của bộ kiểm thử do AI tạo ra.
Sensor cần kèm hướng dẫn sửa lỗi (guidance) để agent tự khắc phục thay vì chỉ báo lỗi.