A colleague at Improving stopped me in the hall and said other developers were asking two questions. Will AI take our jobs? And is it even possible to change languages mid-career? He asked them partly in jest, but the worry behind them was real. I have been in this industry for over three decades and have moved from Lotus macros to dBase to Clipper to FoxPro to Visual Basic to .NET and beyond, so the question landed differently on me. It also made me look back at what has actually threatened my career and what has not.

The first thing I remembered was the moment I realized I may have stolen someone’s job.

When I started in the early 1990s, the generation before me was still working with mainframes, COBOL, and punch cards. I did not know any of that. I walked into businesses with newer tools and started delivering applications without once touching a punch card. I was already the beneficiary of a tool shift that made an older set of skills less relevant. I did not feel like a disruptor; I felt like a kid who showed up to work and found the previous shift’s toolbox still sitting there (except that I wasn’t even aware of that at the time).

That is not a confession; it is context. The same kind of displacement has happened several times since then. Thirty years ago we had Rapid Application Development tools. You described a customer table, a product table, and a sales order table, dragged them onto a surface, and the tool generated a CRUD screen. The promise was the same one we hear today: you will not need a programmer. Business users built things, their needs outgrew what they built, and then they hired a programmer to tighten up things.

I have spent much of my career walking into companies that outgrew MS Access, FoxPro, and whichever drag-and-drop solution was fashionable that year. The systems were full of business logic trapped in button clicks and form events, with no tests, no version control, and no one left who remembered why the calculations worked that way. The tool did not remove the need for judgment; it moved the need to a later, more expensive stage.

Then there was the .NET team I trained a couple of years ago. Some of those developers had been writing .NET for 15 or 20 years, yet their code looked like what I wrote in year one. They had not internalized object-oriented programming, the functional features C# had picked up along the way, common patterns, or SOLID. Generics, LINQ, and lambdas were all sitting in the language they already used, but they had not made the jump from syntax to thinking. They were not bad people. They had simply repeated the first year of their career two dozen times. The real danger is the decision to marry one way of working and stop learning. A tool cannot make that decision for you.

AI is just the latest tool sold with the same pitch. I sat in a conference room recently while a speaker told business owners they would not need developers anymore, because developers do not understand the business (the majority of the audience was made of developers). The sting was that he was half right. Developers who are only tied to their favorite language or framework and never look up from the screen are easy to describe as replaceable. The half that matters is this: developers who understand the problem and the people living with it are not easy to replace.

I have seen business owners cling to consultants who could barely keep up with the latest syntax because those consultants understood the workflow on the factory floor. They noticed the gloves, headset, and sticky notes that reveal the workflow. The code was secondary; the context was the product.

Don Norman captured this in The Design of Everyday Things:

a weak human plus a machine plus a better process beats a strong human plus a machine plus a bad process.

Better process, in this case, means understanding the problem before writing code, naming intent clearly, and staying curious about the people who use what we build. The machine amplifies the human; it does not invent the purpose.

The answer is narrow. AI will take the job of people who only read and write code in one context, in one language, with one framework. It will not replace the people who understand the problem and those affected by it. The real risk is deciding that the tool I already know is the only one worth knowing.

That is the thread I want to pull through this series: stay fluent enough that the tool is never the point, rather than trying to outrun AI. The next post picks up that idea with the simplest question I ask when a new tool appears: what problem does it solve, and for whom?

Further reading

• Are You Writing Code or Solving Problems?
• Mastery Over Tools
• History Repeats From Spreadsheets to AI Tools
• Beyond the Tool What Are We Actually Building