Biến điện thoại Android cũ của bạn thành hệ thống an ninh thông minh với Kotlin, CameraX và Gemini AI. Dự án 'Storog' mã nguồn mở này sử dụng AI để phát hiện thay đổi hình ảnh và gửi thông báo Telegram, đặc biệt hơn là toàn bộ mã nguồn được phát triển bởi một trợ lý AI.

Lê Lân

18/08/2025

Chào các bạn, lại là tôi đây! Sau thành công vang dội (à mà thôi, ít nhất là cũng "hứa hẹn" lắm đó!) của thí nghiệm máy tính bỏ túi trong series VibeTDD của chúng ta, đã đến lúc phải "lên level" rồi. Không chơi mấy bài tập trẻ con nữa, tôi quyết định cho trợ lý AI của mình đối mặt với một thử thách thực sự từ Portfo. Liệu em nó có "gánh team" được không đây? <img src='https://truyentranh.letranglan.top/api/v1/proxy?url=https://i.imgur.com/human_brain_ai.png' alt='Bộ não con người và AI làm việc cùng nhau'> ### Thử thách "khủng" hơn: Từ món đồ chơi đến "chiến trường" thực tế Tưởng tượng mà xem, sau khi Claude (trợ lý AI của tôi) đã hướng dẫn tôi "nhẹ nhàng" qua những kiến thức cơ bản về TDD (Test-Driven Development - Phát triển hướng kiểm thử) với bài toán máy tính cầm tay, tôi quyết định "chơi lớn" hơn. Nhiệm vụ lần này là xây dựng một **dịch vụ thanh toán (Payout Service)** với các yêu cầu cực kỳ "khó nhằn" sau đây: * **Xác thực dữ liệu thanh toán:** Phải kiểm tra UserId, Amount (số tiền), Currency (loại tiền tệ). * **Giới hạn số tiền:** Số tiền không được vượt quá 30. * **Tiền tệ chấp nhận:** Chỉ cho phép EUR, USD, GBP. * **Tổng số tiền thanh toán cho mỗi người dùng:** Không được vượt quá 100. * **Lưu trữ thanh toán hợp lệ:** Cần lưu vào bộ nhớ (in-memory). * **Xử lý lỗi:** Phải xử lý lỗi xác thực một cách "duyên dáng". <img src='https://truyentranh.letranglan.top/api/v1/proxy?url=https://i.imgur.com/complex_system.png' alt='Sơ đồ hệ thống phức tạp'> **Luật chơi (cơ bản vẫn giống Phase 1, nhưng có thêm chút "gia vị"):** * Claude sẽ dẫn dắt toàn bộ quá trình TDD. * Tôi chỉ làm những gì nó "ra lệnh" thôi. * Ban đầu, tôi sẽ không "chỉ bảo" gì về TDD cả. * Khi Claude hỏi "làm gì tiếp theo?", tôi sẽ trả lời "tự quyết đi". Nhưng lần này, tôi đã "mở to mắt" hơn để soi mói xem có "anti-pattern" (những thói quen xấu trong lập trình) nào xuất hiện không. Và tin tôi đi, có đấy! ### Chuyện gì đã xảy ra: Hội chứng "Over-Engineering" (làm quá phức tạp mọi thứ) <img src='https://truyentranh.letranglan.top/api/v1/proxy?url=https://i.imgur.com/spaghetti_code.png' alt='Mớ bòng bong code bị lỗi kiến trúc'> #### Vấn đề 1: "Bùng nổ" các bài kiểm thử (Test Explosion) Claude khởi đầu rất "ngon lành" với bài test đầu tiên: `@Test fun 'should store payout when all data is valid'() { val payout = Payout('user123', 25.0, 'EUR') payoutService.processPayout(payout) // Nên không ném ngoại lệ}` Cứ tưởng "êm xuôi" rồi, nhưng rồi nó lại gợi ý thêm... **15 bài test nữa** cho cùng một chức năng cơ bản! Kiểu như: `@Test fun 'should store payout with minimum amount'()` `@Test fun 'should store payout with maximum amount'()` `@Test fun 'should store payout with EUR currency'()` `@Test fun 'should store payout with USD currency'()` `@Test fun 'should store payout with GBP currency'()` `// ... và 10 bài test tương tự khác` **Cờ đỏ số 1:** Trợ lý AI của chúng ta mặc định chọn cách kiểm thử "đầy đủ đến từng ngóc ngách" thay vì những bài test tối giản, có trọng tâm. Thay vì dùng **tam giác hóa (triangulation)** – tức là viết một test chung chung, rồi thêm test cụ thể để ép code đi đúng hướng – nó lại muốn test mọi trường hợp có thể. Kiểu này thì tốn thời gian mà lại không hiệu quả! <img src='https://truyentranh.letranglan.top/api/v1/proxy?url=https://i.imgur.com/test_explosion.png' alt='Biểu đồ bùng nổ các bài kiểm thử'> #### Vấn đề 2: Thảm họa "Object Mother" Khi Claude bắt đầu tạo ra các đối tượng `Payout` trực tiếp trong từng bài test, tôi đã phải "nhảy vào" ngay lập tức: "Cái này mà cứ thế thì không thể bảo trì được đâu. Hãy dùng mẫu thiết kế **Object Mother** đi!" Và phản hồi của Claude thì... ôi thôi, nó "quá lố" luôn: `object PayoutMother { // "Valid" variations fun withSmallAmount() = Payout("user123", 1.0, "EUR") fun withMediumAmount() = Payout("user123", 15.0, "EUR") fun withLargeAmount() = Payout("user123", 29.0, "EUR") fun withMaxAmount() = Payout("user123", 30.0, "EUR") // Currency variations fun withEUR() = Payout("user123", 25.0, "EUR") fun withUSD() = Payout("user123", 25.0, "USD") fun withGBP() = Payout("user123", 25.0, "GBP") // User variations fun withUser1() = Payout("user1", 25.0, "EUR") fun withUser2() = Payout("user2", 25.0, "EUR") // ... 15 more similar methods} // And then, the horror: object InvalidPayoutMother { fun withNegativeAmount() = Payout("user123", -5.0, "EUR") fun withZeroAmount() = Payout("user123", 0.0, "EUR") fun withExcessiveAmount() = Payout("user123", 31.0, "EUR") fun withInvalidCurrency() = Payout("user123", 25.0, "JPY") fun withEmptyUserId() = Payout("", 25.0, "EUR") // ... more invalid variations}` **Cờ đỏ số 2:** Trợ lý AI coi Object Mother như một "nhà máy" sản xuất *mọi kịch bản kiểm thử có thể*, thay vì một phương thức linh hoạt duy nhất với các giá trị mặc định hợp lệ và ngẫu nhiên. Cách tiếp cận đúng phải là thế này cơ: `object PayoutMother { fun of( userId: String = Rand.string(), amount: Double = Rand.amount(), currency: String = Rand.currency(), ) = Payout( userId = userId, amount = amount, currency = currency, )}` <img src='https://truyentranh.letranglan.top/api/v1/proxy?url=https://i.imgur.com/object_mother_chaos.png' alt='Object Mother lộn xộn, nhiều hàm'> <img src='https://truyentranh.letranglan.top/api/v1/proxy?url=https://i.imgur.com/clean_object_mother.png' alt='Object Mother gọn gàng, linh hoạt'> #### Vấn đề 3: TDD "kinh điển" gần như BẤT KHẢ THI với AI Chu trình red-green-refactor (đỏ-xanh-tái cấu trúc) truyền thống, cái mà đã hoạt động tuyệt vời với bài toán máy tính, giờ đây đã **tan thành mây khói**. **Điều gì nên xảy ra (TDD kinh điển):** 1. Viết một bài test thất bại (đỏ). 2. Viết mã tối thiểu để nó vượt qua (xanh). 3. Tái cấu trúc mã. 4. Lặp lại. **Điều thực sự đã xảy ra:** * Claude viết 5-10 bài test cùng một lúc. * Nó gợi ý triển khai *tất cả mọi thứ* cùng lúc. * Không có tam giác hóa hay phát triển tăng dần. * Bỏ qua hoàn toàn giai đoạn "viết mã tối thiểu". Nhưng đây mới là vấn đề sâu xa hơn: TDD kinh điển không chỉ kém hiệu quả với AI mà còn *bất khả thi* vì những lý do thực tế: * **Bùng nổ ngữ cảnh:** Mỗi chu trình red-green thêm vào lịch sử trò chuyện, làm tăng độ phức tạp của "ngữ cảnh" mà AI phải xử lý. * **Tiêu thụ bộ nhớ:** Các phiên làm việc với AI phình to nhanh chóng với những lần hỏi đáp qua lại. * **Chi phí thời gian:** Việc liên tục chuyển đổi giữa test/triển khai trở nên chậm chạp một cách khó chấp nhận. * **Giới hạn phiên:** Bạn sẽ "đụng trần" giới hạn token trước khi hoàn thành bất kỳ tính năng có ý nghĩa nào. <img src='https://truyentranh.letranglan.top/api/v1/proxy?url=https://i.imgur.com/broken_tdd_cycle.png' alt='Chu trình TDD bị phá vỡ'> **Giải pháp của tôi - Nguyên lý VibeTDD:** Thay vì viết từng bài test một, chúng ta hãy viết **một tập hợp nhỏ các bài test liên quan** trước, sau đó triển khai chúng cùng lúc. Cách tiếp cận theo lô này sẽ: * Giảm chi phí chuyển đổi ngữ cảnh. * Giúp các phiên AI dễ quản lý hơn. * Duy trì kỷ luật test-first. * Cho phép xác thực tốt hơn tính đầy đủ của các bài test. `// Thay vì: Viết một test → triển khai → viết test tiếp theo → triển khai` `// Hãy làm thế này: Viết một tập hợp test có trọng tâm → xác minh chúng thất bại → triển khai cùng lúc` `@Test fun 'should throw exception when UserId is empty'() { /* ... */ }` `@Test fun 'should throw exception when UserId is null'() { /* ... */ }` `@Test fun 'should not throw exception when UserId is valid'() { /* ... */ }` `// Sau đó triển khai UserIdValidator để cả ba pass` <img src='https://truyentranh.letranglan.top/api/v1/proxy?url=https://i.imgur.com/vibetdd_principle.png' alt='Nguyên lý VibeTDD: Gom nhóm các bài kiểm thử'> #### Vấn đề 4: Quá chủ động (và chỉ dẫn không chính xác) Claude cứ thế "tự tiện" viết code mà không chờ tôi cho phép: "Bây giờ chúng ta sẽ triển khai logic xác thực..." [rồi nó cứ thế viết liền 50 dòng code] Từ đó, tôi rút ra bài học là phải cực kỳ cụ thể: ❌ "Tiếp tục bước tiếp theo" ❌ "Triển khai phần xác thực" ❌ "Tiếp tục đi" ✅ "Chỉ viết bài test cho việc xác thực UserId trống thôi nhé" ✅ "Chỉ triển khai phương thức xác thực UserId thôi" ✅ "Cho tôi xem trường hợp test tiếp theo duy nhất thôi" <img src='https://truyentranh.letranglan.top/api/v1/proxy?url=https://i.imgur.com/human_guidance_ai.png' alt='Con người hướng dẫn AI'> #### Vấn đề 5: Thiếu kiến thức cơ bản về Kỹ thuật phần mềm Mặc dù dẫn dắt TDD, Claude lại bỏ qua các nguyên tắc kỹ thuật phần mềm cơ bản: * **Không Tách biệt Trách nhiệm (No Separation of Concerns - SoC):** `class PayoutService { fun processPayout(payout: Payout) { // Logic xác thực trộn lẫn với logic nghiệp vụ if (payout.userId.isEmpty()) throw Exception("...") if (payout.amount <= 0) throw Exception("...") if (payout.currency !in listOf("EUR", "USD", "GBP")) throw Exception("...") storage.store(payout) // Logic nghiệp vụ }}` Cứ như một nồi lẩu thập cẩm vậy, mọi thứ trộn lẫn vào nhau. Điều này vi phạm nguyên tắc **Single Responsibility Principle (SRP)** – mỗi "thực thể" (lớp, hàm) chỉ nên có MỘT trách nhiệm duy nhất. * **Không Mocking trong Test:** `@Test fun 'should validate payout data'() { val service = PayoutService(InMemoryStorage()) // Phụ thuộc vào đối tượng thật! // ...}` Thay vì sử dụng các đối tượng **mock** (đối tượng giả lập) để kiểm thử độc lập một phần code, nó lại dùng phụ thuộc thật. Điều này khiến bài test trở nên chậm chạp và kém tin cậy hơn. * **Các Quy tắc Nghiệp vụ "Cứng nhắc":** `if (payout.amount > 30.0) // Số "ma thuật"!` Số `30.0` là một "magic number" – một giá trị được mã hóa trực tiếp mà không có tên giải thích rõ ràng. Điều này khiến mã khó đọc, khó bảo trì và khó thay đổi. * **Mã không biên dịch được:** Claude tự tin trình bày thế này: `shouldThrow<ValidationException> { // Sai cú pháp import service.process(invalidPayout) }` Kiểu như "tôi tự tin lắm, nhưng mà code của tôi không chạy được đâu" vậy! ### Khoảnh khắc "Can thiệp" của tôi Sau khi chứng kiến Claude tạo ra một mớ hỗn độn "không thể bảo trì nổi" trong khi nó cứ khăng khăng "mọi thứ hoàn hảo," tôi đã phải *nhảy vào* và nói: "Cái này vi phạm nguyên tắc Single Responsibility Principle đó. Hãy tách phần xác thực ra thành các lớp validator riêng biệt đi!" Phản ứng của Claude: "Bạn hoàn toàn đúng! Tôi đã vi phạm Single Responsibility Principle..." Thấy chưa? Nó *biết* các nguyên tắc, nhưng lại không *áp dụng* chúng nếu không có sự thúc đẩy rõ ràng từ tôi. ### Thành quả sau khi được "dìu dắt" kỹ lưỡng Sau khi "nắn gân" và sửa đổi đường đi nước bước, cuối cùng chúng tôi cũng có một giải pháp với kiến trúc ngon lành cành đào: <img src='https://truyentranh.letranglan.top/api/v1/proxy?url=https://i.imgur.com/clean_architecture_payout.png' alt='Kiến trúc dịch vụ thanh toán đã được cải thiện'> #### Mô hình Miền (Domain Model) `data class Payout( val userId: String, val amount: Double, val currency: String)` Đơn giản, rõ ràng, đại diện cho dữ liệu của chúng ta. #### Giao diện Validator `interface PayoutValidator { fun validate(payout: Payout)}` Một hợp đồng rõ ràng cho tất cả các "người xác thực" của chúng ta. #### Các Validator riêng biệt `class UserIdValidator : PayoutValidator { override fun validate(payout: Payout) { if (payout.userId.isEmpty()) { throw InvalidPayoutException( PayoutErrorCode.EMPTY_USER_ID, "UserId cannot be empty" ) } }}` `class AmountValidator( private val configuration: PayoutConfiguration) : PayoutValidator { override fun validate(payout: Payout) { if (payout.amount <= 0) { throw InvalidPayoutException( PayoutErrorCode.INVALID_AMOUNT, "Amount must be greater than zero" ) } val maxAmount = configuration.getMaxAmount() if (payout.amount > maxAmount) { throw InvalidPayoutException( PayoutErrorCode.INVALID_AMOUNT, "Amount cannot exceed $maxAmount" ) } }}` Mỗi validator chỉ lo một việc duy nhất, đúng chuẩn SRP! #### Phối hợp Dịch vụ (Service Orchestration) `class PayoutService( private val storage: PayoutStorage, private val validators: List<PayoutValidator>) { fun process(payout: Payout) { validators.forEach { it.validate(payout) } storage.store(payout) }}` Dịch vụ này chỉ chịu trách nhiệm phối hợp các validator và lưu trữ, không còn trộn lẫn các trách nhiệm nữa. #### Xử lý Lỗi "đúng bài" `enum class PayoutErrorCode { EMPTY_USER_ID, INVALID_AMOUNT, INVALID_CURRENCY, USER_LIMIT_EXCEEDED}` `class InvalidPayoutException( val code: PayoutErrorCode, message: String) : Exception(message)` Phân loại lỗi rõ ràng và tạo ngoại lệ tùy chỉnh, giúp việc xử lý lỗi trở nên dễ dàng và tường minh hơn. #### Các bài Test "sạch đẹp" `@ExtendWith(MockKExtension::class) class AmountValidatorTest { @InjectMockKs private lateinit var validator: AmountValidator @MockK private lateinit var configuration: PayoutConfiguration @ParameterizedTest @ValueSource(doubles = [0.0, -5.0, -100.0]) fun 'should throw exception when amount is zero or negative'(amount: Double) { val payout = PayoutMother.of(amount = amount) val exception = shouldThrow<InvalidPayoutException> { validator.validate(payout) } exception.code shouldBe PayoutErrorCode.INVALID_AMOUNT }}` Sử dụng MockK để giả lập các phụ thuộc, giúp bài test chạy nhanh hơn và kiểm thử chính xác đơn vị code mà nó phụ trách. ### Những khám phá "đắt giá" <img src='https://truyentranh.letranglan.top/api/v1/proxy?url=https://i.imgur.com/tdd_thinking_vs_mechanics.png' alt='TDD tư duy và TDD cơ học'> #### ✅ Điều AI làm tốt * **Triển khai nhanh chóng:** Một khi kiến trúc đã được định hình, nó triển khai vèo vèo. * **Tạo test case toàn diện:** Gần như quá toàn diện luôn ấy! * **Nhận diện mẫu:** Có thể áp dụng các mẫu thiết kế nhất quán cho các lớp tương tự. * **Hỗ trợ tái cấu trúc:** Giúp cải thiện mã một cách "cơ học" rất tốt. #### ⚠️ Điều cần con người "giám sát chặt chẽ" * **Quyết định kiến trúc:** Mặc định chọn cách tiếp cận đơn giản nhất (và thường là sai). * **Tách biệt trách nhiệm:** Trộn lẫn các trách nhiệm nếu không được nhắc nhở. * **Chiến lược kiểm thử:** Test quá nhiều cho các kịch bản đơn giản, nhưng lại thiếu test cho các trường hợp phức tạp. * **Quản lý phụ thuộc:** Tránh sử dụng mocking, cứ dùng thẳng phụ thuộc thật. #### ❌ Điều AI "vật lộn" * **Kỷ luật TDD:** Muốn viết tất cả mọi thứ cùng lúc. * **Triển khai tối thiểu:** Nhảy ngay tới giải pháp hoàn chỉnh thay vì từng bước nhỏ. * **Quản lý ngữ cảnh:** Dễ dàng mất dấu trọng tâm hiện tại với các yêu cầu phức tạp. * **Đánh giá chất lượng:** Rất tự tin về những đoạn code chất lượng... kém. ### Vấn đề "khó nhằn" nhất: Khả năng mở rộng Phát hiện đáng lo ngại nhất là: **TDD do AI dẫn dắt không thể mở rộng theo độ phức tạp của dự án.** * **Máy tính (10 dòng code):** Kỷ luật TDD rất tốt. * **Dịch vụ Thanh toán (200+ dòng code):** Cần sự can thiệp liên tục của con người. * **Ứng dụng thực tế (1000+ dòng code):** Sẽ trở nên không thể quản lý nổi. AI dường như có một ngưỡng phức tạp nhất định, nơi mà hành vi của nó thay đổi một cách cơ bản. <img src='https://truyentranh.letranglan.top/api/v1/proxy?url=https://i.imgur.com/ai_scaling_problem.png' alt='Vấn đề mở rộng khi AI dẫn dắt dự án lớn'> ### Những bài học "xương máu" cho VibeTDD #### 1. TDD kinh điển phải "biến hóa" cho AI Cách tiếp cận "một test tại một thời điểm" không tương thích với việc cộng tác với AI. Nguyên lý VibeTDD: Viết các tập hợp test nhỏ, có trọng tâm trước, sau đó triển khai chúng cùng lúc. Điều này giúp giảm chi phí ngữ cảnh và duy trì kỷ luật test-first. #### 2. AI "khuếch đại" cách tiếp cận của bạn Nếu bạn không cung cấp cấu trúc và quy ước, AI sẽ tự tạo ra – và chúng sẽ không hề "ngon lành" chút nào. #### 3. Cần "vi quản lý" Với các yêu cầu phức tạp, bạn cần chia nhỏ công việc thành những phần cực kỳ nhỏ, rời rạc. AI không thể duy trì ngữ cảnh cho việc triển khai tính năng lớn. #### 4. Kiến trúc phải do CON NGƯỜI dẫn dắt AI mặc định sẽ chọn cấu trúc đơn giản nhất, cái mà hiếm khi là cấu trúc đúng đắn cho một phần mềm dễ bảo trì. #### 5. Chiến lược kiểm thử cần được "chăm chút" AI tạo ra các bài test "đầy đủ" thay vì các bài test "chiến lược". Nó không hiểu sự khác biệt giữa phạm vi bao phủ cần thiết và việc kiểm thử "quá mức" một cách vô lý. ### Lời phán quyết cuối cùng VibeTDD Phase 2 là một trải nghiệm "khiêm tốn hóa". Mặc dù AI chắc chắn có thể tạo ra mã vượt qua các bài kiểm thử, nhưng nó không thể duy trì kỷ luật và tư duy kiến trúc làm nên giá trị của TDD. Insight (cái nhìn sâu sắc) thực sự là: Giá trị của TDD không chỉ nằm ở việc có các bài kiểm thử, mà nó nằm ở **quá trình tư duy** tạo ra thiết kế tốt. AI có thể thực hiện *cơ chế* TDD nhưng không thể thực hiện *tư duy* TDD. ### Bước tiếp theo: "Đổi vai" Đối với Phase 3, tôi sẽ "lật ngược tình thế" hoàn toàn. Thay vì để Claude dẫn dắt, tôi sẽ tự mình lái quy trình TDD và sử dụng AI như một trợ lý triển khai. Giả thuyết của tôi là: Nếu con người cung cấp kỷ luật và kiến trúc thông qua thiết kế test, thì AI có thể là một đối tác triển khai *tuyệt vời*. Liệu Claude có viết mã tốt hơn khi bị "kiềm chế" bởi các bài test do con người thiết kế không? Liệu TDD có thể đóng vai trò "hàng rào bảo vệ chất lượng" cho mã do AI tạo ra không? Cùng chờ xem nhé! <img src='https://truyentranh.letranglan.top/api/v1/proxy?url=https://i.imgur.com/human_leads_ai.png' alt='Lập trình viên hướng dẫn trợ lý AI'> Bạn có thể tìm thấy toàn bộ mã nguồn của thí nghiệm này tại: VibeTDD Phase 2 Repository

Lê Lân

13/08/2025

Khám phá cách mình xây dựng một ứng dụng web quản lý cho thuê thiết bị xây dựng hiệu quả với serverless stack: Firebase Authentication, Firestore real-time database và Vercel deployment. Từ những vấn đề đau đầu đến giải pháp hiện đại, cùng tìm hiểu hành trình phát triển thú vị này nhé!

Lê Lân

12/08/2025

Khám phá Awesome AI Coding Tools, bộ sưu tập mã nguồn mở các công cụ AI mạnh mẽ nhất giúp tối ưu hóa quy trình phát triển phần mềm. Từ tạo code đến gỡ lỗi, tài liệu và hơn thế nữa. Đóng góp để xây dựng nguồn tài nguyên tốt nhất cho cộng đồng dev!

Lê Lân

28/07/2025

Khám phá cách tích hợp LLM vào quy trình phát triển phần mềm quy mô lớn, vượt xa tính năng tự động hoàn thành đơn thuần. Bài viết giới thiệu khuôn khổ và công cụ Rulebook-AI giúp nâng cao chất lượng, tính nhất quán và tuân thủ các nguyên tắc kỹ thuật tốt nhất.

Lê Lân

27/07/2025

Alo, alo các tín đồ AI! Năm 2025 này, thế giới phát triển AI đang 'chạy' nhanh hơn cả tên lửa, và dĩ nhiên, nó cũng khai sinh ra những phong cách lập trình AI cực kỳ độc đáo. Trong bài blog mới toanh này, chúng mình sẽ 'mổ xẻ' hai 'trường phái' đang làm mưa làm gió, định hình lại cách các bạn dev nghĩ, code và triển khai AI đó!1. Vibe Coding – Code theo 'cảm hứng'Nghe cái tên Vibe Coding là thấy 'chill' rồi đúng không? Đây là kiểu code mà bạn cứ 'phiêu' theo cảm hứng, nhanh như chớp và cực kỳ trực giác!Cực kỳ lý tưởng cho những lúc bạn muốn thử nghiệm ý tưởng nhanh gọn lẹ (kiểu prototyping), sáng tạo không giới hạn (creative coding) hay 'code ra kết quả' trong nháy mắt (real-time experimentation). Tưởng tượng nhé, nó cứ như bạn đang 'tám' chuyện với ChatGPT để nó tự động 'phọt' ra code, hay dùng Notion AI để viết bài vèo vèo, hoặc để Copilot 'nhả' gợi ý code 'thần tốc'. Bạn cứ 'phát' ra ý tưởng, còn AI sẽ giúp bạn biến nó thành hiện thực, không cần suy nghĩ quá nhiều, cứ để 'vibe' dẫn lối!<img src='https://truyentranh.letranglan.top/api/v1/proxy?url=https://i.imgur.com/vibe_coding_flow.png' alt='Vibe Coding - Lập trình AI theo cảm hứng và dòng chảy'>2. Agentic Coding – Code theo 'chiến lược'Nếu Vibe Coding là 'nghệ sĩ tự do', thì Agentic Coding lại là 'kiến trúc sư' đích thực! Phong cách này tập trung vào mục tiêu cụ thể, được chia thành từng module (khối) nhỏ gọn, và hoạt động cực kỳ tự động, bài bản.Nó sinh ra để dành cho việc xây dựng những 'AI agent' siêu thông minh, có khả năng suy luận, lập kế hoạch chi tiết và thực hiện hàng loạt các bước phức tạp một cách mượt mà. Cứ hình dung như bạn đang 'dựng' một 'người máy' có thể tự động tìm kiếm thông tin, phân tích, rồi đưa ra quyết định mà chẳng cần bạn phải nhúng tay quá nhiều vậy.Về kỹ thuật, bạn sẽ kết hợp sức mạnh của các LLM (Mô hình Ngôn ngữ Lớn) mã nguồn mở với logic tự động hóa chặt chẽ và những 'mệnh lệnh' (prompt) được cấu trúc tinh vi. Mọi thứ đều được tính toán kỹ lưỡng, đâu ra đấy!<img src='https://truyentranh.letranglan.top/api/v1/proxy?url=https://i.imgur.com/agentic_coding_modules.png' alt='Agentic Coding - Lập trình AI theo mục tiêu và module'>Dù bạn đang 'ôm' dự án cá nhân, 'cân' hệ thống tự động hóa cho cả doanh nghiệp, hay 'đắp' ra những sản phẩm AI 'độc lạ bình dương', thì việc nắm rõ khi nào nên 'bung lụa' với Vibe Coding và khi nào cần 'lên khuôn' với Agentic Coding chính là bí kíp 'khai sáng' cho sự nghiệp AI của bạn đó! Đây chính là siêu năng lực mà mọi dev AI đều muốn sở hữu!<a href="https://agamitechnologies.com/blog/vibe-coding-vs-agentic-coding">Đọc bài blog đầy đủ để hiểu sâu hơn về hai phong cách này nhé!</a>Giờ thì, 'phi đội' AI của chúng ta ơi, chia sẻ ngay nào! Phong cách nào bạn 'tâm đắc' hơn khi 'xây dựng' AI: Vibe hay Agentic?

Lê Lân

21/07/2025

Este artigo explora como a Inteligência Artificial e Modelos de Linguagem de Grande Escala (LLMs) estão revolucionando a Engenharia de Software. Aborda o Desenvolvimento Assistido por IA (AIAD), melhores práticas, MLOps, desafios éticos e a implementação para impulsionar a transformação digital em negócios.

Lê Lân

19/07/2025

Khám phá cách Vercel v0 và Strapi AI đang cách mạng hóa quy trình phát triển web, từ việc tạo nguyên mẫu giao diện người dùng siêu tốc đến quản lý nội dung thông minh. Hãy cùng tìm hiểu những công cụ AI này giúp bạn xây dựng ứng dụng web hiện đại, năng động và khả năng mở rộng dễ dàng.

Lê Lân

18/07/2025

Khám phá dự án Storog biến smartphone cũ thành hệ thống an ninh thông minh dùng Kotlin, CameraX, Gemini AI và Telegram, được phát triển chủ yếu bởi trợ lý AI. Tìm hiểu cách một chiếc điện thoại cũ có thể trở thành "bảo vệ" giám sát hình ảnh, phân tích bằng AI và gửi cảnh báo qua Telegram.

Lê Lân

18/07/2025

Tuyển tập Awesome AI Coding Tools là danh sách mã nguồn mở, được tuyển chọn kỹ lưỡng các công cụ AI hữu ích nhất cho lập trình viên, từ sinh mã đến gỡ lỗi và tài liệu.

Lê Lân

14/07/2025

Khám phá sự thật về lập trình với AI: So sánh OpenAI, Anthropic, Google Gemini và bí quyết tận dụng tối đa Lovable.dev để xây dựng sản phẩm thực tế nhanh chóng.

Lê Lân

13/07/2025

Chào bạn, có bao giờ bạn nghĩ đến việc xây dựng một "engine" lập trình chỉ với sự trợ giúp của AI chưa? Nghe thì "ngầu" và có vẻ nhanh, tiện lợi lắm đúng không? Tôi cũng từng nghĩ vậy đấy! Nhưng hóa ra, đây lại là một cuộc "thí nghiệm" không hồi kết, nơi tôi chẳng bao giờ biết ngày mai mình sẽ gặp phải chuyện gì. Đôi khi AI cho ra những ý tưởng siêu phàm, nhưng lắm lúc nó lại "lạc trôi" đi đâu đó, khiến tôi phải ngồi vò đầu bứt tóc: "Liệu có thể xây dựng một thứ gì đó thực sự dùng được với con AI này không?". Nhiều khi tôi có cảm giác mình không phải đang "code" mà là đang "quản lý mớ hỗn độn" mà chính "người cộng sự" AI của mình gây ra! Bài viết này là một cuốn nhật ký chân thực về cuộc thí nghiệm ấy. Không có gì đảm bảo thành công đâu nhé, nhưng chắc chắn tràn ngập "vibe" và những bất ngờ thú vị! 🎲 Bây giờ, hãy cùng xem tôi đã "dấn thân" vào con đường này như thế nào, và tại sao AI lại "dính líu" vào đây... 🤖 <img src='https://truyentranh.letranglan.top/api/v1/proxy?url=https://i.imgur.com/AICodeChaos.png' alt='AI tạo ra code hỗn loạn'> Mọi chuyện bắt đầu từ một ý nghĩ chợt lóe lên trong đầu tôi: "Tại sao không thử tạo một trò chơi giả lập cuộc sống của một lập trình viên, dùng một cách tiếp cận mới toanh - 'Vibecoding' nhỉ?". Chỉ trong vài giây, tôi đã viết xong những dòng code đầu tiên, và thế là, game gần như đã... hoàn thành! Một "người chơi" đầu tiên xuất hiện, với hình ảnh nhân vật của riêng mình – và những nét phác thảo đầu tiên của một thế giới ảo bắt đầu hiện rõ. Nhưng đó mới chỉ là khởi đầu cho hành trình "Vibecoding" của tôi. Ý tưởng này nghe có vẻ "độc đáo" và "meta-cool" đến mức một quyết định khác tự động xuất hiện: với một trò chơi được tạo ra theo cách "dị" như vậy, nó cần một engine độc nhất vô nhị của riêng mình. Các engine hiện đại thường không "hợp cạ" với AI vì cấu trúc bên trong của chúng thường "đóng kín", khiến AI không thể điều khiển hay thay đổi sâu bên trong được. Thế nên, tôi muốn tự tay tạo ra một thứ gì đó "mở", sẵn sàng cho mọi thử nghiệm và hợp tác thực sự với AI. 🛠 <img src='https://truyentranh.letranglan.top/api/v1/proxy?url=https://i.imgur.com/VibecodingConcept.png' alt='Ý tưởng Vibecoding'> Một phần không thể thiếu của "Vibecoding" chính là sự "khó lường" của nó. Đôi khi, trợ lý AI của tôi hăm hở tạo ra hàng trăm dòng code cho một tính năng mới, nhưng... nó lại chẳng hoạt động chút nào. Hoàn toàn không! Thế là tôi lại ngồi đó, "mổ xẻ" cái thành quả lao động "hoành tráng" của trí tuệ nhân tạo, cố gắng tìm ra lỗi. Sau một hồi "ngâm cứu" (và có lẽ là hơn một cốc cà phê ☕), tôi chợt nhận ra một chi tiết "ngớ ngẩn": một biến được khai báo sai phạm vi, hoặc một dòng code nào đó lại "đá nhau" với dòng khác. Tôi di chuyển cái biến "đáng nguyền rủa" đó đến đúng phạm vi – và, một phép màu đã xảy ra, mọi thứ bỗng "sống lại" một cách kỳ diệu! Những khoảnh khắc như vậy, bạn sẽ cảm thấy mình vừa là một thám tử 🕵️‍♂️ vừa là một phù thủy 🧙‍♂️, nhận ra rằng ngay cả AI tiên tiến nhất cũng không thể thay thế hoàn toàn trực giác và kinh nghiệm của con người. Nhưng quá trình gỡ lỗi và giải quyết vấn đề lặp đi lặp lại cùng nhau này mới chính là "vibe" thực sự! ✨ <img src='https://truyentranh.letranglan.top/api/v1/proxy?url=https://i.imgur.com/AIBugDebugging.png' alt='Người lập trình đang gỡ lỗi code AI tạo'> Đôi khi, việc "cãi nhau" với AI còn trở thành một môn thể thao riêng: nó lười biếng, nó ngớ ngẩn, bạn chỉ muốn "chửi thề" một trận, và một số mô hình (tôi nghĩ là Gemini) thậm chí còn có thể "chửi lại" bạn cơ! Những lúc như vậy, bạn nhận ra làm việc với AI không chỉ là code – mà còn là "dây thần kinh", sự kiên nhẫn và khiếu hài hước. 😅 Điều làm tôi bực mình nhất là khi mô hình làm điều gì đó bạn không mong đợi, bạn chỉ ra lỗi, và nó trả lời: "Tôi đã làm đúng như bạn yêu cầu" và thậm chí còn trích dẫn lại chính lời của bạn! Lúc đó, bạn chỉ muốn tắt máy tính và đi "làm vài ly" thôi! 🥃 Tôi làm việc song song với tất cả các mô hình mới nhất: Sonnet 3.7, Gemini 2.5, GPT 4.1. Và thành thật mà nói, chỉ có Sonnet và Gemini là thực sự cho phép bạn viết code và nhận được câu trả lời hợp lý – còn lại thì hoặc chẳng làm gì cả, hoặc cố gắng xây dựng một kiến trúc song song khổng lồ cho một tính năng bé tí tẹo! 🤦‍♂️ Đôi khi bạn mất hàng giờ để "thuyết phục" AI tạo ra một thứ gì đó hoạt động được, chỉnh sửa, tạo lại, lại chỉnh sửa... Và đến một lúc nào đó bạn nhận ra rằng, hiệu quả hơn là cứ bấm "reset", xóa sạch tất cả những "sáng tạo" của AI, và bắt đầu lại từ đầu. Hoặc, thở dài thườn thượt, tự mình ngồi xuống viết đoạn code đó theo kiểu "cổ điển". Đó cũng là "Vibecoding" – sự linh hoạt trong tư duy và biết khi nào nên tin tưởng vào cỗ máy, và khi nào nên tin vào đôi tay và cái đầu của chính mình. 💪 <img src='https://truyentranh.letranglan.top/api/v1/proxy?url=https://i.imgur.com/AIStubbornness.png' alt='AI trả lời bướng bỉnh'> Hệ thống biến đổi (transformation system) – nền tảng cho việc định vị, xoay và thay đổi kích thước đối tượng – đã trải qua rất nhiều lần "lột xác". Dù đây là một chức năng tiêu chuẩn cho bất kỳ engine nào, việc xây dựng nó cùng với AI lại có một cái "chất" riêng. Các mô hình AI hiện đại không hề "hiểu" khái niệm không gian là gì. Chính vào khoảnh khắc đó, ảo ảnh về "trí thông minh" sụp đổ: bạn nhận ra nó chỉ là một bộ tạo chuỗi token – đúng về mặt hình thức, nhưng chẳng có ý niệm gì về việc nó tồn tại trong thế giới thực như thế nào. Cuối cùng, tôi cũng đã thành công trong việc làm cho các thành phần chịu trách nhiệm hiển thị (dù là ảnh tĩnh hay sprite động) tự động đồng bộ hóa với các thay đổi của phép biến đổi, đảm bảo hệ thống luôn phản hồi mượt mà. 🖼 Tiếp theo là hệ thống vật lý – một lần nữa, AI chẳng "hiểu" các khái niệm thế giới hay cách kết nối nó với các phép biến đổi. Sau một ngày "thử và sai", tôi đành ngồi xuống và tự mình viết nó thôi. ⚡ <img src='https://truyentranh.letranglan.top/api/v1/proxy?url=https://i.imgur.com/EngineTransformPhysics.png' alt='Hệ thống transformation và vật lý trong game engine'> Và một engine thì làm sao mà thiếu được "editor" của riêng nó nhỉ? Tôi và AI đã tạo ra một bộ công cụ để quá trình phát triển trở nên thoải mái nhất có thể – ở đây, AI thực sự đã làm rất tốt, dù tôi phải liên tục "nhắc nhở" nó tái sử dụng code có sẵn thay vì viết lại tất cả các style từ đầu mỗi lần: Object Inspector: Cho phép bạn "soi" sâu vào bất kỳ đối tượng nào trong game, xem các thành phần của nó (như transform hay sprite), và nhanh chóng điều chỉnh thuộc tính của chúng. Các thành phần mới có thể được thêm "trên đường bay" hoặc xóa đi những cái không cần thiết. Asset Manager: Một bảng điều khiển tiện lợi để quản lý đồ họa và các tài nguyên khác của dự án. Tài nguyên có thể dễ dàng kéo thả trực tiếp vào khung cảnh game. Sprite Sheet Editor: Niềm tự hào đặc biệt của tôi! Một cửa sổ riêng biệt nơi bạn có thể tải lên một hình ảnh (sprite sheet) và "cắt lát" nó thành các khung hình cho hoạt ảnh một cách trực quan. Bạn có thể tạo khung hình, thay đổi kích thước và thứ tự của chúng, rồi lưu thông tin này lại. Sau đó, thành phần sprite sẽ sử dụng dữ liệu này để tạo hoạt ảnh mượt mà. Không còn phải mất công thiết lập tọa độ khung hình thủ công nữa! Gizmo: Một công cụ tương tác ngay trên khung cảnh để thao tác trực quan với các đối tượng được chọn: di chuyển, xoay, thay đổi kích thước. Tôi đã đặc biệt chú ý để làm cho Gizmo trực quan và hoạt động chính xác với điểm xoay (pivot point) của đối tượng. Bạn có thể đoán được rồi đấy – mô hình AI không hề biết cách để làm cho thứ này hoạt động. Nhưng sau lần tạo lại thứ 10, nó cũng "tạm ổn" rồi! 🛠 <img src='https://truyentranh.letranglan.top/api/v1/proxy?url=https://i.imgur.com/EngineEditorTools.png' alt='Giao diện editor của game engine với các công cụ'> Kết quả không chỉ là một đống code vô tri, mà là một game engine hoàn chỉnh! Vâng, có thể nó chưa hoàn hảo, và lịch sử của nó có những khoảnh khắc khiến bạn phải bật cười, nhưng nó là của tôi, độc nhất vô nhị, được xây dựng dựa trên sự nhiệt huyết thuần túy, dòng chảy của cảm hứng và sự hợp tác chặt chẽ với một trợ lý AI. Engine này là bằng chứng sống cho thấy "Vibecoding" với AI không chỉ là một từ thông dụng, mà là cả một triết lý phát triển. Nó cho phép bạn không sợ thử nghiệm, dũng cảm đối mặt với sai lầm (chúng là một phần của hành trình!), và tự tin tiến về phía trước. Đây là một quá trình mà bạn không ngại thử những điều mới, ngay cả khi kết quả trung gian đôi khi trông... "dị" một chút. Điều quan trọng chính là quá trình tìm tòi sáng tạo, cái "vibe" độc đáo khi tạo ra một thứ gì đó mới mẻ, của riêng mình, cùng với AI. Và engine này chính là bằng chứng sáng giá nhất cho điều đó. ✨ <img src='https://truyentranh.letranglan.top/api/v1/proxy?url=https://i.imgur.com/VibeEngineResult.png' alt='Game engine được tạo ra từ Vibecoding'> Vậy đó, đây chính là "engine vibe" mà tôi đã tạo ra. Không hoàn hảo, không đúng sách vở, nhưng là của riêng tôi – với những bug, những "meme" và cả một núi "nỗi đau" để chia sẻ cùng bạn bè qua những miếng pizza ngon lành! 🍕 Và vâng, không một hệ thống nào hoàn thành 100% cả: có bug và "ngõ cụt" logic ở khắp mọi nơi, và việc sửa chúng thì... thà viết lại từ đầu còn dễ hơn! Sai một "agent" để refactor cũng không phải là ý hay: nó sẽ hết ngữ cảnh hoặc đơn giản là "mất dấu" logic. 🤷‍♂️ Nếu bạn đã đọc đến đây – xin nể bạn! Đừng ngại thử nghiệm, tranh cãi với AI, đôi khi hãy xóa sạch mọi thứ và bắt đầu lại. Đó mới là niềm vui thực sự của "Vibecoding". Và nếu bạn đã từng có những khoảnh khắc "lịch sử" hoặc hài hước của riêng mình với AI – đừng ngần ngại chia sẻ chúng ở phần bình luận nhé. Hãy cùng nhau tạo nên một "bộ sưu tập" những câu chuyện "vibe" và cười "sặc sụa" nào! 😂 <img src='https://truyentranh.letranglan.top/api/v1/proxy?url=https://i.imgur.com/HappyCodingCommunity.png' alt='Cộng đồng lập trình viên vui vẻ chia sẻ kinh nghiệm'>

Lê Lân

09/07/2025

Khám phá cách biến việc lập trình AI thất thường thành thành công gấp 10 lần bằng Kỹ thuật Context Engineering. Tìm hiểu 5 đặc tả 'as Code' để cung cấp thông tin toàn diện, giúp AI tạo mã chất lượng cao một cách nhất quán.

Lê Lân

08/07/2025

Khám phá cuộc thử nghiệm thực chiến 3 tháng với Amazon Q, Claude và GPT-4o trong lập trình. So sánh tốc độ, chất lượng code, và khả năng giải quyết vấn đề để tìm ra công cụ AI phù hợp nhất cho developer.

Lê Lân

02/07/2025

Khám phá lý do tại sao phương pháp 'code bằng cảm hứng' của AI lại không phù hợp với các hệ thống phần mềm doanh nghiệp phức tạp, quy mô lớn, nơi sự hiểu biết sâu sắc và ổn định là yếu tố sống còn.

Lê Lân

29/06/2025

Bài viết phân tích sâu về "vibe coding" và việc lạm dụng AI trong lập trình, chỉ ra những rủi ro bảo mật, kỹ thuật và môi trường, đồng thời đề xuất các ứng dụng AI tích cực.

Lê Lân

26/06/2025

Tìm hiểu Vibe Coding là gì, cách AI cách mạng hóa lập trình, giúp tạo phần mềm nhanh chóng bằng ngôn ngữ tự nhiên. Khám phá các khái niệm, cách hoạt động, lợi ích và thách thức.

Lê Lân

23/06/2025

Khám phá cách các công cụ AI như GitHub Copilot đang cách mạng hóa tốc độ code, nhưng làm thế nào để đảm bảo chất lượng và tính bền vững cho phần mềm lớn? Bài viết giới thiệu một framework toàn diện và dự án Rulebook-AI, một giải pháp tiên phong giúp tích hợp LLM vào quy trình phát triển phần mềm một cách có nguyên tắc, đảm bảo cả tốc độ lẫn chất lượng.

Lê Lân

18/06/2025

Chào mừng bạn đến với kỷ nguyên của trí tuệ nhân tạo (AI)! Bạn đã nghe về những 'trợ lý' lập trình AI (AI coding agents) chưa? Chúng ta đang sống trong một thời đại mà mấy 'em' này có thể giúp chúng ta 'phóng' ra hàng trăm dòng code chỉ trong tích tắc. Nghe là thấy mê rồi đúng không?<img src='https://truyentranh.letranglan.top/api/v1/proxy?url=https://i.imgur.com/AICodingAgent.png' alt='AI Coding Agent hỗ trợ viết code'>Thế nhưng, khoan vội mừng nhé! Dù các công cụ AI này siêu đỉnh, nhưng rất nhiều nhà phát triển – từ các 'ông lớn' công nghệ cho đến những startup bé xinh hay cả những người 'tự học' tại gia – lại vô tình... bỏ quên một 'người bạn' cực kỳ quan trọng: **Test-Driven Development (TDD)** và các thực hành tốt nhất trong lập trình. Chính vì thế, không ít lần, cái sự phấn khích 'phóng code' ban đầu lại nhanh chóng biến thành... bối rối, thất vọng, thậm chí là 'bó tay' khi phát hiện ra rằng, mớ code do AI tạo ra lại ẩn chứa đủ thứ lỗi 'tàng hình' mà bạn không ngờ tới!<img src='https://truyentranh.letranglan.top/api/v1/proxy?url=https://i.imgur.com/TDD_importance.png' alt='Tầm quan trọng của TDD trong phát triển phần mềm'>Bạn biết đấy, AI có thể viết code rất nhanh, nhưng nó chưa hẳn đã 'hiểu' được toàn bộ ngữ cảnh hay ý định sâu xa của bạn đâu nhé. Code nhanh thì tốt, nhưng code đúng, code chạy ổn định mới là điều quan trọng nhất, đúng không?<img src='https://truyentranh.letranglan.top/api/v1/proxy?url=https://i.imgur.com/CodeQuality.png' alt='Mối quan hệ giữa tốc độ và chất lượng code'>Vậy nên, khi làm việc với AI coding agents, việc áp dụng TDD và các thực hành tốt nhất là CỰC KỲ cần thiết. Đừng nghĩ AI viết code là bạn không cần kiểm tra đâu nhé! Hãy xem AI như một 'trợ lý siêu tốc', còn TDD chính là 'người kiểm duyệt' cuối cùng để đảm bảo mọi thứ 'đâu ra đấy', không để lọt bất kỳ 'con sâu' nào làm rầu nồi canh đâu. Cứ như có một 'cặp bài trùng' vậy!

Lê Lân

16/06/2025

Tìm hiểu cách tích hợp các mô hình ngôn ngữ lớn (LLM) như GitHub Copilot vào kỹ thuật phần mềm quy mô lớn một cách thông minh, kết hợp tốc độ AI với các nguyên tắc phát triển bền vững. Khám phá Rulebook-AI, một khung sườn điều phối AI giúp cải thiện chất lượng, tính nhất quán và khả năng hiểu ngữ cảnh của code do AI tạo ra.

Lê Lân

16/06/2025