Tác nhân lập trình đã thay thế mọi framework tôi từng dùng
(blog.alaindichiappari.dev)> "Kỹ nghệ phần mềm đã quay trở lại"
- Khi kỷ nguyên lập trình tự động hóa mở ra nhờ sự phát triển của các mô hình AI frontier và coding agent, công việc thủ công phải tự gõ từng dòng code đang biến mất, cho phép kỹ sư phần mềm quay lại tập trung vào thiết kế và tư duy cốt lõi
- Từ cuối năm ngoái, mức độ trưởng thành của công cụ và mô hình đã tăng mạnh, khiến một cách làm việc trở nên khả thi: tập trung vào vai trò kiến trúc sư nhưng vẫn có thể trực tiếp can thiệp và chỉnh sửa khi cần
- Trong phát triển web, mobile và desktop, những framework và tầng trừu tượng không cần thiết tích tụ lâu nay không giải quyết được độ phức tạp thực sự mà còn làm vấn đề tăng thêm
- Trong ba vấn đề mà framework tuyên bố giải quyết — đơn giản hóa, tự động hóa, giảm chi phí lao động — chỉ có tự động hóa là từng có giá trị chính đáng, nhưng ngay cả điều đó giờ cũng có thể bị AI tự động hóa thay thế
- Thay vì bị hạ xuống thành người vận hành (operator) cho các hệ thống do Google, Meta, Vercel và các hyperscaler thiết kế, chúng ta nên quay về với kỹ nghệ thực thụ: tự tay tạo ra thiết kế và sản phẩm của riêng mình
Sự trỗi dậy của lập trình tự động hóa
- Cách diễn đạt "automated programming" mà Antirez đặt tên nắm bắt đúng bản chất hơn nhiều so với "vibe coding"
- Giống như máy in, máy dệt hay dây chuyền lắp ráp, tự động hóa luôn là cốt lõi của các cuộc đổi mới trong lịch sử, và thay đổi lần này cũng nằm trên cùng một đường hướng đó
- Sau tháng 12 năm 2025, năng lực của các mô hình frontier và coding agent đã thay đổi mạnh mẽ, đến mức với những ai quan sát kỹ thì điều này đã quá rõ ràng
Sự thay đổi trong vai trò của kỹ sư
- Những công việc đòi hỏi tư duy sâu như kiến trúc, trade-off, quyết định sản phẩm hay edge case vẫn còn nguyên
- Thứ biến mất là lao động thủ công mệt mỏi và hao mòn của việc phải tự tay gõ mọi dòng code
- Nếu dùng mô hình và công cụ trong một môi trường được thiết lập sạch sẽ và kỹ lưỡng, bạn có thể đảm nhận vai trò kiến trúc sư mà không cần tự mình xếp từng viên gạch
- Điều đó vẫn cần nền tảng từ 20 năm kinh nghiệm tự viết code; nếu không hài lòng, bạn vẫn có thể trực tiếp đi vào, hiểu, chỉnh sửa rồi cập nhật cấu hình
- Bạn có thể tạo ra công cụ cần thiết ngay lập tức, từ đó dành nhiều thời gian hơn để hiện thực hóa công nghệ mình hình dung
Framework và độ phức tạp không cần thiết
- Trong phát triển web, mobile và desktop, qua nhiều năm đã tích tụ một mớ ô nhiễm khổng lồ từ framework, thư viện và tooling
- Các tầng trừu tượng không trừu tượng hóa được điều gì có ý nghĩa cứ chồng chất lên nhau, tuyên bố giải quyết một vấn đề nhưng lại tạo ra mười vấn đề mới
- Toàn bộ ngành đã chọn cách mua sẵn tư duy đóng gói, thay vì mài sắc tư duy trước độ phức tạp thực sự của việc xây dựng phần mềm
- Nó giống như quấn lụa quanh một cái chân bị gãy: bề ngoài trông đẹp hơn nhưng cái chân vẫn gãy như cũ
Ba vấn đề mà framework tuyên bố giải quyết
- "Đơn giản hóa (Simplification)": hiện tượng kỹ sư sợ tự mình thiết kế nên mù quáng chấp nhận cấu trúc của người khác
- Thay vì thiết kế ngược từ mục tiêu, họ áp dụng thiết kế one-size-fits-all vào mọi nơi
- Đó không phải đơn giản hóa mà là đầu hàng về mặt trí tuệ (intellectual surrender)
- Tự động hóa (Automation): giá trị duy nhất thực sự có thể chấp nhận được là loại bỏ boilerplate code
- Tự động hóa những việc lặp đi lặp lại nhưng thiết yếu như ORM, quản lý CRUD, sinh code hay tài liệu hóa API
- Nhưng chính ở điểm này AI đang thay đổi mọi thứ
- Giảm chi phí lao động (Labour cost): lý do thầm lặng không bao giờ xuất hiện trên slide hội thảo
- Nếu để Google, Meta, Vercel quyết định cách xây sản phẩm và triển khai code, bạn có thể thuê một "React developer" thay vì kỹ sư phần mềm
- Không cần đào tạo, plug-and-play, dễ dàng thay thế như một bánh răng (cog) trong bộ máy
- Đó không phải kỹ nghệ mà là vận hành (operating)
Thực tế của cách làm việc mới
- Tôi đã phát triển theo cách này hơn 2 năm gần như không có lỗi đáng kể, và cuộc cách mạng thực sự bắt đầu từ tháng 12 năm ngoái
- Một cơ hội đã mở ra để loại bỏ độ phức tạp không cần thiết và tập trung vào độ phức tạp xoay quanh ý tưởng
- Chi phí loại bỏ boilerplate gần như tiến về 0, không còn phải viết cùng một đoạn code hai lần
- Có thể lập tức xây dựng những công cụ nhỏ chuyên biệt theo đúng mục đích để khớp chính xác với vấn đề
- Không cần các monorepo manager hào nhoáng, một Makefile đơn giản đã đáp ứng 99% use case
- Khi vấn đề thực sự trở nên rất phức tạp thì lúc đó mới nghĩ tiếp; trước đó tuyệt đối không giải trước mới là kỹ nghệ
- Cần giải quyết vấn đề bạn đang có ngay bây giờ, chứ không phải vấn đề mà ai đó trên sân khấu hội thảo nói rằng một ngày nào đó bạn có thể gặp
Tái khám phá Bash và các công cụ cơ bản
- Agent rất thành thạo với các công cụ cơ bản (basic tools) đã tồn tại suốt hàng chục năm
- Bash ra đời năm 1989, và ngay cả mô hình tầm thường nhất hiện nay cũng hiểu Bash tốt hơn bất kỳ con người nào trên thế giới
- Các coding agent đang có xu hướng chuyển từ những cấu hình MCP phức tạp và tốn kém sang vòng lặp agent đơn giản dựa trên Bash
- Những công cụ lâu đời nhất lại chính là những công cụ phù hợp nhất cho tương lai (most future proof)
Cái giá của sự phụ thuộc vào framework
- Với phần lớn use case, không cần những framework đắt đỏ, nhiều lỗi cùng các thư viện đi kèm khi bạn chỉ dùng 10% tính năng của chúng
- Chi phí vô hình như bảo trì, cập nhật bảo mật và các ràng buộc thiết kế là rất lớn, và chúng hạn chế tự do của lập trình viên
- Nếu tiếp tục chấp nhận trade-off này, chúng ta sẽ bỏ lỡ cơ hội lớn nhất trong nhiều thập kỷ
- Hãy cảnh giác với cấu trúc lệ thuộc vào triết lý thiết kế của các tập đoàn lớn như Google, Meta, Vercel
- Lập trình viên cần tin vào tư duy và cảm quan thẩm mỹ của chính mình, đồng thời xây dựng công cụ và sản phẩm của riêng mình
> “Đừng quấn lụa quanh một cái chân gãy; hãy tạo ra thứ thực sự là của riêng bạn”
- Lập trình viên cần tin vào tư duy và cảm quan thẩm mỹ của chính mình, đồng thời xây dựng công cụ và sản phẩm của riêng mình
5 bình luận
Đây đúng là một phương pháp phát triển khiến việc bảo trì trở nên khó khăn theo đúng nghĩa. Trong thời đại AI, đây là người đang thực hành cách giữ vững chỗ đứng của mình suốt đời trong kỷ nguyên mới.
Mình thật sự không đồng cảm với câu kiểu như “những framework và thư viện phụ trợ đắt đỏ, đầy lỗi nhưng trong đa số use case chỉ dùng 10% tính năng”.. Chẳng phải việc chọn một môi trường có quy mô phù hợp với dự án vốn là một đức tính tốt sao. Nếu có vẻ như sẽ không làm nhiều tính năng thì cứ dùng thứ nhẹ như
expresslà được mà. Có nhất thiết ngay từ đầu phải tự làm ra thứ để thay thếexpresskhông..Nếu nói là nhiều tính năng nhưng lại chẳng dùng bao nhiêu thì ngược lại mình thấy web server như Apache hay nginx còn đúng kiểu đó hơn, nhưng chẳng lẽ vì chúng nặng mà lại đi làm web server từ đầu sao, cứ cấu hình rồi dùng thôi
Đã có những framework được tổ chức bài bản và có rất nhiều tài liệu mà AI đã học, vậy thì liệu có nhất thiết phải tự tạo ra thứ gì đó mới của riêng mình không; ngược lại, điều đó có vẻ còn làm giảm năng suất.
Tôi không nghĩ cần phải vứt bỏ những gì đã giúp giảm chi phí thiết kế kiến trúc và cho phép chúng ta tập trung vào phần cốt lõi (dịch vụ).
Ừm... có phải kiểu thực hành này là từ thời Cursor còn cung cấp mức sử dụng không giới hạn không... Thay vào đó, ít nhất trong một thời gian tới, hướng đi sắp tới có vẻ sẽ là làm sao tiết kiệm token và hỗ trợ AI cho tốt hơn nhỉ?
Ngay cả khi không cần giá token đắt đỏ mà vẫn có thể loại bỏ trùng lặp, thì có lý do gì để không dùng framework chứ?
Ý kiến trên Hacker News
Có vẻ trong tương lai gần, nhiều lập trình viên và công ty sẽ chịu cú sốc lớn vì sự khoa trương với AI
Hiện giờ có thể tạo ra thứ gì đó bằng AI, nhưng vấn đề thật sự nằm ở những phần mà nếu không tự va chạm thì sẽ không hiểu được
Cuối cùng, những người chỉ làm ‘vibe code’ sẽ đụng phải giới hạn thực tế, và chỉ những ai hiểu cách hệ thống thực sự vận hành mới sống sót
Họ có thể sửa và merge bug chỉ trong 2 phút, và việc “hiểu hệ thống” với “không trực tiếp viết code” hoàn toàn có thể cùng tồn tại
AWS đang đặt cược rất lớn vào hướng này, và khi các công cụ phi xác định ngày càng ổn định hơn, khả năng vượt qua chất lượng ở mức con người là rất cao
Nếu giao việc mà không hiểu, thì không thể đảm bảo độ chính xác, khả năng bảo trì hay khả năng mở rộng của kết quả
Nhưng nếu phải làm việc cùng những người như vậy, thì tôi sẽ tự hỏi vì sao phải trả cho họ hàng trăm nghìn đô, lại còn thêm phí thuê bao LLM nữa
Tất nhiên sẽ có những app làm bằng ‘vibe coding’ bị hỏng, nhưng những đội vừa làm test, quản lý phiên bản và tài liệu hóa song song thì ngược lại sẽ càng phát triển hơn
Cuối cùng, cách tiếp cận cân bằng mới là điều quan trọng
Biết đâu một ngày nào đó sẽ xuất hiện cả ‘de-slopper bot’
Lý do dùng framework là vì những người thiết kế nó đã từng gặp nhiều vấn đề và bài toán scale hơn tôi
Lúc đầu dự án thì dễ, nhưng khi quy mô lớn lên thì việc thiết kế lại rất đau đớn
Đọc những bài như thế này, nhiều lúc còn thấy chính bài viết có vẻ như do LLM viết ra
Những phép so sánh kiểu ‘cắt rồi khâu gạch lại’ lại càng cho thấy sự mâu thuẫn đó
Tự xây cả stack vẫn rất kém hiệu quả và chi phí bảo trì cao
Dù vậy, điểm khác bây giờ là ta có thể dễ dàng tạo ra các component tùy biến phù hợp với bài toán hơn
Không cần học cái mới, cứ dùng framework quen thuộc là đủ
Vấn đề của tôi, vấn đề của nền tảng, và vấn đề phải lách qua framework
Một bài viết than phiền về nỗi đau khi viết code nghe khá lạ. Viết code thật ra lại là phần dễ
Nếu Tolkien mà dùng AI, có lẽ ông ấy sẽ phí thời gian vào việc chỉnh prompt
Đặc biệt ở những phần khó, sự trợ giúp từ AI lại càng dễ phản tác dụng
trong các bài về AI lại nói “AI viết code thay để ta tập trung suy nghĩ”
Nếu là cùng một nhóm người thì khá mâu thuẫn
Dạo này giao cho Claude Code thì phần lớn đều được giải quyết trong vài phút
Nhưng tôi vẫn tin code do mình viết hơn. Cuối cùng, quan trọng không phải tốc độ mà là độ sâu của sự hiểu biết
Giống như Warhol, nếu biết tận dụng tốt công cụ mới thì đó cũng là nghệ thuật
LLM chỉ là công cụ hỗ trợ giai đoạn đầu của sáng tạo, còn thiên tài vẫn đến từ con người
Việc thấy phiền với các bản vá bảo mật Node.js là một sự hiểu lầm
Đó là một đặc quyền. Giải pháp tự làm thì không có cộng đồng bảo mật hỗ trợ và còn nhiều lỗ hổng hơn
Có thể dễ dàng tuyển được lập trình viên React, nhưng không có lập trình viên nào cho “framework độc quyền do AI tạo ra”
Chẳng có gì quá ghê gớm
Có tồn tại điểm trung gian giữa coding agent và framework
Tôi vẫn dùng cùng những công cụ cũ, nhưng agent xử lý các việc lặp đi lặp lại, còn
tôi tập trung vào kiến trúc và các edge case
Phớt lờ agent hay mù quáng tin nó đều là cực đoan
Năng lực thật sự là biết khi nào cần cầm vô lăng
Vấn đề của bài này là nó đặt framework và ‘kỹ thuật thực thụ’ vào thế đối lập
Những nền tảng như Vercel, Next.js, Firebase giúp triển khai ngay lập tức và CI/CD trở nên khả thi
Nghĩ lại thời phải tự dựng Jenkins ngày xưa thì đúng là một cuộc cách mạng
Kỹ thuật thực sự không phải là ‘phát minh lại’, mà là đưa sản phẩm đến tay khách hàng thật nhanh
Việc AI tái hiện lại framework hiện có mà chưa qua kiểm chứng thực chiến là kém hiệu quả
Nếu không có hệ sinh thái và các pattern chung thì rất khó cộng tác
Việc lập trình viên ít kinh nghiệm dùng AI sai cách cũng chẳng khác gì ngày trước
Tự làm lấy thì sẽ mất tài liệu, middleware và cả khả năng bảo trì
Kiểu như mới nhận ra rằng “à, API có thể nối với nhau”
Nhưng những khám phá như vậy không đồng nghĩa với hiểu được các trade-off
Trong 6 tháng gần đây tôi đã làm phát triển embedded bằng Cursor + Opus 4.x
LLM không chỉ giúp về phần mềm mà còn hỗ trợ cả thiết kế mạch, CAD, CNC
Ví dụ, tôi đã hoàn thành hàm wrapper cho màn hình dựa trên ST7789 chỉ với ba prompt
Giờ tôi hầu như không dùng thư viện nào ngoài LVGL, TinyUSB, nén và mã hóa
Những hàm chuyên biệt theo mục đích do LLM tạo ra thì nhỏ, nhanh và không có lớp trừu tượng thừa thãi
Tôi nghĩ đã đến lúc nhiều thư viện nên rời sân khấu
Những thứ như .NET thì không thể thay thế, nhưng các bộ hàm đa dụng thì hoàn toàn có thể bị thay thế
Phần vất vả của việc lập trình không nằm ở gõ phím mà là hợp tác với con người, kiểm thử và tư duy thiết kế
Gần đây việc khó nhất với tôi là thiết kế cấu trúc dữ liệu lock-free
Trong thời đại LLM, giá trị của framework lại càng lớn hơn
Nhờ dữ liệu huấn luyện, LLM rất mạnh với các pattern quen thuộc như React
Việc con người có thể can thiệp để debug cũng rất quan trọng
Dù AGI có xuất hiện đi nữa, cũng không có lý do gì để không tiếp tục học những framework hiệu quả
Bản thân những cuộc đối thoại như vậy cũng là một thí nghiệm thú vị