AI, Coding, and the Programmer’s Role

With all the fear, uncertainty, and doubt swirling around AI, I want to step back and explain how I actually use these tools—and why they’re not going to put programmers out of their jobs anytime soon.

I use AI every day. I have Claude (both with Claude Code and through Cursor) for coding, and ChatGPT for research, brainstorming, and expanding references. They’re valuable tools, but not magic. The difference lies in how you use them.

Why I use AI (and How)

I don’t “vibe code.” My projects are too large for that; the context breaks down fast. Instead, I give AI detailed prompts—documents that define the architecture, decisions, and examples. With that direction, AI performs far better.

That’s because I don’t ask AI to program. I ask it to code.

This may sound like a meaningless distinction, but it’s not. It’s the most important distinction to understand.

Programming vs Coding

A programmer designs and manages programs: defining architecture, analyzing requirements, breaking work into parts, and guiding execution.

A coder translates directions into code: the raw material that compilers and machines transform into deliverables.

AI can be a competent coder—sometimes better than average. But it’s not a programmer. It doesn’t do analysis, design, or leadership. And when people forget that, they get into trouble

A Lesson from the 1980s

This divide isn’t new. Back in the late 1980s, there was a war between developers who wrote everything in macro-assembler and those moving to C.

Assembler was powerful, efficient, and elegant—but slow to produce. With C, you could build a working system in hours instead of days.

Assembler advocates argued their code was smaller and faster. True, but in practice? Compilers were “good enough,” and C developers could deliver real products faster. The compiler did the assembly for us.

AI today is playing the compiler. Tools like Claude act as compilers or transpilers: they take structured instructions and translate them into code. They’re imperfect, but guided by a skilled programmer, they’re extremely productive.

The Real Risk

Here’s the danger: if you don’t know what good code looks like, AI will happily hand you bad code. You won’t even know it’s wrong until it breaks.

I’ve run experiments giving AI only vague, user-level instructions. The results? Usually poor, sometimes catastrophic. Without proper direction, AI produces junk.

It’s no different than trying to use a CNC machine (a sophisticated programming machine) without knowing mechanical engineering. More powerful tools amplify skill—but they also amplify ignorance.

So yes, people who blindly rely on AI are going to be eaten alive. And people like me, who know how to guide it, will make a good living fixing their messes

How to Use AI Well

  • Act like a senior developer. Even if you’re new, you need to define work clearly, divide it up, and review results.
  • Treat AI like a junior coder. Direct it precisely, review its output, and correct mistakes.
  • Don’t delegate what you don’t understand. If you can’t tell when code is bad, learn more before turning AI loose.
  • Remember the rule of thumb: if you need AI, you probably shouldn’t use it. If you don’t need it, you can use it to great benefit.

A Tool, Not a Crutch

AI won’t eliminate programmers. It will eliminate rote coding. The winners will be those who can lead, analyze, and architect—while treating AI as the world’s most tireless (if sometimes clueless) assistant.

The future belongs not to those who let AI code for them blindly, but to those who can guide and command it.

Keep the Light,
Otter
Brian Jones

Thirty Years of Redwall MUCK

It’s the end of an era … Redwall MUCK was created 30 years ago, with permission from Brian Jacques, as a site to allow role-playing within his universe.

I had the pleasure to found it (or often a pleasure, sometimes not, that’s the nature of a social system) and run it as its Chief Wizard, Otter.

It’s a day for celebration, though I know many are sad to see it go. 30 years is a great run!

We had thousands of characters, and quite a few less players (players can have many characters, and we only tracked characters). We demanded privacy for our users, before privacy was well known. We expected good and kind players. We mostly got them. Many people made life-long friends and even met spouses in our community. It was a great place.

When Brian Jacques passed away in 2011, his works stopped. At that point, without his regular updates to the universe and his promotion, the series readership fell away as well. Everyone wants the new thing. It was a given that our users would drift as well.

Some asked why I didn’t give it away, was it expensive to host, etc.

I didn’t give it away because the people that entrusted their secrets to it (which they shouldn’t have done but did) would have had their secrets exposed to whomever received it. They trusted us, and we honored that trust.

It was never about the money. The MU cost under $10/month to run.

A TV program named Barney Miller may be unknown to most of our players, but it ran a few years. When they didn’t have a good set of new stories to tell, they closed it and took it off the air. It was smart, and it meant they left only good memories. Other shows ran long after there was nothing to say. Who remembers or wants to remember them?

Thus, we came to a close.

On September 15, 1995 the MU started.

On September 14, 2025 the MU closed for the final time.

I sent the final system message. It was this:

Otter shouts, “Go forth everyone and bring into reality that which was brought here. And pass it forward, do what they say can’t be done. Thank you all for coming, and it wouldn’t have been the same without each and every one of you. To 30 great years!”

I meant it.

There should always be places for those who don’t fit in, who wish for a place to go where things are better, who are welcomed when they arrive. For 30 years, Redwall MUCK was such a place.

Thank you, all of you, players and confused non-players alike.

And while it’s not literally true, the idea is still true:

I won’t say goodbye to you, because one evening you may drop by to share this good life with us. You know you are always welcome at Redwall Abbey. All you need to bring with you is a ready smile and an open heart.

Keep the Light,
Otter

Green Fields Ahead

I can do anything!

Greenfield projects in software imply that there won’t be a legacy system to accommodate, so this time, everything can be done right and all that “old cruft” can be ignored and we’ll all be coding in a land of rainbows and joy with only sunshine.

The reality is, greenfield projects are considered more risky. My earlier article on Getting to Enterprise explains one warning about greenfield risk — starting with enterprise tech because “you’ll need it anyway.”

Feel free to search for articles on the risks of greenfield development. This article focuses on what the coders need and do during greenfield and where not having legacy helps and hinders them.

Continue reading

The Amazing World of Step/Graduated Tables

Really? Tax Tables?

This isn’t a topic most people would find interesting, until they are subjected to implementing graduated or step tables. And I’ve found that many people aren’t aware of how a progressive tax model works even when seeing the tables.

I bring this up because when implementing a tax calculator using those tax tables if the tables are followed “as written” from most sources the code can generate wrong values and can even claim there are no brackets!

Credit to the Internal Revenue Service — its tables are defined properly!

How can so many be so wrong and what’s the actual error? And is the error in more than tax tables? Well…

Continue reading

The Reification Abstraction

One of the areas I enjoy is problem domain modeling. Developers have a tendency to skip this and immediately plunge into solutions. This works for them when the problem is understood…which is true far less often than they think.

Reification is a term used in many domains, but it’s easy to show it in problem modeling — and it’s often known (though not named) so if it seems familiar, excellent. (If you have experience in databases, it’s a part of normalization as well.)

To show an example, I’d like to model something that is not nearly as simple as it sounds, and use conceptual reification to address it.

Continue reading

DoorDash and the Two Audiences Failed

I like DoorDash and have used them for a few years, across many cities (I travel often, I’m not sure what their analysis makes of the various places I’ve ordered from).

What’s amusing is that my home in Las Vegas is one of many where the routing algorithm used for their drivers takes them to the wrong place every single time. I’ve updated my delivery directions to include the cross streets that bracket my condo, but it never helps.

A driver finally showed me why … and it’s a classic example of either bad analysis or bad design in the UX.

Continue reading

Mandated Lack of Security for Security’s Sake

I needed a QuickBooks Desktop license to access a company file for a lawsuit, so I bought one. Being paranoid, of course I put it on a machine not on the internet so that nothing I did could expose it (it’s not my data, of course I wouldn’t want it accessible online).

Since I did have the new QB Desktop (QB Premier 2021) I fired it up to experiment with importing transactions.

And discovered that in order to use QB Desktop I had to be online and logged into Intuit.

For my security I had to expose my accounting data to the internet …

What?

Continue reading

Keep On Supporting Them!

I wrote about how people and companies should help people learn to develop software who didn’t take the traditional university route (Developing Developer’s) and the Wall Street Journal today posted success stories of some who have taken non-traditional paths successfully in Blue-collar Workers Make the Leap to Tech Jobs. No college Degree Necessary.

This will, I hope, entice the recruiters who are seeking people expand their nets for entry level people. Job postings that demand degrees and many years of experience in a laundry list of tools will easily reject the people who have done what the journal article reports. I wrote about this last year in The Staffing Crisis. The same problem remains among the less skilled recruiters.

Continue reading

Trusting Everything?

The Wall Street journal today just posted an article Apps with Hidden Data Harvesting Software are Banned by Google, which is just one of many. I’m not even going to say it’s more egregious than many.

I worked on cybersecurity compliance for the nuclear power industry for a few years. I wasn’t doing the cyber protection itself (I’m not a security administrator, computer or network) but rather the software that enabled them to track all the details per NEI-0809. I learned a lot more than I ever wanted to know about security, and that includes having worked with classified data (oddly, as a site adminstrator) in USAF and having security certifications.

We want to trust; we want to believe that what we download, what we draw in from public repositories, even what we buy, is secure. It’s not.

Continue reading