Câu chuyện của hai developer
Tháng trước tôi làm code review cho hai developer trong team - gọi là Minh và Hùng cho tiện.
Cả hai đều dùng Claude Code, Cursor, Copilot. Cả hai đều hào hứng với AI. Nhưng kết quả khác nhau hoàn toàn.
Minh commit một feature mất 3 ngày. Code đẹp, test đủ, không có gì để chê về chất lượng. Khi tôi hỏi "Em dùng AI thế nào?", Minh nói: "Dạ em hỏi Claude khi bí, nhưng chủ yếu vẫn tự code anh ơi."
Hùng cũng cùng feature đó - mất 6 tiếng. Khi tôi hỏi, Hùng giải thích một chuỗi dài: "Em describe requirement cho AI, nó outline plan, em approve, nó viết từng file, em review từng file, có chỗ em guide lại, có chỗ em override hoàn toàn..."
Không phải Hùng thông minh hơn Minh. Hùng đã thay đổi cách anh ấy nghĩ về công việc.
Vấn đề: dùng AI như cái búa mới
Khi một cái búa mới xuất hiện, người ta có xu hướng dùng nó để đóng mọi thứ - kể cả vít.
Tôi quan sát đủ kiểu developer dùng AI:
Nhóm 1 - "Tôi không cần AI". Vẫn code tay 100%, coi AI là trend ồn ào. Họ đang thu hẹp mình.
Nhóm 2 - "AI viết code, tôi paste". Productivity tăng một chút. Nhưng họ không thực sự hiểu code mình ship. Đây là con đường nguy hiểm hơn nhóm 1.
Nhóm 3 - "AI là pair programmer, tôi là người dẫn dắt". Nhóm này thay đổi cả mental model về workflow. Và đây là nhóm đang tăng tốc thực sự.
Sự khác biệt giữa nhóm 2 và nhóm 3 không phải là tool - mà là tư duy.
Quay lại chuyện kỹ thuật: workflow cũ vs workflow mới
Hãy cùng mổ xẻ điều này một chút.
Developer workflow truyền thống:
Nhận requirement → Hiểu vấn đề → Thiết kế → Code → Debug → Test → Review → ShipTrong mô hình này, bạn là người thực thi từng bước. AI tool (nếu có) là autocomplete thông minh hơn.
Developer workflow trong thời đại AI:
Nhận requirement → Phân tích & decompose → Delegate → Oversee → Review → Curate → ShipNghe có vẻ nhỏ nhặt. Nhưng thay đổi về ngữ nghĩa này kéo theo thay đổi lớn về cách bạn sử dụng thời gian và năng lượng nhận thức.
Từ "thực thi" chuyển sang "chỉ đạo và kiểm soát".
Đây không phải là tôi đang hứa hẹn "AI làm hết, developer nhàn". Ngược lại - developer trong workflow mới phải giỏi hơn ở một số thứ cốt lõi. Nhưng những thứ đó khác với trước.
Ba tư duy cốt lõi của developer workflow thời AI
Tư duy 1: Architect trước, code sau
Trước đây, nhiều developer (kể cả tôi thời trẻ) hay nhảy thẳng vào code. Requirements còn mơ hồ cũng ngồi gõ luôn. "Code một cái xem sao" là phương châm không ít dự án.
Với AI, cách tiếp cận đó phản tác dụng. AI sẽ viết code rất nhanh theo bất kỳ hướng nào bạn chỉ định - kể cả hướng sai.
Tôi đang thấy rõ: developer dùng AI hiệu quả nhất là những người nghĩ kiến trúc rõ ràng trước, rồi mới dùng AI để fill in implementation.
Không cần document chi tiết. Nhưng cần có trong đầu (hoặc viết ra):
- System boundary là gì
- Data flow trông như thế nào
- Các edge case nào quan trọng
- Constraint nào phải respect
Khi bạn đã có mental model đó, prompt cho AI sẽ rõ ràng hơn, output sẽ sát với ý định hơn, review sẽ nhanh hơn. Khi chưa có mental model đó mà đã prompt - bạn đang delegate thinking cho AI. Đó là vấn đề.
Tư duy 2: Review = kiểm tra intent, không chỉ kiểm tra syntax
Code review khi AI generate code không giống code review truyền thống.
Ngày trước, review thường bắt đầu từ: "Code này có bug không? Có clean không? Có đúng convention không?"
Khi AI viết code, những câu hỏi đó vẫn cần - nhưng có một câu hỏi quan trọng hơn: "Code này có làm đúng điều tôi muốn không?"
AI rất giỏi viết code syntactically correct, conventionally reasonable, và... không làm đúng điều bạn muốn vì bạn chưa nói đủ rõ. Đây là điểm mà nhiều developer bị burn: code pass review hình thức, nhưng fail ở logic business.
Tôi đang apply cái này như sau: Với mỗi file AI tạo ra, tôi đọc từ góc độ "đây có phải là thứ tôi muốn ship không?" chứ không phải "code này có đẹp không?"
Nếu bạn không hiểu rõ đủ để review từ góc độ intent - thì bạn chưa nên delegate task đó cho AI.
Tư duy 3: Context là tài sản, không phải overhead
Một trong những discovery thú vị nhất của tôi khi dùng Claude Code nặng: chất lượng output phụ thuộc nhiều vào context bạn cung cấp hơn là prompt bạn viết.
Developer kém dùng AI: "Viết một API endpoint để lấy danh sách orders."
Developer giỏi dùng AI: "Project này là e-commerce system dùng .NET 8, CQRS pattern, Orders table có các cột X, Y, Z, performance requirement là p95 < 200ms, đây là interface hiện có, đây là convention chúng tôi follow, viết endpoint GET /orders với filtering và pagination."
Cùng một request. Khác nhau về context. Output khác nhau hoàn toàn.
Điều này có nghĩa là: đầu tư vào việc chuẩn bị context - project structure, conventions, domain knowledge, existing patterns - là đầu tư có ROI rất cao khi dùng AI. Không phải overhead, mà là multiplier.
Kinh nghiệm từ dự án thực tế
Tôi đang build BKGlobal và sondo.top song song - tức là đang operate như một 1-person engineering team với AI là "junior dev" của mình.
Một số thứ tôi học được từ thực tế:
Không phải task nào cũng nên delegate cho AI. Nếu task đòi hỏi deep understanding về business context tôi tích lũy nhiều năm - tôi tự code. AI sẽ miss những nuance quan trọng mà không có documentation nào capture được.
AI là pair programmer tuyệt vời cho exploration. Khi tôi muốn thử một approach mới, không chắc chắn về direction - prompt AI cho một prototype nhanh, đánh giá xem có đúng hướng không, rồi mới invest thời gian đúng đắn. Giảm đáng kể thời gian "đi sai đường".
AI giúp tôi maintain standards nhất quán hơn. Khi mệt, khi deadline gấp, human developer (kể cả senior) hay cut corners. AI không mệt. Nếu tôi đã define standards rõ trong context - AI sẽ apply nhất quán. Tôi dùng điều này như một "guard rail" cho bản thân.
Multi-step workflow hiệu quả hơn one-shot. Thay vì prompt một lần "viết toàn bộ feature này", tôi break down thành: "1. Viết interface và data model. 2. Implement core logic. 3. Viết tests. 4. Viết integration layer." Từng bước có checkpoint. Kết quả tốt hơn nhiều.
Điều tôi thấy ở developer thực sự thriving
Từ việc mentoring team và observe cộng đồng dev, tôi thấy những developer đang tăng tốc thực sự trong 2026 có một điểm chung: họ đang re-invest thời gian tiết kiệm được từ AI vào những thứ AI không làm được.
Cụ thể:
- Hiểu business domain sâu hơn
- Build system thinking rõ hơn
- Communicate technical decisions tốt hơn với stakeholders
- Mentor người khác
- Experiment với architecture mới
Trong khi những developer không tăng tốc thì đang làm gì với thời gian tiết kiệm được từ AI? Đơn giản là... nghỉ ngơi. Hoặc làm thêm volume công việc cùng loại.
Không phán xét - nhưng đó là sự khác biệt tôi thấy.
Gửi các bạn trẻ đang bắt đầu
Nếu bạn đang ở năm 1-3 trong nghề và đọc đến đây, tôi muốn nói thêm một điều:
AI tools tốt nhất khi bạn đã có nền tảng. Nếu bạn chưa biết tại sao code chạy, không hiểu data flow, không có mental model về architecture - AI sẽ generate code bạn không thể evaluate. Bạn sẽ ship thứ bạn không hiểu. Đó là con đường nguy hiểm.
Đừng bỏ qua giai đoạn học những thứ cơ bản chỉ vì "AI có thể làm thay". Fundamentals là thứ cho phép bạn sử dụng AI hiệu quả - không phải thứ AI thay thế.
Học để hiểu. Dùng AI để tăng tốc sau khi đã hiểu. Thứ tự đó quan trọng.
Triết lý
Tôi "believe in basic" - tagline này không phải là hoài cổ về thời chưa có AI.
"Basic" với tôi là: hiểu rõ vấn đề trước khi giải, biết mình đang làm gì và tại sao, không ship thứ mình không hiểu.
Những điều đó không thay đổi dù workflow bên ngoài thay đổi thế nào. AI thay đổi cách bạn thực thi - nhưng không thể thay đổi tư duy bạn đem vào công việc.
Developer workflow trong thời đại AI, sau tất cả, vẫn là workflow của một người kỹ thuật có tư duy rõ ràng - chỉ là bây giờ bạn có một đội ngũ "AI junior" đang chờ bạn chỉ đạo.
Câu hỏi không phải "tôi có nên dùng AI không?". Câu hỏi là: "Tôi đã đủ rõ ràng về vấn đề để delegate chưa?"
Bạn đang cấu trúc workflow như thế nào?
Tôi rất tò mò - trong team hoặc dự án cá nhân của các bạn, AI đang fit vào workflow như thế nào? Có task nào các bạn vẫn giữ cho "human only" không? Lý do là gì? 👇
/Son Do - believe in basic
#1percentbetter #AIWorkflow #DeveloperMindset #CareerCraft #SoftwareEngineering