Ngày 22 tháng 4, tôi mở terminal, gõ một dòng cho Claude: “tôi muốn pivot sang AI engineer, cần học LLM bottom-up, viết blog làm output layer, plan giúp tôi 30 bài”. Đến chiều 17 tháng 5, bài thứ 30 đã live trên blog.nghia-pham.com. Gần 1 tháng. Không phải tôi viết một mình. Tôi viết bài 1, các bài còn lại do Claude Code agents viết song song.

Bài này không phải khoe productivity. Tôi muốn note lại thật cụ thể: workflow ra sao, cost rough estimate khoảng bao nhiêu, cái nào hay thật, cái nào dở thật, và ai nên (hoặc không nên) làm theo. Đặc biệt là cái dở, vì những bài “AI tăng năng suất 10x” trên LinkedIn thường bỏ qua phần đó.

Tại sao 30 bài

Lúc plan, tôi và Claude argue khá lâu. Tôi muốn approach “đọc paper rồi viết bài, không code”. Claude pushback: reading-only tạo illusion of understanding, không build được intuition thật về tại sao attention work, tại sao LoRA cheap. Chốt approach hybrid: 70% hands-on code cộng đọc Karpathy Zero-to-Hero, 30% viết blog làm nơi chốt kiến thức. Blog là output sau verify, không phải nguồn học.

Series chia 7 Part: Foundation, Tokenization và Embeddings, Attention và Transformer, Training, Fine-tuning, Inference, Advanced. Audience là senior dev 3+ năm FE/BE đã xài ChatGPT hằng ngày nhưng chưa đọc kỹ về LLM bên dưới. Đó là chính tôi của 2 tháng trước.

Bài 1 viết tay

Bài 1 (mental model pipeline tokenize, embed, predict next token) tôi để Claude viết trực tiếp trong session main. Không có agent, không có outline. Chỉ là tôi chat với Claude, edit thẳng vào file. Mất buổi tối.

Cái này quan trọng. Bài 1 không phải để “warm up”. Nó là style reference cho phần còn lại. Mọi agent sau này sẽ được brief: “viết theo tone của bài 1 này”. Analogy mở bài, numbered Phần N, pitfall storytelling, cheatsheet cuối, Lời kết teaser. Pattern này tôi đã chốt từ series Kibana A-to-Z trước đó, nhưng bài 1 là incarnation cụ thể cho LLM domain.

Publish xong, tôi tự hỏi: nếu một agent đọc bài này rồi viết bài 2, output có giống không. Nếu giống, scale lên 30 bài được.

Spawn 5 agents song song

Bài 2 đến 5 cộng landing page: tôi spawn 5 agent song song trong cùng một message, mỗi agent một bài. Prompt mỗi agent gồm:

  • File path bài 1 làm style reference (đọc trước khi viết).
  • Outline chi tiết của bài đó: từng Phần N nói gì, code example nào cần có, audience expectation, pitfall stories đề xuất.
  • Hard constraints: ASCII slug, frontmatter schema, lang vi, tags ASCII.
  • Mục tiêu word count (1500-2500 từ).

Wall clock cho batch 5: khoảng 8-10 phút. Tôi đứng dậy pha cà phê, quay lại đã có 5 file mới trong src/content/blog/. Đọc qua, sửa vài chỗ tone hơi tutorial-y, build, deploy.

Cảm giác lúc đó hơi lạ. Không phải vì “AI viết được”, cái đó năm 2023 đã clear. Lạ vì 5 thread chạy song song, mỗi thread đọc cùng một reference rồi đi viết về một topic khác nhau, output landed cùng lúc, tone consistent. Như có một team nhỏ.

Scale lên 8 agents

Phần 2 và Phần 3 (Tokenization, Attention, Transformer block, nanoGPT) là 8 bài. Tôi spawn 8 agent song song. Prompt ngắn hơn batch trước (đã có pattern, không cần explain lại) nhưng outline vẫn detailed.

Batch 8 wall clock: khoảng 3-5 phút. Token compute concurrent là sức mạnh thật của Claude Code, không phải feature marketing. Mỗi agent có context window riêng, không share, không lock chờ nhau. Cost mỗi agent rough estimate 35-45K token (input outline + reference bài 1 + output bài hoàn chỉnh).

Sau batch này tôi nhận ra một thứ. Bottleneck không còn ở “agent có viết được không”. Bottleneck là outline quality của tôi. Nếu outline mơ hồ (“nói về RoPE”), output mơ hồ. Nếu outline cụ thể (“Phần 1: positional encoding cũ, Phần 2: rotational matrix intuition, Phần 3: RoPE in PyTorch 10 dòng, Phần 4: pitfall khi train context dài”), output cụ thể. Tôi tốn nhiều thời gian viết outline hơn viết prose.

Part 4 đến Part 7: cluster commits

Phần 4 (Training) đến Phần 7 (Advanced) tôi đổi pattern: spawn agent trong branch riêng, mỗi cluster gom 8-9 bài, merge vào main qua PR-based workflow. Commit 61f99cd cluster-a (bài 14-21), commit fe5399c cluster-b (bài 22-30).

Workflow này thêm một layer review trước khi land vào main. Tôi đọc lướt từng bài, spot-check chỗ math, paste code Python vào Jupyter chạy thử, confirm reference link không broken. Mỗi cluster review tốn khoảng 1.5-2 giờ.

Tổng cost rough estimate: khoảng nửa triệu token cho 29 bài (bài 1 viết tay không tính). Tôi có Claude Max plan $200/month nên không trả per token, nhưng nếu pay-as-you-go thì rough estimate $20-30 cho cả series.

Cái hay

Speed. 1 tháng cho 30 bài là điều solo gần như impossible với tôi. Nếu viết tay, tôi optimistic estimate 6-9 tháng vì còn job và project khác. Speed này không miễn phí (cost token, cost review effort), nhưng so với alternatives thì gap quá lớn.

Consistency. Đây là phần tôi không expect. 30 bài viết bởi 30 instance khác nhau của model, output tone rất đồng nhất. Lý do: tất cả đọc cùng một reference (bài 1). Style frontmatter, structure Phần N, cheatsheet table, Lời kết teaser, dev-friendly analogy, tất cả lặp lại đều. Khi tôi viết tay 30 bài, mood của tôi tuần thứ 4 chắc chắn khác tuần đầu, tone sẽ drift. Agent không drift trong cùng một batch.

Parallel scaling. Cái này obvious nhưng đáng nhấn. Spawn 8 agent song song không tốn 8x wall clock, chỉ tốn ~1x (slowest agent quyết định). Đây là thứ tôi không thể tự làm: tôi chỉ có một bộ não, không split context được.

Cost amortization. So với thuê freelancer viết technical content (tham khảo VN: 500K-2M VND/bài 1500 từ, technical càng cao càng đắt), 30 bài có thể tốn 15-60 triệu. Token cost tôi rough estimate trong khoảng $20-30 (giả định pay-as-you-go). Một đơn vị magnitude khác hẳn.

Cái dở

Phần này viết thẳng. Chỉ nói cái hay là contribute thêm vào tiếng vang “AI 10x productivity” trên LinkedIn, cái này không giúp ai đưa quyết định.

Em-dash leak ra prose. Series xong, tôi grep thử em-dash trong toàn bộ blog: 555 em-dash trên 25 file. Phần lớn là batch LLM. Em-dash là LLM output tell rõ nhất, người Việt không dùng em-dash trong prose tự nhiên. Bài nào có nhiều em-dash đọc kiểu AI-generated, dù content đúng. Tôi đang batch fix cleanup, và sau incident này add rule no-ai-dash-tells.md vào project. Bài học: prompt sớm trong outline yêu cầu agent dùng dấu chấm, dấu phẩy, dấu chấm phẩy thay em-dash. Tôi add rule sau khi đã ship 25 bài có vấn đề.

Technical density mismatch audience. Một số bài deep dive (linear algebra, calculus, probability cho LLM) quá dày code và math cho audience target. Audience là senior dev đã xài ChatGPT, không phải sinh viên năm 1 ngành toán. Agent có xu hướng “show off” độ chi tiết, dồn nhiều derivation hơn cần. Tôi phải edit lại vài chỗ. Bài học: outline phải nói rõ “không derive từ axiom, anchor vào intuition rồi link external resource cho ai muốn deeper”.

Cost không rẻ nếu pay-as-you-go. Rough estimate $20-30 nghe rẻ vì subscription đã absorb. Output token đắt gấp 3-5 input; người không có flat-rate plan cần tính kỹ trước khi scale workflow này.

Hands-on milestone gap. Đây là cái dở nhất, và nó hoàn toàn là lỗi của tôi, không phải agent. Series có 3 milestone hands-on: bài 13 (nanoGPT từ đầu), bài 21 (fine-tune Llama-3 LoRA tiếng Việt trên RunPod), bài 26 (self-host vLLM cộng RAG). Đến giờ tôi chưa code xong bất kỳ milestone nào. Blog viết rất kỹ về cách làm, nhưng tôi chưa làm. Reader có thể đọc xong nghĩ “tôi hiểu rồi”, rồi cả tôi và reader đều có illusion of understanding. Plan tới: 2 tuần next làm nanoGPT, không viết thêm series mới cho đến khi xong milestone 1.

Reader feedback chưa có. Mới publish, chưa biết bài nào retention tốt, bài nào reader drop sau Phần 1. Đây không phải dở của workflow, nhưng là rủi ro: tôi đã invest 1 tháng và nửa triệu token vào content chưa có evidence có giá trị cho người ngoài. Optimal hơn có thể là viết 5 bài thật kỹ rồi đo retention trước khi scale 30.

Một moment quirky

Bài 13 là nanoGPT walk-through. Agent viết bài này có workaround tôi không expect. Project Claude Code của tôi có security hook scan Python code: nếu code có method tên là Python builtin tên-dài-3-chữ-bắt-đầu-bằng-e (cái mà evaluate string thành code, bạn biết tôi đang nói cái nào), hook block.

PyTorch có method standard tên gần giống, dùng để switch model từ training mode sang inference mode. Agent gặp tên này, hook scan, block. Agent không complain, nó tự workaround bằng model.train(False), một cách viết alternative trong PyTorch để đạt cùng effect.

Cái này hợp lý về code, nhưng moment đáng chú ý là: agent tự nhận ra hook đang block, tự pick alternative API, viết tiếp như không có gì. Tôi chỉ phát hiện sau khi đọc bài, thấy pattern không phổ biến, search history mới hiểu lý do.

Bạn senior dev nào đang nghĩ agent là “fancy autocomplete” có thể consider lại. Nó có problem solving thật trong scope task. Như một junior dev tự xoay xở khi block.

Có nên làm theo không

Workflow này hợp lý nếu:

  • Bạn đã có domain expertise ở chủ đề viết. Outline tốt cần đi từ knowledge thật. Nếu bạn chưa biết về LLM mà bắt agent viết series LLM, output sẽ smooth và sai. Reader hoặc bạn không spot được sai.
  • Bạn chỉ thiếu output bandwidth, không thiếu insight. Insight phải có sẵn (paper đã đọc, code đã chạy, intuition đã build), agent chỉ là layer convert insight thành prose tiếng Việt readable.
  • Bạn sẵn sàng dành 40-50% effort cho outline cộng review. Đừng tưởng “AI viết hết”. Outline detailed và review pass là phần khó nhất.
  • Bạn có cơ chế catch AI-tells (em-dash, “Tóm lại”, “Hãy cùng tìm hiểu”, boilerplate intro). Grep trước khi publish. Tôi đã ship trước khi có grep rule.

Workflow này KHÔNG hợp lý nếu:

  • Bạn đang học chủ đề mình viết. Agent sẽ confidently viết sai, bạn confidently publish sai. Cả hai cùng tự deceive.
  • Output quality matter hơn velocity (book chapter, paid course, deliverable cho client). Một bài AI-assisted cao tay luôn thua một bài author chăm chút.
  • Bạn không có audience đo retention. Scale 30 bài mà không biết bài nào work là gamble.

Cái tôi sẽ làm khác lần sau

Nếu lùi lại tháng 4:

  1. Add rule no-em-dash từ bài 1, không chờ ship 25 bài rồi mới phát hiện.
  2. Viết 3 bài đầu thật kỹ, deploy, đo retention 2 tuần trước khi scale. Tôi mất 1 tháng và nửa triệu token cho 30 bài chưa biết bài nào reader thật sự đọc hết.
  3. Block 2 tuần cho milestone 1 (nanoGPT) ngay sau publish Part 3, không tiếp tục Part 4 trước khi code chạy. Hiện tại tôi có 30 bài và 0 milestone, ratio kỳ.
  4. Outline explicit về density expected từng bài. Bài explanation mềm khác bài có 5 code block khác bài có 3 bảng so sánh.

Cảm giác publish bài cuối

Bài 30 (eval LLM: MMLU, GSM8K, HumanEval) deploy chiều 17 tháng 5. Tôi nhìn npm run deploy print URL production, mở browser, scroll landing page series, hết 30 link prev/next. Cảm giác không phải “wow tôi xong rồi”. Cảm giác là “ok content layer xong, giờ đến phần khó”.

Phần khó là milestone hands-on, là 70% effort còn lại của plan ban đầu. Code nanoGPT từ đầu không có nghĩa là đọc code Karpathy rồi gật, nó là tự gõ từng dòng, gặp loss không converge, debug, retry. Không có agent nào viết được kinh nghiệm đó cho tôi.

Plan tới: 2 tuần nanoGPT, 1 tuần fine-tune LoRA Llama-3 trên RunPod, rồi self-host vLLM. Không viết series 2 cho đến khi xong milestone 1.

Bạn đã thử workflow tương tự chưa: viết tay bài đầu làm reference, spawn agent batch viết phần còn lại. Pattern nào hiệu quả nhất với bạn, pattern nào fail, ratio outline-review-write của bạn thế nào. Nếu có incident hoặc lesson tôi nên add vào bài này, comment hoặc nhắn cho tôi, tôi sẽ update.