Effort, the illusion of value

In 1982, Bill Atkinson handed in a management form tracking the number of lines of code written that week. Atkinson wrote -2000.

Producing code is not the same thing as producing value.

Old lesson - new hype

This fact has nothing to do with AI. It was common knowledge. The agentic coding hype has however made this easy to forget.

I spend too much time lurking at Hacker News, Lobsters and in various sub-reddits. Everywhere I look I see people bragging on how many lines they shipped today. Either by vibe-coding something from scratch, or porting something from one language to the next2.

Someone on the Internet put it quite well saying something along the lines of:

Aha, LOC was only a bad measurement when it was you being measured!

During my twenty-five years in the field, I have never met an engineer who believed that line-of-code-per-day was a good measure of progress. Most tend to think the opposite, that less code for the same result is better (obviously while readable and maintainable). Still, at the moment an agent is producing the code instead of the person, the very same engineer will proudly post their produced lines of code.

The measurement stick did not get better. It just stopped being personal.

Effort is easy to measure

What numbers does the business care about? Numbers that assist in making the right things? These are often monetary numbers or close to, such as revenue, cost, retention, acquisition, etc.

Lines of code tell you nothing. It is easy to measure though, that is why it is used.

Imagine three features of roughly the same code size:

• Improved checkout flow. A change that significantly lowers the threshold for purchase on a web shop. High positive value on sales.
• Mandatory login during checkout. A change that adds friction to the checkout and raises the threshold for purchase. Most likely a negative value, even though it shipped.
• The feature nobody asked for. A lot of changes, ships on time. Zero value, only cost.

If you are measuring the code size, all these are identical. Yet they have very different effects. This is a problem.

Measuring the effort is not useless though, but it needs to be balanced with the value (effect) they bring. Effort with no value is just cost in disguise.

In the reasoning I hear today, almost nobody talks about value, everyone is talking about producing code.

Code is now cheap(er)

Using AI, the cost of producing source code has dramatically dropped. This is overall a good thing. That means that an organisation can accomplish something with less effort than only using humans to produce the same source code.

However, this does not mean that all ideas and features should be produced.

If what you produce cannot be converted into a value stream it is only a cost. Regardless of humans or agents, every line of code is both an asset and a liability (I am thinking that it is shifting more and more to being a liability). A larger code base is harder to reason about (therefore slower to work with), harder to on-board into, and statistically contains more bugs than a smaller code base.

When code gets cheap to produce it can be very tempting to build features that have no real value. You don't get an avalanche of value, you get an avalanche of code, with all the negative effects mentioned above.

With production cost dropping, it is even more important to ask "is this feature needed, what value does it bring?".

Value

The value of something is almost always monetary, at least in principle (and in a commercial organisation).

The imaginary features I used in the previous examples are close to the value generation. Features that are further away from the value, such as security, performance optimisations, clean code, etc. still have monetary value. They increase the acquisition rate of a product, lowers the cost of on-boarding, etc. However, the further away, the harder it is to quantify.

It makes sense to split this into two:

Short distance. When the distance to the value is short, such as purchases, acquisition, retention, support tickets, etc. I think it is valuable to have a hypothesis before the feature is developed. "This should affect X with Y". It does not have to be perfect or in a revenue stream, but it should be closely tied to it. Then measure after building and tune in continuous development in this area.

Long distance. Things like performance work, maintainability, UI/UX improvement, etc. It is much harder to define a hypothesis related to a strategic business value. You have to rely on your experience and judgement.

Judgement, is that not like a feeling? As any good engineer, you know to avoid feelings and rely on hard data, right?

Well, I do not think it is a failure, or a bad option in these situations. Failure would be to measure things such as effort, or to define an invalid model when trying to quantify something which is too distant from a business value.

Sober up

I think the industry is acting drunk at the moment. Carried away with how easy it is to produce thousands of lines of code, and mistaking this for value.

Measuring value is much harder than measuring effort though, and sometimes you can only estimate its effect based on experience and make judgement calls.

These judgement calls require experience, domain knowledge and collaboration within your team, department or organisation.

Everything has changed, and at the same time, nothing has changed. The organisations that sober up and get their value focus right will have a lot more success using agentic coding than the others, just as it always has been.