- AI Fire
- Posts
- 🤖 Claude Code’s Creator Reveals A Coding Agent Skill That's More Valuable Than Ever
🤖 Claude Code’s Creator Reveals A Coding Agent Skill That's More Valuable Than Ever
AI coding agents are changing how software gets built, but the biggest advantage actually comes from engineers who know how to guide them. Full guide inside for you.

TL;DR
Coding Agents work better when the codebase gives them clear rules, reliable checks, and useful context. Tests, lint rules, CI workflows, documentation, and Skills reduce repeated mistakes.
I’ll show you how old engineering practices can guide many Coding Agents at once. You’ll learn how to turn recurring problems into automation and organize team knowledge for Claude Code.
You’ll also see why senior engineers create more value by building systems for people and agents. These systems make correct decisions easier across the whole team.
Key points
Coinbase cut the time from idea to first pull request from 8 days to under 30 minutes.
A common mistake is keeping important rules only in prompts or team conversations.
Turn repeated fixes into tests, lint rules, CI checks, or reusable Skills.
Table of Contents
Introduction
The way we write code is changing fast. Claude Code, Codex, Cursor, and other Coding Agents can now build features, test changes, and work across a full codebase with less manual work.
It may seem like old engineering skills are becoming less useful, but the opposite is happening.
Boris Cherny, one of the creators of Claude Code, says the automation skills engineers built in the past are becoming more valuable in the Coding Agent era.
This guide will show you exactly why that mindset matters now, and how to put it into practice.
🤖 What slows your Coding Agent most? |
I. From One Developer to Many Agents
Before coding agents appeared, most of your engineering infrastructure, like tests, lint rules, CI checks, supported just one developer or one team at a time.
Now, that same setup can guide many coding agents working across your codebase simultaneously. Every rule you encode becomes a guardrail for every agent session. So:
Lint rules catch repeated code problems before they spread across every agent and every commit
Automated tests check whether a change works as expected without you reviewing each one manually
CI workflows catch issues before new code is merged automatically, every time
Preview environments let Coding Agents test changes on a real version of the product
Example: OpenAI's "Harness Engineering" Experiment
One of the clearest examples of this we can show you comes from OpenAI's own team. In a blog post published titled "Harness Engineering," OpenAI described how they built an internal product containing roughly one million lines of code. Every line was generated by Codex, guided by a carefully designed system around it.
The team also created a fixed architecture where code could only depend on approved layers (Types → Config → Repo → Service → Runtime → UI). Custom linters and structural tests checked these dependency rules automatically on every commit.
The clever part, I think, is when Codex broke a rule, the lint error message explained the problem clearly, and that message fed directly back into the agent's context as it tried to fix the issue.
Once those rules were baked into the codebase, they guided every change Codex made, with no engineer repeating the same instructions in each prompt.
That's the multiplier effect in action.
II. Turn Repeated Coding Agent Problems Into Automation
If a coding agent makes the same mistake twice, that's not a prompt problem anymore, it's an automation gap.
A Coding Agent can fix the same issue every time it appears. But that still burns tokens, and it might miss the problem in some cases. When you see a pattern repeating, you should turn the fix into a permanent part of your codebase.
Boris Cherny (Head of Claude Code at Anthropic) described this quite directly: once you write a lint rule, CI step, or routine for a recurring issue, that whole class of problem is handled automatically forever. That's a fundamentally different outcome than prompting your way through it each time.
Depending on what's breaking, you can turn the solution into:
Problem type | Solution |
|---|---|
Wrong import patterns, bad naming, anti-patterns | Lint rule that blocks the pattern automatically |
Broken behavior or regressions | Automated test that protects the expected behavior |
PRs that don't meet your standards | CI check that blocks the merge |
Tasks Claude runs the same way every time | Reusable script or service |
Don't jump straight to building the fix. First, confirm the pattern is real and understand the root cause:
Review the codebase, recent commit history, tests, lint output, and CI configuration to find one issue that has appeared more than once.
Don’t fix it immediately. First:
- Show evidence that the issue is repeating.
- Explain the root cause.
- Choose the best long-term solution from a lint rule, automated test, CI check, or reusable script.
Then, build the solution, run the related checks, and confirm that the new automation can detect the problem.
Finally, summarize the issue, list the files you changed, and explain how this automation will stop Coding Agents from making the same mistake in future sessions.After you run this, Claude Code will look for proof that the same problem has happened more than once. It will also test whether the current checks can detect the issue before building a better automation.


III. Encode Team Knowledge for ALL Coding Agent
I’ve always said this, a coding agent can’t automatically know your team’s conventions, architecture decisions, or codebase standards. When this knowledge only lives in your heads or your old chats, Claude Code has to guess during each new task.
Key points
Team knowledge should be stored in the right place, including
CLAUDE.md, documentation, Skills, comments, tests, and guardrails.CLAUDE.mdshould stay short and guide Claude Code toward deeper project documentation.Claude Code should create a draft knowledge map first, while the team reviews and confirms any unclear rules before files are updated.
1. First, Where to Put What?
First, you need to store your team knowledge in several places like this:
Type of knowledge | Where it lives |
|---|---|
Rules that apply to most tasks | CLAUDE.md or AGENTS.md file |
Repeatable workflows (testing, review, deployment) | Skills |
Architecture, product logic, important decisions | Documentation files |
Design choices that aren't obvious from the code | Code comments |
Standards that can be checked automatically | Tests and guardrails |
Each type of information should live in the right place. Short rules can stay in CLAUDE.md, while longer explanations should move into separate documentation.
2. Real-World Example: How Stripe Did It
When Stripe rolled out Cursor to more than 3,000 engineers, the company used Cursor Rules to provide codebase context and coding standards.
Each team could also add rules for the code it managed. This gave Cursor the right context from the beginning, so developers didn't have to explain the same conventions in every prompt.
→ You can absolutely do the same thing with Claude Code using CLAUDE.md. The principle is identical: encode what the agent needs to know upfront, at the project level, so no individual session starts from scratch.
3. How to Structure CLAUDE.md Properly
CLAUDE.md should be a short starting point that explains how Claude Code should work and where it should look for more context.
The file can include:
How to run and test the project.
Important architecture boundaries.
Documentation to read for different tasks.
Actions that require your approval.
Skills to use for specific workflows.
What not to include: everything. It’s super hard for any of us to handle CLAUDE.md that tries to capture all project knowledge. Btw, it makes it hard for Claude to understand which rules matter most. If a section is more than a few lines, it probably belongs in a separate document or Skill that CLAUDE.md links to.
How useful was this AI tool article for you? 💻Let us know how this article on AI tools helped with your work or learning. Your feedback helps us improve! |
4. Prompt to Build Your Team Knowledge Map
You don't need to prepare separate files in advance, if Claude Code is already open in your project, just run this:
Study this codebase and create a team knowledge map for a new Coding Agent.
Read the project structure, main modules, configuration files, existing documentation, package scripts, code comments, and any current CLAUDE.md or AGENTS.md files.
Identify:
- The main architecture and how data moves through the project.
- Coding conventions that appear consistently in the existing code.
- Important commands for setup, development, testing, and deployment.
- Architecture decisions that a new Coding Agent could misunderstand.
- Repeatable workflows that could become Claude Code Skills.
For each point, show the files or code patterns that support it. Don’t create rules that aren’t supported by the current project.
Then organize the knowledge into:
- Short instructions for CLAUDE.md.
- Detailed explanations for separate documentation files.
- Repeatable workflows that could become Skills.
- Questions that still need confirmation from the team.
Draft the proposed knowledge structure and sample content, but don’t change any files yet.
Keep CLAUDE.md short and use it as a map to deeper documentation. End with the decisions I need to review before you update the project.
Use the first result as a draft, then review the architecture, conventions, commands, risks, and proposed Skills to make sure they reflect how your team actually works.
Once you’ve confirmed the open questions, you can let Claude Code update CLAUDE.md, the supporting documentation, and any Skills.

IV. Do Coding Agent Systems Matter for You?
As coding agents handle more implementation work, you (if you’re a senior engineer) need to focus on building an environment that helps agents make the right decisions.
This is not about managing agents the way you'd manage tasks. It's about building systems, the kind that make correct decisions easier for everyone, humans and agents alike.
1. Learn What Coinbase Actually Did
Coinbase's Chintan Turakhia, Senior Director of Engineering, believed that Coinbase would not see the full impact of coding agents by retrofitting AI into existing systems.
So instead of bolting agents onto the old workflow, they redesigned the entire process around them.
Teams wrote product and technical requirements that agents could read directly, then used Plan Mode to map out execution before generating any code.
The results:
Metric | Before | After |
|---|---|---|
Idea to first PR | 8 days | Under 30 minutes |
Idea to production | 20 days | 1.8 days |
PRs created by agents | — | 75% of all PRs |
Manual coding saved per developer/week | — | 7 hours |
Turakhia's long-term target is 4 hours from idea to production.
Cursor helped with the implementation. But the bigger improvement came from senior engineers creating clearer inputs, limits, and review steps.
2. Real Skill That Scales
A normal senior engineer can fix one architecture mistake. But a senior engineer who turns that mistake into a lint rule or CI check stops every Coding Agent from making the same mistake again permanently.
That's what scales. Not fixing things one by one, but building the system that makes the wrong thing harder to do than the right thing.
This is exactly the skill that grows in value at senior, staff, and principal engineering levels. Your experience doesn't just help your own work anymore, it becomes part of the infrastructure that the whole team, and every agent, operates inside.
Conclusion
Coding Agents work best when your codebase gives them clear rules, useful context, and fast feedback. Tests, lint rules, CI checks, documentation, and Skills turn your engineering knowledge into a system the whole team can use.
I believe this is where senior engineers create the most value. You solve repeated problems once, then build guardrails that help developers and Coding Agents avoid them in future work.
If you are interested in other topics and how AI is transforming different aspects of our lives or even in making money using AI with more detailed, step-by-step guidance, you can find our other articles here:
Opus 5 Honest Review: Near-Fable 5 Intelligence at Half the Price (July 2026)
How to Use Gemini + NotebookLM to Keep Your AI Accurate Every Time (For Free)
How I’d Make Money with Claude Before Everyone Starts Copying the Same Ideas*
Never Hit a Claude Limit Again with These Methods: From Basics to Advanced Ways*
This #1 Trending Skill Completely Gives Claude a Research Superpower (55K-Star Now)*
*indicates a premium content, if any



Reply