Show HN: How well do you use Claude Code?

A bunch of companies that I spoke to had their own claude & codex OTel dashboards that showed spend + seats per month.

However, none of the dashboards actually analyzed how the engineers worked with the tools and if there were any areas for improvement! That's why I created https://www.promptster.ai.

Managers get aggregate level view of code quality and how that ties with team workflows (nothing on a per-engineer level). While engineers get personalized coaching on how they can save tokens while keeping output high.

We also have a tool built for individuals to test their local claude code setups. It's open-source and completely local. You can check that out here: https://github.com/pa-arth/cc-audit.

Would love feedback on either and reach out if you're interested in purchasing the teams product!

Comments

johntashJul 25, 2026, 8:02 AM
> Managers get aggregate level view of code quality

What's the measure of code quality in this case?

PaarthmjJul 27, 2026, 12:28 AM
It's a combination of DORA metrics (software delivery) + maintainability score + complexity score.
tysilvaJul 25, 2026, 6:21 PM
It really does feel like leaders in large organizations are lost on the valuable metrics when it comes to code in general. The mantra seems to often be, make number go higher - regardless of if it's valuable data or not.
PaarthmjJul 27, 2026, 12:29 AM
Yeah, curating exactly what's important to see as a manager is a difficult part of this journey!
kandrosJul 25, 2026, 12:16 PM
If quality is the metric, nobody would use something like that, seems like a micromanagement tool
PaarthmjJul 27, 2026, 12:30 AM
well, it's not per-engineer. instead, the managers get team-wide metrics so the idea is that they know what the quality of their teams code is, and they can recommend trainings / meetings on how to improve on X part of their AI workflow.
larsienJul 25, 2026, 10:55 AM
Agree, it is the most important part
tdu01Jul 25, 2026, 12:11 PM
My team is hyper productive with Cursor, using different models for different tasks. My senior engineers approve PRs, but it's not humanly possible and is demoralising to review the amount and rate of code being churned. Sure there are a lot of automated tests. We struggle with a measure for code quality that scales. We mitigate by having small releases and running A/B instances but I still lose sleep over pace vs quality.
PaarthmjJul 27, 2026, 12:31 AM
Pace vs quality is going to be the debate for the next couple years!
vivzkestrelJul 25, 2026, 3:25 AM
- Am I the only guy in all of HN that doesnt use codex, doesnt use claude code, doesnt write code with agents?
none2585Jul 25, 2026, 5:20 AM
All of HN? Surely not.

I do think, however, that holding out on it is a losing proposition. It's a very useful productivity tool if you know how to use it and those who don't will be left behind.

gonzalohmJul 25, 2026, 11:52 AM
What do you mean by left behind? This is a tool akin to using and idle. I don't think anyone is going to be left behind for not using it. Writing code has never been the bottleneck anyway.

A lot of people brag about how much more code they write using an LLM, but I can't see how that's a good thing. The bottleneck is understanding the requirements and writing the minimum amount of code to meet them

PaarthmjJul 27, 2026, 12:25 AM
yes, I agree with what the others have said that amount of code written is not a metric for "engineering skill." However, I do think that once the requirements have been scoped properly, there's no reason for a human to be involved in that stage.

The spec-development & testing phases before and after implementation can and should have human involvement, not the implementation. With that being said, there's so many places for this SDLC to be optimized / made more productive with agents that I think everyone should be using them. How well you use them, now that's another story... (check out the above^^)!

none2585Jul 25, 2026, 2:53 PM
I agree code produced is a poor measure. And I agree that some of the bigger pieces of coding were everything you mention, coding still did take _some_ amount of time.

Usually in a day I have one agent going on whatever my large, main task is, generally feature work of some sort. Previously this is what most of my sprints would have been filled with.

But now, while that's going I have one or two others simultaneously working on crashes (I do mobile), other bugs, a small refactor, or maybe a small enhancement.

And finally I usually have another where I'm querying analytics or working on higher level questions to try and help guide what we should do next, either from a product or technical perspective.

A single one of these are all sped up by using LLMs but to be able to do several in parallel makes me much more effective than I was before. This is why I believe that those who don't use these tools properly will be left behind.

kandrosJul 25, 2026, 12:13 PM
Feedback loop alone to validate hypothesis, even if you throw away all the code and decide to write by hand is a terrific value proposition.

I believe it’s only possible to truly appreciate that after doing it for a while with trial and error, without external opinions

boveykingJul 25, 2026, 4:13 AM
Yes. Look, how quickly I can click yes, Because I am a "Yes Oriented Programmer" after using Cluade code.

But honestly, it is extremely rare thing not using codex, or cluade code or any other agent.

vivzkestrelJul 25, 2026, 5:06 AM
i do use an LLM every now and then to write a function or two but i have stayed away from doing entire projects on full automation
boveykingJul 25, 2026, 5:24 AM
Yes. That is what I usually do. Like old days' unit test. Write a couple of units and test. I never do plan first then let llm automatically code the entire project.
PaarthmjJul 27, 2026, 12:26 AM
are unit tests even still useful?
sphJul 25, 2026, 5:06 PM
You are not.
gap_fanaticJul 24, 2026, 11:01 PM
Does this work with codex too?
PaarthmjJul 24, 2026, 11:05 PM
the teams product does, working on support for the cc-audit product!
WheelMuMuJul 26, 2026, 7:48 AM
[flagged]