Lập trình đôi cùng AI: hướng dẫn thực tế cho builder một mình

Có một sự cô đơn đặc biệt khi build một mình - không phải cô đơn theo nghĩa buồn bã, mà là cái cảm giác không có ai để nghĩ cùng. Bạn ngồi đó với màn hình, với đống lỗi, và không có người nào để nói "ý tôi muốn làm thế này" rồi nghe họ hỏi lại "tại sao?"

Pair programming - lập trình theo cặp - từng là thứ xa xỉ của những team lớn, với hai kỹ sư ngồi cạnh nhau, một người gõ, một người nghĩ. Không phải workflow của indie builder.

Nhưng bây giờ thì khác. AI đã trở thành một "người đồng hành" đủ năng lực ngồi ghế thứ hai - và câu hỏi không còn là có nên pair với AI không nữa, vì gần như ai cũng đang làm điều đó rồi. Câu hỏi thật sự là: bạn có đang làm điều đó có chủ đích không?

Tại sao "pair programming" là framework đúng

Trong mô hình truyền thống, có hai vai: driver thì gõ code, navigator thì nghĩ về cấu trúc, phát hiện vấn đề, và nhìn xa hơn. Họ đổi vai cho nhau. Không ai "cầm quyền" mãi mãi.

Điều làm mô hình này vận hành - dù với con người hay AI - là một cơ chế rất đơn giản: khi bạn giải thích điều mình đang làm, bạn bắt buộc phải hiểu nó. Không biết bao nhiêu lần, chính trong lúc soạn một prompt chi tiết, bạn sẽ tự nhiên tìm ra câu trả lời - trước khi AI kịp trả lời bạn.

Sự khác biệt giữa "dùng AI theo kiểu bình thường" và "pair với AI" là ở đây: ý định. Prompt mơ hồ cho ra code mơ hồ. Nhưng khi bạn tiếp cận mỗi session như một buổi pair - bạn là navigator, AI là driver - thứ bạn cho vào tốt hơn, thứ bạn nhận ra cũng tốt hơn.

Cách đổi vai thực tế

Với mỗi chunk công việc:

1. Bắt đầu ở vai navigator. Mô tả tính năng, ràng buộc, và output mong muốn bằng ngôn ngữ bình thường - như brief cho một kỹ sư giỏi nhưng chưa biết gì về codebase của bạn.
2. Review output của driver. Đừng paste vào và chạy ngay. Đọc code AI viết như đang review một pull request. Giả định nào đang được đặt ra? Edge case nào chưa được xử lý?
3. Đổi vai. Tự viết bước tiếp theo rồi mới giao lại. Hoặc nếu hướng AI đi sai, hãy tự refactor - rồi brief lại cho chunk tiếp theo.

Điểm mấu chốt là việc đổi vai. Ở mãi trong vai navigator - chỉ ra chỉ đạo mà không bao giờ tự viết - là con đường nhanh nhất dẫn đến comprehension debt: codebase chạy được nhưng bạn không còn thực sự hiểu nó nữa.

Rubber-duck debugging với con vịt biết nói chuyện

Kỹ thuật rubber-duck debugging kinh điển hoạt động vì một lý do đơn giản: diễn đạt vấn đề thành lời buộc bạn phải cấu trúc nó. AI là con vịt biết cấu trúc lại - nó đặt câu hỏi làm rõ, đưa ra giả thuyết, và giúp bạn loại trừ nguyên nhân nhanh hơn so với việc nhìn chằm chằm vào diff một mình.

Khi gặp bug, hãy thử cấu trúc này trước khi paste lỗi:

Tôi đang thấy [triệu chứng]. Tôi kỳ vọng điều này xảy ra: [expected behavior].
Điều đang thực sự xảy ra: [actual behavior].
Giả thuyết hiện tại của tôi là [giả thuyết]. Tôi đang bỏ qua điều gì?

Cấu trúc này buộc bạn hình thành giả thuyết trước khi hỏi - và điều đó thường tự nó đã trả lời câu hỏi. Khi không, response của AI sẽ thu hẹp không gian tìm kiếm thay vì cho bạn một gợi ý chung chung.

Buổi debug hay nhất không phải là lúc AI tìm ra lỗi nhanh nhất. Mà là lúc bạn hiểu codebase sâu hơn khi kết thúc so với lúc bắt đầu.

Context là thứ bạn phải chủ động cung cấp

Trong pair programming giữa người với người, navigator giữ context mà driver không cần nghĩ đến - business logic, kiến trúc hiện tại, những quyết định đã được đưa ra. Khi pair với AI, bạn phải tự cung cấp context đó - mỗi session, mỗi lần.

Một vài thứ nhất quán cải thiện chất lượng output:

• Chia sẻ ràng buộc, không chỉ yêu cầu. "Thêm retry mechanism" yếu hơn nhiều so với "Thêm retry mechanism - đây là app macOS có kết nối mạng không ổn định, và chúng ta không thể block main thread."
• Paste type và interface liên quan. AI hallucinate ít hơn khi nhìn thấy shape thực của data.
• Đề cập đến những gì bạn đã thử. Điều này ngăn AI quay lại các hướng bạn đã loại trừ.
• Nói rõ mức độ fidelity bạn muốn. "Phác thảo cấu trúc" và "production-ready, xử lý edge case" cho ra kết quả rất khác nhau.

Nếu muốn đi sâu hơn vào kỹ thuật cung cấp context, xem thêm cách cho AI context thực sự hữu ích.

Khi nào thì nên tự cầm bàn phím

Có những lúc bạn nên dừng pairing và tự viết code:

Khi logic là thứ thực sự riêng của sản phẩm bạn. AI cực kỳ mạnh với những pattern quen thuộc - CRUD, auth flow, parsing, UI component tiêu chuẩn. Nhưng với thứ gì đó genuinely unique với domain của bạn - một thuật toán đặc thù, một constraint không xuất hiện ở bất kỳ tài liệu công khai nào - nó thường confabulate một cách tự tin. Hãy tự viết phần đó.

Khi bạn đã accept ba gợi ý liên tiếp mà không đọc. Đây là dấu hiệu của crutch pattern. Dừng lại, đọc lại 20 dòng vừa được merge, và kiểm tra xem bạn có giải thích được từng quyết định không. Nếu không - bạn đang đổi một vấn đề thật lấy một vấn đề nhanh hơn.

Khi refactor liên quan đến toàn bộ cấu trúc của một module. AI tốt ở local transformation. Thay đổi kiến trúc lớn cần được một người nghĩ qua trước - rồi mới giao AI giúp thực thi kế hoạch đó, không phải tự nghĩ ra kế hoạch.

Một session 45 phút thực tế

0–5 phút: brief rõ ràng. Viết một đoạn ngắn mô tả bạn đang build gì, thứ gì đã có, và "done" trông như thế nào. Brief này là cho AI - nhưng thật ra hành động viết nó cũng đang làm rõ suy nghĩ của chính bạn. Nhiều bug được tránh ở bước này.

5–25 phút: drive từng chunk nhỏ. Giao một task được scoped rõ ràng mỗi lần. Review output. Đổi vai hoặc iterate. Đừng accept thứ gì bạn không giải thích được.

25–35 phút: tự viết phần khó. Xác định phần specific nhất với product logic của bạn - nơi AI có nhiều khả năng đoán sai nhất. Viết phần đó không có AI. Đây là lúc bạn "kiếm được" sự hiểu biết khiến phần còn lại maintainable về sau.

35–45 phút: để AI viết test. AI xuất sắc trong việc generate edge-case test khi đã có working code để xem xét. Đưa function, hỏi về những case bạn có thể bỏ sót, review và thêm những gì có vẻ đúng. Đây là một trong những use case genuinely high-leverage nhất.

Câu hỏi cần trả lời trước khi đóng tab

Trước khi kết thúc session, hãy tự hỏi: Nếu không có AI, mình có thể tự build lại phần core logic vừa ship không?

Không cần phải reproduce chính xác từng dòng - mà là "mình có hiểu đủ để defend nó trong code review, extend nó tuần sau, và debug nó khi nó break không?"

Nếu có, session đó thành công. Nếu không, bạn đã nhận comprehension debt mà lãi suất sẽ cộng dồn.

Suy cho cùng, pair programming với AI không phải là cách ship nhiều code hơn với ít công hơn. Đó là một practice để ship thứ thật trong khi vẫn là kỹ sư hiểu điều đang chạy trong production - và sự phân biệt đó đáng để bảo vệ.