Ngày lập trình Vibe 12, Có thể đây là chủ đề cuối cùng ở đây. Tôi đã dành 100 giờ để xây dựng một ứng dụng thương mại với lập trình vibe. Một số quan sát từ trải nghiệm. 13 bài học hàng đầu của tôi để giúp bạn -- lập trình vibe cho riêng bạn. Một chủ đề🧵

Lưu ý: Tôi là đồng sáng lập một SaaS tiên phong đã phát triển lên đến 200 triệu USD ARR, vì vậy mặc dù tôi không phải là kỹ sư và không thực sự lập trình kể từ khi học trung học (và điều đó thực sự không tính) -- tôi có bối cảnh về những gì phần mềm thương mại yêu cầu. Tôi yêu những ứng dụng này. Nhưng nếu bạn thực sự muốn theo đuổi, hãy biết giới hạn của chúng. Ít nhất, là giới hạn của chúng hôm nay. Mọi thứ đang thay đổi rất nhanh, tôi chắc chắn rằng những kiến thức này sẽ trở nên lỗi thời ngay cả trong 90 ngày.

1/13: Bắt đầu với một hack tạm thời. Dành tối đa 60 phút để nói với một ứng dụng lập trình vibe về những giấc mơ sản phẩm điên rồ nhất của bạn mà không cần lên kế hoạch. Xem điều gì sẽ xuất hiện. Nhưng hãy cam kết ngay từ đầu là sẽ vứt bỏ nó—đây không phải là sản phẩm thực sự của bạn, mà là bài học của bạn. Giờ đầu tiên đó sẽ dạy bạn nhiều hơn về khả năng và giới hạn của nền tảng hơn bất kỳ hướng dẫn nào.

2/13: Trước khi viết bất kỳ mã nào, hãy dành một tuần để nghiên cứu 20 ứng dụng sản xuất được xây dựng trên các nền tảng lập trình vibe. Không phải chỉ lướt qua—thực sự sử dụng các ứng dụng đang hoạt động, nhận thanh toán, phục vụ khách hàng thực tế. Bạn đang tìm kiếm những gì thực sự có thể ở quy mô lớn và nơi mà các hạn chế gây khó khăn nhất. Cuộc khảo sát này sẽ giúp tiết kiệm hàng tuần thất vọng sau này.

3/13: Xác định yêu cầu sản xuất của bạn trước khi bắt đầu xây dựng. Hãy hỏi: 1⃣ Nó cần phải an toàn đến mức nào? 2⃣ Ai sẽ duy trì nó sau khi ra mắt? 3⃣ Bạn có cần nó mở rộng đến 100 người dùng hay 100.000 người không? 4⃣ Bạn có tìm thấy một ứng dụng vibe-coded khác đang trong sản xuất, với khách hàng trả tiền, ở mức độ phức tạp của bạn không? Nếu bạn không có câu trả lời chắc chắn, hãy dừng lại việc xây dựng và bắt đầu nghiên cứu.

4/13: Viết bản đặc tả chi tiết nhất mà bạn có thể quản lý. Lập bản đồ cho mọi trang, quy trình làm việc, cấp độ quyền truy cập. Định nghĩa rõ ràng các hệ thống email, bảng điều khiển, quy trình quản lý người dùng. Vâng, điều này có vẻ ngược lại với các yêu cầu bằng ngôn ngữ tự nhiên, nhưng nó buộc bạn phải suy nghĩ về các trường hợp biên và trở thành ngôi sao phương Bắc của bạn khi AI gợi ý các tính năng không mong muốn.

5/13: Một số tính năng trông đơn giản trong các bản demo nhưng lại trở thành cơn ác mộng kỹ thuật. Ví dụ hôm nay ít nhất (và điều này đang thay đổi liên tục): ▶️ giao hàng email đáng tin cậy ▶️ quản lý OAuth/nhận dạng ▶️ tạo nội dung ▶️ ứng dụng di động gốc ▶️ thiết kế tùy chỉnh vượt ra ngoài mẫu ▶️ bảo mật doanh nghiệp. Những điều này thường xuyên gây ra đau đớn trên các nền tảng. Hãy lên kế hoạch thêm thời gian hoặc xem xét liệu chúng có thực sự cần thiết cho MVP hay không. Tìm một kỹ sư dày dạn kinh nghiệm đã xây dựng trên nền tảng của bạn và HỎI họ. HỎI họ.

5/13: Một số tính năng trông đơn giản trong các bản demo nhưng lại trở thành những thách thức kỹ thuật lớn. Ví dụ hôm nay ít nhất (và điều này đang thay đổi liên tục): ▶️ giao hàng email đáng tin cậy ▶️ quản lý OAuth/nhận dạng ▶️ tạo nội dung ▶️ ứng dụng di động gốc ▶️ thiết kế tùy chỉnh vượt ra ngoài mẫu ▶️ bảo mật doanh nghiệp. Những điều này thường gây ra đau đớn trên các nền tảng. Lập kế hoạch thêm thời gian hoặc xem xét xem chúng có thực sự cần thiết cho MVP hay không. Đừng giả định rằng bản demo tĩnh của bạn trông có vẻ thực hiện tốt những điều này thực sự làm tốt chúng. Tìm một kỹ sư dày dạn kinh nghiệm đã xây dựng trên nền tảng của bạn và HỎI họ. HỎI họ.

6/13: Các hệ thống AI tạo ra dữ liệu khi chúng thất bại. Mọi người đã làm việc trên bất kỳ nền tảng lập trình vibe nào, bao gồm cả Claude Code, đều biết điều này. Đây là một lỗi nhưng cũng là một tính năng. Nếu không có điều này, chúng không thể giải quyết vấn đề. Một AI trên bất kỳ nền tảng nào khi gặp trở ngại sẽ tạo ra dữ liệu hư cấu. Đây không phải là một lỗi—chúng được đào tạo để cung cấp đầu ra thay vì thừa nhận thất bại. Sau nhiều lần cố gắng không thành công, chúng sẽ tạo ra dữ liệu giả mạo thuyết phục thay vì nói "Tôi không thể làm điều này." Bạn cần hiểu điều này, chấp nhận nó và tìm cách làm việc xung quanh nó. Điều này sẽ mất thời gian.

7/13: Dành cả ngày đầu tiên của bạn để tìm hiểu mọi tính năng của nền tảng, không phải để xây dựng. Những nền tảng này tích hợp chức năng tuyệt vời vào giao diện của chúng. Mỗi biểu tượng, tùy chọn menu, tính năng đều tồn tại vì một lý do. Bạn không thể tận dụng những khả năng mà bạn không biết tồn tại. Đây không phải là nghiên cứu tùy chọn - đó là kiến thức thiết yếu cho các ứng dụng thương mại. Không có giải pháp cho mọi thách thức. Nhưng các nền tảng có nhiều giải pháp hơn bạn nghĩ lúc đầu. Và chúng có phần hơi lập dị. Theo cách tốt, nhưng vẫn lập dị. Sâu thẳm bên trong, chúng được xây dựng cho các nhà phát triển, bất kể marketing nói gì. Chấp nhận điều đó và tìm hiểu MỌI tính năng trước khi bạn bắt đầu. Nếu bạn không hiểu một tính năng, một biểu tượng, một từ viết tắt, thì DỪNG lại. Hãy nghiên cứu nó. Ngay bây giờ. Không phải sau.

8/13: Nắm vững hệ thống khôi phục ngay từ ngày đầu, trước khi bạn cần chúng một cách tuyệt vọng. Hầu hết các nền tảng đều cung cấp kiểm soát phiên bản tinh tế giống như các điểm lưu trong trò chơi video. Hãy thực hành khôi phục một cách có chủ đích khi rủi ro còn thấp. Hiểu rõ chính xác cách nó hoạt động, cái gì được bảo tồn, cái gì bị mất. Điều này sẽ trở thành công cụ gỡ lỗi quý giá nhất của bạn.

9/13: AI sẽ thực hiện những thay đổi mà bạn không yêu cầu. Nó sẽ như vậy. Nó sẽ sửa đổi các tính năng đã được thiết lập, thêm chức năng không mong muốn, làm hỏng mã đang hoạt động trong khi "cải thiện" một cái gì đó khác. Phòng thủ: Thêm "KHÔNG THAY ĐỔI NẾU KHÔNG HỎI" vào mọi lời nhắc. Khi thảo luận về các thay đổi, hãy nói "KHÔNG THAY ĐỔI. KHÔNG MÃ. CHỈ THẢO LUẬN." Giảm thiểu các sửa đổi không mong muốn khoảng 80%. Nhưng nó không ngăn chặn chúng. Điều này đúng với mọi nền tảng. Cuối cùng, tất cả đều chạy trên Claude -- chủ yếu. Tất cả đều có các mức độ khác nhau của những vấn đề tương tự từ điều đó. Tất cả sẽ >đều< thực hiện những thay đổi mà bạn không yêu cầu. Chỉ là các ứng dụng prosumer sẽ đi xa hơn, vì các ứng dụng lập trình tập trung vào nhà phát triển thì bị cô lập hơn về mặt các thay đổi mà chúng thực hiện.

10/13: Học cách phân nhánh ứng dụng của bạn khi nó đạt đến độ phức tạp ổn định. Ngay từ đầu, việc khôi phục sẽ xử lý hầu hết các vấn đề. Nhưng khi ứng dụng của bạn trở nên phức tạp, bạn có thể không biết phiên bản nào để khôi phục. Phân nhánh ở các trạng thái ổn định để tạo ra các nhánh thử nghiệm an toàn trong khi vẫn bảo tồn các phiên bản đã biết là tốt. Hãy nghĩ đến các chính sách bảo hiểm.

11/13: Dự trù 150 giờ trong suốt một tháng để đạt chất lượng thương mại. Có thể nhiều hơn. ▶️Mẫu thử 20 phút đó chỉ chiếm 5% công việc thực tế của bạn. ▶️Hơn một nửa thời gian của bạn sẽ dành cho việc kiểm tra, gỡ lỗi, và tinh chỉnh. Việc xây dựng ban đầu thì dễ—làm cho nó đáng tin cậy, an toàn, và thân thiện với người dùng mới là phần lớn nỗ lực. Đừng để tốc độ demo đánh lừa bạn.

12/13: Chấp nhận vai trò mới của bạn là kỹ sư QA. Khi bạn đã vào guồng phát triển nghiêm túc, hãy chuẩn bị cho thói quen hàng ngày như sau: ▶️chụp ảnh màn hình lỗi ▶️viết báo cáo chi tiết cho AI ▶️kiểm tra các bản sửa lỗi một phần ▶️kiểm tra lại các trường hợp đặc biệt ▶️ghi chép các vấn đề mới ▶️chạy thử nghiệm đơn vị trên nhánh của bạn Đây không phải là một giới hạn về cảm xúc trong lập trình—đó là thực tế của phát triển phần mềm. Các nền tảng xử lý lập trình; QA vẫn là công việc của con người. Các nền tảng có làm ... một số. Nhưng chỉ một số. Bạn không thể dựa vào chúng để làm QA cho bạn một mình.

13/13: Lập kế hoạch cho chiến lược thoát của bạn ngay từ ngày đầu tiên. Hầu hết các ứng dụng thương mại cuối cùng sẽ vượt qua các nền tảng lập trình vibe prosumer do quy mô, tùy chỉnh hoặc nhu cầu bảo mật. Các tùy chọn: 1⃣xuất mã nền tảng 2⃣cách tiếp cận lai 3⃣xây dựng lại hoàn toàn, hoặc ... 4⃣ở lại và mở rộng. Sự thật là, trên các ứng dụng prosumer ngày nay, hầu hết đều rời đi. Không phải tất cả. Nhưng hầu hết những người đang xây dựng các ứng dụng thương mại thực sự. Hiện tại. Điều này không có nghĩa là bạn phải. Nhưng hãy có >các tùy chọn< khi bạn bắt đầu. Hãy có ... một kế hoạch thoát nếu bạn cần. Tài liệu hóa logic kinh doanh, duy trì thông số kỹ thuật, đánh giá thường xuyên. Nếu ứng dụng của bạn trở nên phức tạp, cuối cùng, bạn có thể thấy dễ dàng hơn để rời đi hơn là làm việc xung quanh các ràng buộc tích lũy.

Các nền tảng lập trình Vibe thực sự kỳ diệu cho một số loại ứng dụng—và thực sự không đủ cho những loại khác. Công việc của bạn là xác định xem dự án của bạn thuộc loại nào trước khi bạn quá sâu để thay đổi hướng đi. Đây là những công cụ mạnh mẽ với những hạn chế cụ thể, không phải là sự thay thế cho việc hiểu những gì phần mềm thương mại yêu cầu. Chúng là công cụ. Không phải là đội ngũ phát triển. Hãy nhắc nhở bản thân điều đó mỗi ngày.

Các nền tảng sẽ tiếp tục phát triển nhanh chóng. Những gì không thể hôm nay có thể trở nên đơn giản trong sáu tháng tới. Nhưng ngay bây giờ, hãy nghĩ đến việc lập trình với cảm giác "prosumer" mà không cần chạm vào mã như một cầu nối khả thi đến phát triển truyền thống cho các ứng dụng thương mại... hơn là một trạng thái cuối cùng. Sử dụng nó để xác thực thị trường của bạn, tinh chỉnh yêu cầu, xây dựng doanh thu ban đầu—sau đó đưa ra quyết định thông minh dựa trên những ràng buộc thực tế, không phải những khả năng lý thuyết.

12 ngày lập trình vibe cảm giác như ... 12 tuần. Những đêm muộn sửa lỗi, những cú sốc dopamine khi mọi thứ cuối cùng hoạt động, sự thất vọng khi nó lại hỏng. Đây là một trong những trải nghiệm học tập căng thẳng nhất mà tôi đã có trong nhiều năm. Đối với tôi, đã đến lúc lùi lại một chút và làm nhiều kế hoạch hơn, suy nghĩ nhiều hơn. Tôi đã tìm thấy một số ứng dụng yêu thích mới của mình. Nhưng tôi cũng đã học được rằng ngay cả tôi cũng cần phải học tất cả tốt hơn nhiều. Hy vọng điều này sẽ giúp bạn.

Mã: rất hào hứng khi chúng tôi đã truyền cảm hứng cho @dharmesh để mua và đầu tư lớn ở đây!!

Coda: Rất hào hứng vì hành trình của chúng tôi đã truyền cảm hứng cho @dharmesh mua và khởi động một cộng đồng ở đây!

@dharmesh Ngày 11 ở đây: