What do You Really Enjoy?

I remember the first time I received a software development assignment. By then, I had already been building small Shell, Perl, and Python scripts for operational automation for a long time, but always within my own domain of knowledge: managing firewall rules, users, files, and similar tasks. I knew the requirements. I knew the constraints.

While some utility and operational automation can get quite sophisticated nowadays, I don’t think I had written anything with more than a few conditionals or simple loops back then.

I also became interested in operations very early in my career and didn’t care much about software development at first. As I’ve mentioned before, I dropped out of school early, so I didn’t even have a solid foundation to build on.

One of the account managers where I worked had a client who needed a monthly report to identify fraud in their loyalty program. The problem wasn’t especially complicated. They wanted to identify members who were swiping their loyalty card too frequently at the same store—say, more than five times in a single day. The idea was that an employee could register for the loyalty program and, whenever a non-member customer checked out, swipe their own card instead to accumulate points they could later redeem for goods or gift cards.

The account manager had tried several times to convince the development team to productize the report, but it never became a priority. The client was important, but not important enough. As a result, he spent an entire workday every month manually sorting everything out in a spreadsheet.

We had a good working relationship, and he knew I was resourceful, so he asked if I wanted to take a shot at automating it.

I struggled, but it turned into a great learning experience. I learned about different data structures, started breaking my code into helper functions, and, after a couple of days, my Python script was producing the same results as the spreadsheet. The operational side was easy: cron jobs, moving files around, sending notifications.

That project gave me confidence, and from there I slowly started swimming toward the deep end of the pool.

My coding skills improved over the years, but it wasn’t until my job at Google really kicked my butt that things finally clicked.

Working in DevOps and SRE exposed me to much more complex problems. I read books, had my code reviewed by engineers who were far better than me, and eventually reached the point where I caught myself thinking, I really enjoy this coding stuff.

Then 2025 arrived.

AI reached the point where it could write genuinely useful code. No more clunky copy-and-paste from a web interface, manually managing context windows, or constantly stitching pieces together. The improvements came incredibly fast. Suddenly Claude Code with Opus 4.7 could handle most of the implementation on its own.

I started delivering solutions much faster. More than once I woke up in the middle of the night with an idea, and by dawn it was already implemented. It was, and still is, an incredible way to build software.

Today I was showing my wife a project I’m working on when she asked,

“Are you even looking at the code?”

Well… not really.

I checked afterward. The project has grown to more than 12,000 lines of code, and I haven’t looked at any of them.

I’m not going to argue whether this is the right way to build software. That’s a different discussion.

What struck me was something else.

AI coding agents made me realize that, while writing code has always been enjoyable, what I actually love is creating solutions.

Someone presents me with a problem, and I want to solve it.

For most of my career, solving software problems and writing code were inseparable. If you wanted to solve a problem with software, you had to write software. Becoming a programmer was simply the price of admission.

That assumption no longer holds.

Today I can describe a problem, discuss trade-offs, iterate on a design, review the implementation, and ship a working solution while writing very little (or none) of the code myself.

And I don’t miss it.

In fact, I prefer it.

That realization also helped me understand why the industry seems so divided about AI.

Some people are resisting it.

Others have embraced it completely.

I don’t think the difference has much to do with AI itself.

I think it has everything to do with what people actually enjoy.

If the part you love most is writing code, AI increasingly automates the activity you value. Every improvement can feel like another step toward making your expertise less valuable.

If what you love is solving problems, AI is the most powerful tool you’ve ever been given. Every improvement expands the range of problems you can solve while dramatically reducing the time between an idea and a working solution.

Those are very different perspectives.

Whether we like it or not, software development is becoming less about producing code and more about producing solutions.

Customers don’t buy code.

Companies don’t buy code.

People pay to have problems solved.

Code was simply the most efficient way we knew to produce those solutions.

Now it isn’t.

I think many developers are going to discover over the next few years that they built their identity around a skill that is rapidly becoming a commodity.

That doesn’t mean programming disappears.

Just as spreadsheets didn’t eliminate accountants, programming languages won’t disappear overnight.

There will still be people doing it.

There will simply be far fewer people willing to pay for it.

So maybe this is a good time to ask yourself a simple question.

When you strip coding away…

What is left that you actually enjoy?