Hậu COVID, các công ty sa thải 20–30% workforce và nhận ra... họ vẫn ổn.
Số lượng CS graduates tăng gấp 3 lần trong 10 năm. AI tools bùng nổ. Và mọi công ty bắt đầu tự hỏi: "Mình có cần tuyển thêm người, hay chỉ cần ít người hơn nhưng AI-native?"
Đây không phải giả thuyết. Nó đang xảy ra.
Mihail Eric - Head of AI tại Monaco, giảng viên Stanford, cựu technical lead tại Amazon Alexa, và người tạo ra class AI software development đầu tiên của Stanford (CS146S) - đã chia sẻ cái nhìn sâu sắc về AI native engineer thực sự là gì. Những insight này cắt xuyên qua hype và đánh đúng vào vấn đề cốt lõi.
5 bài học quan trọng.
Bạn Không Phải AI Native Engineer Chỉ Vì Giỏi Prompt
Phá bỏ myth này trước.
AI native engineer không phải là người viết prompt hay hơn mọi người. Đó chỉ là table stakes. Mihail định nghĩa đó là người có nền tảng vững về system design và algorithmic thinking, kết hợp với khả năng orchestrate agentic workflows - như một manager điều hành team.
Ví dụ của ông rất chuẩn: AI agent giống như những intern thông minh và hăng hái. Bạn kick off họ, họ tự làm việc trong terminal. Nhưng đôi khi họ bị stuck. Đôi khi họ đi sai hướng hoàn toàn.
Nhiệm vụ của bạn? Context switch giữa 3–4 agent đang chạy song song, nhớ mỗi agent đang làm gì, stuck ở đâu, và đẩy họ tiếp tục.
Đó không phải coding skill. Đó là management skill. Những AI native engineer giỏi nhất năm 2026 không phải coder giỏi nhất - họ là orchestrator giỏi nhất.
Như mình đã viết trong Prompting Không Làm Bạn Học Nhanh Hơn, dựa vào AI mà không có nền tảng giống như xem người khác tập gym vậy. AI native engineer thực sự có cơ bắp - họ chỉ dùng AI để nâng nặng hơn.
Build Đúng Thứ, Đừng Chỉ Build Nhanh
Kịch bản này diễn ra mỗi ngày trong năm 2026:
Bạn mở Claude, Codex, hoặc Cursor. Build liên tục trong 1 tháng. Feature này xong thêm feature kia. UI đẹp. Architecture phức tạp. Kỹ thuật hoàn hảo.
Launch.
Không ai muốn dùng.
AI giúp bạn build nhanh hơn bao giờ hết. Nhưng nếu build sai thứ, bạn chỉ đang fail nhanh hơn mà thôi.
Skill thật sự không phải tốc độ - mà là judgment. Biết build cái gì quan trọng hơn vô hạn so với biết build như thế nào. Điều này luôn đúng, nhưng AI khuếch đại nó. Khi cost build gần bằng 0 về effort, cost build sai thứ vẫn catastrophic về thời gian và cơ hội.
Trước khi viết một dòng code (hoặc prompt), trả lời: Ai sẽ dùng? Giải quyết problem gì? Có ai trả tiền cho nó không?
Experimentation Không Phải Tùy Chọn
Ngay cả Anthropic - công ty đứng sau Claude - cũng rewrite Claude Code mỗi 1–2 tuần bằng chính Claude.
Nghĩ kỹ đi. Team build AI coding tool tiên tiến nhất thế giới cũng không có "đáp án cuối cùng." Họ experiment liên tục.
Bài học: build experimentation vào workflow. Đừng chờ "best practice" từ blog post hay conference talk. Khi thứ gì đó trở thành best practice, landscape đã thay đổi rồi.
Áp dụng ở mọi cấp độ:
- Cá nhân: Thử tool mới mỗi tuần. Phá workflow cũ và build lại.
- Team: Chạy time-boxed experiment. "Thử X trong 2 tuần rồi đo kết quả."
- Architecture: Design system dễ thay thế, không chỉ dễ build.
Engineer phát triển tốt không phải người có setup ổn định nhất. Mà là người phá đi và build lại nhanh nhất.
Software Taste: Last Mile Phân Biệt Tốt Và Xuất Sắc
Sự khác biệt giữa functional software và incredible software nằm ở taste.
Mihail chỉ ra rằng taste được rèn giũa ở last mile - khi bạn đã pass test, đã đủ requirements, đã kịp deadline... nhưng vẫn tiếp tục. Không phải vì grade. Không phải vì sprint review. Mà vì problem chưa thực sự được giải quyết.
Đây là lời nhắn nhủ tới các bạn sinh viên IT: bài tập được điểm A chỉ là điểm xuất phát, không phải đích đến. Engineer ship một CRUD app chạy được và engineer obsess về loading states, error handling, edge cases của cùng CRUD app đó - cùng bằng cấp, nhưng khác taste.
Như mình viết trong 5 Tầng Hiểu Biết Khi Học Code, đạt mức "nó chạy" chỉ là level 2 hoặc 3. Mastery thực sự đến từ những level phía sau - khi bạn hiểu tại sao nó chạy và khi nào nó break.
Software taste không thể học từ AI. Nó chỉ được phát triển khi bạn care nhiều hơn mức tối thiểu yêu cầu.
Agent-Friendly Codebase: Lợi Thế Cạnh Tranh Năm 2026
Đây là takeaway thực tế nhất. Muốn AI agent làm việc hiệu quả trong codebase, codebase cần phải sẵn sàng cho chúng.
Agent-friendly codebase trông như thế nào?
- Test coverage đầy đủ - agent cần feedback loop để biết thay đổi có break gì không
- README đồng nhất với code thực tế - không phải document 3 năm tuổi mô tả architecture khác hoàn toàn
- Linting và style checking nhất quán - agent produce code tốt hơn khi pattern rõ ràng và được enforce
- Design patterns nhất quán - nếu codebase dùng 4 cách state management khác nhau, agent sẽ chọn cách tệ nhất
Insight then chốt: nếu bước 1 (codebase) bừa bộn, bước 2 (output của AI) sẽ khuếch đại sự bừa bộn đó. Garbage in, garbage out - ở quy mô lớn.
Giống như sự thật về nghề lập trình: nền tảng là quan trọng. Codebase sạch không chỉ là engineering hygiene - giờ đây nó là force multiplier cho AI-assisted development.
Agent-friendly codebase sẽ là một trong những skill có giá trị nhất cho software engineer phát triển trong năm 2026. Không phải vì nó trendy - mà vì nó là sự khác biệt giữa agent ship feature và agent tạo technical debt.
Tổng Kết
AI native engineer năm 2026 không được định nghĩa bởi tool họ dùng. Mà bởi:
- Orchestration ability - quản lý nhiều agent như quản lý team
- Product judgment - build đúng thứ, không chỉ build nhanh
- Experimentation mindset - không sacred cows, liên tục iterate
- Software taste - care về last mile
- Codebase discipline - làm code agent-ready
Bar cho entry-level engineer cao hơn bao giờ hết. Nhưng ceiling cho engineer biết adapt cũng cao hơn bao giờ hết. Câu hỏi không phải AI có thay đổi công việc của bạn không - nó đã thay đổi rồi. Câu hỏi là bạn có đang thay đổi theo không.
Bài viết dựa trên insights từ phỏng vấn Mihail Eric. Mihail là Head of AI tại Monaco, giảng viên Stanford, và người tạo CS146S: The Modern Software Developer - khóa học đầu tiên của Stanford về AI-native software development.