Rather than an integer number of lines of code, how about using a boolean : "it works" or "it does not work"? or "Does it meet the spec" or "it does not meet the spec"? Even a mediocre manager should able to test that one out.
Task completion should be the metric, not line counts, otherwise the incentive is creating the most bloated piece of software and the most comprehensive unit-test possible. Any system is going to be (ab)used by the employee to their benefit.
Task completion would also be abused, because it's too vague. It simply shifts the burden to the one formulating the task (e.g. preventing holes in the specification like missing performance or hardware requirements).
Exaggerated example: if the "task" is to automatically deliver a report containing certain data and formatted in a specified way, the easy way might be an implementation that stalls the DB server for hours with deeply nested FULL OUTER JOINs on non-index fields.
The task would be completed quickly and arguably correctly, since neither runtime nor memory requirements were explicitly specified...
But you said it yourself, any system is going to be abused...
Task completion as a metric incentivizes hacky approaches that cause issues down the line. You can counteract some with strict code review standards, but a bad job requires a longer review, and then the reviewers start falling behind in their task completion metric.
Organizations are always imperfect, which is why I strongly recommend taking the lead and being pro-active in keeping management informed of what you're accomplishing.
Out of sight, out of mine <== don't let that happen to you
I don't believe it is any coincidence that the highest compensated engineers I know also are highly visible through their own efforts.
That'll be exploited as well. The number of pointless UI and feature changes would skyrocket without the app actually getting better or gaining meaningful functionality.
Meta-metrics might be much more helpful, though harder to come up with, quantify and monitor. Things like defect rates, user reported incidents, user satisfaction, stuff like that.
Things that cannot easily be gamed from within the development process and that are still directly linked to the success and economic viability of the product and its development methodology (though on a higher level).
The smart thing to do is to regularly keep your manager updated on what you're doing, especially if they don't come by regularly and ask you.
Especially if you are WFH.