Điểm nổi bật
- Engagement: 2 points, 1 comment sau khoảng 1 giờ; quy mô nhỏ nhưng luận điểm phản ánh kinh nghiệm rất thực của các đội đang ship với agent.
- Luận điểm của tác giả: vibe coding hợp cho PoC bỏ đi, nhưng với sản phẩm thật thì greenfield dễ thành mớ code khó bảo trì nếu chưa chốt data model, data flow và cấu trúc tổng thể.
- Phe đồng tình một phần: tác giả nhấn mạnh agent ngày càng mạnh hơn trên codebase sẵn có vì có pattern, style và ràng buộc để bám theo.
- Phe phản biện: bình luận duy nhất cho rằng LLM vẫn xử lý greenfield được, miễn người vận hành biết đặt constraint hoặc dùng chính LLM để cùng tạo ra constraint.
- Điểm chốt: tranh luận không còn là “AI code tốt hay xấu”, mà là “ở giai đoạn nào cần con người đóng khung bài toán trước”.
Biểu đồ
Tóm tắt
Thread này xuất phát từ một confession khá điển hình của làn sóng AI coding hiện tại: tác giả từng nghĩ vibe coding đặc biệt hợp với dự án greenfield, nhưng sau một thời gian dùng harness và model mới, anh đổi ý. Theo lập luận của tác giả, agent thực ra hoạt động tốt hơn trên codebase có sẵn, vì nó có style, convention, data flow và mô hình miền để bám vào; còn greenfield nếu thả quá sớm sẽ rất dễ thành mớ hỗn độn khó quay lại bảo trì.
Bình luận phản biện không phủ nhận hoàn toàn. Thay vào đó, nó cho rằng vấn đề không nằm ở greenfield tự thân, mà ở việc người điều khiển không nêu đủ constraint. Như vậy, cuộc tranh luận được nâng lên một tầng trưởng thành hơn: thay vì cãi nhau AI có “code được hay không”, HN đang bàn về điều kiện quản trị để AI code có ích.
Chi tiết
Điểm đáng giá ở thread này là nó mô tả rất sát giai đoạn hậu-hype của AI coding. Khi các demo đầu tiên bùng nổ, nhiều người tin rằng greenfield là mảnh đất lý tưởng cho vibe coding: không legacy, không ràng buộc, cứ để model sinh ra sản phẩm mới thật nhanh. Nhưng trải nghiệm thực tế của tác giả cho thấy tốc độ đầu có thể đánh đổi bằng chi phí bảo trì cực lớn phía sau. Nếu kiến trúc, data model và data flow chưa được định hình, agent sẽ đi theo quán tính cục bộ của từng prompt, khiến codebase mất coherence rất nhanh.
Lập luận của tác giả có sức nặng vì nó ăn khớp với cách agent hiện tại thật sự làm việc. Trên một codebase đã có pattern, naming, thư viện và ranh giới module, agent thường quan sát được “luật ngầm” rồi tiếp tục theo quỹ đạo đó. Nói cách khác, giá trị của AI không chỉ nằm ở sinh mã mới, mà ở khả năng nội suy từ cấu trúc đã hiện hữu. Đây là lý do nhiều đội gần đây báo cáo rằng agent hữu ích nhất khi làm refactor có hướng dẫn, mở rộng tính năng trong hệ thống có sẵn, hoặc tự động hóa việc test và sửa lỗi trên nền codebase đã ổn định.
Bình luận phản biện cũng đáng chú ý vì không đơn thuần phủ định. Người phản biện cho rằng greenfield vẫn khả thi nếu operator biết đặt ràng buộc, hoặc thậm chí biết dùng chính LLM để truy vấn ngược và xây bộ constraint trước khi code. Đây là điểm rất quan trọng. Nó gợi ra rằng “vibe coding” có lẽ không chết, nhưng phải tiến hóa từ mode thả nổi sang mode đồng thiết kế: con người và LLM cùng xác định schema dữ liệu, biên module, tiêu chí chất lượng và các bất biến hệ thống trước khi sinh khối lượng mã lớn.
Với đội sản phẩm và lãnh đạo kỹ thuật, thread này là lời nhắc đúng lúc. Lợi thế của AI coding không đến từ việc bỏ qua kiến trúc, mà từ việc nén vòng lặp sau khi kiến trúc tối thiểu đã rõ. Nếu không có lớp khung này, tốc độ đầu vào của agent chỉ chuyển thành nợ kỹ thuật đầu ra. Đây cũng là lý do ngày càng nhiều team không hỏi “nên cho agent viết bao nhiêu phần trăm code”, mà hỏi “nên giao agent ở pha nào của vòng đời sản phẩm”. Đó là câu hỏi trưởng thành hơn và thực tế hơn rất nhiều.