Forty Years of Experience, and Suddenly Everything Changed

I've been developing software for more than forty years.

That's a long time to be doing anything, and certainly long enough to see a few technological revolutions come and go.

I've watched development tools evolve, programming environments change, and entire approaches to building applications become obsolete.

Through most of those changes, one thing remained reasonably consistent.

If I wanted to create something, I had to do the work necessary to create it.

I could use better tools. I could reuse existing code. I could develop libraries and templates to automate repetitive operations.

But the fundamental process still involved me sitting at a computer, writing code, building applications, debugging problems, and figuring out how to make everything work together.

Then AI came along.

And somewhere along the way, I realized that the most important thing changing wasn't the programming language or development environment.

It was my relationship with the work itself.

A Decision I Had to Make

When AI began becoming useful for serious software development, I had a choice.

I could dismiss it as another technological fad.

I could treat it as a convenient way to generate snippets of code or answer questions.

Or I could make a serious effort to understand what it was capable of doing, why it worked, and perhaps more importantly, why it sometimes failed.

I chose the third option.

That decision has probably changed my approach to software development more than any new programming language or development tool I've encountered in years.

And it wasn't simply because AI could generate code.

It was because I began to understand that I could approach entire projects differently.

The Work I Used to Do

Consider something as ordinary as collecting information about software products.

I've been working on Clarion Desktop, a directory intended to help Clarion developers discover products, tools, resources, and other information relevant to their work.

One of the challenges is that the information comes from many different sources.

Some vendors have excellent websites with detailed product descriptions.

Others have pages that haven't been updated in years. Some provide very little useful information at all.

Traditionally, building a directory like this would involve a substantial amount of manual work.

Find the website. Locate the product information. Determine what the product actually does. Separate useful facts from marketing language. Write a meaningful description. Decide how it should be categorized.

Repeat that process for another product.

And another.

There's nothing particularly glamorous about that work, but it matters if you want the resulting directory to be useful.

Now consider a different approach.

An AI agent can examine the available product information, identify useful details, and prepare a proposed description.

Instead of personally performing every step, I can concentrate on evaluating the result.

Does the description make sense? Is the product correctly identified? Did the system misunderstand something? Does the information need additional verification?

I haven't eliminated my responsibility for the quality of the directory.

I've changed where I spend my time.

That distinction is important.

The Computer Can Do More Than Type

Software testing is another area where my thinking has changed.

For decades, developers have spent enormous amounts of time running applications, testing controls, checking results, fixing errors, and doing it all over again.

We've had automated testing tools for years, of course.

But the newer AI capabilities introduce another possibility.

An AI system can potentially run an application, inspect what appears on the screen, evaluate the results, identify a problem, and participate in correcting it.

That's a considerably different proposition from simply generating a few lines of code.

It doesn't eliminate the need for testing or human judgment. In fact, AI-generated changes can introduce their own problems.

But it changes how the work can be organized.

And when you begin thinking about an entire development process in those terms, the possibilities become much more interesting.

Forty Years of Experience Still Matters

Here's the part I find particularly interesting.

AI hasn't made my forty-plus years of experience irrelevant.

Quite the opposite.

When I ask AI to help design a system, I'm not approaching the problem without any idea of what a good design should look like.

I've spent decades dealing with software architecture, data structures, user interfaces, business rules, deployment problems, and the consequences of decisions that seemed perfectly reasonable when they were made.

That experience helps me recognize when AI is heading in the wrong direction.

And believe me, it can head in the wrong direction.

It can produce code that looks wonderful but doesn't work.

It can confidently explain something that isn't true.

It can solve the problem you described while completely missing the problem you actually needed solved.

It can also create unnecessary complexity, duplicate existing functionality, or make changes that introduce new problems elsewhere.

Those are not theoretical concerns. They're part of working with AI on real projects.

The difference is that I can recognize many of those problems because I've encountered their underlying causes before.

I know when an explanation doesn't quite add up.

I know when an architecture is becoming unnecessarily complicated.

And I know that an application which compiles successfully is not necessarily an application that works correctly.

That experience gives me a foundation for directing AI rather than simply accepting whatever it produces.

I'm Still the Developer

This is something I think people sometimes misunderstand about AI-assisted development.

They imagine that you're turning the work over to a machine and collecting the results.

That's not how I see it.

I'm still making the decisions.

I'm deciding what the application needs to accomplish. I'm evaluating the architecture. I'm determining which features matter, which approaches are worth pursuing, and which results are acceptable.

What has changed is how much of the implementation work I need to perform personally.

Instead of spending all my time writing every function, I can spend more of it thinking about how the pieces fit together.

Instead of manually researching every possible solution, I can explore alternatives and evaluate them.

Instead of being limited primarily by how quickly I can produce code, I can work on multiple aspects of a project while AI helps with the implementation and investigation.

And because I understand the technology well enough to recognize its limitations, I don't have to pretend that everything it produces is correct.

That, to me, is where the real productivity improvement comes from.

Not from surrendering responsibility.

From being able to exercise that responsibility across a much larger amount of work.

What About the People Who Aren't Ready?

I also understand that my experience isn't necessarily going to be everyone's experience.

I've spent a lifetime learning how software works. I already have a substantial foundation of technical knowledge.

Not everyone has that advantage.

Some people have spent years becoming exceptionally good at work that AI may now perform much more cheaply.

For them, the transition may be far more difficult.

I don't think we should casually dismiss those concerns by telling people to learn a few prompts and everything will be fine.

There are going to be genuine disruptions.

Some jobs will change. Some will disappear. And some people will have a difficult time finding a new place in the workforce.

That's part of why I consider AI to be something approaching a modern Industrial Revolution.

It isn't simply improving the tools we already use.

It's changing what people can accomplish, what businesses need employees to do, and what certain kinds of work are worth.

I don't pretend to know exactly how that will play out.

But I do think ignoring the change is a poor strategy.

The Part I Didn't Expect

If someone had told me years ago that, after more than forty years in software development, I'd find myself fundamentally rethinking how I build applications, I'm not sure I would have believed them.

After that much time, you develop habits.

You know the tools. You know the processes. You know how to get things done.

And there is a certain comfort in that familiarity.

But I've discovered something interesting.

Learning to work effectively with AI hasn't meant abandoning those decades of knowledge.

It's given me an entirely new way to apply them.

Projects that once seemed too large or too time-consuming for one person to tackle have become much more approachable.

Ideas I might previously have set aside because of the implementation effort are now worth exploring.

And perhaps most importantly, I'm finding that I spend more time thinking about what I want to accomplish and less time being constrained by the mechanics of accomplishing it.

That's a remarkable change this far into a career.

I don't know what AI will look like five years from now, much less twenty.

I don't know which professions will flourish, which will struggle, or how many entirely new kinds of work will emerge.

But I do know this.

After more than forty years of developing software, I could have decided that I already knew enough.

Instead, I decided there was something important I needed to learn.

And that decision has changed what I believe is possible.