Kỹ nghệ trong thời đại LLM

• Bài viết tổng hợp 1 năm rưỡi suy ngẫm tại Reindeer về cách xây dựng sản phẩm và tổ chức phát triển trong thời đại LLM, với mọi nhận định đều bắt đầu từ việc xem ngữ cảnh của con người (human context) là tài nguyên khan hiếm nhất
• Lượng nội dung được tạo ra bùng nổ nhưng tốc độ tiêu thụ của con người vẫn giữ nguyên, và khoảng cách đó trở thành nút thắt mới — cần chặn vòng luẩn quẩn slop nuôi slop (slop feeds slop)
• Những quyết định mang tính cấu trúc như mô hình hóa và thiết kế API vẫn là phần việc của con người, và cần có người dám nói "không" với các đầu ra do LLM tạo ra
• Không thể thắng LLM chỉ bằng code review, nên cần xây dựng các lớp phòng thủ dựa trên tự động hóa và kỷ luật như linter, LLM judges, PR nhỏ
• Năng lực cốt lõi của lập trình viên không còn là kiến thức kỹ thuật sâu mà là khả năng chuyển đổi ngữ cảnh và kích thước context window của chính mình; người thích nghi sẽ trở nên siêu năng suất, còn người không thích nghi sẽ trở thành giá trị âm ròng (net negative) cho cả đội

---

Ngữ cảnh của con người là tài nguyên khan hiếm

• Sự thật không thay đổi suốt 25 năm trong ngành — tài nguyên đắt đỏ nhất là ngữ cảnh của con người; con người cũng giống LLM ở chỗ có context window và attention mask hữu hạn
• Thay đổi hiện nay là LLM slop đang đổ về từ mọi phía — tỷ lệ giữa tốc độ sản xuất và tốc độ tiêu thụ của con người trở thành nút thắt mới
• Vấn đề là slop nuôi slop
  • LLM tạo ra comment code phình to, mô tả PR dài dòng, tài liệu chỉ kể lịch sử thay vì nêu kết quả
  • LLM tiếp theo lại đọc những thứ đó, để rồi ngữ cảnh bị lấp đầy bởi nhiễu và tiếp tục lặp lại cùng một kiểu
• Nội dung văn bản trong tổ chức phải mang tính nén, chỉ nên chứa những gì không thể hiện rõ từ code và hành vi của nó

Những vùng không thể thay thế con người

• Mô hình hóa là việc của con người
  • Chuyển CUJ (Critical User Journey) thành luồng API, xác định đâu là component, mối quan tâm và ranh giới của từng phần là gì
  • Vì LLM có thể nhả code rất nhanh nên mô hình hóa tệ cũng lan rất nhanh, tạo ra các dependency méo mó mà về sau không thể sửa nổi
  • Khi chi phí thực thi rẻ đi, tỷ trọng của quyết định cấu trúc do con người đưa ra trong giá trị cuối cùng càng tăng
  • Mô hình hóa là sự thật của tổ chức ngoài đời thực, và phải tồn tại như một thực thể sống mà mọi người có thể truy cập ở một nơi
• Định nghĩa API cần kỷ luật nghiêm ngặt từ con người
  • LLM có xu hướng liên tục thêm các field tiện cho từng tác vụ cụ thể, nhưng mỗi field như vậy lại làm bẩn API vĩnh viễn
  • API là hợp đồng công khai (public contract), không phải scratch pad — cần một con người biết nói "không"

Phòng thủ quy mô lớn trước slop

• Không thể đánh bại LLM bằng code review của con người — không có khả năng mở rộng, và cuối cùng sẽ dẫn tới trạng thái mọi người nhắm mắt phê duyệt
• Reindeer hội tụ về các lớp cưỡng chế tự động
  • Linter: các quy tắc logic tuyệt đối như dependency bị cấm giữa các service, hay ranh giới kiến trúc
  • LLM judges: những thứ khó mã hóa nhưng model có thể kiểm tra, ví dụ các hợp đồng ngầm
• Tuy vậy, khi đụng vào API hoặc có thay đổi về mô hình hóa thì review bởi con người thật vẫn là bắt buộc
• Ở mức quy tắc hằng ngày, nguyên tắc là "đừng ném slop vào nhau"
  • PR nhỏ, nếu cần thì dùng stacked PR
  • Cần chống lại cả cám dỗ ném ra một PR slop 2.000 dòng lẫn khả năng reviewer sẽ nhắm mắt duyệt cho xong
  • PR là đơn vị cơ bản của attention — nếu vượt quá context window của con người thì nó có thể được duyệt, nhưng sẽ không thực sự được đọc

Padded rooms — vùng để thả LLM chạy tự do

• Khi đã có cấu trúc trên, có thể xác định những vùng mà LLM được tự do hoạt động, gọi là "padded rooms" (phòng đệm)
  • Không ảnh hưởng đến mô hình hóa và không tạo dependency dài hạn
  • Dù slop xuất hiện cũng có thể dễ dàng thay thế, và không lan ra toàn bộ codebase
  • Có thể chiếm phần lớn code của công ty, nhưng không phải phần chịu tải (load bearing)
• Lời giải cho bài toán custom theo khách hàng cũng nằm ở đây
  • Mọi custom phải sống 100% bên trong padded rooms
  • Chỉ cần rò sang core là core sẽ nứt vỡ và mỗi khách hàng mới lại tạo thêm rủi ro
  • Padded rooms là hạ tầng giúp bạn nói "yes" thật nhanh với khách hàng mà không phải trả giá ở kiến trúc

Sự đảo chiều về mặt kinh tế của technical debt

• Việc tách riêng vùng chịu tải và vùng padded cũng làm thay đổi mối quan hệ với technical debt
• Trước đây: nếu đang phát triển mà phát hiện vấn đề mô hình hóa, người ta thường để lại cho chính mình trong tương lai, vì chi phí viết lại cao nên trong dự án lớn đành nuốt nợ kỹ thuật
• Còn hiện tại: chi phí viết lại gần như tiến về 0
  • Khoản đầu tư thật sự chưa bao giờ là gõ code, mà là mô hình hóa
  • Vứt đi, sửa mô hình hóa rồi viết lại là chuyện rẻ
  • Càng trì hoãn thì càng đắt — mọi LLM đi ngang qua đoạn code sai đó sẽ tiếp nhận nó, slop nuôi slop, và một lỗi mô hình hóa không được sửa ngay sẽ nhanh chóng biến thành khoản nợ phức tạp gấp nhiều lần

PM trong thời đại này

• Vai trò PM đang thay đổi — cần phối hợp chặt với người phụ trách mô hình hóa để đảm bảo CUJ không bị vỡ khi được chuyển thành API và component
• Nếu PM và người làm mô hình hóa không đồng bộ thì sẽ tạo ra
  • một sản phẩm hoạt động về mặt kỹ thuật nhưng không đáp ứng CUJ, hoặc
  • một CUJ đẹp đẽ nhưng không thể xây dựng hợp lý
• Ở Reindeer, PM tự dựng MVP trực tiếp trong một repo riêng
  • Với tiền đề rằng đoạn code này sẽ không bao giờ chạm vào production
  • Điều đó cho phép di chuyển rất nhanh cùng LLM và có tự do để cho khách hàng xem
  • Những gì thành công hoặc cần gặp khách hàng sẽ đi qua quy trình mô hình hóa và phát triển chính thức
  • Có thể dựng demo thật nhanh và xác thực với khách hàng trước khi đầu tư vào core — sự cân bằng giữa tốc độ kiểm thử ý tưởng và mức độ nghiêm ngặt kiểu phẫu thuật đối với thứ được đưa vào sản phẩm

Hạ tầng giúp bạn thoát khỏi vòng lặp

• Khác biệt giữa việc phải nắm tay agent từng chút một và việc cho nhiều tác vụ chạy song song rồi đi ngủ nằm ở reward function tốt
  • Nếu không có, LLM sẽ lên đường rồi không biết quay lại
  • Nếu có, nó sẽ tự đánh giá được lúc nào mình đang gần đúng và lúc nào đang đi xa
• Trong phát triển phần mềm, reward function tốt được dịch thành test tốt
  • Bao gồm cả E2E test cho platform
  • Kéo LLM ra khỏi thói quen xấu phụ thuộc vào mock mà rốt cuộc không test gì cả
  • Evals cho các đầu ra dựa trên LLM
  • LLM judges với ngữ cảnh sạch thực hiện vòng lặp review tự động — để judge không rơi vào cùng kiểu ảo giác mà agent viết code đã mắc phải
• Ở cấp tổ chức, hạ tầng này cần được chia sẻ
  • Reindeer có một repo marketplace kỹ năng trung tâm được chia theo danh mục, chứa toàn bộ kỹ năng nội bộ
  • Được hỗ trợ tự động trong mọi harness như Claude Code, Codex, và cả pi.dev cho những người cực kỳ unhinged như chính tác giả
  • Lập trình viên mới sẽ ngay lập tức nhận được toàn bộ kỹ năng của tổ chức, bao gồm cả các skill để onboarding và setup

Lập trình viên của tương lai

• Năng lực quyết định của lập trình viên thời đại này không còn là kiến thức sâu mà là khả năng chuyển đổi ngữ cảnh cùng kích thước context window/attention mask của bản thân
  • Người thắng là người có thể giữ được ngữ cảnh lớn, di chuyển giữa các tác vụ mà không mất tập trung và quản lý nhiều agent song song
  • Độ sâu kỹ thuật kiểu mũi nhọn trở nên kém quan trọng hơn vì LLM sẽ bù đắp phần đó
• Năng lực bổ sung là khả năng mô hình hóa, hiểu tốt kiến trúc hệ thống và có cảm giác đúng đắn về những gì cần đề phòng ở giai đoạn thiết kế
• Lý do thế giới mới này chia lập trình viên thành hai nhóm
  • Người thích nghi sẽ trở nên siêu năng suất (super-productive)
  • Người không thích nghi không chỉ trung tính mà còn thành giá trị âm ròng (net negative) cho cả đội
  • LLM là bộ nhân (multiplier) — với người biết dùng thì nó nhân năng suất, với người không biết dùng thì nó nhân tốc độ gây hại
  • Xét về đãi ngộ, lương của kiểu lập trình viên thứ hai sẽ về 0 — vì sẽ không còn việc cho họ
• Có thể làm nhiều việc hơn rất nhiều với ít người hơn rất nhiều, nhưng việc mở rộng đội ngũ sẽ cực kỳ khó, nên phải rất chọn lọc

Về chi phí token

• Câu hỏi lặp đi lặp lại: điều gì xảy ra nếu chi phí token tăng gấp 5–10 lần
• Theo thời gian, nỗi lo này trở nên thiếu thực tế
  • AI có định luật Moore tăng tốc, chất lượng trên mỗi đô la tiếp tục tăng
  • Có đủ nhiều open model để không thể hình thành cartel
• Lý do token rẻ là vì nếu Claudex đột nhiên trở nên đắt đỏ vô lý, mọi người sẽ chuyển sang Qwen trên một neocloud nào đó