Trong nhiều năm trước, hình ảnh quen thuộc của một developer là ngồi trước màn hình, đọc requirement, viết code và gửi pull request. Quy trình này vẫn tồn tại, nhưng trong vài năm gần đây, cách chúng ta làm việc với code đang thay đổi nhanh chóng.

Sự xuất hiện của các công cụ AI hỗ trợ lập trình, các workflow tự động hóa và các hệ thống agent đã tạo ra một mô hình làm việc mới: agentic coding workflow.

Trong mô hình này, developer không chỉ viết code. Họ còn đóng vai trò như một người điều phối: đưa ra quyết định, kiểm soát chất lượng và định hướng hệ thống.

Một cách đơn giản để hiểu mô hình này là:

• Agent / AI là “đôi tay” thực thi.
• Con người là người thiết kế và kiểm soát.

Điều này dẫn đến một triết lý làm việc rất quan trọng:

Hãy di chuyển nhanh, nhưng đừng nhanh hơn khả năng kiểm tra của con người.

Trong bài viết này, chúng ta sẽ cùng phân tích những nguyên tắc làm việc quan trọng của một Senior Software Engineer khi làm việc trong môi trường như vậy.

1. Trước khi viết code, hãy nói rõ các giả định

Một trong những nguyên nhân phổ biến nhất khiến dự án phần mềm bị chậm tiến độ không phải là bug, mà là hiểu sai requirement.

Nhiều developer, đặc biệt là những người còn ít kinh nghiệm, có xu hướng đọc requirement, tự suy đoán phần chưa rõ và bắt đầu viết code ngay. Khi review diễn ra, reviewer mới phát hiện rằng developer đã hiểu sai một phần quan trọng của bài toán.

Kết quả là toàn bộ phần code đó phải làm lại.

Để tránh tình huống này, một nguyên tắc quan trọng là luôn nói rõ các giả định trước khi bắt đầu implement.

Ví dụ:

ASSUMPTIONS I'M MAKING:
1. Endpoint này chỉ được gọi bởi user đã đăng nhập.
2. API sẽ trả về tối đa 100 items mỗi lần.
3. Không cần xử lý pagination ở client.
→ Nếu các giả định này sai, hãy chỉnh lại trước khi tôi implement.

Việc làm này có ba lợi ích lớn.

Thứ nhất, nó giúp phát hiện hiểu nhầm từ rất sớm. Reviewer có thể ngay lập tức xác nhận hoặc sửa lại assumption.

Thứ hai, nó giúp tiết kiệm thời gian review. Người review không cần đọc toàn bộ code để hiểu developer đang nghĩ gì.

Thứ ba, nó tạo ra một context rõ ràng cho code. Sau này khi quay lại code, người khác cũng hiểu được logic ban đầu.

Trong thực tế, rất nhiều bug lớn không đến từ lỗi kỹ thuật, mà đến từ việc developer giải sai bài toán.

2. Khi gặp mâu thuẫn, hãy dừng lại và hỏi

Một kỹ năng quan trọng của developer giỏi là biết khi nào không nên tiếp tục code.

Trong thực tế, requirement hiếm khi hoàn hảo. Bạn có thể gặp những tình huống như:

• Tài liệu mô tả một behavior, nhưng code hiện tại lại làm khác.
• Hai file cấu hình định nghĩa logic khác nhau.
• API documentation không khớp với implementation.
• Business rule chưa được viết rõ.

Trong những tình huống này, phản xạ sai lầm của nhiều developer là tự chọn một hướng và tiếp tục làm việc.

Điều này có vẻ tiết kiệm thời gian trong ngắn hạn, nhưng thường gây ra vấn đề lớn hơn khi code được review.

Một cách làm tốt hơn là:

1. Dừng lại.
2. Nêu rõ vấn đề.
3. Trình bày các khả năng.
4. Hỏi lại người chịu trách nhiệm về hệ thống.

Ví dụ:

Tôi thấy file cấu hình A định nghĩa timeout là 30 giây, nhưng file B lại là 60 giây.
Giá trị nào là đúng cho production?

Cách giao tiếp này không chỉ giúp tránh bug mà còn thể hiện rằng developer đang chủ động suy nghĩ về hệ thống, thay vì chỉ làm theo chỉ dẫn.

3. Đừng trở thành một “yes-machine”

Trong nhiều team kỹ thuật, đặc biệt là các team có cấu trúc phân cấp rõ ràng, developer dễ rơi vào trạng thái chỉ làm theo chỉ đạo.

Manager hoặc architect đưa ra một hướng giải quyết, và developer trả lời:

Ok, em làm theo.

Thoạt nhìn điều này có vẻ hiệu quả. Nhưng về lâu dài, nó tạo ra một môi trường mà những vấn đề tiềm ẩn không bao giờ được nói ra.

Một senior engineer cần làm tốt hơn thế.

Nếu bạn thấy một giải pháp có vấn đề, bạn nên:

• chỉ ra rủi ro
• giải thích hậu quả
• đề xuất phương án thay thế

Ví dụ:

Cách này sẽ khiến mỗi request phải gọi thêm một API khác.
Điều đó có thể làm latency tăng khoảng 150–200ms.
Chúng ta có thể cache dữ liệu này trong Redis để tránh gọi lại mỗi lần.

Điều quan trọng là: sau khi đưa ra ý kiến, bạn vẫn tôn trọng quyết định cuối cùng của người thiết kế hệ thống.

Mục tiêu của việc phản biện không phải là chứng minh mình đúng, mà là giúp hệ thống trở nên tốt hơn.

4. Sự đơn giản luôn chiến thắng sự thông minh

Một trong những sai lầm phổ biến của developer là over-engineering.

Khi gặp một bài toán, họ ngay lập tức nghĩ đến:

• design pattern phức tạp
• abstraction nhiều tầng
• framework nội bộ

Trong nhiều trường hợp, điều này không cần thiết.

Một nguyên tắc tốt là trước khi hoàn thành code, hãy tự hỏi:

• Có thể giải quyết bài toán này với ít code hơn không?
• Abstraction này có thực sự cần thiết không?
• Một developer khác có dễ hiểu đoạn code này không?

Một đoạn code tốt thường có ba đặc điểm:

• ngắn gọn
• rõ ràng
• dễ đọc

Trong môi trường production, code “boring” thường là code tốt.

Những đoạn code quá clever có thể gây ấn tượng lúc ban đầu, nhưng sau vài tháng, khi team phải maintain chúng, sự phức tạp đó trở thành gánh nặng.

Một senior engineer giỏi không cố gắng viết code thông minh. Họ cố gắng viết code đơn giản đến mức không thể hiểu sai.

5. Chỉ sửa những gì bạn được giao

Một thói quen nguy hiểm của developer là “tiện tay sửa luôn”.

Trong lúc làm một task nhỏ, bạn có thể thấy:

• một function đặt tên không rõ
• một file có cấu trúc không đẹp
• một đoạn code có thể refactor

Ý tưởng cải thiện code là tốt. Nhưng nếu bạn sửa quá nhiều thứ không liên quan đến task ban đầu, bạn sẽ tạo ra một pull request rất khó review.

Reviewer phải đọc nhiều code hơn, hiểu nhiều thay đổi hơn và mất nhiều thời gian hơn.

Vì vậy, một nguyên tắc quan trọng là:

Chỉ sửa những gì nằm trong phạm vi của task.

Nếu bạn thấy một vấn đề khác, hãy:

• ghi chú lại
• tạo issue mới
• hoặc đề xuất refactor ở task khác

Cách làm này giúp giữ cho mỗi thay đổi trong codebase nhỏ, rõ ràng và dễ kiểm soát.

6. Đừng để dead code tồn tại quá lâu

Sau mỗi lần refactor, rất dễ xuất hiện những đoạn code không còn được sử dụng.

Ví dụ:

• một function cũ không còn được gọi
• một class đã bị thay thế
• một file legacy không còn dùng

Những đoạn code này thường được gọi là dead code.

Dead code có hai vấn đề lớn.

Thứ nhất, nó làm codebase trở nên khó hiểu. Một developer mới đọc code có thể mất thời gian tìm hiểu những thứ thực ra không còn được sử dụng.

Thứ hai, nó làm tăng nguy cơ bug. Một ngày nào đó, ai đó có thể vô tình sử dụng lại một đoạn code cũ mà không biết rằng nó đã lỗi thời.

Vì vậy, sau khi refactor, bạn nên:

• kiểm tra xem có code nào không còn được dùng
• liệt kê chúng
• hỏi reviewer xem có nên xóa không

Việc dọn dẹp codebase thường xuyên giúp hệ thống gọn gàng và dễ bảo trì hơn.

7. Một workflow làm việc hiệu quả

Một developer giỏi không chỉ viết code tốt, mà còn làm việc theo một quy trình rõ ràng.

Một workflow đơn giản nhưng hiệu quả có thể gồm bốn bước.

Bước 1: Lập kế hoạch

Trước khi viết code, hãy phác thảo kế hoạch:

• hiểu requirement
• xác định các bước implement
• nghĩ trước về test

Bước 2: Implement

Viết code theo kế hoạch đã đặt ra.

Tránh mở rộng scope hoặc thêm các thay đổi không cần thiết.

Bước 3: Verify

Sau khi code xong, hãy kiểm tra:

• test có pass không
• behavior có đúng với requirement không
• logic mới có phá vỡ logic cũ không

Bước 4: Report thay đổi

Khi gửi pull request, hãy mô tả rõ ràng:

• bạn đã thay đổi những gì
• bạn cố ý không thay đổi những gì
• có rủi ro nào cần lưu ý

Một mô tả rõ ràng giúp reviewer hiểu nhanh hơn và giảm thời gian review.

Kết luận

Vai trò của một senior software engineer không chỉ là viết code.

Họ còn là người:

• làm rõ requirement
• giao tiếp hiệu quả
• giữ cho hệ thống đơn giản
• bảo vệ chất lượng codebase

Trong thời đại của AI và agentic coding, vai trò này càng trở nên quan trọng. Khi máy móc có thể viết code nhanh hơn con người, giá trị của developer nằm ở khả năng tư duy, thiết kế và kiểm soát hệ thống.

Nếu phải tóm tắt triết lý này trong một câu, có lẽ đó là:

Hãy viết code đơn giản đến mức người khác có thể hiểu ngay, và làm việc có kỷ luật để hệ thống luôn đáng tin cậy.