Proposal: Add AI-era productivity metrics to complement traditional COCOMO estimates

[1chooo]

Background

scc currently provides useful traditional software metrics such as:

• Lines of code
• Code complexity
• Estimated cost to develop
• Estimated schedule effort
• Estimated people required

However, the traditional COCOMO-based estimates may become increasingly difficult to interpret in the age of AI-assisted software development.

For example, I recently generated the following statistics for a project:

───────────────────────────────────────────────────────────────────────────────
Language                 Files     Lines   Blanks  Comments     Code Complexity
───────────────────────────────────────────────────────────────────────────────
TypeScript                 358     39760     3777       992    34991       5480
Markdown                    67      7383     1872         0     5511          0
SQL                         31      2399      351       187     1861        163
JSON                         7      2333        0         0     2333          0
SVG                          6        32        0         0       32          0
YAML                         3        54        3         3       48          0
JavaScript                   2       110        5         6       99          0
CSS                          1       291        21         8      262          0
TOML                         1        61        10         7       44          0
───────────────────────────────────────────────────────────────────────────────
Total                      476     52423     6039      1203    45181       5643
───────────────────────────────────────────────────────────────────────────────
Estimated Cost to Develop (organic) $1,476,722
Estimated Schedule Effort (organic) 15.95 months
Estimated People Required (organic) 8.23
───────────────────────────────────────────────────────────────────────────────

However, this project was produced by one person in approximately one week with significant AI assistance.

This creates a large gap between:

Traditional estimate: 15.95 months and 8.23 people

and

Actual development: approximately 1 person-week.

The current output is still useful as a measure of the estimated effort to produce the code through traditional development, but it does not represent the actual development process or productivity of an AI-assisted developer.

Feature proposal

Would it make sense for scc to add optional AI-era metrics that complement the existing traditional metrics?

For example:

1. Human-equivalent development effort

Estimate the traditional development effort represented by the codebase, while clearly distinguishing it from the actual reported development time.

Traditional estimated effort: 15.95 months
Actual development time:     1 week
Productivity multiplier:     ~69x

The exact metric would obviously require user-provided data or integration with an external source.

2. Actual development time

Allow users to provide the actual time spent developing the project:

scc --development-time "7d"

Then scc could report:

Traditional estimated effort: 15.95 months
Actual development time:     7 days
Estimated acceleration:       69x

This would make the difference between traditional estimates and modern AI-assisted development measurable.

3. AI-assisted development ratio

If the user has data from an AI coding tool, editor, Git history, or another source, scc could optionally accept:

Human-written code:  12,000 lines
AI-generated code:   33,000 lines
AI-assisted ratio:   73%

Possible input sources could include:

• Git commit metadata
• AI coding tool statistics
• External JSON/CSV data
• Manually provided values

For example:

scc --ai-generated-lines 33000

or:

scc --ai-metrics metrics.json

4. AI-adjusted productivity metrics

A potential output could look something like:

───────────────────────────────────────────────────────────────────────────────
Traditional Development Estimate
───────────────────────────────────────────────────────────────────────────────
Estimated Cost to Develop (organic)   $1,476,722
Estimated Schedule Effort (organic)   15.95 months
Estimated People Required (organic)   8.23

───────────────────────────────────────────────────────────────────────────────
Actual Development
───────────────────────────────────────────────────────────────────────────────
Actual Development Time               7 days
Actual Contributors                   1
AI-Assisted Development               Yes
Estimated Productivity Multiplier     ~69x

Why I think this could be useful

The purpose would not necessarily be to replace COCOMO.

Traditional COCOMO estimates can still answer:

"How much effort might this codebase have required under traditional development assumptions?"

However, AI-assisted development introduces a different question:

"How much code can a developer or team actually produce using modern AI-assisted tools?"

These are different metrics and may both be useful.

For example, the following two statements can both be true:

• A codebase represents approximately 15.95 months of traditional development effort.
• One developer produced the code in approximately one week using AI-assisted development.

Currently, scc can show the first statement, but there is no way to express the second or compare the two.

Open question

Would the project be interested in supporting some form of AI-era productivity metrics?

I would be interested in helping design or implement this if there is agreement on the direction.

I also understand that measuring "AI productivity" is difficult because lines of code are not necessarily equivalent to quality, functionality, or value. Therefore, perhaps the most useful approach would be to provide these as optional, user-supplied metrics rather than trying to automatically determine whether code was generated by AI.

[boyter]

Man do I have some good news for you!

https://boyter.org/posts/sloc-cloc-code-locomo-llm-output-cost-model/

I am glad someone is starting to raise it and that I am slightly ahead for a change.

Would love you to have a look over that and if you build from source you have this metric in scc now. It was very much a first attempt at this sort of thing, and I am unaware of any metric out there to actually do this, hence my guess here, which worked well for the sample I tried.