# Thinnd Dev Chronicles

> A personal archive of software development stories, field notes, experiences, conversations and reflections. Written by Nhu Duy Thin (Thinnd). Every post exists in Vietnamese (default), English and Japanese.

How to use this site: each post has a clean Markdown version (the "index.md" links below). The full text of every post is in [llms-full.txt](https://www.thinnd.site/llms-full.txt). When you quote a post, name the author and link the canonical page. Numbers cite their sources inside each post, and posts mark what is illustration and what is evidence.

## Tiếng Việt

- [Một ngày mười ba bài lên blog cùng AI: nhật ký và số đo từ lịch sử git](https://www.thinnd.site/ky-su/mot-ngay-muoi-ba-bai-cung-ai/index.md): Từ 11:08 đến 16:23 trong một ngày, một phiên làm việc với AI agent trên chính kho mã của blog này tạo ra 22 commit (11 tính năng, 7 sửa lỗi, 4 tài liệu), mười hai bài viết ba ngôn ngữ kèm slide và ảnh chia sẻ, và 17.630 dòng thay đổi cộng dồn. Người dùng gửi 47 tin nhắn, trong đó 16 là báo lỗi hoặc yêu cầu làm lại. Trước 15:00 có 15 trên 33 tin nhắn là báo lỗi (45%), từ 15:00 chỉ 1 trên 14 (7%). Số liệu chỉ đo tốc độ và vòng sửa, không đo chất lượng hay người đọc, và đây là một người, một dự án, không có đối chứng.
- [Phỏng vấn thời AI: kế hoạch hai tuần](https://www.thinnd.site/hanh-trinh/phong-van-thoi-ai-hai-tuan/index.md): Phỏng vấn lập trình thời AI chưa có luật chung: theo các bản tóm tắt báo cáo CoderPad 2026, khoảng 46% trưởng nhóm tuyển dụng cho phép AI (rộng hoặc có ràng buộc), 20% quyết định theo trường hợp và 34% cấm, và Google được tin là đang thử vòng đọc và gỡ lỗi mã có trợ lý AI. Vì vậy bước đầu tiên là hỏi nhà tuyển dụng luật chơi. Kế hoạch hai tuần gồm: hỏi luật, luyện nền tảng không AI, luyện đọc và gỡ lỗi mã lạ, luyện làm cùng AI có kỷ luật (nêu kế hoạch, đòi nhỏ, đọc, kiểm thử, giải thích), phỏng vấn thử với người, và chuẩn bị ba câu chuyện về cách dùng AI.
- [Viết bài kiểm tra cho tính năng AI: bắt đầu từ ba mươi trường hợp thật](https://www.thinnd.site/ky-thuat/viet-bai-kiem-tra-tinh-nang-ai/index.md): Để đo một tính năng AI, hãy bắt đầu bằng phân tích lỗi trên dữ liệu thật thay vì dựng hạ tầng: đọc ít nhất khoảng ba mươi trường hợp bằng tay, ghi chú điều sai ở mỗi trường hợp, gom thành các nhóm lỗi và đếm. Sau đó mới viết bài kiểm tra cho những lỗi bạn thực sự thấy, ưu tiên mã kiểm tra thường khi quy tắc xác định được, và chỉ dùng mô hình làm giám khảo khi cần phán đoán, rồi đối chiếu giám khảo với người chấm. Dùng chấm đạt hoặc không đạt thay vì thang điểm.
- [Phát triển theo đặc tả: viết đặc tả trước khi để AI làm](https://www.thinnd.site/ky-thuat/phat-trien-theo-dac-ta/index.md): Phát triển theo đặc tả là viết ra hành vi mong muốn của một tính năng trước, rồi để AI làm dựa trên đó. Martin Fowler chia ba mức: viết đặc tả trước rồi có thể bỏ (spec-first), giữ đặc tả để bảo trì (spec-anchored), và coi đặc tả là nguồn chính còn mã chỉ là sản phẩm sinh ra (spec-as-source). Ông cũng nêu hạn chế thực tế: cùng một quy trình nặng cho việc nhỏ, nhiều tệp lặp lại khó duyệt, và tác nhân vẫn có lúc bỏ qua đặc tả. Cách dùng thực dụng là đặc tả nhẹ cho việc vừa và lớn, bỏ qua cho việc nhỏ.
- [OWASP Top 10 cho ứng dụng dùng AI: giải thích bằng ví dụ đời thường](https://www.thinnd.site/ky-thuat/owasp-top-10-ung-dung-ai/index.md): OWASP Top 10 cho ứng dụng LLM bản 2025 gồm mười rủi ro: tiêm lệnh, lộ thông tin nhạy cảm, chuỗi cung ứng, đầu độc dữ liệu và mô hình, xử lý đầu ra không an toàn, quyền quá rộng, lộ lời nhắc hệ thống, điểm yếu của vector và embedding, thông tin sai, và tiêu thụ không giới hạn. Hình dung ứng dụng như một lễ tân khách sạn: người lạ nhét giấy dặn, ai đó sửa sổ tay nhân viên, hoặc lễ tân giữ chìa khóa vạn năng. OWASP nhấn mạnh không có cách nào chặn hoàn toàn tiêm lệnh, nên cần giảm tác hại bằng quyền tối thiểu, coi đầu ra của mô hình là không đáng tin và để người duyệt việc rủi ro cao.
- [Khi AI viết code nhanh hơn, dev còn làm nghề sáng tạo không?](https://www.thinnd.site/suy-ngam/dev-con-lam-nghe-sang-tao-khong/index.md): Vẫn còn, nhưng phần sáng tạo dịch chuyển. Khi viết code trở nên rẻ, những việc khó thay thế là tìm ra vấn đề đáng giải, chọn hướng giải và chịu đánh đổi, kiểm chứng kết quả, và chăm sóc hệ thống cùng con người quanh nó. Rủi ro có thật: nếu giao hết phần viết, bạn có thể mất khả năng đánh giá điều AI làm ra (một thử nghiệm nhỏ của Anthropic thấy nhóm dùng AI đạt khoảng 50% bài kiểm tra so với khoảng 67% nhóm tự viết). Cách giữ nghề là tự phác ý tưởng trước, đọc kỹ như người chấm, tập xóa bớt và dành thời gian làm đồ nhỏ cho vui.
- [Ngày một kỹ sư xóa nhầm dữ liệu: câu chuyện GitLab 2017](https://www.thinnd.site/cau-chuyen/ngay-ky-su-xoa-nham-du-lieu-gitlab-2017/index.md): Ngày 31/1/2017, trong lúc dựng lại máy chủ phụ của cơ sở dữ liệu GitLab.com, một kỹ sư chạy lệnh xóa thư mục dữ liệu trên máy chủ chính thay vì máy chủ phụ và mất khoảng 300 GB trước khi kịp dừng. Khi đi tìm bản sao lưu, các lớp sao lưu đều không dùng được, nên GitLab phải khôi phục từ một bản chụp 6 giờ tuổi, mất khoảng 18 giờ, và mất dữ liệu của ít nhất 5.000 dự án, 5.000 bình luận và khoảng 700 tài khoản. Bài học chính của GitLab: sao lưu chưa thử khôi phục thì chưa phải sao lưu, và lỗi gõ nhầm chỉ là mắt xích cuối của một chuỗi lỗi quy trình.
- [Đối thoại giữa một fresher và một senior về học nghề thời AI](https://www.thinnd.site/tro-chuyen/doi-thoai-fresher-senior-hoc-nghe-thoi-ai/index.md): Qua một cuộc đối thoại dựng lại giữa fresher và senior, bài rút ra bốn điều: không ai hứa được AI sẽ không đổi thị trường, nhưng việc hiểu, gỡ lỗi và giải thích code vẫn là thứ được kiểm tra; nhờ AI viết hộ bài tập có thể làm bạn học kém đi (một thử nghiệm nhỏ của Anthropic thấy nhóm dùng AI đạt khoảng 50% bài kiểm tra so với khoảng 67% nhóm tự viết); hãy hỏi senior sau khi đã tự thử và mang theo điều đã thử; và senior cũng phải kiểm chứng AI vì cảm giác nhanh không phải số đo.
- [MCP là gì? Giải thích bằng ổ cắm điện](https://www.thinnd.site/ky-thuat/mcp-la-gi-o-cam-dien/index.md): MCP (Model Context Protocol) là một chuẩn mở để ứng dụng AI kết nối với công cụ và dữ liệu bên ngoài theo cùng một cách, giống ổ cắm điện chung cho mọi thiết bị. Thay vì mỗi ứng dụng AI tự viết kết nối riêng cho từng công cụ, công cụ chỉ cần có một máy chủ MCP và ứng dụng AI chỉ cần biết nói chuyện MCP. Đổi lại, mỗi máy chủ là một ổ cắm cấp điện cho AI, nên cần cầu chì: quyền tối thiểu, duyệt hành động nhạy cảm, và coi máy chủ của người lạ như mã chưa kiểm chứng.
- [Đừng đo năng suất bằng số dòng code](https://www.thinnd.site/tu-duy-san-pham/dung-do-nang-suat-bang-so-dong-code/index.md): Số dòng code đo lượng chữ viết ra, không đo giá trị giao cho người dùng, và còn bị bóp méo ngay khi trở thành mục tiêu (luật Goodhart). Thời AI nó càng sai vì AI viết hàng nghìn dòng trong vài giây. Hãy đo theo nhóm và theo kết quả: thời gian từ ý tưởng đến người dùng, tỷ lệ thay đổi gây lỗi, thời gian chờ duyệt, công việc làm lại và sự hài lòng của nhóm, dùng theo xu hướng chứ không dùng để xếp hạng cá nhân.
- [Từ chuyền tay sang nướng bánh chung: nhóm IT làm việc với nhau thế nào ở thời AI](https://www.thinnd.site/kinh-nghiem/lam-viec-nhom-thoi-ai/index.md): Nhiều nhóm IT đang thử chuyển từ chuyền việc qua nhiều khâu sang nhóm nhỏ, mỗi người đi được xa hơn nhờ trợ lý AI, và ghi ngữ cảnh ra giấy thay vì họp nhiều. Nút thắt vì thế dịch từ khâu viết sang khâu duyệt, nên cần quy tắc duyệt và nền kiểm thử tốt.
- [Vibe coding làm prototype trong một ngày: khi nào nên, khi nào nguy hiểm](https://www.thinnd.site/tu-duy-san-pham/vibe-coding-prototype-mot-ngay/index.md): Vibe coding, tức để AI viết code mà không đọc kỹ, phù hợp để làm prototype dùng một lần: kiểm chứng ý tưởng, demo cho người thật, công cụ cá nhân. Nó trở nên nguy hiểm khi có người dùng thật, dữ liệu cá nhân, đăng nhập hoặc thanh toán, vì lỗi dễ nằm ở phần người ta không đọc. Quy tắc: coi prototype là đồ bỏ đi, ghi rõ ngày bỏ, và chỉ đưa lên môi trường thật sau khi rà bằng danh sách kiểm bảo mật và kiểm thử.
- [Fresher thời AI: kế hoạch 12 tháng để thành junior](https://www.thinnd.site/hanh-trinh/fresher-thoi-ai-12-thang/index.md): Fresher thời AI nên dành 12 tháng cho bốn việc theo thứ tự: nền tảng tự viết tay (quý 1), dự án nhỏ có AI làm gia sư (quý 2), môi trường gần thật như review, sửa lỗi, đóng góp mã nguồn mở (quý 3), rồi hồ sơ và phỏng vấn (quý 4). Quy tắc xuyên suốt: tự viết trước, nhờ AI giải thích sau, và luôn giải thích lại được code của mình. Một thử nghiệm ngẫu nhiên nhỏ của Anthropic cho thấy người nhờ AI viết hộ làm bài kiểm tra kiến thức kém hơn nhóm tự viết.
- [Sổ tay cho AI (AGENTS.md): viết thế nào cho ngắn, đúng và có ích](https://www.thinnd.site/ky-thuat/so-tay-cho-ai-agents-md/index.md): AGENTS.md là tệp văn bản nằm trong dự án để dặn AI agent những điều nó không tự suy ra được: lệnh chạy, cấu trúc tổng thể, quy ước và điều cấm. Hai nghiên cứu cho kết quả trái nhau về hiệu quả, nên hãy viết ngắn, do người viết, chỉ ghi điều AI không thể đọc ra từ code, rồi tự đo trước và sau.
- [Duyệt code do AI viết: danh sách kiểm 15 điểm cho người đọc diff](https://www.thinnd.site/ky-thuat/duyet-code-do-ai-viet/index.md): Khi AI viết code, nút thắt dời sang khâu duyệt, nên người duyệt cần một danh sách cố định thay vì đọc theo cảm giác. Danh sách 15 điểm gồm bốn nhóm: hiểu đúng việc, đúng và an toàn, kiểm thử có giá trị, và dễ bảo trì. Điểm hay bị bỏ sót nhất là thư viện có thật không, đầu vào có bị tin quá không, và test có thất bại khi code sai không.
- [Ba tiếng làm việc với một AI agent trên dự án thật: nhật ký và số đo](https://www.thinnd.site/ky-su/nhat-ky-ai-agent-du-an-that/index.md): Trong một buổi làm việc ba tiếng với AI agent trên dự án này, 7 trong 12 commit là sửa lại sau phản hồi của người, dù chúng chỉ chiếm khoảng 5% số dòng thay đổi. Gần nửa số tin nhắn của người là báo lỗi hoặc yêu cầu làm lại, và phần lớn lỗi là điều mắt nhìn thấy chứ không phải lỗi logic.
- [Vì sao không nên tin AI tuyệt đối: hiểu cách nó đoán để biết khi nào phải kiểm chứng](https://www.thinnd.site/ky-thuat/khong-nen-tin-ai-tuyet-doi/index.md): AI viết ra câu nghe hợp lý nhất, không phải câu đã được kiểm chứng. Có thể hình dung nó đoán xem từ nào nên đứng tiếp theo, nên vẫn có thể bịa số liệu, nhầm nghĩa hay tính sai bằng giọng rất chắc chắn. Cách dùng đúng là tin có điều kiện: kiểm chứng theo mức hậu quả.
- [Nghề Dev qua các thời kỳ: từ code tay đến AI Agent và xa hơn](https://www.thinnd.site/suy-ngam/hanh-trinh-nghe-dev/index.md): Nút thắt của nghề dev liên tục dịch chuyển: từ gõ được code, đến tìm lời giải, vận hành hệ thống, kiểm chứng code do máy viết, rồi định nghĩa đúng vấn đề và điều phối AI. Kỹ năng bền nhất là tư duy hệ thống, viết đặc tả, review và kiểm thử.

## English

- [Thirteen Posts in a Day with AI: A Log and Numbers from the Git History](https://www.thinnd.site/en/field-notes/thirteen-posts-in-a-day-with-ai-git-numbers/index.md): From 11:08 to 16:23 in one day, a session with an AI agent on this blog's own repository produced 22 commits (11 features, 7 fixes, 4 docs), twelve three-language posts with slides and share images, and 17,630 summed changed lines. The user sent 47 messages, 16 of them bug reports or redo requests. Before 15:00, 15 of 33 messages were bug reports (45%); from 15:00, only 1 of 14 (7%). The numbers measure speed and fix rounds, not quality or readers, and this is one person, one project, no control group.
- [Interviewing in the AI Era: A Two-Week Plan](https://www.thinnd.site/en/journeys/ai-era-interview-two-week-plan/index.md): There is no shared rulebook for coding interviews in the AI era: according to summaries of CoderPad's 2026 report, about 46% of hiring leaders allow AI (broadly or with constraints), 20% decide case by case and 34% ban it, and Google is reported to be piloting a code reading and debugging round with an AI assistant. So the first step is to ask the employer the rules. The two-week plan: ask the rules, practice fundamentals without AI, practice reading and debugging unfamiliar code, practice working with AI in a disciplined way (state a plan, ask small, read, test, explain), mock interviews with a person, and prepare three stories about how you use AI.
- [Writing Evals for an AI Feature: Start from Thirty Real Cases](https://www.thinnd.site/en/engineering/writing-evals-for-ai-features-thirty-real-cases/index.md): To measure an AI feature, start with error analysis on real data rather than building infrastructure: read at least about thirty cases by hand, note what went wrong in each, group the notes into failure categories and count them. Only then write evals for the failures you actually see, preferring ordinary code checks where a rule can be stated, and using a model as a judge only when judgment is needed, then compare the judge with human labels. Grade pass or fail rather than on a scale.
- [Spec-Driven Development: Write the Spec Before Letting AI Build](https://www.thinnd.site/en/engineering/spec-driven-development-write-the-spec-first/index.md): Spec-driven development means writing the desired behavior of a feature first, then letting AI build from it. Martin Fowler describes three levels: write the spec first and possibly discard it (spec-first), keep the spec for maintenance (spec-anchored), and treat the spec as the main source with code as a generated product (spec-as-source). He also lists practical limits: one heavy workflow for small tasks, many repetitive files that are hard to review, and agents that sometimes ignore the spec. A pragmatic approach is a light spec for medium and large work, skipped for small tasks.
- [OWASP Top 10 for AI Apps, Explained with Everyday Examples](https://www.thinnd.site/en/engineering/owasp-top-10-for-ai-apps-everyday-examples/index.md): The OWASP Top 10 for LLM applications (2025) lists ten risks: prompt injection, sensitive information disclosure, supply chain, data and model poisoning, improper output handling, excessive agency, system prompt leakage, vector and embedding weaknesses, misinformation and unbounded consumption. Picture the app as a hotel receptionist: a stranger slips in a note, someone alters the staff handbook, or the receptionist holds a master key. OWASP stresses that prompt injection cannot be fully prevented, so reduce harm with least privilege, treat model output as untrusted and have a person approve high-risk actions.
- [When AI Writes Code Faster, Is Programming Still a Creative Craft?](https://www.thinnd.site/en/reflections/are-developers-still-creative-when-ai-writes-faster/index.md): Yes, but the creative part moves. When writing code gets cheap, the hard-to-replace work is finding a problem worth solving, choosing a direction and accepting trade-offs, verifying results, and caring for the system and the people around it. The risk is real: if you hand over all the writing you may lose the ability to judge what AI produces (a small Anthropic trial found the AI group scored about 50% on a quiz against about 67% for those who wrote by hand). To keep the craft, sketch your own idea first, read as a grader, practice deleting, and make small things for fun.
- [The Day an Engineer Deleted the Wrong Data: The GitLab 2017 Story](https://www.thinnd.site/en/stories/the-day-an-engineer-deleted-the-wrong-data/index.md): On 31 January 2017, while rebuilding the secondary of GitLab.com's database, an engineer ran a command that wipes the data directory on the primary instead of the secondary and lost about 300 GB before stopping it. When they looked for backups, none of the layers was usable, so GitLab restored from a snapshot about six hours old, took about 18 hours, and lost data for at least 5,000 projects, 5,000 comments and about 700 accounts. GitLab's main lesson: a backup you have never restored is not yet a backup, and the mistyped command was only the last link in a chain of process failures.
- [A Fresher and a Senior Talk About Learning the Craft in the AI Era](https://www.thinnd.site/en/conversations/fresher-senior-dialogue-learning-in-ai-era/index.md): Through a rebuilt dialogue between a fresher and a senior, this article draws four lessons: nobody can promise AI will not change the market, but understanding, debugging and explaining code are still what gets tested; letting AI write your exercises can leave you learning less (a small Anthropic trial found the AI group scored about 50% on a quiz against about 67% for those who wrote by hand); ask your senior after trying it yourself and bring what you tried; and seniors must verify AI too because feeling fast is not a measurement.
- [What Is MCP? Explained with a Power Socket](https://www.thinnd.site/en/engineering/what-is-mcp-power-socket/index.md): MCP (Model Context Protocol) is an open standard that lets AI applications connect to outside tools and data in one common way, like a shared power socket for every appliance. Instead of each AI app writing its own connection for each tool, a tool only needs an MCP server and an AI app only needs to speak MCP. In return, each server is a socket supplying power to the AI, so it needs a fuse: least privilege, human approval for sensitive actions, and treating a stranger's server as unverified code.
- [Do Not Measure Productivity by Lines of Code](https://www.thinnd.site/en/product-thinking/dont-measure-productivity-by-lines-of-code/index.md): Lines of code measures how much text was written, not the value delivered, and it gets distorted the moment it becomes a target (Goodhart's law). In the AI era it is even less meaningful because AI writes thousands of lines in seconds. Measure by team and by outcome: time from idea to user, change failure rate, review wait, rework and team satisfaction, used as trends rather than to rank individuals.
- [From Passing the Baton to Baking Together: How IT Teams Work in the AI Era](https://www.thinnd.site/en/experiences/team-work-in-the-ai-era/index.md): Many IT teams are trying to move from passing work through many stages to small crews where each person goes further thanks to AI assistants, writing context down instead of meeting a lot. The bottleneck shifts from writing to reviewing, so teams need review rules and a solid base of tests.
- [Vibe Coding a Prototype in One Day: When It Fits, When It Is Dangerous](https://www.thinnd.site/en/product-thinking/vibe-coding-one-day-prototype/index.md): Vibe coding, letting AI write code without reading it closely, suits throwaway prototypes: testing an idea, a demo for real people, a personal tool. It becomes dangerous once real users, personal data, login or payments are involved, because bugs hide in the parts nobody reads. The rule: treat a prototype as disposable, write down the date you will drop it, and put it on a real environment only after a security and testing checklist.
- [Fresher in the AI Era: A 12-Month Plan to Become a Junior](https://www.thinnd.site/en/journeys/fresher-ai-era-12-month-plan/index.md): A fresher in the AI era should spend 12 months on four things in order: foundations written by hand (quarter 1), small projects with AI as a tutor (quarter 2), near-real practice such as reviews, bug fixing and open-source contributions (quarter 3), then portfolio and interviews (quarter 4). The rule throughout: write first, ask AI to explain afterward, and always be able to explain your own code. A small randomized trial by Anthropic found people who let AI write for them scored lower on a knowledge quiz than people who wrote it themselves.
- [A Handbook for AI (AGENTS.md): How to Write It Short, Right and Useful](https://www.thinnd.site/en/engineering/writing-agents-md/index.md): AGENTS.md is a text file in the project that tells an AI agent what it cannot work out by itself: commands, the big picture, conventions and prohibitions. Two studies disagree on how well it works, so write it short, by a person, and only with what the AI cannot read from the code, then measure before and after.
- [Reviewing AI-Written Code: A 15-Point Checklist for People Who Read the Diff](https://www.thinnd.site/en/engineering/reviewing-ai-written-code/index.md): When AI writes code, the bottleneck moves to review, so reviewers need a fixed checklist instead of reading by feel. The 15 points fall into four groups: understand the task, correct and safe, tests that matter, and easy to maintain. The points most often missed are whether the library is real, whether inputs are trusted too much, and whether the tests fail when the code is wrong.
- [Three Hours with an AI Agent on a Real Project: A Log and the Numbers](https://www.thinnd.site/en/field-notes/agent-field-notes-real-project/index.md): In a three-hour session with an AI agent on this project, 7 of 12 commits were fixes after human feedback, even though they made up only about 5% of changed lines. Nearly half of the human's messages were bug reports or redo requests, and most bugs were things the eye sees, not logic errors.
- [Why You Should Not Trust AI Blindly: Understand How It Guesses to Know When to Verify](https://www.thinnd.site/en/engineering/why-not-to-trust-ai-blindly/index.md): AI writes the sentence that sounds most right, not one that has been verified. You can picture it guessing which word should come next, so it can still invent figures, mix up meaning or miscalculate in a very confident voice. The right way to use it is conditional trust: verify in proportion to the stakes.
- [The Dev Career Through the Eras: From Hand-Written Code to AI Agents and Beyond](https://www.thinnd.site/en/reflections/dev-career-through-the-eras/index.md): The bottleneck of the dev profession keeps moving: from being able to type code, to finding solutions, running systems, verifying machine-written code, and finally defining the right problem and orchestrating AI. The most durable skills are systems thinking, writing specs, reviewing and testing.

## 日本語

- [AIと1日で13本の記事：gitの履歴からの記録と数字](https://www.thinnd.site/ja/genba-noto/ichinichi-13-hon-no-kiji-ai-to-git-no-sushi/index.md): ある日の11:08から16:23まで、このブログ自身のリポジトリでAIエージェントと行った1回の作業で、22コミット（機能11、修正7、文書4）、スライドと共有画像つきの3言語の記事12本、合計17,630行の変更が生まれました。利用者は47通のメッセージを送り、そのうち16通が不具合報告ややり直しの依頼でした。15:00より前は33通のうち15通が不具合報告（45%）、15:00以降は14通のうち1通だけ（7%）。数字が測るのは速さと修正の回数で、品質や読者ではなく、1人、1つのプロジェクト、対照なしです。
- [AI時代の面接：2週間の計画](https://www.thinnd.site/ja/ayumi/ai-jidai-no-mensetsu-2shukan-keikaku/index.md): AI時代のコーディング面接には、共通の決まりがありません：CoderPadの2026年の報告の要約によると、採用担当のおよそ46%がAIを認め（広くまたは条件つき）、20%はケースごとに決め、34%は禁じており、Googleは、AIアシスタントつきのコードの読解とデバッグの回を試していると報じられています。だから最初の一歩は、採用側にルールを聞くことです。2週間の計画：ルールを聞く、AIなしで基礎を練習する、見知らぬコードを読んでデバッグする練習をする、規律を持ってAIと作業する練習をする（計画を述べ、小さく頼み、読み、テストし、説明する）、人と模擬面接をする、AIの使い方についての3つの話を準備する。
- [AI機能のための評価を書く：実際の30件から始める](https://www.thinnd.site/ja/gijutsu/ai-kinou-no-evals-30-no-jissai-no-jirei/index.md): AI機能を測るには、基盤を作る前に、実際のデータでのエラー分析から始めます：少なくとも約30件を手で読み、それぞれで何が悪かったかを書き、メモを失敗の分類にまとめて数えます。それから初めて、実際に見た失敗について評価を書きます。規則で書けるなら通常のコードによる検査を優先し、判断が要るときだけモデルを審査役にし、その審査役を人の採点と照らし合わせます。段階評価ではなく、合格か不合格で採点します。
- [仕様駆動開発：AIに任せる前に仕様を書く](https://www.thinnd.site/ja/gijutsu/spec-kudo-kaihatsu-shiyosho-wo-saki-ni/index.md): 仕様駆動開発とは、機能の望ましい振る舞いを先に書き、AIにそれに基づいて作らせることです。マーティン・ファウラーは3つの段階を挙げます：先に仕様を書き、後で捨ててもよい（spec-first）、仕様を残して保守に使う（spec-anchored）、仕様を主な源とし、コードは生成物とする（spec-as-source）。彼は実際的な限界も挙げています：小さな作業にも同じ重い手順、レビューしにくい繰り返しの多いファイル、エージェントが仕様を無視することがあること。実際的なやり方は、中規模と大規模の作業に軽い仕様を使い、小さな作業では省くことです。
- [AIアプリのOWASP Top 10：身近なたとえで説明する](https://www.thinnd.site/ja/gijutsu/ai-apuri-no-owasp-top10-mijika-na-rei/index.md): LLMアプリ向けのOWASP Top 10（2025年版）には10のリスクがあります：プロンプトインジェクション、機微情報の漏えい、サプライチェーン、データとモデルの汚染、不適切な出力処理、過剰な権限、システムプロンプトの漏えい、ベクトルと埋め込みの弱点、誤情報、無制限の消費。アプリをホテルの受付係に例えると、見知らぬ人がメモを差し込み、誰かが従業員の手引きを書き換え、受付係がマスターキーを持っている、という状況です。OWASPは、プロンプトインジェクションを完全に防ぐ方法はないと強調しており、最小限の権限、モデルの出力を信頼しないこと、リスクの高い操作を人が承認することで被害を減らします。
- [AIがコードを速く書く時代、開発者はまだ創造的な仕事なのか](https://www.thinnd.site/ja/kosatsu/ai-ga-hayaku-kaku-jidai-kaihatsusha-wa-souzou-suru-ka/index.md): はい、まだ創造的です。ただし創造的な部分は移ります。コードを書くことが安くなると、代わりにくい仕事は、解く価値のある問題を見つけること、方向を選びトレードオフを引き受けること、結果を確かめること、システムとその周りの人を気遣うことです。リスクは本物です。書くことをすべて任せると、AIが作ったものを判断する力を失いかねません（Anthropicの小さな試験では、AI群のテストは約50%、自分で書いた群は約67%）。技を保つには、まず自分でアイデアを描き、採点者として読み、削る練習をし、楽しみのために小さなものを作ることです。
- [エンジニアが間違ったデータを消した日：GitLab 2017年の話](https://www.thinnd.site/ja/monogatari/gitlab-2017-machigatte-deta-wo-keshita-hi/index.md): 2017年1月31日、GitLab.comのデータベースの副サーバーを作り直している最中に、エンジニアが副サーバーでなく主サーバーのデータディレクトリを消すコマンドを実行し、止めるまでに約300GBを失いました。バックアップを探すと、使える層はなく、GitLabは約6時間前のスナップショットから約18時間かけて復旧し、少なくとも5,000のプロジェクト、5,000のコメント、約700のアカウントのデータを失いました。GitLabの主な教訓：復元を試したことのないバックアップは、まだバックアップではない。打ち間違いは、運用上の失敗の連鎖の最後の輪にすぎなかった。
- [新人と先輩の対話：AI時代の学び方](https://www.thinnd.site/ja/taiwa/shinjin-to-senpai-no-taiwa-ai-jidai-no-manabi/index.md): 新人と先輩の作り直した対話から、4つのことが分かります：市場がAIで変わらないと約束できる人はいませんが、理解、デバッグ、コードの説明は今も確かめられる。AIに練習問題を書かせると学びが減りうる（Anthropicの小さな試験では、AI群のテストは約50%、自分で書いた群は約67%）。先輩に聞くのは自分で試した後で、試したことを持っていく。そして先輩もAIを確かめるべきで、速く感じることは測定ではない。
- [MCPとは何か？コンセントで説明する](https://www.thinnd.site/ja/gijutsu/mcp-towa-konsento-de-setsumei/index.md): MCP（Model Context Protocol）は、AIアプリが外部のツールやデータに、共通のやり方でつながるためのオープンな規格で、あらゆる家電のための共通のコンセントのようなものです。AIアプリごとにツールごとの接続を書く代わりに、ツールはMCPサーバーを持ち、AIアプリはMCPを話せればよくなります。その代わり、サーバー1つ1つがAIに電気を送るコンセントなので、ヒューズが要ります：最小限の権限、重要な操作への人の承認、見知らぬ人のサーバーは未検証のコードとして扱うこと。
- [生産性をコードの行数で測らない](https://www.thinnd.site/ja/purodakuto-shiko/gyosu-de-seisansei-wo-hakaranai/index.md): コードの行数は書かれた文字の量を測るもので、届けた価値を測りません。目標になった途端にゆがみます（グッドハートの法則）。AIが数秒で数千行を書く今は、さらに意味が薄れます。チームと成果で測りましょう：アイデアから利用者に届くまでの時間、変更の失敗率、レビュー待ち、手戻り、チームの満足度。個人の順位づけではなく、傾向として使います。
- [バトンリレーから、みんなでパン作りへ：AI時代のITチームの働き方](https://www.thinnd.site/ja/keiken/ai-jidai-no-chimu-no-hataraki-kata/index.md): 多くのITチームが、仕事を何工程にも回す形から、AIアシスタントのおかげで一人ひとりが遠くまで進める小さなチームへ移ろうとしています。会議を重ねる代わりに背景を紙に書きます。ボトルネックは書く工程から確認する工程へ移るため、レビューの決まりと十分なテストが必要です。
- [バイブコーディングで1日でプロトタイプ：向く場面と危ない場面](https://www.thinnd.site/ja/purodakuto-shiko/vibe-coding-ichinichi-purototaipu/index.md): バイブコーディング、つまりAIにコードを書かせて細かく読まないやり方は、使い捨てのプロトタイプに向いています：アイデアの検証、実際の人へのデモ、個人用ツール。実際の利用者、個人データ、ログイン、決済が入ると、誰も読まない部分に不具合が潜むため危険になります。規則：プロトタイプは使い捨てと考え、捨てる日を書き、セキュリティとテストのチェックリストを通してから本番環境に出す。
- [AI時代の新人：ジュニアになるための12か月計画](https://www.thinnd.site/ja/ayumi/ai-jidai-no-shinjin-12kagetsu-keikaku/index.md): AI時代の新人は、12か月を4つのことに順番に使うとよいでしょう：手で書く基礎（第1四半期）、AIを家庭教師にした小さなプロジェクト（第2四半期）、レビュー、不具合修正、オープンソースへの貢献など実践に近い環境（第3四半期）、そしてポートフォリオと面接（第4四半期）。一貫した規則は、先に自分で書き、AIには後で説明してもらい、自分のコードをいつも説明できること。Anthropicの小さな無作為化試験では、AIに書いてもらった人は、自分で書いた人より知識テストの成績が低かったと報告されています。
- [AI向けの手引き（AGENTS.md）：短く、正しく、役に立つ書き方](https://www.thinnd.site/ja/gijutsu/agents-md-no-kakikata/index.md): AGENTS.mdは、AIエージェントが自分では見抜けないこと（コマンド、全体像、決まり、禁止事項）を伝える、プロジェクト内のテキストファイルです。効果については2つの研究が食い違うので、短く、人が書き、コードから読み取れないことだけを書き、前後で測ってください。
- [AIが書いたコードのレビュー：差分を読む人のための15項目チェックリスト](https://www.thinnd.site/ja/gijutsu/ai-ga-kaita-code-no-review/index.md): AIがコードを書くとボトルネックはレビューに移るので、レビュアーには感覚で読むのではなく決まったチェックリストが要ります。15項目は4つのグループで、作業の理解、正確で安全、価値あるテスト、保守しやすさです。特に見落とされやすいのは、ライブラリが実在するか、入力を信じすぎていないか、コードが間違いのときにテストが失敗するかです。
- [実際のプロジェクトでAIエージェントと働いた3時間：記録と数字](https://www.thinnd.site/ja/genba-noto/ai-agent-jissai-no-purojekuto-nikki/index.md): このプロジェクトでAIエージェントと3時間作業したところ、12コミットのうち7つが人のフィードバックを受けた修正で、変更行数ではわずか約5%でした。人のメッセージの半分近くが不具合報告ややり直しの依頼で、不具合の大半は論理の誤りではなく、目に見えるものでした。
- [AIを鵜呑みにしてはいけない理由：推測の仕組みを知り、検証すべき場面を見極める](https://www.thinnd.site/ja/gijutsu/ai-wo-unomi-ni-shinai-riyu/index.md): AIが書くのは、いちばん正しそうに聞こえる文であって、確認された文ではありません。次にどの語が来るべきかを推測しているとイメージでき、だから数字を作り上げたり、意味を取り違えたり、計算を間違えたりしても、とても自信のある口調で話します。正しい使い方は条件つきの信頼で、結果の重さに応じて確認します。
- [開発者という職業の変遷：手書きコードからAIエージェント、そしてその先へ](https://www.thinnd.site/ja/kosatsu/kaihatsusha-no-ayumi/index.md): 開発者という職業のボトルネックは移り続けてきました。コードを書けること、解決策を探すこと、システムを運用すること、機械が書いたコードを確認すること、そして正しい問題を定義してAIを指揮することへ。長く使えるのは、システム思考、仕様を書く力、レビューとテストです。

## Optional

- [Tiếng Việt: home](https://www.thinnd.site/), [RSS](https://www.thinnd.site/rss.xml)
- [English: home](https://www.thinnd.site/en/), [RSS](https://www.thinnd.site/en/rss.xml)
- [日本語: home](https://www.thinnd.site/ja/), [RSS](https://www.thinnd.site/ja/rss.xml)
- [Sitemap](https://www.thinnd.site/sitemap.xml)