Đã đăng vào Thứ Ba, 7:28 SA 54 phút đọc

7 task AI vẫn làm cực tệ năm 2026

MayFest2026

Bài viết của một developer đã dùng AI đủ lâu để hết ảo tưởng – và vẫn đang dùng AI mỗi ngày.

Tháng trước mình có một buổi demo nội bộ khá vui. PM hỏi: "Anh dùng AI nhiều thế, giờ developer mình còn cần làm gì nữa?"

Mình trả lời thật: "Còn làm hầu hết mọi thứ quan trọng."

Không phải để tự vỗ ngực. Mà vì sau gần hai năm dùng Cursor, Claude, Codex, Grok – mỗi ngày, không bỏ ngày nào – mình nhận ra một pattern rõ ràng: AI giỏi thật, nhưng nó giỏi sai chỗ mình hay cần nhất.

Nó generate boilerplate nhanh như gió. Nó giải thích regex trong 3 giây. Nó viết unit test cho happy path cực ngon. Những thứ đó tiết kiệm cho mình có khi 2-3 tiếng mỗi ngày, mình không phủ nhận.

Nhưng mỗi lần mình gặp task thực sự khó – kiểu task mà career của dev được đánh giá qua đó – thì AI bắt đầu... bết. Không phải hỏng hoàn toàn. Mà kiểu nó vẫn trả lời, vẫn trông có vẻ đúng, nhưng output thì không dùng được trong thực tế. Và điều đó đôi khi còn nguy hiểm hơn là nó từ chối trả lời.

Bài này mình viết từ kinh nghiệm thực chiến. Không phải lý thuyết, không phải benchmark, không phải đọc paper rồi tổng hợp lại. Là những lần mình ngồi chờ AI, đọc output của nó, rồi nhận ra mình vẫn phải tự nghĩ.

Task 1: Hiểu và làm rõ yêu cầu mơ hồ

Đây là task mà mình tốn nhiều thời gian nhất trong công việc, và cũng là task AI tệ một cách... có hệ thống.

Vấn đề cụ thể là gì

Hồi tháng 3, mình nhận ticket từ business: "Cần tối ưu luồng thanh toán để tăng conversion."

Câu đó có thể nghĩa là mười thứ khác nhau. Giảm số bước checkout? Thêm payment method? Fix bug nào đó đang gây drop-off? Hay đơn giản là PM muốn mình làm gì đó để có cái báo cáo lên C-level?

Mình thử hỏi Claude: "Tôi nhận yêu cầu này, cần làm gì để làm rõ requirement?"

Claude đưa ra một danh sách đẹp lắm:

Hỏi về KPI mục tiêu cụ thể
Xác định baseline conversion rate hiện tại
Clarify scope (mobile/web/cả hai?)
Hỏi về timeline và budget constraint

Ừ, đúng. Nhưng mà... mình cũng biết vậy. Cái mình cần không phải danh sách câu hỏi chuẩn chỉnh. Cái mình cần là hiểu được context chính trị đằng sau cái ticket đó.

Tại sao PM viết câu đó? Áp lực từ đâu? CEO vừa xem report chuyển đổi và nổi giận, hay đây chỉ là wishlist của một buổi brainstorm? Nếu mình hỏi quá nhiều câu, PM có cảm thấy mình đang delay không? Cái nào trong số mười nghĩa đó là thứ họ thực sự muốn?

AI không có context đó. Nó không biết lịch sử làm việc giữa mình và PM. Nó không biết tuần trước hai người vừa cãi nhau về estimate. Nó không biết cái ticket được tạo vào 9 giờ tối thứ Sáu nghĩa là gì.

Tại sao AI tệ ở đây

Yêu cầu mơ hồ không phải vấn đề kỹ thuật. Nó là vấn đề xã hội. Nó cần bạn đọc giữa dòng chữ, hiểu dynamics của tổ chức, đoán được intent thật sự của người viết.

AI được train trên text. Nó rất giỏi xử lý những gì được viết ra. Nhưng phần quan trọng nhất của requirement mơ hồ lại nằm ở phần không được viết ra.

Thêm nữa, AI có xu hướng interpret requirement theo hướng technical nhất có thể. Mình thử paste cái ticket vào và hỏi "đây có nghĩa là gì?" – nó immediately đi vào "có thể implement theo cách A, B, hoặc C." Trong khi cái mình cần đầu tiên là hiểu tại sao người ta muốn cái đó.

Một ví dụ khác đau hơn

Project gần đây, client gửi spec document 30 trang. Mình đưa cho Claude, hỏi: "Document này có mâu thuẫn nào không?"

Claude tìm được 3-4 chỗ về mặt kỹ thuật: section 2.3 nói response time < 200ms nhưng section 4.1 yêu cầu process realtime video stream, hai cái này conflict.

Đúng. Nhưng mình tự đọc cũng thấy mấy cái đó. Cái mình không thấy – và AI cũng không thấy – là cái mâu thuẫn ẩn: client muốn system "dễ dùng cho người không tech" nhưng lại specify UI flow phức tạp đến mức developer còn phải đọc hai lần mới hiểu. Đây không phải mâu thuẫn kỹ thuật mà là mâu thuẫn về mental model của chính client. Và cái đó, Claude hoàn toàn bỏ qua.

Một pattern khác mình hay thấy: AI over-specify requirement mơ hồ

Cái này nguy hiểm hơn là AI không trả lời được. Khi requirement mơ hồ, AI thỉnh thoảng tự điền vào chỗ trống bằng assumption của nó – và trình bày như thể đó là điều đương nhiên.

Ví dụ: mình paste cái ticket "tối ưu luồng thanh toán" vào Claude và hỏi "implement như thế nào?" thay vì hỏi "requirement này nghĩa là gì?" – Claude sẽ immediately đi vào viết code, với assumption rằng "tối ưu" nghĩa là giảm số bước checkout. Reasonable assumption, nhưng có thể sai.

Và điều tệ hơn: code nhìn có vẻ đúng, chạy được, pass test. Bạn demo. PM nhìn vào và nói: "Ừ cũng hay nhưng không phải thứ tôi muốn." Lúc đó mới biết "tối ưu" của PM là thêm wallet payment method, không phải giảm bước.

2 ngày công down the drain.

Cái AI không hiểu: requirement là cuộc đàm phán

Một developer senior giỏi không chỉ clarify requirement – họ shape requirement. Họ push back khi requirement không realistic, suggest alternative khi requirement có technical constraint, và negotiate scope dựa trên effort vs value.

Đây là kỹ năng hoàn toàn khác với "hiểu requirement." Và AI không có đủ context về business, về stakeholder, về technical constraint thực tế để làm được điều đó.

Mình hay thấy junior dev dùng AI để "hiểu requirement" và cảm thấy tự tin vì AI đã explain rất rõ ràng. Rồi build một thứ technically correct nhưng không phải thứ business cần. Đây là anti-pattern cần cảnh báo.

Cách mình xử lý hiện tại

Mình dùng AI như bước đầu để scan lỗi kỹ thuật obvious. Sau đó tự ngồi với requirement và hỏi: "Nếu mình là người viết cái này, mình đang lo ngại điều gì?" Câu đó AI không trả lời được, phải tự ngồi nghĩ.

Một habit mình develop: viết ra "what I think this means" trước khi hỏi AI. Cái đó force mình phải articulate assumption của mình, và khi share với stakeholder thì thường họ correct mình ở những điểm quan trọng. AI không trigger được cái exercise đó một cách tự nhiên.

Còn một thứ nữa: reading the room khi họp requirement. Khi PM giải thích feature mà giọng nghe có vẻ defensive, hoặc khi họ skip qua một phần rất nhanh, hay khi có người im lặng ở góc phòng sau khi một yêu cầu được nêu – những signal đó quan trọng hơn nhiều text trong document. AI không ở trong phòng đó.

Task 2: Ước lượng effort và thời gian thực tế

Đây là thứ mình đã thử nhiều lần và fail thảm nhiều lần nhất.

Câu chuyện cụ thể

Sprint planning tháng Tư. Mình có feature mới: integrate với third-party payment gateway, support retry logic, logging, và notify user khi transaction fail.

Mình thử hỏi Claude để cross-check estimate của mình: "Feature này cần bao lâu để implement?"

Claude đưa ra breakdown đẹp:

API integration: 1-2 ngày
Retry logic: 0.5 ngày
Logging: 0.5 ngày
Notification: 0.5 ngày
Testing: 1 ngày
Tổng: 3.5-4.5 ngày

Mình estimate là 8-10 ngày.

Ai đúng? Mình đúng. Và không phải vì mình giỏi hơn AI. Mà vì mình biết những thứ AI không biết:

Payment gateway cụ thể đó có API doc không update từ 2022, mình sẽ mất ít nhất 1 ngày chỉ để đọc và test thử
Codebase của công ty có một abstraction layer kỳ lạ mà bất kỳ integration mới nào cũng phải đi qua – thêm 1 ngày để hiểu
QA team của mình cần environment riêng để test payment, setup cái đó thêm 0.5 ngày
Luôn luôn có ít nhất một surprise với payment – lần trước là 3DS flow không document đầy đủ
Code review với senior sẽ có comment, sửa đi sửa lại thêm 1-2 ngày

AI estimate trên lý thuyết. Developer estimate trên thực tế.

Tại sao AI không estimate được chính xác

Có mấy lý do chính:

Thứ nhất, AI không biết technical debt của bạn. Codebase 5 năm tuổi với kiến trúc được viết trước khi microservice là trend khác hoàn toàn với greenfield project. AI không biết bạn đang build trên foundation nào.

Thứ hai, AI không biết team của bạn. Junior hay senior? Onboarded chưa? Đang focused hay đang split giữa 3 project? Tất cả những cái đó ảnh hưởng lớn đến estimate thực tế.

Thứ ba, AI estimate happy path. Nó tính công việc khi mọi thứ diễn ra như kế hoạch. Nhưng trong thực tế: staging environment down, dependency có breaking change, requirement thay đổi giữa sprint, người review có câu hỏi cần 2 ngày để clarify. AI không tính những cái đó.

Thứ tư, AI không biết unknown unknowns. Những cái bạn không biết là bạn không biết. Những bất ngờ thật sự. Và đây là thứ ăn hết buffer của mọi estimate.

Mình đã thử dạy AI estimate bằng cách nào

Mình thử cung cấp context đầy đủ hơn: paste cả architecture overview, describe technical debt, nói team size và seniority level. Estimate của Claude tốt hơn một chút – nhưng vẫn thiếu. Nó vẫn không catch được những thứ kiểu "thư viện này có bug tiếng tăm với PostgreSQL version chúng tôi đang dùng."

Mình nghĩ về mặt lý thuyết, nếu bạn cung cấp đủ context (toàn bộ codebase, toàn bộ lịch sử của team, toàn bộ technical debt inventory), AI có thể estimate tốt hơn. Nhưng cái đó không thực tế – cái bạn cần biết để provide đủ context thì bạn cũng đã đủ kiến thức để tự estimate rồi.

Estimation bias mà AI không biết là tồn tại

Có một loại bias trong estimation mà ngay cả developer giỏi cũng mắc, và AI hoàn toàn ignore: planning fallacy. Người ta consistently underestimate time cần thiết cho task của mình trong khi estimate khá chính xác cho task của người khác. Đây là cognitive bias được document kỹ, nhưng AI khi estimate cũng bị ảnh hưởng tương tự – nó estimate theo "một developer lý thuyết tối ưu," không phải theo "bạn, với codebase cụ thể của bạn, với mức energy cụ thể của bạn hôm nay."

Còn một điều nữa: interruption cost. Trong một ngày làm việc thực tế với meeting, Slack, email, câu hỏi từ đồng nghiệp, mình thường có khoảng 4-5 tiếng focused coding time, không phải 8 tiếng. AI estimate theo 8 tiếng. Kết quả: task "2 ngày" của AI thành "4 ngày" thực tế.

Và cái nguy hiểm nhất: integration tax. Khi feature hoàn chỉnh, bạn cần integrate nó với phần còn lại của hệ thống. Chạy full regression test. Fix conflict merge. Deploy lên staging. Get approval. Deploy production. Monitor. Document. AI tính thời gian viết code, không tính integration tax – thường là 30-50% thêm.

Sprint burndown thật sự của mình

Mình có habit track estimate vs actual trong mỗi sprint. Sau 6 tháng với 12 sprint, mình có data:

Khi mình estimate một mình: trung bình actual là 1.4x estimate (underestimate 40%)
Khi mình dùng AI để "sanity check" estimate: actual là 1.5x estimate (underestimate 50%)
Khi mình dùng historical data của chính mình để adjust: actual là 1.1x estimate

Kết quả: AI làm estimate của mình tệ hơn, không tốt hơn. Vì nó lôi mình về hướng lạc quan hơn.

Cách mình dùng AI cho estimation

Thay vì hỏi "mất bao lâu?" mình hỏi "tôi đang thiếu gì trong estimate này?" Sau đó describe estimate của mình và reasoning. AI khá tốt ở việc point out những góc mình bỏ sót (ví dụ: "bạn có tính thời gian update documentation không?"). Nó làm được vai trò checklist hơn là estimator.

Một prompt mình thấy effective nhất:

"Estimate của tôi cho task X là Y ngày. Tôi đã tính: [list]. Tôi đang làm việc với codebase [mô tả ngắn]. Hãy chỉ ra những thứ TÔI ĐÃ KHÔNG ĐỀ CẬP mà có thể ảnh hưởng đến estimate. Không đưa ra estimate mới."

Cái đó tốt hơn nhiều vì nó force AI vào role checklist thay vì role estimator.

Task 3: Thiết kế Architecture Production-grade

Đây là task mà AI nguy hiểm nhất – vì output của nó trông rất thuyết phục.

Ví dụ từ năm ngoái

Mình cần thiết kế architecture cho hệ thống xử lý event, scale lên tầm vài triệu event mỗi ngày. Mình hỏi Claude với đủ context: traffic pattern, budget constraint, team size (4 backend dev), existing stack (AWS, PostgreSQL, Redis).

Claude đưa ra một architecture đẹp:

API Gateway → Lambda → Kinesis → Lambda processors → DynamoDB
CloudWatch cho monitoring
SQS cho dead letter queue
Auto-scaling configuration

Trình bày rõ ràng, có diagram ASCII, giải thích trade-off. Mình đọc thấy khá ổn.

Rồi mình ngồi với senior architect của team và đi qua từng phần. Khoảng 30 phút sau mình biết tại sao cái architecture đó sẽ không work cho specific case của mình:

Lambda cold start sẽ create latency spike không chấp nhận được vào buổi sáng khi traffic tăng đột biến
DynamoDB với access pattern của mình (nhiều range query trên time-series) sẽ đắt gấp 3-4 lần estimate của AI
Team mình không ai có kinh nghiệm Kinesis production – learning curve sẽ tốn tháng đầu tiên
Compliance requirement của khách hàng yêu cầu data phải ở region cụ thể và Kinesis có limitation ở đó

AI đưa ra architecture đúng về mặt lý thuyết và đúng trong nhiều context. Nhưng không đúng với context của mình.

Pattern AI hay mắc khi thiết kế architecture

AI thích best practice hơn là fit practice. Nó sẽ đề xuất thứ được cộng đồng nói nhiều nhất, được viết blog nhiều nhất, benchmark tốt nhất trong general case. Nhưng production architecture không phải general case – nó là specific case với đủ loại constraint kỳ lạ.

AI không có risk appetite của bạn. Startup với 5 người khác hoàn toàn với enterprise team 50 người. Người dùng của bạn có chấp nhận được downtime 30 phút không? AI không biết. Nó sẽ đề xuất highly available setup mặc định, đôi khi overkill 300%.

AI không model được operational complexity. Cái gì dễ build và cái gì dễ operate là hai chuyện khác nhau. Kubernetes cluster nghe hay, nhưng nếu team không có SRE thì ai oncall lúc 3 giờ sáng khi pod crash? AI đề xuất Kafka vì Kafka tốt, nhưng không ai trong team biết Kafka thì đó không phải good choice cho bạn.

AI không biết legacy constraint. Hệ thống cũ đang chạy, data migration là rủi ro, backward compatibility cần duy trì trong 6 tháng transition – những cái này ảnh hưởng rất lớn đến architecture decision nhưng rất khó để AI model hết.

Câu chuyện khác: Khi AI tự mâu thuẫn

Mình đã làm một experiment nhỏ: cùng một bài toán architecture, mình hỏi Claude theo hai angle khác nhau. Lần một: "Tôi cần hệ thống reliable và easy to operate." Lần hai: "Tôi cần hệ thống scale được và cost-effective."

Hai câu trả lời khác nhau đáng kể. Điều đó ổn – trade-off thật sự tồn tại. Nhưng khi mình hỏi "hai approach này có mâu thuẫn nhau không?", Claude trả lời theo hướng "có thể kết hợp cả hai bằng cách..." rồi đưa ra một architecture hybrid nghe có vẻ tốt nhưng thực ra là vừa phức tạp vừa không giải quyết được trade-off gốc.

Đó là vấn đề cốt lõi: AI tối ưu cho câu trả lời thuyết phục, không phải câu trả lời đúng. Và trong architecture, hai thứ đó đôi khi rất khác nhau.

Cái AI làm tốt trong architecture

Brainstorm. Checklist. Đặt câu hỏi. "Bạn đã consider data consistency model chưa? Eventual consistency có chấp nhận được không?" – những câu hỏi kiểu đó, AI rất tốt. Mình dùng Claude như một rubber duck thông minh, không phải như architect.

Khi nào nên và không nên hỏi AI về architecture

Nên hỏi AI khi:

Bạn muốn hiểu trade-off của một pattern mà bạn chưa familiar (ví dụ: saga pattern vs two-phase commit)
Bạn cần list những factor cần xem xét cho một decision
Bạn muốn review xem mình đang thiếu angle nào trong analysis
Bạn cần compare two options về mặt lý thuyết

Không nên hỏi AI khi:

Bạn cần decision final cho production system
Context của bạn có nhiều constraint specific mà khó communicate đầy đủ
Decision có implication về team và organization (không chỉ technical)
Bạn đang seeking validation cho decision đã có sẵn (AI sẽ validate, đó không phải là review thật)

Experiment mình hay làm

Khi mình cần validate architecture decision, mình làm cái này: sau khi mình và team đã có conclusion, mình mô tả bài toán cho Claude không bao gồm conclusion của mình, chỉ bao gồm constraint và requirement. Rồi xem Claude đề xuất gì.

Nếu Claude đề xuất giống mình: confidence tăng một chút (nhưng không quá nhiều vì có thể mình và AI cùng bị bias tương tự).

Nếu Claude đề xuất khác: interesting. Không phải nghĩa AI đúng hay mình đúng. Nghĩa là có angle mình cần investigate thêm. Tại sao approach đó reasonable? Assumption nào AI đang make mà mình không? Đây là dialog hữu ích.

Cái này work vì mình dùng AI để generate option mình có thể đã bỏ sót, không phải để validate option mình đã có.

Task 4: Debug Heisenbug và các bug khó

Đây là task mình mất nhiều tóc nhất trong 2 năm qua, và AI không giúp được nhiều như mình kỳ vọng.

Heisenbug là gì, dành cho ai chưa biết

Heisenbug là bug xuất hiện khi bạn không nhìn vào nó, và biến mất khi bạn bật debugger lên. Tên đặt theo Heisenberg uncertainty principle. Thường xảy ra với concurrent code, timing-dependent behavior, production-only config, hay environment difference.

Câu chuyện mất 3 ngày

Hệ thống của mình có một issue kỳ lạ: request timeout chỉ xảy ra vào giờ cao điểm buổi sáng (7h-9h), chỉ trên production, chỉ với một subset user nhất định, và không reproduce được trên staging dù traffic load test tương tự.

Mình paste toàn bộ log, stack trace, và config vào Claude. Nó đưa ra 8 hypothesis:

Database connection pool exhaustion
Deadlock trong query
Network latency spike
Memory pressure gây GC pause
Third-party API timeout
Thread pool saturation
Caching layer issue
Load balancer behavior

Tất cả đều reasonable. Tất cả đều có thể đúng. Và đây là vấn đề: với 8 hypothesis reasonable, mình vẫn phải tự quyết định cái nào investigate trước. AI không có cơ sở để prioritize vì nó không có signal từ hệ thống thực tế đang chạy.

Cuối cùng bug là gì? Database connection pool exhaustion – nhưng theo cách không obvious: pool size configure đúng, nhưng một số long-running transaction do query suboptimal không release connection đúng lúc, và vào giờ cao điểm thì pool cạn. Query suboptimal đó chỉ chạy với data pattern của một nhóm user cụ thể (user cũ, có nhiều historical data). Và nó chỉ xảy ra production vì staging không có cùng data distribution.

AI không thể diagnose cái đó vì để diagnose cần:

Quan sát actual connection pool metrics theo real-time
Correlate với specific user behavior
Hiểu data distribution khác nhau giữa staging và production

Tất cả những cái đó nằm ngoài context AI có thể access.

Loại bug AI làm tốt vs tệ

Loại bug	AI làm được	AI tệ
Syntax error, typo	✅ Rất tốt
Logic error trong isolated function	✅ Tốt
Off-by-one, wrong condition	✅ Tốt
Memory leak cơ bản	🟡 Tạm được
Race condition	🟡 Suggest được nhưng không diagnose
Environment-specific issue	❌
Data-dependent bug	❌
Timing-dependent behavior	❌
Bug do interaction giữa nhiều service	❌
Production-only behavior	❌

Tại sao AI kém với bug phức tạp

Bug phức tạp thường không nằm trong code – nó nằm ở sự tương tác giữa code, data, environment, và timing. AI nhìn code nhưng không nhìn được toàn bộ bức tranh đó.

Thêm nữa, để debug Heisenbug thật sự cần intuition từ kinh nghiệm. Cái "hm, mùi này nghe quen, trước đây mình từng gặp similar issue ở..." – đó là pattern matching từ memory dài hạn của một developer, không phải thứ AI làm tốt.

AI cũng không biết đặt câu hỏi đúng để thu hẹp phạm vi. Nó đưa ra nhiều hypothesis nhưng không có strategy để eliminate chúng hiệu quả. Developer giỏi biết: "Câu hỏi nào tôi có thể trả lời nhanh nhất để loại ra nhiều hypothesis nhất?" AI không think theo kiểu đó.

Cách mình dùng AI khi debug

Mình dùng AI tốt nhất ở bước đầu: "Những nguyên nhân có thể gây ra triệu chứng này là gì?" Nó như brainstorming. Sau đó mình tự investigate, và thỉnh thoảng quay lại hỏi thêm về specific area. Nhưng cái narrative của debugging – ai là suspect chính, investigate theo order nào – mình phải tự quyết.

Một case khác: memory leak trong production

Tháng trước team mình có memory leak trong Node.js service. Memory tăng dần, restart container mỗi 6 tiếng. Mình mô tả triệu chứng cho Claude.

Claude đưa ra các suspect: closure giữ reference không cần thiết, event listener không được remove, cache không có eviction policy, stream không được close, global variable accumulate. Đủ loại.

Mình paste code relevant. Claude point ra một EventEmitter không có removeListener ở một chỗ. Đúng pattern cổ điển. Mình fix. Restart. Memory vẫn leak.

Hóa ra là một thứ khác hoàn toàn: third-party library (cụ thể là một client library cho một external service) có bug trong version hiện tại, buffer responses không clear đúng cách trong một edge case. Bug đã được report trên GitHub của library đó từ 3 tháng trước nhưng chưa có fix. Cách giải quyết là upgrade version hoặc workaround.

Claude không biết bug đó vì training data có cutoff. Và ngay cả không có cutoff, để diagnose cần bạn trace chính xác memory đang accumulate ở đâu – cần tool như heap snapshot, không phải chat.

Bài học: AI debug tốt với pattern có trong training data. Với bug đến từ specific version của specific library hoặc từ interaction giữa nhiều component, cần tool observability thật sự, không phải AI.

Khi AI giúp được: explain error message kỳ lạ

Có một use case mình thấy AI genuinely useful khi debug: giải thích những error message cryptic. Stack trace dài 50 dòng với Java exception chồng chất, hoặc segfault message từ native library, hoặc weird SSL handshake error – những cái đó đọc một mình mất nhiều thời gian hơn mình cần. Paste vào Claude và hỏi "cái này nghĩa là gì và nguyên nhân thường là gì?" thì rất nhanh.

Đây là use case limited nhưng real.

Task 5: Viết code production-ready ngay từ lần đầu

Đây là task mà nhiều người nghĩ AI đã làm tốt rồi. Mình có quan điểm khác.

Phân biệt "code chạy được" và "code production-ready"

Code chạy được:

Function returns đúng output với happy path input
Unit test pass
Không có obvious syntax error

Code production-ready:

Handle edge cases và error cases đầy đủ
Log đủ để debug khi issue xảy ra
Có observability (metrics, tracing)
Secure: không có SQL injection, XSS, auth bypass tiềm năng
Performance: không có N+1 query, không memory leak
Maintainable: readable, documented, follows team convention
Testable: design cho phép test isolation
Graceful degradation khi dependency fail

AI rất tốt ở cái đầu. Với cái sau thì...

Ví dụ cụ thể

Mình hỏi Claude viết một service layer đơn giản: fetch user data, check permission, transform và return. Code trông clean, type-safe, test đi kèm. Mình đọc lần đầu thấy ổn.

Rồi mình mang vào code review với senior. Nhận được 12 comment:

Error từ database không được log với request ID – khi production issue xảy ra không trace được
Permission check không có audit log – compliance requirement
N+1 query: service gọi DB một lần cho user, một lần cho role, một lần cho permissions – nên join
Không có timeout trên DB call – nếu DB slow thì request hang
Không có circuit breaker pattern
Response không sanitize PII fields trước khi log
Cache strategy: data này nên cache, không phải fetch từ DB mỗi request
Không handle trường hợp user bị deactivate between request
Error message leak internal detail (table name, query structure)
Thiếu rate limiting consideration
Unit test chỉ cover happy path, không có test cho DB error, timeout, permission edge case
Naming không nhất quán với convention của codebase

Cái nào trong số đó là fault của AI? Tất cả, ở mức độ nào đó. Không phải vì AI ngu, mà vì để viết production-ready code cần context mà AI không có:

Compliance requirement của công ty
Monitoring và observability strategy của team
Performance pattern của specific database và workload
Security policy và threat model
Convention của codebase hiện tại
Operational experience (những gì đã fail trước đây)

Pattern AI hay miss nhất

Security: AI viết code secure theo "textbook security" – tránh obvious issues như SQL injection, hash password, v.v. Nhưng business-logic security vulnerabilities (IDOR, privilege escalation theo logic phức tạp, timing attack) thì miss nhiều.

Observability: Code của AI hiếm khi có đủ logging và metrics. Và khi có thì thường ở wrong level – log quá nhiều thứ không cần thiết, bỏ qua thứ quan trọng.

Error handling: AI xử lý error theo kiểu "catch và throw lại" hoặc "return null." Graceful degradation, fallback strategy, user-friendly error message – ít được nghĩ đến.

Performance trong context thực tế: AI optimize theo isolated function. N+1 query trong context của một service phức tạp hơn với nhiều call chain – AI ít catch được.

Nhưng mà AI ngày càng tốt hơn ở điểm này

Thật ra phải nói thêm: Claude và Cursor đã improve đáng kể. Nếu bạn provide đủ context – "code này sẽ handle 1000 request/second", "team dùng structured logging với correlation ID", "security sensitive endpoint cần audit trail" – AI sẽ incorporate những yêu cầu đó tốt hơn nhiều.

Vấn đề là bạn phải biết cần provide context gì. Và để biết cần provide gì thì bạn cần có kinh nghiệm production. Vòng tròn hơi kỳ.

Code review culture và AI

Có một side effect thú vị mình quan sát trong team: từ khi mọi người dùng AI để generate code nhiều hơn, quality của code review trong team giảm. Không phải vì mọi người lười review. Mà vì code của AI trông clean và có structure nên reviewer tend to trust it more. "Code trông ổn, AI generate mà."

Đây là trap. Code AI generate trông professional theo surface – type safe, consistent naming, có comment. Nhưng những issue mình liệt kê ở trên (missing observability, incomplete error handling, security edge case) không visible ở surface level.

Mình đã phải explicitly set norm trong team: "code từ AI vẫn phải review nghiêm như code của người viết." Và thực ra nên review kỹ hơn vì người review không quen với code đó, không biết assumption của "tác giả."

Một checklist mình dùng để review code AI generate

Mình tạo một checklist riêng cho việc này sau khi bị burn vài lần:

Security:

Input validation có đủ không, không chỉ type checking mà còn business rule?
Authorization check có ở đúng layer không, hay dựa vào caller?
Error message có leak thông tin nhạy cảm không?
Có log gì không nên log không (PII, credential)?

Observability:

Happy path có log không?
Error case có log với đủ context để debug không?
Có metric/trace hook nào không?
Log level có appropriate không (debug vs info vs error)?

Performance:

Có query nào chạy trong loop không?
Có operation nào có thể async hóa không?
Cache có được dùng khi nên dùng không?
Timeout có set không?

Resilience:

Dependency fail thì xảy ra gì?
Có retry với backoff không, hay fail fast ngay?
Partial failure được handle như thế nào?

Checklist này không AI-specific – nó là good engineering practice. Nhưng với code AI generate mình apply nó stricter hơn vì AI không có context về operational requirement.

Task 6: Sáng tạo ý tưởng thực sự mới và đột phá

Đây là task mà mình có góc nhìn hơi controversial và có thể nhiều người không đồng ý.

Trước hết, phân biệt hai loại "sáng tạo"

Recombination creativity: Kết hợp những thứ đã tồn tại theo cách mới. "Uber cho X", "Airbnb cho Y", "thêm AI vào Z." AI rất tốt ở đây – nó đã học từ hàng triệu idea, pattern, và có thể combine chúng nhanh và đa dạng.

Genuinely novel creativity: Nhìn thấy vấn đề mà người khác chưa thấy, hoặc approach theo cách chưa có precedent. Đây là thứ AI còn yếu.

Thực tế từ brainstorming session

Mình có habit dùng AI để brainstorm feature idea. Nó nhanh và đưa ra nhiều option. Nhưng sau nhiều tháng, mình nhận ra pattern: AI đề xuất những thứ đã được làm rồi ở đâu đó, chỉ là mình chưa biết.

Ví dụ: mình hỏi "cách mới để notify user về activity quan trọng mà không spam?" AI đề xuất intelligent notification batching, priority-based delivery, quiet hours, activity digest. Tất cả đều là feature đã có trong các product khác – Slack, Linear, Gmail, Notion. AI đang recall feature, không phải invent.

Không có gì sai với cái đó. Recall feature tốt cũng có giá trị. Nhưng nếu bạn đang cần differentiated product, thứ không ai đang làm, thì AI không giúp được nhiều.

Một experiment khác

Mình hỏi Claude: "Đưa ra 10 idea thực sự mới cho productivity app, không phải thứ đã có."

Nó đưa ra 10 idea. Mình Google từng cái. 8/10 đã có người làm rồi, một số đã fail. 1/10 là combination của feature hiện có theo cách mới nhưng implement được. 1/10 là... "AI-powered insights" tức là cũng đã có rồi chỉ là label khác.

Tại sao AI không làm được genuinely novel creativity

AI được train trên những gì đã tồn tại. Nó interpolate trong distribution của training data. Genuinely novel idea nằm ngoài distribution đó. Về mặt lý thuyết AI có thể extrapolate, nhưng nó không reliable và không consistent.

Thêm nữa, sáng tạo thật sự thường đến từ frustration cá nhân hoặc observation từ trải nghiệm sống. Post-it note được invented vì người trong 3M thích đánh dấu trang sách. Slack được built vì team của Flickr cần communicate trong khi build game. Những pain point đó không phải thứ AI có thể experience.

AI cũng không có commitment với idea. Một entrepreneur sẽ obsess về vấn đề trong nhiều năm, pivot nhiều lần, iterate dựa trên real feedback. AI đưa ra idea rồi... đưa ra idea tiếp theo nếu bạn hỏi. Không có skin in the game.

Cái AI tốt trong sáng tạo

Expanding on your idea: Bạn có kernel idea, AI giúp explore implications, challenges, và variations. Rất tốt ở đây.

Challenge your assumptions: Prompt đúng ("tại sao idea này sẽ fail?") thì AI đặt câu hỏi hay.

Cross-domain inspiration: "Feature này trong travel app có analog gì trong healthcare app không?" AI kết nối được các domain – useful.

Rapid prototyping of concepts: Bạn có idea, AI giúp hiện thực hóa nhanh để test – rất tốt.

Một điều nữa về creativity: cái gọi là "AI creativity" thường là confident bullshitting

Mình đã làm một test: hỏi AI đưa ra idea "hoàn toàn chưa ai làm" cho một problem cụ thể. AI đưa ra 10 idea với vẻ tự tin. Mình search từng cái. 8 đã có. 2 còn lại thì khi mình hỏi tiếp "idea này có feasible không?" thì AI chính nó list ra lý do tại sao không khả thi.

Vậy thì idea đó là genuinely novel hay là novel theo nghĩa "AI không chắc nó đã có người làm chưa?"

Khác nhau rất lớn.

Tốt nhất khi dùng AI cho creativity là đừng expect nó sáng tạo. Expect nó liệt kê, kết hợp, và articulate – sau đó mình là người phán đoán cái nào mới, cái nào feasible, cái nào phù hợp với context.

Cái tạo ra genuinely novel idea trong thực tế

Nhìn lại những feature hoặc solution tốt nhất mình hoặc team mình đã tạo ra – hầu hết đến từ một trong ba nguồn:

Frustration cá nhân sâu sắc: Bạn dùng chính sản phẩm của mình và thấy một thứ cực kỳ annoying. Cái pain đó drive bạn tìm solution. AI không frustrated – nó không dùng sản phẩm.

Observation từ domain khác: Ai đó trong team có background khác (y tế, giáo dục, logistics) và notice rằng "ở chỗ tôi làm trước, họ giải quyết kiểu này." Cross-pollination của human experience. AI có thể simulate cái đó ở mức nhất định, nhưng thiếu độ sâu của người thật đã sống trong domain đó.

Constraint bắt buộc sáng tạo: Budget cut, deadline cứng, limitation kỹ thuật – những cái đó force you ra khỏi comfortable solution. "Không dùng được third-party service này vì cost, phải tự làm." Những constraint như vậy đôi khi tạo ra solution tốt hơn. AI không có constraint thật sự – nó không bị ép buộc.

Task 7: Đưa ra quyết định có yếu tố con người, chính trị và trade-off kinh doanh

Đây là task mà nếu bạn cứ nhắm mắt tin AI thì sớm muộn sẽ có vấn đề.

Loại quyết định mình nói đến

Không phải "dùng library nào" hay "SQL hay NoSQL." Mà là những cái kiểu:

"Chúng ta có nên rewrite codebase hay tiếp tục maintain?"
"Deploy feature này khi nào? Trước hay sau đợt marketing campaign?"
"Team member này underperform, approach thế nào?"
"Client muốn thứ này nhưng nó sẽ tạo technical debt nặng – mình nói gì với họ?"
"Budget hạn hẹp, feature nào bỏ, feature nào giữ?"

Trải nghiệm cụ thể

Năm ngoái công ty có quyết định khó: cần migrate từ monolith sang microservice. Về mặt kỹ thuật, đây là việc nên làm – scale issue ngày càng rõ, team muốn deploy independent, v.v. Nhưng có nhiều yếu tố phi kỹ thuật:

Founder của công ty viết phần lớn monolith ban đầu và có emotional attachment với nó
Một senior dev là expert về monolith architecture, microservice sẽ giảm leverage của người đó
Timeline migrate ít nhất 18 tháng – investor muốn feature, không muốn nghe về infrastructure
Team có 2 junior mới vào, chưa đủ kinh nghiệm cho distributed system

Mình hỏi Claude: "Nên migrate không, và nếu có thì migrate như thế nào?"

Claude đưa ra analysis kỹ thuật rất đầy đủ về trade-off monolith vs microservice. Pros and cons. Migration strategy. Even acknowledge rằng "organizational readiness" là factor. Nhưng nó không thể weigh những cái đó theo context cụ thể của mình.

Làm sao nó biết founder của mình react thế nào? Làm sao nó biết investor đang impatient đến mức nào? Làm sao nó biết senior dev kia có resent nếu bị marginalized không?

Quyết định không phải tối ưu hóa – nó là navigation

AI có thể optimize theo criteria rõ ràng. "Maximize performance, minimize cost, ensure reliability" – với đủ constraint, AI có thể tìm technical solution tốt.

Nhưng quyết định thực tế trong tổ chức không có criteria rõ ràng. Nó là cân bằng giữa:

Technical debt vs speed to market
Team morale vs business need
Short-term pain vs long-term gain
Stakeholder expectation vs reality

Và những cái đó được weigh theo context chính trị, lịch sử, và relationship mà AI không có.

Một ví dụ nhỏ hơn nhưng cũng đau

Sprint planning, cần cut scope vì không đủ thời gian. Mình hỏi Claude: "Feature nào nên bỏ?" Cung cấp list 10 feature với business description và estimated effort.

Claude đề xuất bỏ 3 feature dựa trên effort/value ratio. Reasonable. Nhưng:

Feature #2 trong list bỏ là feature mà sales team đã promise cho khách hàng enterprise 3 tháng trước
Feature #5 là feature mà CEO personally excited về (mình biết từ all-hands meeting)
Feature #7 là feature junior dev mới đang build, cut nó sẽ affect morale của người đó

AI không biết những cái đó. Và "đúng về mặt kỹ thuật và lý thuyết" rất khác với "đúng trong tình huống này."

Cái AI làm tốt ở đây

Đặt framework để suy nghĩ. "Khi đưa ra quyết định này, bạn nên xem xét những factor nào?" Rất ổn. Liệt kê pros/cons của từng option. Tốt. Identify risk mình có thể đã bỏ qua. Hữu ích. Nhưng cuối cùng weigh factor nào nặng hơn trong context của mình thì mình phải tự làm.

Một case đặc biệt: technical debt decision

Đây là loại quyết định có đủ yếu tố con người, chính trị, và technical để làm AI bị lạc hoàn toàn.

Hệ thống đang chạy ổn. Có technical debt rõ ràng. Nhưng fix technical debt nghĩa là stop feature development trong 2-3 tháng. Business thì đang muốn feature để cạnh tranh với competitor vừa launch.

Câu hỏi với AI: "Nên prioritize technical debt hay feature development?"

AI trả lời rất balanced: "Tùy vào severity của technical debt và competitive pressure. Nếu debt ảnh hưởng reliability thì ưu tiên. Nếu không thì feature trước."

Câu đó đúng hoàn toàn và vô dụng hoàn toàn. Vì cái mình cần biết không phải framework tư duy – cái đó mình đã có. Cái mình cần biết là: với CTO cụ thể này, với culture cụ thể này, với investor expectation cụ thể này, nên frame cuộc conversation như thế nào để có outcome tốt nhất?

Đó là kỹ năng navigating organization, không phải kỹ năng technical decision making. Và AI không có organizational context đó.

Điều mình học được về AI và quyết định quan trọng

Mình có rule đơn giản: với quyết định mà hậu quả sẽ cảm nhận được hơn 3 tháng sau, mình không để AI drive. Mình có thể dùng AI để organize thinking, identify blind spot, và prepare cho conversation. Nhưng actual decision phải là của người có đủ context và phải chịu accountability.

Cái "chịu accountability" quan trọng hơn nhiều người nghĩ. Khi bạn phải live với quyết định của mình – code review sau 6 tháng, support system bạn build, explain với team tại sao approach này tệ hơn approach kia – bạn sẽ think differently trước khi quyết định. AI không có cái accountability đó, và cái đó ảnh hưởng fundamentally đến chất lượng reasoning.

Phân tích sâu: Tại sao AI vẫn yếu những thứ này?

Sau khi liệt kê 7 task, mình muốn drill deeper vào lý do. Vì hiểu lý do thì mới biết khi nào expect AI tốt, khi nào không.

Lý do cốt lõi

1. AI được train để predict text, không phải để think

Đây là cái fundamental nhất. Large language model predict token tiếp theo based trên pattern trong training data. Nó cực kỳ giỏi ở cái đó. Nhưng nhiều task trong list mình nêu cần reasoning dựa trên thông tin chưa có trong training data – như: hệ thống cụ thể của bạn, team cụ thể của bạn, constraint cụ thể của bạn.

Có người argue rằng AI "thực sự understand" chứ không chỉ pattern match. Đây vẫn là debate open. Nhưng từ practical standpoint: AI tốt với những thứ nằm trong distribution của training data, yếu với những thứ specific và novel.

2. AI không có grounding trong physical và social reality

Một developer giỏi biết estimate tốt một phần vì họ đã fail estimate nhiều lần và học từ đó. Họ biết "third-party API thường có quirk" vì đã bị làm khó bởi quirk đó. AI không trải qua những frustration đó. Nó chỉ đọc về chúng.

Tương tự với organizational dynamics: AI đọc về office politics, nhưng không "sống" trong một team, không cảm nhận tension khi hai người không agree, không biết cách đọc room.

3. Context window vẫn là bottleneck

Dù context window đã tăng rất nhiều (Claude bây giờ handle được hàng trăm nghìn token), nhưng codebase thật thường lớn hơn thế. Toàn bộ organizational history, communication, và technical decision không fit vào context. AI chỉ làm việc với cái bạn cho nó thấy.

4. AI không có accountability

Quyết định architecture tốt hay tệ sẽ thấy sau 2 năm, khi codebase khó maintain hay dễ scale. AI không biết cái đó. Nó không phải chịu trách nhiệm với quyết định. Developer phải live với quyết định của mình – cái đó tạo ra incentive để think carefully. AI không có incentive đó.

So sánh Claude vs Codex vs Grok (từ góc nhìn thực tế)

Mình dùng cả ba thường xuyên. Đây là observation của mình, không phải benchmark chính thức:

Task	Claude	Codex (GitHub Copilot)	Grok
Explain complex concept	✅ Tốt nhất	🟡 Ổn	🟡 Ổn
Generate boilerplate	✅ Tốt	✅ Tốt (inline nhanh hơn)	✅ Tốt
Debug known bug pattern	✅ Tốt	🟡 Ổn	🟡 Ổn
Architecture discussion	✅ Richer conversation	❌ Không phù hợp	🟡 Ổn
Ambiguous requirement	🟡 Hỏi clarify tốt hơn	❌ Không phù hợp	🟡 Tương tự
Security review	✅ Khá tốt	🟡 Basic	🟡 Ổn
Production-ready code	🟡 Tốt hơn với context	🟡 Tốt với inline context	🟡 Tương tự
Novel idea	Cả ba đều tương đương – không ai thực sự novel

Codex (via Copilot) shine nhất ở inline completion trong IDE – nó nhanh, contextual, và không cần context switch. Claude shine ở reasoning và extended conversation. Grok thì... mình dùng ít nhất, thấy tốt cho search-heavy task nhưng chưa build habit.

Dự đoán 1-2 năm tới

Mình không có crystal ball, nhưng từ trajectory hiện tại:

Sẽ tốt hơn đáng kể:

Code generation production-ready: Với longer context và better instruction following, AI sẽ incorporate security, logging, error handling tốt hơn – nếu bạn provide đủ context
Debug known pattern: Tool tích hợp với actual runtime (memory, CPU, request trace) sẽ làm AI debug tốt hơn rất nhiều
Architecture tradeoff: AI sẽ learn nhiều failure case hơn, biết khi nào popular choice không phù hợp

Sẽ vẫn khó:

Genuinely novel creativity: Đây là fundamental limitation của model được train trên existing data
Human/political decisions: AI không có organizational context và không có accountability
Ambiguous requirement từ human với hidden agenda: Cần đọc người, không đọc text

Wild card:

Agentic AI (AI agent có thể browse code, run test, observe production) có thể thay đổi game với debug và production-readiness
AI với persistent memory và organizational context sẽ giảm nhiều limitation mình nêu

Cách tận dụng AI hiệu quả dù nó còn nhiều hạn chế

Sau hai năm trial-and-error, đây là workflow mình đang dùng.

Nguyên tắc cơ bản

Dùng AI cho subtask, không phải full task. Thay vì "viết feature X cho mình," hãy break down thành: "viết interface cho service X," rồi "implement method Y theo spec này," rồi "review code này theo checklist bảo mật," rồi "viết test cho edge case Z." Mỗi subtask nhỏ hơn, AI làm tốt hơn, và bạn control được quality ở từng bước.

Provide context mà bạn thường bỏ qua. Team convention, performance requirement, security consideration, operational constraint – những thứ bạn biết vì bạn làm việc ở đây nhưng AI không biết. Càng cụ thể càng tốt.

Treat output như draft, không phải final. Mental model này thay đổi cách bạn work với AI. Bạn không "accept hay reject" output – bạn "review và improve" output. Khác nhau về cách đọc và cách interact.

Hỏi AI phản biện chính nó. Sau khi AI đưa ra suggestion, hỏi: "Vấn đề gì có thể xảy ra với approach này?" hay "Tôi đang thiếu gì trong cách nghĩ này?" AI khá tốt ở vai trò devil's advocate khi bạn explicit yêu cầu.

Workflow mình đang dùng

Buổi sáng: Planning và architecture

Đây là task cần brain của mình nhất. Mình ít dùng AI ở bước này, và khi dùng thì dùng như rubber duck – nói to requirement và constraint ra, AI hỏi ngược lại, mình clarify. Quá trình đó giúp mình tự think rõ hơn, không phải AI think thay mình.

Khi coding: Inline completion và generate boilerplate

Copilot chạy background, mình accept suggestion cho những phần mechanical (imports, type annotation, repetitive pattern). Những phần logic phức tạp mình vẫn tự viết và chỉ hỏi AI khi stuck.

Code review trước khi commit:

Mình paste code vào Claude với prompt: "Review theo checklist sau: error handling, security, performance, observability, maintainability. List cụ thể issue và suggestion." Cái này tiết kiệm được kha khá comment của reviewer thật.

Khi debug:

Dùng AI ở bước đầu để generate hypothesis list. Sau đó tự investigate. Quay lại AI khi cần explain một specific behavior hay trace một specific execution path.

Documentation và test:

AI làm tốt nhất ở đây. Generate test case từ implementation, viết docstring, viết README section. Mình review và adjust, nhưng 70-80% output dùng được.

Prompt tips thực tế

Cho architecture discussion:

Context: [mô tả hệ thống, team size, tech stack, constraint]
Vấn đề: [mô tả cụ thể]
Câu hỏi: [câu hỏi cụ thể]
Sau khi đưa ra suggestion, hãy chỉ ra 3 assumption bạn đang make và điều gì sẽ thay đổi nếu assumption đó sai.

Cho code review:

Review code này và focus vào:
1. Edge case chưa handle
2. Security issue tiềm ẩn  
3. Performance concern với traffic [X] request/giây
4. Missing observability
5. Gì khác mà senior dev sẽ comment trong PR

Đừng comment về style hay naming convention.

Cho debug:

Triệu chứng: [mô tả cụ thể, include: khi nào xảy ra, tần suất, điều kiện]
Environment: [production/staging, OS, version]
Log liên quan: [paste log]
Đã thử: [list những gì đã investigate]
Câu hỏi: List các hypothesis theo order ưu tiên để investigate, và cách verify nhanh nhất cho từng hypothesis.

Cho estimate sanity check:

Task: [mô tả]
Estimate của tôi: [X ngày] vì [reasoning]
Codebase context: [tech stack, architecture đặc thù]
Team context: [size, seniority]

Câu hỏi: Tôi đang thiếu gì trong estimate này? Không hỏi tổng thời gian, chỉ hỏi gap.

Tool stack hiện tại của mình

Mình không dùng một tool duy nhất. Đây là setup:

Cursor: IDE chính với AI integration. Tốt cho inline completion và chat trong context của codebase. Cái killer feature là nó có thể index toàn bộ codebase và AI có context đó khi bạn hỏi.

Claude: Cho extended reasoning, architecture discussion, và review task cần longer conversation. Mình mở web UI song song với IDE.

GitHub Copilot: Mình vẫn giữ vì một số team member prefer nó, và nó có Copilot in the CLI khá hữu ích cho command generation.

Grok: Thỉnh thoảng cho research task cần web access gần đây.

Điều mình học được: đừng locked vào một tool. Chúng có strength khác nhau và đang evolve nhanh.

Kết luận và góc nhìn cá nhân

Bài này mình viết không phải để nói "AI useless" hay "AI dangerous." Mình vẫn dùng AI mỗi ngày và nó đã thực sự làm công việc của mình dễ hơn đáng kể.

Nhưng sau hai năm, mình thấy rõ một pattern trong cộng đồng dev: người mới tiếp xúc với AI thường either quá excited (nghĩ AI làm được tất cả) hoặc quá skeptical (nghĩ AI là hype, không dùng). Cả hai đều miss the point.

AI tốt theo một cách rất cụ thể: nó tốt với những task có answer nằm trong distribution của training data, được define rõ ràng, và không cần context từ real world ngoài những gì bạn provide.

Những task quan trọng nhất trong career của developer – understand business problem, make architectural decision, debug production issue phức tạp, work với người và politics, create genuinely new solution – đa phần không nằm trong cái bucket đó.

Điều đó có nghĩa là: giá trị của developer không giảm, nó shift. Những task AI làm được thì delegate cho AI. Những task AI không làm được thì chính đó là thứ phân biệt good developer với average developer.

Mình thấy developer giỏi nhất trong team của mình không phải người dùng AI nhiều nhất – mà là người biết khi nào dùng AI và khi nào không. Người biết trust AI với boilerplate và skeptical với AI khi nói về production decision quan trọng. Người treat AI như junior colleague: hữu ích, nhanh, nhiệt tình – nhưng vẫn cần review và guidance.

Và cái kỹ năng biết distinguish đó không phải thứ AI dạy bạn được. Phải tự học, tự fail, tự rút kinh nghiệm.

Có một câu hỏi mình vẫn chưa có câu trả lời rõ ràng và muốn hỏi anh em: Bạn đang dùng AI tốt nhất ở task nào, và task nào bạn đã thử nhưng hoàn toàn thất vọng?

Không cần câu trả lời đẹp. Thật sự muốn nghe case cụ thể, đặc biệt là những case AI fail theo cách buồn cười hoặc unexpected.

Và nếu bạn không đồng ý với điểm nào trong bài này – comment thẳng vào. Mình viết từ kinh nghiệm cá nhân ở một công ty cụ thể, chắc chắn có góc nhìn khác từ context khác.

Bài được chỉnh sửa bởi AI, nhưng không dùng AI để hoàn toàn generate

AICoding Developer Programming AIagent AI