LLM đang bào mòn sự nghiệp kỹ sư phần mềm của tôi, và tôi không biết phải làm gì
(human-in-the-loop.bearblog.dev)- Các công cụ phát triển dựa trên LLM tham gia từ viết tài liệu thiết kế, lập kế hoạch triển khai, viết mã đến gỡ lỗi, làm suy yếu lợi thế khác biệt từ 10 năm tích lũy chuyên môn backend trong thanh toán và tài chính
- Kiến thức miền trong lĩnh vực tài chính và thanh toán từng là lợi thế cạnh tranh dựa trên kinh nghiệm về tuân thủ PCI, sổ cái bút toán kép, escrow, đối soát, vòng đời thanh toán, tính idempotent của chuyển khoản ngân hàng, nhưng mô hình bắt đầu nắm được các mắt xích trong cấu trúc hệ thống và tạo ra cú sốc đầu tiên
- Khi tự động hóa gỡ lỗi mở rộng nhờ Claude Code, Codex, MCP, DataDog MCP..., một số lỗi có thể được xử lý chỉ với stack trace và ngữ cảnh từ Sentry, rồi sau đó 90% lỗi trong hệ thống phân tán được giải quyết one-shot
- Ngay cả chất lượng mã và kiến trúc, hai trụ cột còn lại, cũng bị thu gọn thành “taste”, và đang xuất hiện xu hướng chấp nhận codebase hạng
ChoặcDmà LLM có thể xử lý thay vì codebase hạngAhoặcBdễ đọc cho con người - Để bảo vệ khả năng được tuyển dụng dài hạn, cần chuyển chuyên môn sang những lĩnh vực mà LLM chưa thể làm tốt một cách dễ dàng, nhưng chuyển sang công việc nghiên cứu lại bị hạn chế bởi quốc gia cư trú, cạnh tranh tuyển dụng, hoàn cảnh gia đình và nguy cơ RSI
Bối cảnh sự nghiệp
- Là kỹ sư phần mềm chuyên nghiệp với 10 năm kinh nghiệm, bắt đầu từ web frontend vì khi đó gỡ lỗi dễ hơn, nhưng sau này đã chuyển sang backend
- Một cách tình cờ, đã đảm nhận vai trò phát triển phần mềm trong các miền tài chính, bookkeeping và xử lý thanh toán, đồng thời có trải nghiệm về tính tự chủ cao trong mối quan hệ gần gũi và thẳng thắn với Product Manager cùng các bên liên quan
- Tích lũy kiến thức miền như tuân thủ PCI (PCI compliance), sổ cái bút toán kép (double-entry ledgers), escrow, đối soát (reconciliation), vòng đời thanh toán (payment lifecycles), tính idempotent của chuyển khoản ngân hàng (bank transfer idempotency)
- Chiến lược sự nghiệp trở thành chuyên gia miền là một lựa chọn rõ ràng để tạo khác biệt bằng chuyên môn trong lĩnh vực có dấu hiệu nhu cầu với chuyên gia miền đang tăng
Trụ cột đầu tiên bắt đầu sụp đổ: kiến thức theo miền
- Năm ngoái đã chuyển sang một công ty trong lĩnh vực tài chính; các công ty trước đó có yếu tố thanh toán và tài chính mạnh, nhưng không phải công ty chỉ tập trung duy nhất vào tài chính
- Công ty mới đón nhận AI toàn diện, cung cấp tài khoản ChatGPT và Claude Enterprise ngay từ ngày đầu tiên, và khuyến khích dùng AI cho nghiên cứu, khám phá và lập trình
- Tuy vậy, điều kiện là mọi dòng mã đi vào production đều phải tự mình rà soát và chịu trách nhiệm
- Dự án đầu tiên là làm lại một hệ thống thanh toán trực tuyến legacy lộn xộn, và được giao vì đã từng có kinh nghiệm xây dựng loại hệ thống này
- Các Design Docs viết trước khi lập trình phải đủ để cả kỹ sư lẫn Product Manager đều đọc được, tức là cần góc nhìn kiến trúc hơn là phân tích kỹ thuật quá sâu
- Design Docs đầu tiên được viết với mức hỗ trợ AI tối thiểu; khi đó từng gọi LLM là “stochastic parrots”, nhưng hiện không còn giữ quan điểm đó nữa
- Phản hồi từ quản lý là viết mã với tốc độ tốt, nhưng viết Design Docs mất quá nhiều thời gian và cần dùng AI nhiều hơn
- Khi ấy mô hình chưa tốt như bây giờ, nhưng vẫn đủ hiệu quả để tăng tốc độ viết và ra quyết định
- Đó là khoảnh khắc nhận ra giá trị của nhiều năm tích lũy về các trade-off khi triển khai, cách acquiring vận hành và cách cấu trúc idempotency để tránh double charge đang suy giảm
- Mô hình vẫn cần được điều phối, nhưng đã có thể nắm được những mắt xích để quyết định nên cấu trúc hệ thống thế nào, trong khi đây vốn là phần khó nhất chỉ hình thành trong đầu sau nhiều năm kinh nghiệm thực chiến
- Vì trên web có nhiều bài giải thích, tài liệu kỹ thuật và bài blog về việc áp dụng công cụ kỹ thuật vào miền chuyên môn, nên có thể thấy mô hình hấp thụ được chúng như dữ liệu huấn luyện
- Khi đó vẫn còn kỳ vọng rằng gỡ lỗi sẽ là lĩnh vực con người tiếp tục nổi trội, và kinh nghiệm với race condition trong production cùng việc gỡ lỗi hệ thống phân tán là cơ sở cho khả năng được tuyển dụng dài hạn
Trụ cột thứ hai bắt đầu sụp đổ: gỡ lỗi và hệ thống phân tán
- Sau khi LLM trở nên giỏi trong việc hỗ trợ viết tài liệu và lập kế hoạch triển khai, chúng cũng bắt đầu viết mã tốt; xu hướng này mở rộng mạnh với làn sóng Claude Code nửa cuối 2025 và sự xuất hiện của Codex
- Trước đó vẫn dùng LLM hằng ngày để viết unit test, nhưng chưa tin đến mức giao cả phần triển khai hoàn chỉnh
- Việc đưa thêm AI vào quá trình viết mã là bước tiếp theo tự nhiên, và vì cũng thích việc đưa sản phẩm lên production và làm người dùng hài lòng không kém gì thích code, nên đó là một sự đánh đổi có thể chấp nhận
- LLM đã giỏi viết mã, nhưng chưa thể gỡ lỗi cho những mớ hỗn độn do mô hình hay con người để lại, nên vai trò khi đó vẫn lớn hơn việc chỉ điều phối robot
- Sau MCP, workflow dạng agent và sự xuất hiện của Claude 4.5, trục gỡ lỗi cũng bắt đầu lung lay
- Claude 4.5 có thể giải quyết khoảng 60% lỗi chỉ với stack trace và một ít ngữ cảnh, và trong phần lớn trường hợp chỉ cần một liên kết Sentry có bật Sentry MCP là đủ
- Đôi khi vẫn tạo ra lời giải trông hợp lý nhưng hoàn toàn sai
- Từ thời điểm đó đã ngừng nghi ngờ máy móc, sau khi chứng kiến Claude Code xử lý trong một lần những lỗi mà trước đây bản thân phải gỡ cả ngày
- Sau đó, với 4.6, 4.7, GPT 5.5, Opus 4.8 và sự xuất hiện của DataDog MCP, CLI đã đạt đến mức giải quyết one-shot lỗi trong hệ thống phân tán
- Bao gồm những lỗi trước đây từng không giải được, những lỗi từng cần hai ngày làm việc toàn thời gian để debug, và cả lỗi trong hệ thống phân tán có khả năng quan sát phân tán kém
- 90% lỗi như race condition kỳ quái, corner case ngoài dự đoán, vấn đề tích hợp bên thứ ba, hay API edge case không được tài liệu hóa đều có thể được xử lý one-shot
- Vẫn cần người rà soát mã và điều phối robot nên tình trạng việc làm vẫn còn, nhưng lúc này bản thân đã trở thành một kỹ sư dạng hàng hóa
- Chuyên môn miền tài chính và thanh toán, trực giác gỡ lỗi, và kiến thức về hệ thống phân tán đã biến thành thứ tri thức có thể được nhúng vào prompt để một kỹ sư senior khác dùng LLM điều phối và tái tạo
- Trái với điều từng được dạy rằng cả generalist lẫn specialist đều có vai trò, thị trường đang chuyển theo hướng biến tất cả thành generalist
- Nếu ai cũng thành generalist mà nhu cầu không tăng theo, giá của generalist sẽ giảm, và trong thực tế nhu cầu còn đang giảm
Trụ cột thứ ba vẫn chưa sụp đổ: chất lượng mã và kiến trúc
- Trụ cột còn lại là chất lượng mã và kiến trúc phần mềm, nhưng hiện nay lĩnh vực này cũng bị thu gọn thành từ “taste”
- Trong suốt sự nghiệp luôn thích refactor, coi trọng mã tốt, và từng thương lượng để dành thời gian cho việc đó trong sprint
- Cũng luôn thích thảo luận về trade-off và cấu trúc codebase trong các chủ đề như DDD, Hexagonal, Clean Architecture
- Agent là công cụ rất yếu trong việc giữ codebase ở trạng thái ngăn nắp
- Nếu không được điều phối, các vấn đề phụ thuộc vòng sẽ xuất hiện rất nhanh
- Chúng thêm mã trùng lặp, chèn comment không cần thiết, trộn pure function với side effect, và bỏ qua các nguyên tắc SOLID
- Khả năng này đáng lẽ phải là lĩnh vực bảo vệ khả năng được tuyển dụng của con người, nhưng ngành lại đang thu nhỏ nó thành từ “taste” và tiến về một thế giới nơi tầm quan trọng của việc tổ chức mã thấp hơn
- Con người vẫn còn vai trò điều phối agent để ngăn codebase spaghetti với đồ thị phụ thuộc vòng
- Không ai muốn codebase hạng
F, nơi cứ sửa gì là vỡ cái khác, nhưng codebase hạngChayDgiờ đã là mức chấp nhận được - Lý do không còn cần codebase hạng
AhayBlà vì codebase giờ được làm ra để LLM xử lý hơn là để con người đọc - Nếu mã nguồn giờ được viết để máy đọc thay vì người đọc, thì việc lựa chọn nhắm tới máy cũng trở thành điều khả thi
- Kiến thức về chất lượng mã và kiến trúc cũng đang mất giá, và thời gian bỏ ra để đọc sách, luyện tập thực tế, tranh luận với kỹ sư khác, viết ADR đang dần trở nên vô ích
Vậy giờ phải làm gì
- Trong một thời gian nữa, có lẽ vẫn giữ được việc làm (ít nhất là ở công ty hiện tại), nhưng triển vọng dài hạn thì không chắc chắn
- Về lâu dài, những gì đã đầu tư 10 năm để học, thậm chí còn hơn nếu tính cả kinh nghiệm trước khi chuyên môn hóa, đang ngày càng mất giá trị
- Ngay cả trụ cột chuyên môn cuối cùng cũng đã bị thu gọn thành “taste”
- Khoảng 8 tháng trước, công ty hiện tại đã có một đợt sa thải (theo giải thích từ phía công ty là không liên quan đến AI), và những đồng nghiệp cũ rất giỏi bị sa thải vẫn đang tìm việc
- Nhiều người trong số họ cũng gặp cùng một vấn đề: chỉ riêng chuyên môn miền không còn đủ để tạo khác biệt nữa
- Công ty hiện đang tuyển lại một vài vị trí, nhưng mức độ quen thuộc với miền không còn là yếu tố khác biệt mạnh
- Trước đây tin tuyển dụng có dạng “Software Engineer - Area”, nhưng giờ chỉ còn “Software Engineer”, còn việc phân đội được quyết định sau khi nhận offer
- Đây là thay đổi tạo ra cơ hội việc làm tốt hơn cho những kỹ sư xuất sắc chưa từng có cơ hội tích lũy kinh nghiệm miền sâu
- Đồng thời, các kỹ sư xuất sắc đã dành cả đời để tích lũy kiến thức miền cũng bị đẩy vào cùng một làn cạnh tranh
- Lựa chọn duy nhất để bảo vệ khả năng được tuyển dụng dài hạn là chuyển chuyên môn miền sang những lĩnh vực mà LLM chưa thể dễ dàng làm tốt
- Cũng đã cân nhắc phương án quay lại đại học để học toán, thống kê, Machine Learning nâng cao và ứng tuyển vào vị trí nghiên cứu tại frontier lab
- Quốc gia đang sống không có frontier lab, còn số ít viện nghiên cứu hiện có thì bị quá nhiều ứng viên cạnh tranh
- Vì hoàn cảnh gia đình nên rất khó chuyển sang nước khác
- Ngay cả khi sau này có thể chuyển đi, vẫn có khả năng RSI (cải tiến tự đệ quy) sẽ khiến nhà nghiên cứu trở nên không cần thiết
- Mức độ bế tắc lớn đến mức còn cân nhắc biến sở thích làm mộc thành nghề
1 bình luận
Ý kiến trên Hacker News
Cái gì cơ? Tôi điều khiển LLM cả ngày, nhưng tuyệt đối sẽ không đồng ý trở thành người chịu trách nhiệm cho một sản phẩm tài chính
Trụ cột đầu tiên vẫn còn nguyên. Có thể tác giả không nhận ra tầm ảnh hưởng của mình, nhưng bằng chứng là các PR bị hoàn tác cho thấy khi tôi bước ra ngoài lĩnh vực mà mình hiểu sâu, tôi không còn có thể phân biệt được lúc nào agent đang nói nhảm. Ngay cả agent cấp cao nhất của chúng tôi, vốn còn có quyền truy cập vào hệ thống phân tán như tác giả nói, cũng thường xuyên sai, tầm nhìn hẹp, và liên tục làm những điều ngớ ngẩn. Cuối cùng, chính chuyên môn của các kỹ sư trong nhóm lại đưa mọi thứ về đúng quỹ đạo
Mythos đã tự tin kết luận rằng một phần codebase của chúng tôi vi phạm một quy định cụ thể, và nói rằng nếu vận hành theo cách hiện tại thì sẽ có rủi ro nghiêm trọng. Nhưng thực tế không phải vậy; nó đã ảo giác ra yêu cầu tuân thủ đó. Tôi biết được điều này vì đoạn code đó đã được cố vấn pháp lý là con người xem xét. Người ta nói đây là mô hình tối tân nhất hiện có. Tôi dùng rất nhiều AI tạo sinh để hỗ trợ viết mã, nhưng ngay cả trong trung hạn cũng không thể thực sự dựa vào những công cụ kiểu này để xây dựng sản phẩm tài chính tuân thủ quy định. Làm vậy hoàn toàn điên rồ. Đúng là nhiều công ty FinTech đang dùng agent để tăng tốc, nhưng nếu đem nó dùng để phát hành sản phẩm mà con người chưa thật sự đào sâu kiểm tra thì đang tự gánh một rủi ro khổng lồ
Trước thời LLM, ở hầu hết công ty vẫn có chỗ cho cả kỹ sư xuất sắc lẫn kỹ sư bình thường cùng làm việc. Sau LLM, có lẽ chỉ những kỹ sư “giỏi nhất” mới sống sót được. Vì giờ đây không còn cần đến kỹ sư bình thường nữa. Do đặc thù của HN, phần lớn kỹ sư đọc bài này sẽ nghĩ rằng mình thuộc top 10~5% theo chuẩn công ty/thành phố/quốc gia, nên sẽ cho rằng mình không phải loại kỹ sư “bình thường” sẽ bị ảnh hưởng bởi việc áp dụng LLM. Về mặt thống kê thì rất có thể họ sai. Cuối cùng đây là vấn đề lòng tự tôn. Khả năng cao là bạn không phải ngôi sao rock, và LLM rốt cuộc có thể lấy mất công việc của bạn. Như mọi khi, kẻ thắng chỉ là doanh nghiệp và các lãnh đạo cấp cao; còn phần lớn chúng ta ở cuối chuỗi thì sẽ chịu thiệt
Trường hợp tôi gặp là developer đã vibe coding một phần, và vì không hiểu sâu yêu cầu hay chính đoạn mã của mình nên phải lặp đi lặp lại nhiều lần mới sửa xong. Có thể gọi đây là vấn đề con người, nhưng hiệu ứng ròng mà tôi thấy là thế này. Trong các trường hợp phức tạp, kiểu như trước đây là “thời gian viết PR khá dài + thời gian review khá dài” giờ đã thành “thời gian viết PR rất ngắn + thời gian review dài hơn”. Tôi không biết trong những trường hợp như vậy có lợi ích thực sự nào không. Đôi khi code dù đúng về mặt chức năng nhưng lại rườm rà với quá nhiều hàm trung gian, và có vẻ sẽ ảnh hưởng đến các lần review sau này
Tôi cũng có cùng mối lo ngại, nhưng thường bị phớt lờ hoặc gạt đi bằng kiểu lập luận “tốc độ triển khai và ROI đáng giá như vậy nên đừng lo”
Cá nhân tôi thấy mọi công ty FinTech mình tiếp xúc đều đã có thứ gì đó như tài khoản AI cho developer từ năm ngoái. Ngay cả ở những nơi như Jane Street, nhân viên cũng đăng blog nói rằng phần lớn công việc của họ là chỉ huy agent. Theo anh thì công ty của anh còn cầm cự được bao lâu?
Tôi thấy rất nhiều bình luận kiểu “AI không thể làm X với độ chính xác 80~100%, nên nghề của chúng ta vẫn an toàn”
Tôi không muốn nghe quá bi quan, nhưng các mô hình đang cải thiện rất nhanh. Nếu khoảng 3 năm trước ai đó mô tả tình trạng hiện nay và nói rằng “mô hình có thể tạo ra toàn bộ một ứng dụng MVP chỉ trong khoảng 30 phút với một prompt”, thì điều đó hẳn sẽ nghe như khoa học viễn tưởng. Những trở ngại mà mô hình đang gặp hiện nay — như giảm tỷ lệ ảo giác, bảo đảm tuân thủ quy định, duy trì codebase gọn gàng — không có vẻ là còn quá xa mới giải quyết được. Ngay cả việc lấy thông tin cụ thể cũng đã phần nào khả thi thông qua nhiều máy chủ MCP/RAG. Tôi lo cho tương lai của các kỹ sư phần mềm. Khi những khiếm khuyết này được giải quyết, nghề này sẽ đứng ở đâu? Vai trò giao việc cho các mô hình AI? Không may là việc đó lại không đòi hỏi nhiều năm chuyên môn, nên là con dao hai lưỡi. Kiểm tra đầu ra của AI? Chỉ cần yêu cầu nó giải thích từng dòng mà mình không hiểu. Cũng như những người làm tính toán thủ công đã bị thay thế bởi máy tính số, tôi nghĩ chúng ta sẽ còn thấy làn sóng sa thải lớn hơn nữa. Làm các phép toán phức tạp trong đầu có thể là một thử thách thú vị, nhưng chậm hơn máy tính rất nhiều và dễ sai hơn. Tương tự, việc tự viết mã bằng tay có lẽ sẽ bị xem là một “thử thách” thú vị, còn AI sẽ trở thành máy tính cầm tay của thời hiện đại
https://youtu.be/5eqRuVp65eY?si=3fLT6S5q2OIUcu6r
Nhiều thứ sẽ tiếp tục được cải thiện đáng kể. Tuy nhiên, nếu nhìn vào lịch sử hiện đại của những biến động lớn do công nghệ tạo ra, có một mô thức lặp đi lặp lại. Giống như tuyết lở hay lũ quét, những thay đổi đột ngột này thường bắt đầu từ một hoặc vài đột phá quan trọng của một công nghệ cụ thể. Tốc độ thay đổi ban đầu rất nhanh và dữ dội, nhưng rồi dần chậm lại khi người ta hái hết những “quả thấp” mới xuất hiện và bắt đầu gặp các rào cản, ma sát mới trong những vùng đất mới. Ở giai đoạn đầu như vậy, việc ngoại suy nguyên xi tốc độ thay đổi bất thường gần đây sang tương lai thường có sức dự báo thấp. Những đợt bùng nổ cực đoan bất ngờ có xu hướng quay về đường xu thế dài hạn. Có thể xem sự xáo trộn hiện tại của LLM là kết quả của nghiên cứu tích lũy từ sau năm 2010, rồi bùng lên với bài báo Transformer năm 2017 và nhanh chóng kích hoạt hàng loạt nghiên cứu xung quanh nó. Nếu vậy, hiện tại có thể đang là giữa hoặc cuối giai đoạn bùng nổ mạnh của LLM. Tốc độ của các đột phá nền tảng, có phạm vi rộng, nâng toàn bộ các ứng dụng LLM lên rõ ràng đã chậm lại, và nhiều phát hiện có tác động lớn gần đây nằm ở việc mở rộng sang lĩnh vực cụ thể, tối ưu hóa, tinh chỉnh và sản phẩm hóa. Điều đó không có nghĩa là ngày mai sẽ không có một đột phá cỡ Transformer khác, nhưng xét về mặt lịch sử thì thiên nga đen hiếm khi đi thành bầy
Khách hàng sẽ không còn mua công cụ phần mềm như hiện nay, mà có thể tự làm toàn bộ phần mềm họ cần nội bộ hoặc nhờ tư vấn prompt engineering làm giúp. Đó có thể là một thế giới rất khác
Hay sẽ chỉ còn khoảng 700 công ty khởi nghiệp một người trên toàn thế giới, còn những người khác đều không có việc làm? Là Matrix à?
Năng suất không tăng thêm nhiều đến thế so với lúc Claude 3.5 ra mắt. Tôi có quyền truy cập không giới hạn vào mọi LLM, nhưng phần lớn đều là rác, và tôi phải sửa nhiều hơn là thứ chúng tiết kiệm được cho tôi. Những người hưởng lợi từ công cụ này chỉ là những người tung ra kết quả chất lượng thấp thật nhanh. Nếu bạn không đồng ý thì bạn cũng là kiểu người đó thôi
Lộ trình sự nghiệp của tôi giống tác giả một cách đáng kinh ngạc. Kỳ lạ là phần mà tác giả xem là trụ cột đầu tiên sụp đổ thì giờ lại có vẻ còn vững nhất
LLM liên tục thất bại trước tính đặc thù trong hoạt động kinh doanh của chúng tôi. Những thứ như luật thuế địa phương, chi tiết của quy trình kế toán, hay sự đặc thù trong cách triển khai sổ cái của chúng tôi. Nó rất giỏi trong việc refactor, chuyển đổi giữa các ngôn ngữ và lần theo lỗi trong code hiện có, nhưng khi lặp lại và mở rộng trong domain của chúng tôi thì lúc nào cũng có nhiều chỗ sai tinh vi. Có thể là vì các công ty tôi từng làm cố tình xử lý những lĩnh vực phức tạp để xây dựng hào lũy cạnh tranh. Đó là những công ty tồn tại được vì không có cuốn sách nào trên đời để làm ra một bản sao, và bí quyết vẫn nằm trong nội bộ. Ngoài ra, nếu là một công ty FinTech nơi quản lý khuyến khích dùng AI để làm nhanh tài liệu thiết kế, thì điều đó có vẻ quá bất cẩn để kinh doanh thứ liên quan đến tiền bạc. Đặc biệt khi có khối lượng lớn giao dịch nhỏ, rất dễ phân bổ sai đến mức hàng triệu đơn vị. Những bug kiểu này thực sự rất khó xử lý. Sửa logic mới chỉ là bước 1; sau đó còn phải sửa dữ liệu tính sai trong cơ sở dữ liệu bất biến, xử lý quy trình tuân thủ và giao tiếp với khách hàng. Các bản sửa đổi trở thành cái bẫy mà tính năng mới và khả năng quan sát phải tính đến. Kiểu như: “Hãy nhớ rằng điểm bất thường trong dữ liệu ngày 2 tháng 2 là do sự cố X”
Tôi đang làm nhiều sản phẩm dựa trên mô phỏng vật lý, hoàn toàn xuất phát từ nguyên lý đầu tiên. Nhưng nếu giao cho nó mà không có nghiên cứu chủ động, tư duy và kiểm chứng, nó sẽ tạo ra code tính toán chậm hơn hàng trăm bậc độ lớn, đồng thời thêm vào những lối rẽ và đường tắt vô lý, kết quả là tạo ra phép tính vô dụng. Chuyện này xảy ra có lẽ khoảng 95% thời gian. Giám sát là cực kỳ quan trọng, và tư duy kiến trúc thì vẫn chưa thể outsource. Thứ có thể outsource chỉ là phần thực thi
Tất nhiên, kỹ sư phần mềm cấp cao thường là người có chuyên môn ở đây, nhưng đó không phải điều bắt buộc. Theo truyền thống, sẽ hữu ích cho năng suất ít ma sát nếu kỹ sư có thể tự xử lý khoảng 90% công việc mà không cần hỏi chuyên gia nghiệp vụ, nhưng chính sự “truyền thống” đó đã kết thúc, và đó là điểm cốt lõi bài gốc đang nói đến. Trong thế giới mới, công việc của kỹ sư cấp cao không phải là tự mình nắm chuyên môn domain đó, mà là khiến agent có được hoặc tiếp thu được nó, và đảm bảo rằng nó đúng theo cách có thể kiểm chứng. Những kỹ sư cấp cao cứ bám víu vào chuyên môn domain nghiệp vụ cao cấp như một thứ giúp mình an toàn sẽ sớm rơi vào ngõ cụt, không khác gì các kỹ sư junior chưa chuyển đổi
Chúng có vốn từ rất sâu nên nghe có vẻ hiểu biết hơn thực tế. Chúng viết code và debug lỗi hiển nhiên rất giỏi, nhưng một nửa trong đó là nhờ giàn thử nghiệm
Ý tưởng cốt lõi là cung cấp tài liệu cho LLM, rồi để LLM đặt nhiều câu hỏi nhằm giải quyết sự mơ hồ và khả năng hiểu sai. Tôi khuyên bạn nên xem thử Skills. Nó thực sự hữu ích. https://www.youtube.com/watch?v=6BB6exR8Zd8
Chúng tôi đã giải quyết được bằng các file claude.md/agents.md được tổ chức tốt. Chúng tôi cũng triển khai supermemory.ai vào đó, để những quyết định mới được đưa ra luôn được AI agent nhớ lại mỗi khi bắt đầu một phiên mới
Tôi luôn nhớ đến câu nói khét tiếng của Steve Jobs: “Ý tưởng thì rẻ”
Thực thi mới là tất cả, và nếu các LLM tuyến đầu giải quyết được phần thực thi, thì giờ đây ý tưởng trở thành cánh cổng dẫn tới sự sung túc. Nhưng bản thân sự sung túc không đảm bảo có được “lực bám giữ”. Điều thường bị bỏ qua là ý chí ở lại với công việc đó và sự quan tâm thật sự của con người. Nhiều người không đủ quan tâm hoặc không thực sự muốn xây dựng, duy trì và sở hữu một thứ gì đó. Có thể ra mắt V1 nhanh hơn, nhưng bạn có thể tiếp tục đổ công sức vào nó không? Một ví dụ hay là công cụ âm nhạc AI Suno. Giờ nó cho ra kết quả khá ổn. Nhiều người có thể có thế giới nhỏ của riêng mình để nghịch một lúc rồi nhanh chóng chán và rời đi, chỉ còn lại một số ít nhà sáng tạo năng suất cao biến nó thành một môi trường “giống như công việc”. Quy mô và tính kinh tế của việc ủy quyền và thực thi có thể đã thay đổi, nhưng vẫn còn rất nhiều yếu tố cần cân nhắc
Ngay cả với tư cách một người có kiến thức âm nhạc hạn chế, tôi cũng thấy vậy, nên các nhạc sĩ có lẽ còn phê phán hơn. Vài lần đầu thì rất ấn tượng và giai điệu cũng bắt tai. Trước đây nó từng nghe kỳ quặc ở phần nền, nhưng phần lớn đã được sửa. Tuy nhiên, sau vài chục bài thì mọi thứ luôn bắt đầu nghe giống nhau. Tất cả đều chung chung, bài hát không kể được câu chuyện nào, và có cảm giác như nhạc nền trong quảng cáo doanh nghiệp. Tôi đã thử viết prompt chính xác hơn nhưng không hiệu quả mấy, và hầu hết các chi tiết có thể làm bài nhạc thú vị hơn đều bị bỏ qua. Những kết quả thú vị nhất lại xuất hiện khi tôi khiến nó lệch quỹ đạo như một kiểu bug. Khi tôi yêu cầu trộn hai thể loại rất khác nhau, nó tạo ra một kết quả mang cảm giác bất an mà tôi không nhớ là từng nghe trước đó. Nhưng nếu muốn làm tiếp thì lúc nào cũng khó, và nó luôn cố quay về kết quả chung chung, bỏ qua chỉ dẫn chi tiết. Suno có thể làm remix. Nó giống với code. LLM rất giỏi trong việc porting một thứ đã hoạt động sang ngôn ngữ khác để nó tiếp tục hoạt động. Nhưng nếu chỉ có ý tưởng thì nó thất bại ở phần độc đáo. Để khiến LLM hiện thực hóa đúng ý tưởng, bạn phải đưa quá nhiều chỉ dẫn, đến mức phải vật lộn với sự mơ hồ của ngôn ngữ tự nhiên và rốt cuộc gần như chẳng khác gì tự viết code
Nếu bạn thúc đủ mạnh và có một hệ thống có thể cho ra code thực sự chạy được, thì có thể giải quyết được phần thực thi. Nhưng đó chính là engineering. Ở trạng thái mặc định hiện tại, nó còn rất xa mới có thể thay thế engineering. Có thể 3 năm nữa thì được. Mọi thứ đang tiến rất nhanh. Nhưng hôm nay bạn chưa thể chỉ nói “hãy làm cho tôi một trình biên dịch Rust tốt hơn” rồi ngả lưng chờ kết quả
Các bài đó là thứ tôi thích và đủ để tôi nghe trong playlist của mình, nhưng chúng không nhận được phản hồi lớn từ thuật toán của Suno. Tôi cũng không quảng bá chúng nhiều ở nơi khác, và ngay cả khi có đăng lên thì cũng chỉ được vài lượt thích. Tôi không thất vọng. Tôi làm nhạc cho chính mình, còn việc chia sẻ chỉ là tác dụng phụ. Kết luận tôi rút ra ở đây là cần rất nhiều công việc để khiến mọi người quan tâm và thích thú với thứ tôi tạo ra. Phải làm marketing, phải đưa nó ra trước mắt mọi người, phải khiến họ chú ý. Tôi cũng tin rằng cần gắn nó với video, câu chuyện, persona, hoặc một kiểu bầu không khí nào đó để cho họ lý do yêu thích. Để nó thực sự “bắt dính”, bạn phải lặp lại tất cả những điều đó với cùng một nhóm khán giả và khiến họ trở nên quen thuộc với nó. Vì vậy cần sự bền bỉ, và bạn phải thật lòng quan tâm tới thứ mình đang cố bán. Tôi phải bám với nó trước khi người khác bám với nó
https://en.wikipedia.org/wiki/Sturgeon%27s_law
Định luật Sturgeon nói rằng “90% mọi thứ đều là rác”. Châm ngôn này do nhà văn và nhà phê bình khoa học viễn tưởng người Mỹ Theodore Sturgeon đưa ra khi bảo vệ giá trị của thể loại này. Sturgeon cho rằng trong bất kỳ lĩnh vực nào, phần lớn tác phẩm đều có chất lượng thấp, vì vậy khoa học viễn tưởng không phải là thứ duy nhất kém cỏi một cách đặc biệt
Ấn tượng của tôi là chúng được dùng như công cụ tạo một phát ăn ngay. Tôi không rành âm nhạc, nhưng có vẻ với nghệ sĩ thì cần các bước trung gian, tách track, tùy biến nhạc cụ và nhiều yếu tố khác mà tôi không biết. Nếu không có những thứ đó thì tôi nghĩ khó mà dùng cho công việc chuyên nghiệp
Tôi không hoàn toàn đồng ý với bài viết này. Vibe coder không thể thiết kế, phát triển và triển khai một hệ thống có độ phức tạp trung bình mà không làm nổ tung mọi thứ
Một phần rất lớn của việc dùng tốt các ứng dụng như Claude là sự hiểu biết mang tính khái niệm và kinh nghiệm về các khái niệm khoa học máy tính. Đó là những thứ vibe coder tuyệt đối không có. Nếu có thì đã không phải là vibe coder nữa
Nếu là “không biết phải làm gì” thì cứ cưỡi con sóng thôi
Hồi website/web app là con sóng thì tôi cũng đã cưỡi nó. Tôi vào ngành phần mềm từ trước cả thời Internet và đã liên tục đổi ngựa giữa dòng. Không bao giờ là quá muộn để học công nghệ mới. Mỗi con sóng mới tạo ra những kiểu công việc và người lao động mới. Chỉ cần trở thành một trong số đó. Cưỡi con thú đó và làm chủ công cụ. Chỉ là cùng một trò chơi quay trở lại lần nữa thôi
Nếu có một kỹ năng luôn có nhu cầu ổn định, thì đó là khả năng cấu trúc mọi thứ trong đầu — công việc mới, quy trình mới, con người mới, bất cứ thứ gì. Tôi đã mài sắc và phát triển kỹ năng này khi làm thợ cơ khí chế tạo nguyên mẫu. Với ai chưa quen, thợ cơ khí chế tạo nguyên mẫu là người làm bất cứ điều gì cần thiết để tạo ra các chi tiết khó trong lịch trình ngắn hàng tuần. Kim loại, nhựa, thứ gì cũng làm. Bạn sẽ giỏi trong việc nhanh chóng làm quen với quy trình, máy công cụ và vật liệu. Làm vậy một thời gian thì bạn hấp thụ thông tin mới rất nhanh, và có thể hiểu công việc nhanh hơn cũng như chính xác hơn rất nhiều người khác. Ai cũng có thể bắt đầu. Chỉ cần tò mò và làm ra thứ gì đó. Rồi làm thêm nữa. Chia sẻ thứ bạn tạo ra và làm những gì người khác muốn
Những năm 90 và 00 từng có làn sóng “lập trình hướng đối tượng sẽ thay đổi mọi thứ”. Nghĩa là những việc trước đó ta đã làm thành công hàng trăm lần, giờ sẽ làm theo hướng đối tượng. Viết code liên quan đến máy bay à? Tôi thực sự đã được nghe ở đại học rằng chỉ cần mua một đối tượng máy bay toàn năng làm mọi thứ về máy bay. Nhưng hóa ra hướng đối tượng không phải thuốc tiên? Thế thì sinh mã, thử Ruby on Rails đi. Tạo website trong 2 giây. Sinh mã có ở khắp nơi. Rồi nó đi theo hướng kỳ quặc và TDD xuất hiện. Tôi từng thấy những cuộc trò chuyện thật sự kiểu như nếu không làm TDD thì nên bị tống vào tù vì là kỹ sư tệ hại. Không, không phải TDD, mà BDD mới là lời giải. Lean, không, Agile, không, agile viết thường, nhưng ban đầu là thế, không, Scrum, không, XML, khoan, đó là chuyện của 10 năm trước rồi, JSON, và cuối cùng là SAFe. Và giờ là “bạn đã thấy chatbot này chưa?”. Mỗi vòng lặp đều mang lại điều tốt nếu bạn chú ý. Nhưng nó cũng mang theo rất nhiều cường điệu và bất an. Cứ thử nghiệm và học hỏi thôi. Có một điều với tôi vẫn không đổi: gần như ai cũng thà chết còn hơn phải suy nghĩ cẩn thận về kết quả khi giấc mơ của họ thực sự thành hiện thực. Chừng nào điều đó vẫn còn đúng, người ta sẽ tiếp tục trả tiền cho ai đó cưỡi con rồng trào lưu bị thổi phồng thay mình
Toàn bộ dây chuyền tạo ra kết quả chất lượng thấp này — à không, “AI native” — vận hành như sau. “Wow, tôi đã dỗ chatbot làm ra thứ mà bản thân tôi hoàn toàn không hiểu. Tôi giỏi việc này ghê!” Nó như một giải khuyến khích cho việc tạo ra thứ gì đó. Một cái gì khác tạo ra nó, còn tôi nhận công mà thậm chí chẳng hiểu rõ. Nỗ lực của tôi không có lãi kép. Không có bài học rút ra. Không có sự hiểu biết tích lũy. Không có insight dẫn đến đổi mới trong tương lai. Không có sự khác biệt hóa. Chỉ là gào vào khoảng không đến mức tê liệt đầu óc, rồi cái máy đánh bạc nhả ra một mớ pha tạp chất lượng thấp trông “đủ ổn”, và hôm sau lại lặp lại. Nếu đó là trò chơi thì tôi xin rút. Người khác thích thì tốt cho họ thôi, nhưng nghĩ rằng ở đây có sự tinh thông nào đó thì là tự huyễn hoặc. Điều kiện duy nhất để “thành công” với công cụ này là ngừng quan tâm và đầu hàng
Tôi đã đăng cái này trước đây, nhưng đáng để đăng lại
Tôi làm DevOps ở một công ty rất tích cực sử dụng LLM. Các giai đoạn đại khái là thế này. Thử bắt LLM làm “rất nhiều thứ”, bắt nó làm nhiều hơn nữa, chạy nhiều agent, rồi quay lại một agent duy nhất nhưng để nó tạo công cụ, và sau đó chuyển sang công cụ có tính quyết định mà cả con người lẫn LLM đều có thể dùng. Lý do là thế này. Trong cả triển khai lẫn kiểm thử, công cụ có tính quyết định cho câu trả lời nhị phân và có thể lặp lại. Khi có sự cố, luôn có thể quay lại công cụ mà con người chạy được. Nó nhanh hơn. Script đơn giản chạy dưới 30 giây, nhưng “ảo giác nghe có vẻ hợp lý” dường như lúc nào cũng mất 2–3 phút. Cuối cùng thì lại quay về bài này. https://spawn-queue.acm.org/doi/10.1145/3194653.3197520 Tức là “lập danh sách tác vụ, viết script cho từng tác vụ, kết hợp các script thành hàm, và các hàm trở thành hệ thống”. Nói thêm là, nếu để LLM làm theo ý nó thì nó sẵn sàng viết code. Có thể thêm test để kiểm tra test có hoạt động không. Trước đây ta vẫn làm vậy với code của con người mà. Cũng có thể đọc code. Khi đọc code thì thấy nó đôi khi vừa tạo ra code chạy được, vừa làm những thứ hoàn toàn điên rồ. Con người cũng vậy, nhưng đó là chuyện khác. Cuối cùng, bạn vẫn phải kiểm tra xem hệ thống được tạo ra có hợp lý hay không. Nói ngắn gọn hơn, coding có thể đã chết nhưng software engineering thì vẫn sống khỏe và chạy tốt
Bạn có thể bắt một LLM lớn làm mọi thứ. Điều đó khả thi và người ta thực sự vẫn làm. Nhưng nó cực kỳ tốn tiền và mất thời gian. Thay vào đó, nếu dùng AI để tạo công cụ xử lý một cách quyết định càng nhiều tác vụ trong quy trình càng tốt, rồi để AI dùng những công cụ đó, thì hệ thống sẽ chạy nhanh hơn và rẻ hơn nhiều. Thêm nữa, cuối cùng bạn còn có thể bỏ AI đám mây đắt đỏ và chuyển sang chạy bằng mô hình cục bộ cỡ nhỏ/trung bình
Nếu hình dung về tương lai của tác giả là đúng, thì các kỹ sư phần mềm giỏi vẫn an toàn
Kiến thức miền có thể học nhanh hơn rất nhiều so với việc học cách áp dụng các nguyên tắc kỹ thuật tốt. Những kỹ sư mà năng lực cạnh tranh chủ yếu là kiến thức miền có lẽ lại không quá xuất sắc về bản thân kỹ thuật phần mềm. Dù vậy, họ vẫn có thể tìm được việc ở những mảng khác trong ngành nơi cần đến kiến thức miền đã tích lũy
Rất nhiều kỹ sư phần mềm giỏi đã phá hỏng vô số hệ thống ERP vì kiêu ngạo cho rằng kiến thức miền là thứ có thể nắm được dễ dàng. Một phần khổng lồ của IT, theo đúng nghĩa đen, là đưa các quy tắc kinh doanh vào hệ thống
Thế nhưng tôi vẫn thấy và vẫn review code của những nhà phát triển phần mềm “chuyên nghiệp” không tuân theo các thực hành kỹ thuật phần mềm tốt. Câu nói rằng những kỹ sư có lợi thế cạnh tranh chính là kiến thức miền có thể không giỏi về kỹ thuật cũng đúng tương tự với những kỹ sư không có kiến thức miền. Ít nhất là theo kinh nghiệm của tôi. Có thể chỉ là chúng tôi kém may mắn
Bởi kiến thức miền có giá trị không phải là kiến thức của hôm qua, mà là kiến thức của hôm nay và ngày mai. Trong các lĩnh vực mà kiến thức miền quan trọng, nó đan xen sâu sắc với kỹ thuật. Bạn sẽ không giao cho Jeff Dean phát triển Unreal Engine từ đầu. Dù vậy, vẫn có nhiều nguyên tắc kỹ thuật phần mềm mà các chuyên gia kiến thức miền chưa hoàn toàn nội tại hóa hoặc chưa thực thi đầy đủ. Chừng nào kiến thức miền còn có giá trị, tình trạng này vẫn sẽ tiếp diễn. Vì kỹ thuật phần mềm bản thân nó cũng là một miền nữa
So với việc tích lũy chuyên môn, phương pháp luận có thể cải thiện nhanh hơn nhiều. Cái trước là vấn đề về cách tiếp cận nên có thể ép buộc và kéo lên rất nhanh. Cái sau phụ thuộc vào khuynh hướng học tập, năng lực và thời gian sẵn có của người đó, và không thể cưỡng ép vượt quá mức hỗ trợ hợp lý. Nó cũng có tính chất tự tích lũy, nên đường cong học tập ban đầu dốc hơn nhiều
Tôi đang dùng Claude Code và Opus 4.7, và vấn đề không hẳn là code do nó tạo ra sai, mà là nó có xu hướng viết quá nhiều
Việc nghĩ về một tính năng cụ thể và đặt nó vào code theo cách phù hợp nhất vẫn rất có giá trị. Claude thường chọn một tầng nào đó trong stack, ví dụ tầng trình bày, rồi nhét nó vào đó. Vài tuần sau khi cùng một dữ liệu lại cần ở nơi khác, Claude không thể tái sử dụng code ở tầng service mà thực hiện kiểu “cấy ghép”. Nếu con người không để ý, lượng code sẽ tăng gấp đôi và logic bị trùng lặp. Tôi không nghĩ các công cụ AI như Claude sẽ sớm khá hơn ở điểm này. Nơi tôi làm việc hiện đã có áp lực giảm dùng Opus 4.7 để tiết kiệm chi phí. Có người còn nói hãy dùng model nhỏ hơn cho “các bản sửa lỗi đơn giản”. Thỉnh thoảng điều đó có thể đúng, nhưng trên thực tế thì bao nhiêu lần chúng ta biết trước đó là một bản sửa lỗi đơn giản? Nếu chi phí tăng lên, có lẽ sự quan tâm đến việc dùng công cụ này để viết “mọi đoạn code” sẽ giảm xuống. Khi mọi người chuyển sang các model rẻ hơn và kém hiệu quả hơn, áp lực đòi không cần review code đó cũng có khả năng biến mất. Rồi cuối cùng mọi chuyện sẽ đi đến đâu thì cứ chờ xem, nhưng có lẽ sẽ không thay đổi kịch tính đến mức như tác giả lo sợ
Chỉ cần bảo AI cắt một nửa số dòng code chạy production và xem có thư viện nào khác có thể tái sử dụng không, đã hiệu quả đáng ngạc nhiên. Có lẽ cũng có thể làm một bot refactor để tìm và tách phần trùng lặp ra. Hiện giờ chưa được cung cấp sẵn, nhưng rõ ràng không phải là bất khả thi
Tuy nhiên, câu hỏi còn bỏ ngỏ là liệu quá nhiều code có thực sự là vấn đề hay không. Những công cụ này giờ đã là một phần của cuộc sống. Nếu chúng giải quyết vấn đề hoặc debug nhanh hơn, và phần mềm có ít bug hơn, thì có thể đó không phải là quá nhiều code mà là số dòng code vừa đủ
fooBar()vàfooBarExtended()Hàm sau có thêm tham số và tính năng cần cho vấn đề hiện tại. Thế nhưng thay vì gọi hàm đó, Claude cứ cố thêm các tham số mở rộng y hệt vào hàm đầu tiên. Ngay cả sau khi tôi bảo đừng làm vậy, sau đó nó vẫn lại đề xuất y như thế, đôi lúc thật sự rất bực
Dù nhìn nhận tương lai của ngành thế nào đi nữa, tôi thấy rất khó để tìm được thành công nghề nghiệp lớn hơn ở nghề mộc thủ công so với phần mềm thủ công
Tôi từng được bảo hãy thử bán đồ nội thất mình làm ra, nhưng câu trả lời của tôi luôn như nhau. Tôi từng mắc sai lầm biến sở thích thành nghề nghiệp một lần rồi, và không định lặp lại sai lầm đó. Ít nhất thì phần mềm hiện vẫn trả tiền khá tốt
Có một người làm cùng tôi chuyên dựng deck, làm vườn, caravan, nhà kho và hàng rào, và anh ấy kiếm rất khá. Tất nhiên nói công bằng thì anh ấy cũng cực kỳ giỏi
Khung cửa bị mục nên tôi đã trả cho thợ mộc 4.000 USD để làm đồ thay thế. Nếu thay cả cánh cửa thì rất dễ tốn tới 25.000 USD. Nếu chuyển đến một khu lịch sử lớn nơi có nhiều cửa chạm khắc tay, bạn có thể kiếm được kha khá tiền
Nhưng tỷ lệ thị trường muốn trả tiền cho phần mềm làm bằng tay thì đúng bằng 0%
Không phải nghề mộc mà là làm nông. Bạn phải kiếm đất và tự trồng thứ để ăn. Không tham gia vào nền kinh tế nữa là cách sống sót duy nhất