Biểu đồ contribution trên GitHub của tôi năm 2025 trông như thuộc về hai developer khác nhau. Nửa đầu năm gần như trống. Nửa sau có hơn 4.000 commit.
Tôi không đột nhiên có thêm thời gian rảnh. Tôi vẫn vừa làm full-time vừa duy trì side project. Điều thay đổi là mức friction giữa một ý tưởng và một phiên bản thực sự chạy được: tôi bắt đầu sử dụng AI coding tools nghiêm túc hơn rất nhiều.
Con số đó cần được hiểu đúng. Số lượng commit tự nó không phải là thước đo productivity. Bốn nghìn commit không chứng minh rằng tôi đã tạo ra bốn nghìn cải tiến có ý nghĩa hoặc code có chất lượng cao. Nhưng biểu đồ thực sự cho thấy một thay đổi trong nhịp làm việc: tôi build, iterate và đưa sản phẩm tới phiên bản chạy được đều đặn hơn trước rất nhiều.
Nút thắt thật sự là năng lượng cần để bắt đầu thử nghiệm
Trong side project, tôi liên tục gặp cùng một vấn đề: phiên bản hữu ích đầu tiên thường nằm sau một bức tường công việc lặp lại. Routing, validation, scripts, tests, configuration và cleanup có thể ăn hết momentum trước khi tôi biết ý tưởng có đáng theo đuổi hay không.
Trước đây tôi thường trì hoãn experiment nếu first working version có vẻ cần nhiều buổi tối setup. AI coding tools không làm công việc đó biến mất, nhưng giảm chi phí của first pass và rút ngắn đường tới phiên bản có thể test.
Vì vậy lợi ích lớn nhất không phải gõ nhanh hơn. Đó là activation energy thấp hơn: nhiều ý tưởng thực sự tới được điểm mà tôi có thể thu thập evidence.
Workflow Node.js của tôi đã thay đổi như thế nào
Tôi không thay development process bằng một cửa sổ chat. Trong side project Node.js, tôi dùng DeepSeek như một second pair of hands cho những task có scope rõ: viết draft implementation đầu tiên, đọc code lạ, đề xuất tests, phân tích stack trace, chia refactor lớn và review deployment assumptions.
- Scaffolding: tạo first version nhàm chán của handler, validation, script hoặc test.
- Code reading: trace request hoặc value trước khi edit.
- Refactoring: chia thay đổi cơ học thành diff nhỏ dễ review.
- Debugging: tạo nhiều hypothesis từ logs.
- Verification: tìm edge case và regression sau khi happy path chạy.
Input, output, constraint và convention hiện có càng rõ thì kết quả càng dễ verify. Task mơ hồ thường tạo abstraction nghe hợp lý nhưng sai.
Vì vậy tôi coi AI output là candidate patch chứ không phải final answer. Type checking, tests, build và real flow là evidence; giọng điệu tự tin không phải.
DeepSeek giúp nhiều nhất ở đâu — và không giúp ở đâu
DeepSeek hữu ích vì tôi có thể dùng lặp lại cho concrete programming tasks. Tôi có thể lấy first pass, bỏ một phần, đưa real error trở lại, thu hẹp scope và iterate nhanh.
Tôi không gọi đây là benchmark. Tôi không làm controlled study với mọi model cạnh tranh và model lineup thay đổi nhanh. Điều có thể nói chắc hơn là: DeepSeek phù hợp đủ tốt với workflow của tôi để tôi dùng AI assistance thường xuyên hơn rất nhiều.
Nó mạnh nhất khi feedback rẻ: có function, tests và error thật. Nó yếu hơn khi task phụ thuộc vào product context không được viết ra hoặc architecture trade-off tinh tế. Khi đó output trôi chảy có thể làm một assumption sai trông như solution hoàn chỉnh.
AI đã thay đổi chi phí của việc thử nghiệm
Cải thiện lớn nhất không phải “AI viết code nên development trở nên tự động”. Nhiều phần nhỏ đơn giản trở nên đủ rẻ để thử. Một feature side project trước đây trông như cần quá nhiều setup giờ có thể thành prototype khi tôi vẫn còn hứng thú với ý tưởng.
Sự khác biệt này rất quan trọng. AI giảm chi phí để đạt tới phiên bản có thể kiểm thử. Nó không loại bỏ architecture, product judgment, deployment hay correctness. Generated implementation vẫn có thể sai; build thành công vẫn có thể hỏng ở runtime; prototype đã deploy vẫn có thể là một sản phẩm tệ.
Với tôi, lợi ích thực tế là momentum. Khi đã thấy toàn bộ hệ thống chạy được, tôi có nhiều động lực hơn để tiếp tục refine nó.
Một benchmark mạnh hơn cần gì
Để benchmark có thể reproduce, tôi sẽ ghi exact model versions, fixed programming tasks, repository snapshots, prompts, raw outputs, elapsed time, accepted/rejected patches, review time, test results và rework.
Tôi cũng sẽ đo nhiều hơn commits: thời gian từ idea tới verified version, defects, rollbacks và lượng work phải viết lại. Không có context đó, 4.000 commits là evidence của activity và behavior change, không phải proof của software quality.
Điều gì đã thay đổi với tôi
2025 là năm tôi ngừng nhìn mọi side project như một ngọn núi setup phải leo hoàn toàn bằng tay. AI làm cho phiên bản đầu tiên chạy được trở nên đủ rẻ để tôi thường xuyên đạt tới giai đoạn mà quyết định sản phẩm thực sự quan trọng.
Đó là lý do nửa sau biểu đồ GitHub của tôi khác đến vậy. Không phải vì AI cho tôi thêm giờ trong ngày, cũng không phải vì mọi dòng code được tạo đều tốt. Nó giảm friction từng khiến những ý tưởng cũ chết trước khi trở thành thứ có thật.
Năm 2026, tôi tập trung vào nửa ít hào nhoáng hơn của câu chuyện: refine workflow, đo quality nghiêm túc hơn và đảm bảo development nhanh hơn tạo ra software tốt hơn chứ không chỉ nhiều commit hơn.