DEV Community

Cover image for Claude Code doesn't make your product better. It makes it bigger.
Aditya Agarwal
Aditya Agarwal

Posted on

Claude Code doesn't make your product better. It makes it bigger.

Shipping faster has never been easier. Shipping better has never been harder.

Claude Code is the most impressive code-generation tool I've ever used. It's also the fastest way to turn a clean codebase into an unmaintainable mess if nobody's paying attention.

And right now, not enough people are paying attention.

The output is not the outcome

Ethan Ding recently published a piece arguing that Claude Code isn't actually making products better. It's making them bigger. More files, more abstractions, more surface area — but not more value for users.

This tracks with what I've seen. The tool is astonishingly good at producing code. It's terrible at knowing when code shouldn't exist.

According to Sentry's David Cramer, AI-generated output is "increasingly complex and hard-to-maintain code" that's a drag on long-term development. Not some rando blog. The co-founder of one of the most widely-used developer tools on the planet. šŸ”„

The k-shaped curve is real

The controversial theory emerging is that AI coding tools create a k-shaped curve. Senior engineers get orders of magnitude more productive. Everyone else gets orders of magnitude more prolific — which is a very different thing.

If you have the taste to reject bad suggestions, Claude Code is a superpower. You know which abstractions are unnecessary. You know when a 200-line file should stay a 200-line file.

If you don't have that taste yet, you accept everything. The codebase bloats. The PR looks impressive. The product doesn't actually improve.

→ Senior engineers use Claude Code to skip boilerplate they already understand.
→ Junior engineers use it to generate boilerplate they've never questioned.
→ Same tool, opposite outcomes.

Faster is not the metric

Here's what I find concerning. The discussion about AI coding tools revolves solely around one aspect: speed. "Deliver 10 times faster." "Prototype within a weekend what previously required a month."

No one stops to ask: is this feature necessary? No one stops to question: is this abstraction worth it?

Claude Code is more than happy to generate a whole module for you that you'll never use. It'll incorporate a service layer, a repository pattern, and three helper files for no reason other than those ten lines could be in a handler. And, it'll do it quickly.

Speed without filter is just chaos with a keyboard. That's not an improvement in efficiency. That's technical debt in the making.

The pricing tells you something too

The $20 Claude Pro plan is exhausted, and you are back to standard usage, almost immediately. It's essentially a trial tier for code generation. You're going to need the Max plan to utilize Claude Code on a daily basis.

This basically means that the developers who benefit most from this tool are the ones whose employers finance it. Hence, the k-shaped curve strikes again.

The junior developer working on a side project isn't in the same situation. This person is being rate-limited while programming a feature and is then provided with half-written code that they cannot fully comprehend. 😬

So what do we actually do?

I don't mean that you shouldn't use Claude Code. I use it too. It works wonderfully for certain things, such as tests, migrations, or repetitive refactoring.

However, I've started to approach the tool in the same way I would deal with a first draft when onboarding a new employee. I read through every line, delete a lot, and ask more often "do we really need this?" rather than "does this function?"

→ The best code review skill in 2025 is knowing what to delete from AI output.
→ The most valuable engineer isn't the one who ships the most code. It's the one who ships the least code that solves the problem.

The tool itself is not the issue. It's the uncritical use of it that's problematic.

What's your experience been — has Claude Code actually made your product better, or just your codebase bigger?

Top comments (3)

Collapse
 
kkierii profile image
Kerry Kier

This is why companies right comapnies that are usign token burn as a metric of productivity is bad. There are several ways to game this and some devs arejust telling claude and others to generate as much code and responses as possible to get more tokens. I have even seen some devs that use cusotom chat systems (openweb ui) and increase the reply response to be extremely large rather than more concise.

The only thing that is benefiting from basing metrics on tokens are inference providers and LLM Providers.

Collapse
 
a3e_ecosystem profile image
A3E Ecosystem

Direction matches what we see in our pipeline. The bigger trap underneath is that more reads as progress in the dashboard. We started gating commit volume against a quality signal (test coverage delta plus cyclomatic complexity delta) so a 600-line PR that drops both is held until trimmed. Without that gate, Claude optimizes for output and you optimize for momentum theater.

Some comments may only be visible to logged-in visitors. Sign in to view all comments.