My Engineering Notes for 2026

Cách đây 15 năm, khi bắt đầu kiếm tiền với nghề lập trình, chưa bao giờ tôi nghĩ nghề mà mình chọn sẽ có ngày hôm nay. Thật khó nếu phải dự đoán tương lai của 2-3 năm tới, những suy nghĩ này là viết cho chính bản thân tôi và cũng là để sau này nhìn lại. Có thể đúng, có thể sai nhưng tôi hy vọng nó có thể giúp ích cho bạn trên con đường nghề nghiệp đang gặp nhiều thử thách.

Part 01 · Things to Agree

I can always be wrong.

1.1 Agentic engineering aims for human on the loop

"Agent tự chạy, tự sửa, tự verify. Nhưng quyết định cái gì và chịu trách nhiệm cho cái gì vẫn là của engineer."

Agentic engineering là build software với coding agent: một LLM có tools, chạy trong loop, tự viết code, tự execute, đọc kết quả rồi tự sửa cho tới khi đạt goal. Điểm khác biệt nằm ở chữ autonomous. Agent không chờ mình gõ từng dòng, nó tự đi một đoạn đường khá dài.

Vì vậy vai trò của mình chuyển từ in the loop, làm từng bước, sang on the loop: đứng trên loop, đặt hướng, quan sát, và can thiệp khi cần.

Những gì vẫn do human quyết định: build cái gì và không build cái gì, trade-off giữa các solution, chọn hướng phù hợp với context của team, và thế nào là "done", thế nào là "đủ tốt để lên production".

Những gì engineering vẫn own: code chạy trên production, kể cả khi agent viết 100%. Incident lúc 2 giờ sáng, vì agent không on-call thay mình. Và quality bar, standard của cả team.

Thị trường sẽ liên tục mang tới term mới: agent loop, agent graph, prompt engineering, context engineering, harness… Mấy cái đó thay đổi cách mình làm, nhưng không thay đổi ai chịu trách nhiệm.

1.2 The effort of writing code is cheap, but good code is still very expensive

"Viết code giờ rẻ. Code tốt thì vẫn đắt, và cái giá đó giờ nằm ở taste của người cầm lái."

Coding agent viết code giỏi, ở tốc độ mà không SE nào, thậm chí không team SE nào theo kịp. Nhưng điều khiển như thế nào để ra được một system tốt vẫn cần taste của người giỏi nghề.

Các metrics cũ đang dần hết tác dụng: LoC, số lượng release, số feature. Những con số này ngày trước còn tạm dùng để nhìn ra team mạnh hay yếu. Ngày nay thì ai cũng có thể ship phần mềm, và lại còn ship rất nhanh.

"Good" của ngày xưa là: software chạy được thôi chưa đủ. Nào là design đúng, dùng resource hiệu quả, maintainability… Phần lớn những bài học đó không đến từ sách, mà đến từ build thing, break thing, và những lần postmortem sau incident.

"Good" của hôm nay: code không chỉ cần executed, mà còn phải được understood, team hiểu nó chạy thế nào và tại sao. Phải được controlled, biết nó đang làm gì, có test, có evidence, có đường rollback. Và phải được owned, có người đứng tên và chịu trách nhiệm.

Code chạy được mà không ai hiểu thì không phải asset. Đó là liability đang chờ ngày phát nổ.

1.3 A new kind of Hello World, an unclear learning path

"Cách học đã thay đổi. Nhưng mình chưa chắc con đường mới có lặp lại được cho tất cả mọi người."

Bài học đầu tiên khi học một language hay framework mới thường là Hello World. Hôm nay, cách pragmatic hơn là đưa instruction cho agent, để nó build, rồi tự challenge bản thân để drill sâu vào knowledge từ chính cái agent vừa làm ra.

Nghe thì hiệu quả, nhưng mình chưa chắc đây là một learning path repeatable cho mọi người.

Ví dụ: đưa cho một bạn junior bài toán N+1 query. Với agent, bạn ấy fix được, test pass, PR đẹp. Nhưng bạn ấy có thật sự hiểu design decision nào đã dẫn tới N+1 ngay từ đầu? ORM đang generate query gì bên dưới? Database xử lý join, index, connection pool ra sao? Khi nào nên eager load, khi nào nên denormalize, khi nào nên cache?

Solve được mà không hiểu implication: đó là khoảng trống mà mình chưa có câu trả lời rõ ràng. Mentor, senior, và chính người học cần ý thức được điều này.

1.4 AI helps us bring good code, fast

"Trong tay đúng người, AI giúp ship code tốt nhanh hơn. Trong tay sai người, nó ship code tệ… cũng nhanh hơn."

Đặt vào đúng tay, team SE giờ có thể kill tech debt trước khi nó compound: rename, refactor, tách file 3000 dòng, merge các feature gần giống nhau. Những việc dễ nhưng chán, trước đây không bao giờ được prioritize nay có thể hành AI cho bỏ ghét.

Team cũng có thể deliver code tốt mà không còn sợ bị gọi là overengineering chỉ vì effort có hạn: test đầy đủ, error handling rõ ràng, docs được cập nhật. Và thử được nhiều option hơn, prototype 2–3 hướng rồi so sánh bằng evidence thay vì cảm tính.

Nhưng AI cũng amplify cái xấu. Ship code còn tệ hơn trước, trong khi system nhìn thì stunning: UI đẹp, demo mượt, happy case chạy hoàn hảo. Còn edge case, error path, concurrency, security… thì chưa ai kiểm tra.

AI amplify và speed up everything, tốt và cả xấu.

1.5 Nothing is always right, and nothing never changes

"Có pattern, có anti-pattern, nhưng không có one-size-fits-all."

Mọi thứ trong notes này là những gì mình thấy đúng tại thời điểm viết. Mỗi team, mỗi system, mỗi context cần decision riêng. Và AI thay đổi rất nhanh: một practice đúng hôm nay có thể lỗi thời sau một đêm, khi model mới ra hay tool mới xuất hiện.

✎ Cẩn thận với sự tự tin

Agent cũng sai, như một senior thỉnh thoảng vẫn sai. Khác ở chỗ PR message của nó lúc nào cũng rất convincing: rõ ràng, tự tin, có cấu trúc. Đừng để sự tự tin đó thay cho việc review.

Part 02 · Working with coding agents

Plan more, prompt less.

2.1 Plan your execution

"Agent chạy rất nhanh. Chạy nhanh mà sai hướng thì lại dễ đến đích. Còn sau đó thì không biết..."

Với agent, phần "làm" giờ rẻ. Phần nghĩ trước khi làm thì không. Bỏ thời gian upfront ở những chỗ mà sau này sửa lại sẽ rất đau.

Design những thứ mình không muốn hối hận. Let agent do the works có thể đúng cho các loại ứng dụng đơn giản, nhưng nếu bạn dễ dãi với kiến trúc thì hãy chuẩn bị sẵn tinh thần đập đi làm lại. Quá trình xây càng nhanh thì quá trình làm móng lại càng cần cẩn trọng và chính xác.

Plan cách maintain requirement. Requirement không nên nằm rải rác trong mọi nơi rồi mình kiếm một cái unify graph magic nào đó. Biến nó thành spec: có version, có owner, update được. Còn các rule và practice chung của team thì đặt vào đúng file md. Rule cho cả repo, rule cho từng module, và knowledge chỉ cần khi làm một loại task cụ thể nên nằm ở những chỗ khác nhau.

Plan cách đưa context tốt nhất cho agent. Đừng chỉ dặn "có gì chưa rõ thì hỏi tôi". Hãy chủ động chuẩn bị những gì nó cần: spec, file liên quan, code mẫu, constraint, definition of done. Agent hỏi lại là tín hiệu context mình đưa còn thiếu, và có thể mình chưa nghĩ đến tình huống đó.

Plan cách evaluate. Trước khi agent bắt đầu, mình phải trả lời được: làm sao biết nó làm đúng, và không phải chỉ là chạy đúng? Không có tiêu chí evaluate thì "done" chỉ là cảm giác.

Test với task nhỏ trước. Đừng giao ngay một epic. Thử một task nhỏ, xem agent hiểu structure tới đâu, context đã đủ chưa, cách evaluate có hoạt động không. Rồi mới scale lên.

2.2 Prepare a good codebase structure

"Agent đọc repo của mình như một người mới vào team. Repo rối thì người mới cũng rối, chỉ có điều agent sẽ tìm mọi cách để làm."

Dù AI code mạnh tới đâu, mạnh tới mức start from scratch chỉ với một câu lệnh rất đơn giản, agentic coding vẫn cần một cấu trúc source code mạch lạc. Cấu trúc đó không nên đến từ template trên mạng, mà nên được xây từ kinh nghiệm dự án thật, và cập nhật theo sự tiến bộ của các công cụ AI coding.

Cấu trúc sạch, phân cấp tốt giúp agent đọc đúng hơn, sửa đúng chỗ hơn, ít lãng phí token đi tìm code, và ít lệch khỏi kiến trúc đã chọn. Cấu trúc đó cũng giúp con người theo kịp khối lượng code khi cần nhảy vào loop (human in the loop). Và nó tăng sự tự tin để ship lên production, kể cả khi PR được tạo hoàn toàn tự động.

Cấu trúc tốt còn là một cách để người khác đọc hiểu cách bạn đang tổ chức để agent làm việc trên dự án. Người mới vào team, hay chính mình sáu tháng sau, nhìn vào là biết agent được dẫn dắt như thế nào.

2.3 Evaluate & improve your harness

"Harness tốt là harness giúp system chạy tốt hơn, không phải harness nhìn ấn tượng hơn."

"Harness" là mọi thứ bọc quanh agent: file md, rules, prompts, tools, scripts, workflow. Nó cần được cải thiện liên tục, nhưng phải có chọn lọc.

Sau mỗi task hay mỗi sprint, hãy nhìn lại xem agent làm tốt ở đâu và nhờ cái gì. Chỗ nào nó sai thì do thiếu context, do rule mơ hồ, hay đơn giản là model chưa đủ sức. Những chỗ mình phải sửa tay lặp đi lặp lại chính là nơi harness cần thay đổi.

Cái bẫy phổ biến nhất là gặp lỗi nào cũng nhét thêm một dòng vào file md. Vài tháng sau file dài 2000 dòng, các rule mâu thuẫn nhau, agent đọc xong còn rối hơn trước. Mỗi rule thêm vào phải trả lời được nó fix vấn đề gì và còn cần thiết không. Rule hết giá trị thì xóa.

✎ Đừng nhầm đích đến

Mục tiêu là đưa system cuối cùng lên production với quality và speed, không phải build một harness thật hoành tráng để đi khoe hay đem đi bán. Khách hàng không dùng file AGENTS.md của mình, họ dùng sản phẩm.

2.4 Invest in domain, go deep

"Agent có thể học nhanh làm nhanh, còn bạn có chịu đi học domain business không lại là việc khác."

Từ trước khi có agentic coding, mình đã nói nhiều về domain: Domain-Driven Design, bounded context, ubiquitous language. Nhưng ít team thật sự đầu tư sâu. Lý do quen thuộc là technology thay đổi liên tục, và engineering tốn quá nhiều thời gian cho coding, testing, shipping, nên không còn thời gian cho domain.

Bây giờ thì không còn lý do đó. Agent có thể gánh phần lớn effort viết code, test và ship. Thời gian và công sức tiết kiệm được nên dành cho việc hiểu domain thật sâu: business rule, edge case của nghiệp vụ, ngôn ngữ mà người dùng thật sự nói.

Và đây chính là chỗ tạo ra khác biệt về taste trong agentic coding. Hai team cùng dùng một model, cùng một tool. Team nào hiểu domain sâu hơn thì đưa context tốt hơn, đặt câu hỏi đúng hơn, và nhận ra ngay khi agent hiểu sai nghiệp vụ.

✎ Lợi thế không copy được

Framework, pattern, prompt đều có thể copy. Hiểu biết sâu về domain của chính mình thì không. Đó là thứ còn lại khi ai cũng có agent giỏi như nhau.

2.5 Avoid super-mega agents that try to solve everything

"Một agent biết làm mọi thứ sẽ không xuất sắc nhất trong một việc cụ thể."

Cám dỗ rất lớn là build một agent "siêu cấp": system prompt khổng lồ, đủ tools, đủ rules, sẵn sàng cho mọi tình huống. Mình không nghĩ đó là hướng đúng.

Thứ nhất, coding agent tốt lên từng ngày. Những gì hôm nay phải dặn kỹ trong prompt thì vài tháng sau model đã tự biết, nên đầu tư quá nhiều dễ thành công sức bỏ đi.

Thứ hai, làm software không cần chuẩn bị cho mọi tình huống cùng lúc. Nhồi mọi thứ vào context làm agent chậm hơn, tốn hơn, và dễ bị nhiễu bởi những rule không liên quan tới task đang làm.

Mình tin một agent tập trung vào một feature cụ thể, với context vừa đủ và instruction rõ ràng, sẽ luôn làm tốt hơn một agent "cái gì cũng làm được".

✎ Nghĩ như chia team

Mình không tuyển một người làm tất cả. Mình chia team theo domain, mỗi người có context riêng. Agent cũng vậy: sâu, rõ trách nhiệm, đúng context, đủ tiêu chí.

Part 03 · About Verification

Chạy được chưa phải là đủ và cũng chưa chắc đúng.

3.1 Automated tests everywhere

"Automation test là thứ duy nhất giúp theo kịp tốc độ của agent."

Automated test không còn là optional. Rào cản ngày xưa là viết test tốn thời gian, maintain test còn tốn hơn mỗi lần code thay đổi. Hôm nay rào cản đó gần như không còn, vì agent viết và update test chỉ trong vài phút.

Viết test trước khi build cái mới giúp agent hiểu đúng độ phức tạp của bài toán ngay từ đầu. Ngược lại, khi test được viết sau implementation, agent rất dễ "hallucinate" phần evaluation: test được viết để khớp với code nó vừa viết, chứ không phải để kiểm tra code đó có đúng không.

Với tốc độ tạo ra code như hiện nay, automated test là thứ cho mình sự tự tin về system về sau, mỗi khi thay đổi, refactor hay upgrade. Không có test thì mỗi lần agent sửa code là một lần đánh cược.

3.2 Red/green TDD

"Test fail trước, rồi mới xanh. Một test chưa từng đỏ thì chưa chứng minh được gì."

Red/green TDD rất đơn giản: viết test trước, chạy để thấy nó fail (red), rồi mới để agent implement cho tới khi pass (green). Chỉ cần dặn agent "use red/green TDD" là đủ, model hiện tại hiểu rõ quy trình này.

Giá trị thật của nó không chỉ nằm ở code. Khi phải nghĩ test case trước, người on the loop buộc phải hiểu bài toán sâu hơn: edge case nào, input nào nguy hiểm, behavior nào là đúng. Quá trình đó đào sâu expertise của chính mình, thay vì giao hết cho agent.

Và output tốt đến đâu phụ thuộc vào test case tốt đến đâu. Càng nhiều case đúng, khi test chuyển sang xanh mình càng tin được kết quả.

3.3 Active red & quality team

"Hãy tấn công system của mình trước khi người khác làm điều đó."

Ngày trước, muốn có một red team, nghĩa là một nhóm chuyên đi tìm cách phá system, thì phải thuê, và chi phí không nhỏ. Bây giờ mình có thể để agent đóng vai đó: tìm lỗ hổng, thử input độc hại, phá các flow quan trọng, rồi fix trước khi có ai đó với ý đồ xấu tìm ra.

Không chỉ security. Agent còn có thể làm manual testing: tự dùng thử app như một user thật, gọi API, click qua UI, chụp screenshot, ghi lại evidence. Test pass chưa chắc app chạy đúng, và agent có thể tìm ra những chỗ mà automated test bỏ sót.

Mình tin agentic manual testing và agentic security sẽ sớm trở thành standard của một sản phẩm tốt, chứ không còn là thứ "nice to have".

✎ Security là một domain

Red team bằng agent không có nghĩa là mọi kĩ sư đều là chuyên gia bảo mật. Cũng không có hệ thống nào là luôn hoàn hảo.

Part 04 · Learn the code for verified understanding

Hiểu được thì mới own được.

4.1 Learn the code after the system works

"System chạy được rồi mới là lúc bắt đầu học, không phải lúc kết thúc."

Với agent, chuyện system chạy trước khi mình hiểu hết code bên trong là bình thường. Nhưng đó không nên là điểm dừng. Code chạy mà không ai hiểu là cognitive debt, và món nợ này cũng có lãi như tech debt.

Cách mình hay làm: nhờ agent viết một bản walkthrough cho từng feature cụ thể, đi từ entry point, qua từng tầng, tới chỗ data được lưu. Điều quan trọng nhất là yêu cầu agent lấy code snippet từ file thật bằng grep hay sed, không để nó gõ lại theo trí nhớ. Code trong walkthrough phải là code đang chạy trên production, không phải phiên bản agent "tưởng tượng" ra.

Giá trị của walkthrough không nằm ở chỗ biết code làm gì, mà ở chỗ hỏi được tại sao lại là code này, và tại sao không phải cách khác. Mỗi lần đọc là một cơ hội học: design decision nào đã được chọn, trade-off nào đã bị bỏ qua, chỗ nào mình sẽ làm khác nếu được làm lại.

4.2 Manual coding can become a hobby

"Có những thứ mình làm không phải vì nó nhanh hơn, mà vì nó nhắc mình về những ngày xưa cũ của engineer."

Một thứ mình nhớ của "the good old time" là debugging.

Cái cảm giác bị kẹt cả buổi chiều với một con bug. Đặt breakpoint, đọc log, thêm print khắp nơi, tự đặt giả thuyết rồi tự bác bỏ. Cảm giác đó giờ có chút vintage, như nghe lại một đĩa nhạc cũ.

Agent giúp mình đi rất nhanh, nhưng nhịp độ đó cũng có giá. Lúc nào cũng prompt, review, merge, prompt tiếp, đầu óc gần như không có lúc nào dừng lại. Ngồi tự tay debug một con bug, không vội, không agent, lại là một cách để cool down: chậm lại, nghĩ sâu, và nhớ ra tại sao ngày xưa mình chọn nghề này.

Mình không muốn tranh cãi hay cố gắng bám víu mà là đôi khi tự pha cà phê thủ công dù phần lớn được máy pha tự động làm ra chính xác hơn.

✎ Giữ cho tay quen

Thỉnh thoảng hãy chọn một con bug nhỏ và tự giải nó. Không phải vì agent không làm được, mà vì đó là một chút vintage của nghề.

Part 05 · Things start changing

Based on my wondering thoughts.

5.1 Comments

"Comment từng được viết cho người đọc code. Nhưng giờ người đọc code nhiều nhất lại không phải là người."

Những thứ ngày xưa viết ra cho con người đọc đang dần ít liên quan hơn trong agentic engineering, và comment là một ví dụ rõ nhất.

Với agent, comment không phải lúc nào cũng giúp nó hiểu code tốt hơn. Comment cũ, comment sai, hay comment mô tả lại những gì code đã nói rõ đều là noise trong context. Nặng hơn, một comment đã lỗi thời so với code bên dưới có thể dắt agent đi sai hướng. Code nói một đằng, comment nói một nẻo, và agent rất dễ tin vào phần được viết bằng ngôn ngữ tự nhiên.

Còn với con người, bài toán là volume. Agent sinh code với khối lượng mà không ai đọc hết được. Dù có dặn agent comment "như người viết", số lượng comment đó cũng không giúp mình đọc nổi. Comment đặt cạnh từng dòng code đã không còn là cách hiệu quả để hiểu một system lớn lên nhanh như vậy.

Nguyên tắc cũ "good comment explains why, not how" vẫn đúng. Nhưng có lẽ đã đến lúc tách bài toán ra làm hai.

Cho con người, thứ mình cần có lẽ không phải comment nằm cạnh dòng code, mà là một file riêng: walkthrough, guide, câu chuyện đằng sau một feature, đọc từ đầu tới cuối như đọc một tài liệu. Đây cũng chính là tinh thần của phần Learn the code after the system works.

Cho agent, thứ nó cần có lẽ cũng không phải comment, mà là một dạng memory: những gì đã học, đã quyết định, đã vấp phải ở đoạn code này, được kích hoạt lại đúng lúc agent quay lại làm việc với nó. Không phải lúc nào cũng nằm sẵn trong file, mà xuất hiện khi thật sự cần.

✎ Mình chưa có câu trả lời

Đây là một trong những chỗ mình còn đang nghĩ. Comment có thể chưa chết, nhưng vai trò của nó chắc chắn đang thay đổi. Câu hỏi lớn hơn là knowledge về code nên sống ở đâu, khi người đọc không còn chỉ là con người?

5.2 The way we patch

"Ngày xưa, patch chậm là rủi ro. Giờ, patch quá nhanh cũng là rủi ro."

Ngày trước, mình luôn nhấn mạnh việc patch đều đặn: có version mới là update, càng sớm càng tốt, vì mỗi ngày chậm trễ là thêm một ngày exposed với lỗ hổng đã được công bố.

Nhưng supply chain attack đã làm câu chuyện đổi chiều. Khi chính package được publish lên registry là thứ bị nhiễm độc, người update sớm nhất lại là người dính đầu tiên. Đôi khi chỉ cần chậm lại vài ngày, để cộng đồng kịp phát hiện có gì bất thường, là mình đã tránh được cả một đợt rotate mọi secret, mọi credential, và kiểm tra lại toàn bộ hệ thống. Không phải lười patch, mà là có chủ đích để thời gian làm lớp kiểm chứng đầu tiên. Nhiều tool quản lý dependency giờ cũng đã có sẵn setting kiểu cooldown hay minimum release age cho đúng mục đích này.

Ngày trước, khi lên version một library, maintainer gần như chỉ biết dựa vào automated test để verify. Đó là may mắn của những project mà team trước còn để lại test. Lý do gốc rễ là khối lượng code thay đổi giữa hai version quá lớn, và một con người không thể đọc hết, hiểu hết. Nên mình chấp nhận nhận về tất cả, rồi tin vào changelog và hy vọng test bắt được lỗi.

Trong thời AI, mình có lựa chọn khác. Mình có thể chỉ patch đúng những dòng mình cần, ví dụ đúng đoạn fix lỗ hổng, thay vì kéo về cả version mới với hàng nghìn dòng thay đổi không liên quan. Ít code mới đi vào hệ thống thì bề mặt tấn công cũng nhỏ hơn. Và lần đầu tiên, có ai đó (agent) thực sự đọc code changes.

✎ Patch tay thì phải nuôi

Khi tự patch từng dòng, mình đang giữ một bản fork nhỏ của library đó. Hãy ghi lại mình đã lấy gì, từ commit nào của upstream, và lý do.

5.3 Stack selection

"Ngày trước mình chọn stack mà team biết. Giờ mình bắt đầu chọn stack tốt nhất cho bài toán."

Tại thời điểm viết những dòng này, nhiều dự án đang port sang Rust vì quản lý memory vượt trội và những lợi thế về bảo mật. Rào cản về ngôn ngữ, thứ từng khiến một team phải cân nhắc rất lâu trước khi đổi stack, đang dần phai nhòa.

Trước đây, lựa chọn công nghệ bị ràng buộc rất nhiều bởi năng lực đội ngũ: team giỏi Java thì viết Java, team quen Node thì dùng Node, dù bài toán có thể hợp với thứ khác hơn. Giờ đây đang có một làn sóng chọn công nghệ tốt nhất cho bài toán, vì AI có thể bù vào giới hạn của con người.

✎ Viết được chưa chắc đã own được

Agent viết Rust giỏi không có nghĩa team mình review, debug và vận hành Rust giỏi. Khi chọn stack mới, hãy sẵn sàng cho các kế hoạch vận hành, nâng cấp và có thể là học ngôn ngữ ở một timeline nào đó ?

5.4 Speed of experiment

"Khi code không còn đắt, câu hỏi không còn là 'build thế nào', mà là 'build cái nào'."

Ngày trước, các nguyên tắc thiết kế phần mềm, từ YAGNI (You Aren't Gonna Need It), KISS (Keep It Simple, Stupid) tới Deferred Decision-Making, đều được xây trên một thực tế kinh tế: code đắt để viết, đắt để refactor, và cực kỳ đắt để vứt đi. Khi quyết định kiến trúc khó đảo ngược, trì hoãn quyết định là cách giảm rủi ro tốt nhất.

Agentic coding phá vỡ nút thắt đó. Build feature không còn là bottleneck. Constraint lớn nhất của phát triển phần mềm đang dịch chuyển từ tốc độ engineering sang tốc độ thử nghiệm sản phẩm.

Vậy hãy test mọi giả thuyết bằng cách build ra các phiên bản khác nhau và đánh giá bằng thực tế, thay vì tranh luận trên slide. Fail fast có lẽ lần đầu tiên thật sự dễ và thực tế, miễn là tránh được spaghetti codebase và AI slop.

2026 là thế, hẹn gặp lại mọi người ở cuối năm 2027.