At the cybersecurity SaaS company where I work, the whole tech team, 10 to 20 people, builds software with the same Claude Code flow. I designed it and I maintain it.
Since then, our delivery pace has changed a lot. Not everything is solved: misunderstandings remain, review is becoming a bottleneck, and usage limits run out quickly. And engineering expertise stays involved at every step, because the code the agent writes is still ours.
Why one shared setup instead of everyone’s own agent
At first, the use of AI varied a lot from one person to another. People did not have the same level with agentic development, or the same experience with Claude Code.
I was already using Claude Code with a harness built for my own work. Our engineering leadership pushed me to rework it and roll it out to the team. The shared setup that came out of it is less than a year old.
Choosing Claude Code starts with a personal preference, and I own it (Anthropic’s transparency in how it communicates, its ethics and the quality of its models). In my view, Anthropic has often led the way on standards that others then adopted, such as MCP or the skills format. Its tools are built for serious, professional use, and Claude Code’s sharing mechanisms lent themselves well to a team setup. Competing solutions exist and are also very capable. My preference still goes to Anthropic.
The goal was to make the shift together. The flow had to speed up our development substantially, whether shipping features, running migrations, doing maintenance or fixing vulnerabilities. It also had to give everyone the same tools. It would not be right for a few people to ship very fast while leaving their colleagues behind.
The setup is strongly recommended, not mandatory. People who want to go further can improve it or use it differently, and trying other approaches is still worthwhile as long as it does not disrupt the team’s flow.
What the setup contains and how it reaches everyone
The setup lives in two places. A Claude Code plugin, distributed through a marketplace, bundles the shared skills. Rules and settings live in the repositories, next to the code they apply to.
A plugin is the unit Claude Code installs and loads as one piece: skills, subagents, hooks, MCP servers. A marketplace is a catalog, a repository that lists plugins and can stay private (plugins documentation). For a team, a change to the flow simply becomes a new plugin version that everyone gets from the marketplace.
The shared skills cover development, review and debugging, among others. Depending on the situation, the developer calls them or the flow does.
MCP servers connect the agent to the team’s tools. Some are existing servers for off-the-shelf tools, others were written in-house. This is how the agent fetches the PRD (the product requirements document) and the information it needs, where that information is written. The debugging flow, for example, relies on an internal MCP server built by our DevOps team, which fetches the logs from the SaaS environment where the bug occurs.
The setup is shared, but the experience stays personal. Claude Code’s memory belongs to each person and keeps their preferences and corrections. Even going through the same flow, everyone gets a more personal experience.
I designed this setup on my own and I do most of the maintenance, based on feedback from my colleagues, new features in the tool and my own practice.
For a given piece of work, the path looks like this:
- A developer starts the agent on a PRD written by product.
- The agent fetches the PRD and the relevant context through MCP, then proposes a plan.
- The developer decides whether the plan is ready to be presented.
- Product, QA and engineering approve the plan together, and the plan is attached to the PRD.
- The agent implements and verifies its work end to end, supervised by the developer.
- The developer tests the result, then asks for a human review of the pull request.
The plan, the last human approval before autonomy
The plan is the last point where a human signs off before Claude works more autonomously. It goes through two filters.
The first is technical. The developer who started the agent reads the plan and decides whether it is solid enough to show to product and QA. The second is collective: product, QA and engineering approve it together. The plan stays in the agent’s session and is also attached to the PRD, in the tool where the PRD lives. The goal is to clear up unknowns and misunderstandings before implementation.
When a PRD involves an architecture change or infrastructure questions, it can be put on hold. An ADR comes first, also run as an agentic flow, to discuss and work through that topic upfront.
The practice Anthropic describes in its development lifecycle course is lighter. The engineer approves their own plan, and only changes considered higher risk go to a tech lead or an architect (Claude Academy). The difference comes from how we are organized: product is very present and plays an important role. With AI, the line between product and development is more porous than it used to be, but responsibilities remain.
This approval does not remove misunderstandings. Some remain, and that is the real difficulty. The problem is not specific to AI: companies have been dealing with it for decades.
Letting the agent work alone without letting it do everything
Once the plan is approved, the agent implements and verifies its own work locally. It runs the automated tests, starts the application to check its behaviour in a browser, and a subagent reviews what was produced.
The agent comes back to a human in four cases:
- When the implementation requires leaving the approved plan
- When verification fails several times in a row
- When a decision falls outside its scope, whether it concerns product, architecture or security
- When an action it needs is blocked
Autonomous does not mean unsupervised. The developer follows what the agent does, checks in on it from time to time, and personally tests the feature and how it renders before asking for any review.
That leaves the question of limits. In our flow, the agent is guided by instructions: the rules in the repositories and the instructions in the skills. Claude Code’s documentation is clear about what these are. They are loaded as context, not as enforced configuration (memory documentation). An instruction steers the agent, it does not prevent anything.
The actual limits are set in the tools. The accounts used through MCP servers only have restricted permissions, and only some MCP actions are allowed. What must stay out of the agent’s reach is blocked by the tool itself, not by its instructions.
What the flow changed, and where it still struggles
Speed changed completely. By my estimate, one person now ships on their own, in a few days, a feature that used to take a team several weeks. This is a trend I observe, not a measurement.
Practices have become consistent enough that I do not see gaps in flow or people falling behind. Skills have grown across the team overall, even if everyone keeps their own interests and their own way of approaching AI.
The first hard point is review. The agent produces faster than the team can review, and review is becoming a bottleneck. It is partly addressed, not fully. We are looking at options such as an external review tool like CodeRabbit, or using the Claude API. With better models and continuous improvements to the flow, I see fewer and fewer errors, which limits the risk of a lighter human review. Anthropic reports the same about its own Claude Code team: once writing code got faster, verification, review and security became the new bottlenecks (Running an AI-native engineering org).
The second hard point is consumption. In my view, a professional seat pays for itself immediately for the company. But each seat’s usage is limited over a rolling five-hour window and a weekly window, and depending on the models and the time, those limits run out quickly. The work then is to tune the flow so each task gets the right model and effort level, which better models make more and more possible.
Keeping the flow in step with the tool
Claude Code moves very fast, and a team setup has to keep up without breaking anyone’s work. I use the tool all the time, at work and on personal projects, and I follow its evolution closely. Besides the official documentation, I follow Boris Cherny, Thariq Shihipar and Lydia Hallie from the Claude Code team, Alex Albert at Anthropic, and the ClaudeDevs account.
Following announcements is easy. Spotting the ones that add nothing is harder: a lot of content presents a flow as a discovery when it is not one, or makes noise about a non-issue. Before something new goes into the flow, I ask myself four questions:
- Have I tried it on a real case, rather than trusting what people say about it?
- What do the official documentation or changelog say it actually does?
- Who is talking about it: someone showing real use, or someone selling a miracle flow?
- What real problem does it solve for the team?
Anything that passes these questions gets tested on my side first. Feedback from my colleagues also triggers adjustments. When a change is ready, it ships as a new plugin version that the team receives through the marketplace.
Staying responsible for the code the agent writes
This flow is designed for my company. It could look very different somewhere else, and that would not be a problem. Working with an agent is a constant balancing act, and the balance is not the same from one company to another.
Parallel work is a good example. An agent lets you run several tasks at once. But the more you parallelize, the stronger the organization and the higher its maturity need to be before you can let go of what is being produced. Every company, with its own way of working, has to find the best way for it to work with an agent.
One thing does not depend on the organization, though. Our job is changing, and an agent gives us a more macro view of what we build. That is where the shift to an agentic flow becomes critical: this wider view must not lower our attention.
Engineering expertise has to stay involved at every step, to judge the plan, follow the implementation, test what was built and review it. If we stop using it, we lose our grip on what we produce. We no longer add value, and we end up out of our depth with what is being produced.
Even when Claude, or another AI, writes the code, it is still our code, and we are still responsible for it.