37K lines of code. That was the whole announcement. Not what it did, not who it helped. Just how much.

I've been making computers do things for companies for more than 30 years now. I've been making computers do things for fun for more than 40.

And now we have AI... Things have changed. For the better? Worse? Who knows. This isn't going to be Yet Another AI Blog Post talking about how we can now do everything we ever dreamed of, or that our industry is collapsing because anyone can now do anything they ever dreamed of.

What this post is going to talk about is how we, as developers, are shooting ourselves in the foot with the metrics we love to throw around with AI agents.

If I think back to those early days when a naive graduate moved from the UK to the Netherlands, and started working on the rest of her life, I always prided myself on making code that was readable, efficient, and did the job the best way I knew how.

I would spend hours at a whiteboard in order to write 20 minutes of code. Going through the problem, what did the user want? More importantly, what did they NEED?! Working out the flow in screens, then flow charts, then English pseudo code, then actual code. Running it in my head to find where it would go wrong.

When I was happy, I moved to the keyboard and usually had working code in the first 1 or 2 attempts at the compiler. I'd then pack that into an installer, burn it to disc (yes, that was a thing), and take it to the client for them to give feedback on.

With that feedback we would make small adjustments and move forward. (And all of this before I'd heard of agile.)

But the code that was made would only be the code that was needed. Not more, not less. I didn't shout about the code, I shouted about the things that my clients loved! Seeing someone improve their life with your hard work is amazing!

Then, in the 00s, people started to gather more and more metrics. How many pull requests had you done? How many tickets? And the most egregious for me: How many lines of code (LOC) had you written?

Note: I was lucky enough never to work for a company that did this, but I felt for those that did!

Around this point there was a lot of pushback about just how you could monitor a developer's efficiency. Tickets are meaningless - 10 tickets could be nothing, 1 could be a game changer. Same for PRs, and of course, the same for LOC. We developers are artisans. Lovingly crafting those words and operators to bend to our will in the best way possible.

What does one care about lines of code? Why, good sir, some of my best days I have negative lines of code! Don't bother me with such banality as LOC.

OK, I'm not that posh, but you get the point. We were proud of the lines we never wrote! And so we should have been. Why waste cycles and make code unreadable for no reason?

And then the AI tools arrived, and I'll be honest: I use them every day and I love them. But all of a sudden LOC became something to brag about! 37K in a day! How awesome am I!!! A bragging contest to see who could add the most bloat in the shortest time. We, the same people who scoffed at LOC a few short years ago, started cheering for it. If you are not writing thousands of LOC a day, then what are you doing with your life?

Something that has never stood out for me with these posts is value. No one ever mentions what their users can now do that they couldn't before. No one talks about what problems have been solved in the real world. No one talks about making things better.

I mention this in my current talks too. LOC was never a good metric, and just because we can now generate LOC far faster than we could 5 years ago doesn't change that.

A 10 line change can still provide more value than a 1000 line change. As can a -1000 change.

AI has changed the game, but not the rules. We need to do things that help.

And we can now do that with more ease! If typing code is now cheap, we have more time for the part that always mattered: listening to people and working out what they actually need. The tools can give us that time back. We just have to spend it on the right thing.

Let me show you what I mean.

My first software to be used in a commercial setting was started way back in 1993. It was for my A-Levels and I wanted to do something AMAZING. Why settle for something fake, when you can do something for real? So I went to a local bakery and told them what I wanted to do (build them a stock control system), and would they let me do it for my A-Level project.

Well... That sounds cool, but we don't need it. What we really need is a way of knowing where our stock is so that when we do an inventory day we can go right to the correct location. Right now we are all over the place and it takes us 3 days. So I wrote an application for that instead. Not as interesting as this awesome fully automated system, but something that would actually provide them value.

When I left the UK 5 years later they were still using that app and it reduced stock taking from 3 days of swearing to 1/2 day of checking off a printout.

The code was much smaller, and it did a job that needed doing. Not something fancy. Something useful. I learnt a good lesson doing that, which I remember to this day.

Writing that application took a huge chunk of time. I was learning new things, syntax, method construction, I/O APIs. If I was doing that today, it would be an afternoon of Claude Code at the most. Including an IaC and CI/CD pipeline. (Though I still think that students should know how to write the code before leaning on AI...). But learning the customer problem would be the same, and without that, the AI agents could write the stock control app in an afternoon too - only it wouldn't have been solving the right problem.

A few months later, when I started Uni, we had our first software engineering lecture. And the lecturer basically taught us the same thing. Coding is what you think you are here for. But actually, what you are here for is to listen to users and solve their problems for them in the best way possible. Even if that doesn't involve a computer at all...

You are not here to type code, you are problem solvers, never forget that!

So what should we count instead? Maybe the honest answer is that it isn't a number at all. It's a question. What can your users do now that they couldn't do yesterday? What got faster, easier or less painful for them? What did you choose not to build?

To all my fellow developers, can we please stop with the LOC maxing. I don't care how many lines you wrote. Can we please go back to counting what helps. Making sure that you are helping people with each change you make.

Modern tools make it easy to generate code, they don't always make it easy to generate the right code.

To quote Stevie from "Miranda", quoting Heather Small's "Proud":

What have you done today to make you feel proud?

I feel far prouder of solving a problem than I do shouting about LOC. I hope that you do too.