[oooyay]

> We hope it leads dev teams, and AI Assistant builders, to adopt measurement & incentives that promote reused code over newly added code.

imo, this is just replacing one silly measure with another. Code reuse can be powerful within a code base but I've witnessed it cause chaos when it spans code bases. That's to say, it can be both useful and inappropriate/chaotic and the result largely depends on judgement.

I'd rather us start grading developers based on the outcomes of software. For instance, their organizational impact compared to their resource footprint or errors generated by a service that are not derivative of a dependent service/infra. A programmer is responsible for much more than just they code they right; the modern programmer is a purposefully bastardized amalgamation of:

- Quality Engineer / Tester

- Technical Product Manager

- Project Manager

- Programmer

- Performance Engineer

- Infrastructure Engineer

Edit: Not to say anything of your research; I'm glad there are people who care so deeply about code quality. I just think we should be thinking about how to grade a bit differently.

[zemo]

> this is just replacing one silly measure with another

> Not to say anything of your research

The second statement isn't true just because you want it to be true. The first statement renders it untrue.

> I'd rather us start grading developers based on the outcomes of software. For instance, ... errors generated by a service

yeah you should click through and read the whitepaper and not just the summary. The authors talk about similar ideas. For example, from the paper:

> The more Churn becomes commonplace, the greater the risk of mistakes being deployed to production. If the current pattern continues into 2024, more than 7% of all code changes will be reverted within two weeks, double the rate of 2021. Based on this data, we expect to see an increase in Google DORA's "Change Failure Rate" when the “2024 State of Devops” report is released later in the year, contingent on that research using data from AI-assisted developers in 2023.

The authors are describing one measurable signal while openly expressing interest in the topics you're mentioning. The thing is: what's in this paper is a leading indicator, while what you're talking about is a lagging indicator. There's not really a clear hypothesis as to why, for example, increased code churn would reduce the number of production incidents, the mean time to resolution of dealing with incidents, etc.

[oooyay]

Thankfully in life no third person gets to dictate what I mean by my own words. There's plenty of good research that comes from studying the silly things, science is filled with things that even an average person would say "duh" or "don't do that". That doesn't make them meaningless. If you disagree that's cool, but I still mean what I said exactly how I said it.

> yeah you should click through and read the whitepaper and not just the summary. The authors talk about similar ideas

Ah, this whitepaper that's gated behind supplying my business email address?: https://www.gitclear.com/coding_on_copilot_data_shows_ais_do...

I read the article that was linked, which is generally what's expected of me on HN.

> The authors are describing one measurable signal...

I'm aware of the research around this topic, it's something I like reading about and I've read a lot of takes both academic and colloquial. That may be why I put that idea into words.

Maybe, just maybe, in our future interactions you can avoid being so unnecessarily hostile?