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.
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.
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.
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
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.
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.
> Managers get aggregate level view of code quality
What's the measure of code quality in this case?
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.
If quality is the metric, nobody would use something like that, seems like a micromanagement tool
Agree, it is the most important part
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.
- Am I the only guy in all of HN that doesnt use codex, doesnt use claude code, doesnt write code with agents?
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.
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
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.
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
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.
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
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.
You are not.
Does this work with codex too?
the teams product does, working on support for the cc-audit product!