Từ tháng 8/2025, hơn nửa code mới đẩy lên production của Ashby là AI sinh ra, nhưng số customer issue gần như không đổi. Khách hàng tăng, code AI viết tăng, nhưng “trời không sập”.
Ashby cũng không thấy regression về chất lượng code, velocity, hay onboarding time của engineer mới — anecdotally, comprehension về codebase còn tăng lên.
Đây không phải toy project. Ashby là bộ talent acquisition software với hơn 100.000 weekly active user, hàng triệu candidate application mỗi tuần, có những feature có scope ngang một công ty riêng (như Calendly hay Looker).
Tôi là Colin, Head of EMEA Engineering tại Ashby. Bài này chia sẻ cách Ashby Engineering nghĩ về AI và những thay đổi trong cách làm việc. Tôi giả định bạn là engineer.
Luận điểm: chi phí sản xuất code đang hướng về zero. AI không lấy mất việc của bạn — nó lấy đi phần cơ học: cú pháp, glue code, gõ phím. Những phần ít thú vị, ít thách thức.
Phần quan trọng với engineer — judgment, taste, hiểu khách hàng — đang trở nên quan trọng hơn, không phải kém đi. Mỗi efficiency gain trong việc sản xuất code chất lượng cao đều đẩy vai trò engineer dịch về phía judgment. AI sẽ là cú dịch chuyển lớn nhất chúng ta từng thấy.
Dịch chuyển đã đang xảy ra. “Gần như tất cả PR của tôi giờ AI viết hết. Tôi implement cả một data ingestion bằng AI… ~40 PR” — Tom, một engineer của Ashby.
Hai ground rule cơ bản
- Empathy không thể thay thế bằng AI.
- Bạn chịu trách nhiệm với cái bạn ship.
Empathy không thể thay thế bằng AI
Build product là công việc của con người. LLM không có taste. Không biết khách hàng của bạn. Không thể cảm nhận sự khó chịu khi dùng một product tệ hay sự hạnh phúc khi dùng một product tuyệt vời. Trong thế giới mà build product chạy được nhanh đến điên rồ, năng lực build một product tuyệt vời càng quan trọng hơn.
Ashby cũng coi trọng individual focus. Khi cộng tác, làm cho hiệu quả: không họp standup vô nghĩa, không planning poker. Họ viết document cho đồng nghiệp đọc, ask for help khi review.
Empathy ở đây là: nhớ viết document cho con người sẽ đọc. LLM có thể giúp viết, nhưng nếu không hướng dẫn, nó sẽ viết những thứ nghe có vẻ thuyết phục mà khó đọc, đầy chi tiết vô nghĩa, không có wisdom. Ví dụ một đoạn PR description LLM viết:
Added .github/workflows/pr-relevant-test-coverage.yml:
- Triggers on pull_request (excluding master) and
workflow_dispatch with pr_number.
- Resolves PR number, collects changed files, and asks
Claude to output up to 15 relevant test files.Đây toàn là thông tin có thể trivially suy ra khi đọc PR. Bản full ~30 dòng. Dòng hữu ích nhất vẫn miss:
Coverage is intentionally not full-suite coverage; it
reflects only Claude-selected relevant tests against
changed files.Tại sao không full-suite? Description này không tôn trọng thời gian của reviewer. Phiên bản tốt hơn:
Coverage is intentionally not full-suite coverage. The
full suite with coverage takes hours to run. We are
using this to give guidance to engineers on where risks
lie.Đừng giao việc viết document cho con người cho LLM.
Bạn chịu trách nhiệm với cái bạn ship
LLM có thể sai một cách tự tin và bất ngờ. Rủi ro lớn nhất với AI không phải là nó sai — là nó nghe có vẻ đúng.
“I didn’t mean to remove the tar-stream package - it was an accidental casualty when I was editing backend/package.json…” — Claude Code.
Bạn chịu trách nhiệm dù từng dòng do bạn gõ hay LLM generate cả PR. Bạn phải hiểu code làm gì, tại sao làm thế, và chuyện gì xảy ra khi nó break.
Càng dùng LLM nhiều, skepticism càng phải tăng, không giảm. Hỏi alternative. Hỏi edge case. Yêu cầu nó tự critique chính nó. Hiểu reasoning trước khi accept output.
Think more, think harder
LLM giúp bạn no-brain qua mọi thứ. Cưỡng lại impulse đó. Việc throw issue cho LLM, auto-generate PR description, để LLM viết test, throw PR ra review — toàn bộ quá trình có thể “feel productive” trong khi bạn đang fix sai issue hoặc build solution kém.
Một biểu hiện đặc biệt nguy hiểm là chạy nhiều agent parallel trên các task khác nhau. Đây là multitasking on steroids. Cảm giác productive khi có 5 agent làm 5 issue, nhưng bạn có ra quyết định tốt nhất không? Bạn có suy nghĩ sâu được về guidance cần cho mỗi agent không?
Hype cycle hiện tại đề cao quantity và velocity, bỏ qua quality và ingenuity. Ashby không theo. Đó là góc nhìn cận thị về thế giới — nơi mọi thứ đều có thể shortcut. Shortcut luôn tồn tại, và nhiều cái làm giảm chất lượng công việc của bạn.
Spec vẫn dành cho con người
Một shift đang xảy ra là intention feed spec cho LLM. Ashby luôn coi trọng spec — giảm risk dev, đảm bảo alignment. LLM cũng benefit từ context của spec.
Nhưng cái con người cần từ spec khác với cái LLM cần. Con người cần thứ tôn trọng thời gian, engage reader, focus attention vào decision quan trọng (ví dụ: tại sao dùng Redis thay vì Postgres, không phải document liệt kê từng giá trị enum).
Phải tiếp tục viết spec cho con người. Spec capture quyết định khó-thay-đổi và identify abstraction cần xây. Ví dụ Colin trao đổi với một engineer về requirement perform action trên hàng triệu form — framework chưa support. Tạo implementation one-off hay improve bulk action building block? Đó là quyết định cần được capture trong spec. Spec viết cho người. LLM có thể consume như additional context.
Cách nghĩ về LLM
LLM không lazy. Nó sẽ produce code và tiếp tục. Sẽ không dừng lại hỏi “có nên tạo abstraction không?”. Nó giỏi summarize, không phải novel thinker. Sẽ không tự suy luận để đơn giản hóa và xóa hàng nghìn dòng code.
Mental model đơn giản Colin dùng: nghĩ LLM như một bộ xúc xắc, không phải superintelligence được hype.
- Một số bài toán LLM rất giỏi, không cần roll điểm cao: summarize, tìm pattern, continue pattern.
- Một số bài toán nó kém kinh khủng — không bao giờ roll sáu nhiều lần liên tiếp được: đếm số chữ ‘r’ trong “strawberry”, nhân số lớn, theo dõi hướng sau nhiều cú quay. Những thứ tưởng đơn giản nhưng cần precision mà xúc xắc không cho.
- Có cách load xúc xắc để tăng tỉ lệ: ví dụ cho nó ví dụ “good looks like”.
Hai mode làm việc với AI
Có hai cách distinct:
Default về sidekick mode. Bạn dùng AI để explore codebase, find/digest information lớn, implement spec chi tiết bạn đã viết. Bạn ra phần lớn quyết định.
Đây là mode cho mọi thứ high-risk: database migration, candidate data handling, security-sensitive code, architectural decision. Những nơi “trông có vẻ đúng” không đủ tốt.
Switch sang delegate mode khi blast radius nhỏ. Bạn review output — đôi khi không review. Prototype, tool local, ops tool là candidate tốt. Bạn move fast vì cost-of-failure thấp.
Hầu hết engineer sẽ over-delegate lúc đầu, rồi over-correct và under-delegate. Câu hỏi không bao giờ là “có nên dùng AI không” — mà là “trust nó đến đâu ở chỗ này”. Nghĩ về chuyện gì sẽ xảy ra nếu code sai. Embarrassing? Đắt tiền? Existential?
Blend giữa hai mode là phổ biến. Đó là chỗ judgment quan trọng — break task ra để switch mode hợp lý. Ví dụ start với LLM build scaffolding, tự hand-write vài SQL query, rồi quay về full delegate cho vài unit test.
Cách Ashby đang dùng AI
Ashby actively khuyến khích engineer dùng AI: qua education, workshop, pairing, token budget hào phóng. Không mandate dùng AI, không đo token usage — niềm tin là đo lường sẽ encourage slop.
Khi viết code rẻ đi, safety trở nên quan trọng hơn. Safety phải build vào hạ tầng, không impose bằng kỷ luật. Ashby nghĩ về safety theo Swiss Cheese model: mỗi layer có lỗ, nhưng lỗ ở vị trí khác nhau. Test bắt cái review miss, feature flag bắt cái test miss, observability bắt cái lọt qua tất cả.
Cụ thể:
- Truy cập AI code generation cho mọi engineer: Cursor (không giới hạn token), Claude Max, Codex, các agent framework.
- Linter, DangerJS, AI giúp code review: nhiều issue được linter và Danger rule bắt; dùng CodeRabbit cho first pass trước reviewer người; tự build code review tool focus vào edge-case bug khó debug ở production.
- Hạ tầng chung cho AI tool: skill file lưu trong repo, team contribute hàng tuần. Engineer có repo clone Git metadata từ main repo vào SQLite — toàn bộ issue, PR, comment ở đó, trả lời “có ai từng gặp bug này chưa?” nhanh và chính xác hơn GitHub API.
- AI cải thiện cộng tác cross-department: train internal model để triage customer issue và route về đúng product team. Automation để Claude Code review incoming bug và produce report về likely cause + người nên consult — đôi khi Support fix issue trong 10 phút thay vì hàng giờ.
Tương lai gần
Change review
Ashby vẫn review code change — review fairly broad. Nhưng output tăng sẽ vượt tốc độ review. Phải critical về lý do review.
Engineer không nên là human linter. Không nên dành thời gian review xem ai dùng useMemo đúng chưa. Self-review + tool (linter) nên handle 90% việc đó. Nếu năm 2026 bạn còn đang review một automated refactor extract function, chúng ta đã thất bại.
Vậy review để làm gì?
- Change này có sense không?
- Vùng high-risk ở đâu? Làm sao giảm risk?
- Performance characteristic ra sao?
- Abstraction có sensible không? Có abstract đủ chưa?
Điểm cuối quan trọng: LLM bias về tạo code mới thay vì reuse code có sẵn. Nếu không check, nó sẽ build cho bạn codebase chạy được nhưng không ai navigate nổi. LLM không quan tâm code nó produce có phức tạp hay không. Đẩy về phía đơn giản giờ là một trong những thứ giá trị nhất reviewer có thể làm.
Automatic verification
Suốt nhiều năm, viết code là phần đắt, test là afterthought. AI lật ngược: viết giờ rẻ, verification là bottleneck mới, và đầu tư phải theo.
Ashby đã có unit test + end-to-end test. QA team tạo skill file mô tả cách viết test consistent và sustainable, tránh flaky test (vốn nhanh chóng erode confidence). Engineer giờ viết end-to-end test bằng Playwright — 65 test case mới trong 4 tuần qua, 70% do người ngoài QA team contribute.
Cần more và better test: fuzz test, frontend unit test. Static analysis trở nên relevant lại. Cần AI review AI: automated review focus vào performance, PII handling, error handling, security. Challenge sẽ là quản noise để con người focus vào decision quan trọng.
Suy nghĩ kết
Codebase giờ có audience mới. Mỗi pattern, mỗi tên, mỗi module boundary giờ được LLM đọc — và LLM hiểu literally. Codebase bừa bãi không chỉ làm chậm đồng nghiệp; nó degrade mọi mảng code AI sinh ra chạm vào. Chất lượng code luôn quan trọng. Giờ nó compound.
Nếu bạn cảm thấy resistance với việc AI sinh code — tôi hiểu. Nhưng nghĩ xem bạn thực sự enjoy gì: gõ code, hay khoảnh khắc abstraction đúng “click vào chỗ”? AI lấy phần đầu. Phần sau sắp quan trọng hơn bao giờ hết. Và bạn không thể build abstraction đúng nếu không hiểu vấn đề và đối tượng đang giải.
Vì vậy hiểu khách hàng giờ là core engineering skill. Engineer của Ashby dành nhiều thời gian hơn cho: xem user session replay, xem customer interview, nói chuyện với internal user, đọc support conversation. Engineer hiểu problem space lãng phí ít thời gian build sai và ra quyết định độc lập tốt hơn. Implementation speed thành multiplier on sound judgment — AI sắp khiến team “order-taking” obsolete đồng thời khiến team như Ashby mạnh hơn.
Ashby tin engineer của họ position tốt cho tương lai này — vì họ được hire không chỉ vì giỏi kỹ thuật, mà vì product-minded, communicator giỏi, và có sound judgment.
Bài gốc: Colin Crowley, Head of EMEA Engineering tại Ashby, 6/2026.