7 ms·

> It's definitely possible for AI to do a large fraction of your coding, and for it to contribute significantly to "improving itself". As an example, aider curr

> It's definitely possible for AI to do a large fraction of your coding, and for it to contribute significantly to "improving itself". As an example, aider currently writes about 70% of the new code in each of its releases. That number itself is not saying much. Let's say I have an academic article written in Word (yeah, I hear some fields do it like that). I get feedback, change 5 sentences, save the file. Then 20k of the new file differ from the old file. But the change I did was only 30 words, so maybe 200 bytes. Does that mean that Word wrote 99% of that update? Hardly. Or in C: I write a few functions in which my old-school IDE did the indentation and automatic insertion of closing curly braces. Would I say that the IDE wrote part of the code? Of course the AI supplied code is more than my two examples, but claiming that some tool wrote 70% "of the code" suggests a linear utility of the code which is just not representing reality very well.

stavros 2y ago
That's pretty reaching though if you're comparing an AI to a formatter. Presumably 70% of a new Aider release isn't formatting.
simonw 2y ago
"The stats are computed by doing something like git blame on the repo, and counting up who wrote all the new lines of code in each release. Only lines in source code files are counted, not documentation or prompt files."
anotherpaulg 2y ago
Every metric has limitations, but git blame line counts seem pretty uncontroversial. Typical aider changes are not like autocompleting braces or reformatting code. You tell aider what to do in natural language, like a pair programmer. It then modifies one or more files to accomplish that task. Here's a recent small aider commit, for flavor. -# load these from aider/resources/model-settings.yml -# use the proper packaging way to locate that file -# ai! +import importlib.resources + +# Load model settings from package resource MODEL_SETTINGS = [] +with importlib.resources.open_text("aider.resources", "model-settings.yml") as f: + model_settings_list = yaml.safe_load(f) + for model_settings_dict in model_settings_list: + MODEL_SETTINGS.append(ModelSettings(**model_settings_dict)) https://github.com/Aider-AI/aider/commit/5095a9e1c3f82303f0b7e3349d56300910b41db4 https://github.com/Aider-AI/aider/commit/5095a9e1c3f82303f0b...
- brianstrimp 2y ago
  Point is that not all lines are equal. The 30% that the tool didn't make are the hard stuff. Not just in line count. Once an approach or an architecture or a design are clear then implementing is merely manual labor. Progress is not linear. You shouldn't judge your sw eng employees by lines of code either. Those that think the hard stuff often don't have that many lines of code checked in. But it's those people that are the key to your success.
  - ban-evader 2y ago
    And you think this is news to any of us?
  - momo_O 2y ago
    I don't think any reasonable person is using "lines of code" as a hard metric for anything -- as you've noted, the quality and impact of code isn't proportional to its length. Lines of code serves as a directional heuristic at best, but that's ok.

stavros 2y ago

That's pretty reaching though if you're comparing an AI to a formatter. Presumably 70% of a new Aider release isn't formatting.

simonw 2y ago

"The stats are computed by doing something like git blame on the repo, and counting up who wrote all the new lines of code in each release. Only lines in source code files are counted, not documentation or prompt files."

anotherpaulg 2y ago

Every metric has limitations, but git blame line counts seem pretty uncontroversial. Typical aider changes are not like autocompleting braces or reformatting code. You tell aider what to do in natural language, like a pair programmer. It then modifies one or more files to accomplish that task. Here's a recent small aider commit, for flavor. -# load these from aider/resources/model-settings.yml -# use the proper packaging way to locate that file -# ai! +import importlib.resources + +# Load model settings from package resource MODEL_SETTINGS = [] +with importlib.resources.open_text("aider.resources", "model-settings.yml") as f: + model_settings_list = yaml.safe_load(f) + for model_settings_dict in model_settings_list: + MODEL_SETTINGS.append(ModelSettings(**model_settings_dict)) https://github.com/Aider-AI/aider/commit/5095a9e1c3f82303f0b7e3349d56300910b41db4 https://github.com/Aider-AI/aider/commit/5095a9e1c3f82303f0b...

brianstrimp 2y ago
Point is that not all lines are equal. The 30% that the tool didn't make are the hard stuff. Not just in line count. Once an approach or an architecture or a design are clear then implementing is merely manual labor. Progress is not linear. You shouldn't judge your sw eng employees by lines of code either. Those that think the hard stuff often don't have that many lines of code checked in. But it's those people that are the key to your success.
- ban-evader 2y ago
  And you think this is news to any of us?
- momo_O 2y ago
  I don't think any reasonable person is using "lines of code" as a hard metric for anything -- as you've noted, the quality and impact of code isn't proportional to its length. Lines of code serves as a directional heuristic at best, but that's ok.