{"slug": "please-make-mistakes", "title": "Please Make Mistakes", "summary": "A team lead at a software company is telling new hires to \"please make mistakes\" when using AI coding tools like Claude Code, encouraging aggressive experimentation over caution. The manager argues that developers must experience AI failure modes firsthand—such as hallucinated imports or broken refactors—because abstract warnings fail to stick, and that the real solution is building automated guardrails like instruction files and CI pipelines rather than restricting tool access. The approach aims to increase team throughput by letting AI generate five pull requests in the time it used to take to write one, while strengthening safety nets to catch errors before they reach production.", "body_md": "A new hire joined my team last month. My first message to them about AI tooling was three words: please make mistakes.\n\nUse Claude Code aggressively, try weird things, push the boundaries of what you think it can do. I’d rather see a PR that’s completely wrong than no PR at all. And then I catch what breaks in review.\n\nIt’s the only approach I’ve found that actually works.\n\n## The Mistakes[#](#the-mistakes)\n\nWhen someone starts using AI for real work, they hit the same failure modes in the same order. I know because I hit them all myself months ago.\n\nThey’ll trust a hallucinated import. They’ll accept a refactor that looks clean but breaks three downstream callers. Eventually someone gets a beautiful solution to a problem that doesn’t actually exist in their codebase.\n\nI did all of this. Weeks of it, before the patterns became obvious enough that I started building guardrails around the most common failures.\n\nBut you can’t skip these failures. I tried explaining them upfront, wrote docs, did walkthroughs. People nod, and then they make the exact same mistakes anyway. Understanding a failure mode in the abstract is different from experiencing it with your own code on your own branch.\n\n## Your Instruction Files[#](#your-instruction-files)\n\nEvery time I see a pattern of mistakes in PRs, I don’t write a Slack message about it. I go update an instruction file.\n\nI’ve got agents with specific domain constraints, skills wrapping deterministic workflows, CLAUDE.md files at the project level with rules about how the codebase should be structured. When a colleague’s AI-generated PR does something wrong, the first question I ask myself isn’t “why didn’t they know better?”\n\nThe question is “why didn’t my instruction files prevent that?”\n\nThe natural instinct is to focus on the person, to write a Slack message or leave a comment explaining the correct pattern. But the actual fix is in configuration. Your CLAUDE.md, your agent definitions, your pre-commit hooks.\n\nOne PR comment fixes one PR. One instruction file fixes every future PR from every person using that agent.\n\n## The Review Load[#](#the-review-load)\n\nI’ve been a code owner for a long time, well before AI was part of the workflow. The fundamental job hasn’t changed. You review PRs and catch things that shouldn’t ship before they affect customers.\n\nWhat changed is the volume and the pace.\n\nA colleague using Claude Code can generate 5 PRs in the time it used to take to write one. That means more review and more edge cases to catch. But the gatekeeper role was already there. AI just raised the throughput on both sides of the equation.\n\nThere’s a temptation to respond to all of this by restricting what people can do with AI tools. Limit access, gate Claude Code behind approvals and training sessions that nobody remembers a week later.\n\nThe opposite works better, in my experience. Let people experiment with everything and fail at everything. But make the safety net strong. Better CI pipelines that catch regressions before merge, and agent definitions that enforce your codebase’s conventions before the code is even written.\n\nThe mistakes that matter aren’t the ones your team makes in their local environment. They’re the ones that reach production. Your job is to make the distance between “mistake” and “customer impact” as long as possible, with as many automated checks in between as you can build.\n\n## The Runway[#](#the-runway)\n\nI had months to figure out how Claude Code works. Months of discovering that it hallucinates when context gets too large, that CLAUDE.md instructions degrade as conversations grow. It’ll confidently refactor code in ways that break things you didn’t ask it to touch. I built agents and skills and hooks and pre-commit checks that prevent failures I’d already experienced, one painful lesson at a time, over a long runway.\n\nMy colleagues don’t have that runway.\n\nThey’re hitting all of these failure modes for the first time, right now, while also trying to ship features on deadline. And they’re doing it without months of accumulated pattern-matching about what goes wrong and what the fix looks like when you finally find it.\n\nSo when I see a PR where Claude clearly lost track of the codebase’s architecture, my reaction isn’t “they should have caught that.” It’s “I need to make the `golang-general-engineer`\n\nagent carry more context about our service boundaries.”\n\nThe instinct is to flag the person. But that energy is pointing in the wrong direction. Point it at your instruction files, not at the person who’s still learning how the tool works.\n\nI still make mistakes with AI too. This week I let Claude refactor a validation pipeline and it dropped a critical check that would have let malformed data through to the API. Caught it only because I have a validation skill that runs deterministic checks against a known schema, and that skill only exists because I made the same mistake three months ago. Without that skill, it ships.\n\n## The Message[#](#the-message)\n\nHere’s what I actually tell people on their first day with Claude Code.\n\nPlease make mistakes. I’ll catch them. And when I do, I’ll improve the guardrails so they don’t happen again.\n\nNo training deck, no certification, no “AI coding best practices” document that nobody reads. Just permission to experiment and a code owner who takes responsibility for what ships.\n\nMaybe this doesn’t scale past a certain team size. I’m one person reviewing PRs for a handful of colleagues, and I can already feel the review load increasing. I don’t know what the answer is at 50 people or 200 people. Probably better tooling and better instruction files that do more of the catching before the PR even gets created.\n\nBut for now, at the scale I’m working at, it’s pretty simple. Let people learn by doing. Catch the mistakes before they reach customers. And when you see a pattern, fix the instruction file.", "url": "https://wpnews.pro/news/please-make-mistakes", "canonical_source": "https://vexjoy.com/posts/please-make-mistakes/", "published_at": "2026-05-09 00:00:00+00:00", "updated_at": "2026-05-27 04:40:53.392569+00:00", "lang": "en", "topics": ["artificial-intelligence", "ai-tools", "ai-agents", "large-language-models", "generative-ai"], "entities": ["Claude Code"], "alternates": {"html": "https://wpnews.pro/news/please-make-mistakes", "markdown": "https://wpnews.pro/news/please-make-mistakes.md", "text": "https://wpnews.pro/news/please-make-mistakes.txt", "jsonld": "https://wpnews.pro/news/please-make-mistakes.jsonld"}}