Introduce semantic parsing in Line Impact calculation
This is already done to some extent, but here are a few ways in which interpreting code semantically could improve the approximation of dev cognitive effort. This list showcases examples of when making a specific change to the code *requires* another follow-up change. Usually, the follow-up change is complementary, but does not act in any way to evolve the codebase (not more than the initial change did).
1. Adding another potential type to an object (should get all Line Impact) vs adding an "else" branch in the section of the code verifying that type
2. Acquiring a synchronization-type object vs releasing it
3. More generally, any resources that need symmetric operations, such as allocating memory in C
4. Extending the db schema of an object to house another column (vs adding that new property to trivial API/method calls on other layers of the app)
5. Creating a new type of Error object/event vs "catching" it in all invocations of the error-triggering code
Definitely some meaty content here, but it would be hard to formulate an actionable task from this. If you can find a more bite-sized way to allow customers to pinpoint semantics they wish to have ignored, I'd be happy to consider that.