What happens when you put Claude Code in front of a real team

A coding agent like Claude Code helps most where the intent is clear and the execution is boring, and least where someone still has to decide what to build. That is the whole short answer. The trouble is that most teams measure it by how much code came out, which is exactly the metric that turns it into a liability.

We wrote this after several months of daily work with an agent inside an existing development process, including the site you are reading now. It is built on Next.js with full Hebrew and English support including RTL, a Supabase-backed content layer and an admin panel. A large share of that work was done alongside an agent, and a real share of it was thrown away and rewritten by hand.

What genuinely gets shorter

The saving is not in writing the function. It is in everything around it: reading a thousand-line file nobody has touched in a year, finding the three places the same pattern repeats, adapting an existing test to a new case, translating a whole screen and confirming that no string stayed hard-coded.

• Survey work: finding where something is defined, where it is consumed, and what breaks if it changes.
• Repetitive work at scale: the same change across twenty files, where the pattern is fixed and only details vary.
• Mechanical conversions: types, migrations, fitting old code to a new interface.
• The first move in unfamiliar code — not to trust it, but to stop staring at an empty file.

In each of those the intent is known in advance and the work is volume. That is where the difference shows immediately, and it is also where the result is cheap to check: either the tests pass or they don't.

Where it breaks

An agent will happily write you code that works and creates a problem. It will add a component nearly identical to one that exists rather than extend it, because it does not know that pattern already lives under another name in another folder. It will route around a type error instead of fixing it, if you asked for it to pass rather than to be right. It will pull in a dependency to save twenty lines.

Every one of those is a mistake a human makes too. The difference is rate. A developer produces one duplication a day and feels the friction; an agent produces six an hour and feels nothing. Debt accumulated at that speed does not surface in one code review. It surfaces three weeks later, when somebody tries to change a single behaviour and finds it defined in four places.

What still needs a person

Three decisions do not transfer to an agent, not for lack of capability but for lack of accountability. What ships and what waits. What the experience is when something fails. And what the system promises the people using it — a promise somebody has to defend in front of a client.

In practice that makes product definition more important, not less. The cheaper execution gets, the more a bad definition costs: it becomes very easy to build the wrong thing quickly. We wrote about that separately in the idea to MVP cluster, because it is the same failure one stage earlier.

That figure comes from content rather than code, but it describes the same dynamic exactly: when production cost collapses, what separates good work from waste is not volume but the gate that decides what passes.

What a working process looks like

What worked for us is not an elaborate method. It is one fixed gate and two habits.

1. An automatic gate before every merge: build, type check, lint and unit tests. If the gate is red there is no discussion.
2. One task at a time, with a stated definition of done. A vague task returns vague code.
3. Review by a person who knows the system, looking at decisions rather than syntax. The review question is "why is this a new file", not "why is there a space here".
4. Rewriting by hand when the second attempt still isn't good. Three rounds of prompt correction cost more than ten minutes of writing it yourself.

The fourth is the hardest for teams to adopt, because it feels like the tool failing. It isn't. An agent pays off on average rather than in every case, and insisting on it in the cases where it doesn't is paid for in time.

If you are weighing this for a team, start with the boring work and the automatic gate rather than with the hardest feature. We also have a comparison of Claude Code and Cursor for anyone choosing between the two.