The Danger to Your Job Isn’t AI. It’s Defining Yourself by a Task.
Every technology wave changed the tasks. The people who adapted focused on the problem instead.
I still remember typing more than 100 lines of C++ from a Charles Petzold book just to display a simple “Hello World” message as a Windows application.
A few years later, Visual Basic arrived. I achieved the same result with a single line of code. After spending months learning the hard way, I wasn’t sure whether to celebrate or use my Charles Petzold book as a pillow.
Over the last 30 years, I’ve watched the same movie play out again and again.
People who define themselves by a task struggle through these transitions. People who define themselves by the problem they solve usually find a way forward.
The code became easier. The business problem didn’t.
Users still needed applications. Businesses still needed solutions. The value had simply moved to a different place.
Did that make me a weaker developer? Of course not.
I went from typing hundreds of lines of code to designing screens and building applications by dragging and dropping text boxes, labels, and buttons. The new visual tools made it easier to solve business problems that users could actually see. And problems users can see are usually the ones businesses are willing to pay for.
New technology had arrived, but the question was the same as it is today: Was my job typing code, or solving a business problem?
Then the next wave arrived.
One of the first packaged applications I worked on was Vantive, a CRM product. Before packaged software, every customer implementation required building screens, workflows, databases, and business logic from scratch. Vantive came with much of that already built in. Instead of building everything, we configured, customized, and extended what was already there.
Projects that once took years could often deliver a first release in a quarter.
Again, the work changed. Developers moved from coding everything new to customizing existing elements.
My role changed as well. Before packaged software, my value came from building things. With packaged software, my value came from understanding both the customer and the technology. When I knew both, I could map out what was possible by default, what could be customized, and what could not be done.
Looking back, I was an early version of what we now call a forward-deployed engineer. The deeper lesson I learned was that technology careers are rarely about the technology itself.
I did not stop creating value because I stopped coding. I simply created value differently.
That is why I view the current AI discussion through a different lens.
I agree with Jensen Huang’s observation that jobs are really collections of tasks. Some tasks will disappear. Some tasks will be transformed. Some entirely new tasks will emerge. The question is not whether tasks will change.
I’ve seen this movie before. The tools change. The job titles change. The anxiety remains remarkably consistent.
Every technology wave forced me to answer the same question: What exactly is my job?
Was my job typing code, designing screens, configuring software, or was it helping businesses solve problems using technology?
If I had defined my job as typing code, I should have become obsolete when 100 lines became one.
If I had defined my job as designing screens, I should have become obsolete when packaged software arrived. Neither happened.
Because my real job was never typing code or drawing screens. My real job was solving business problems with technology.
I’m reminded of an old story about stonecutters. A traveler asks one worker what he is doing.
“I’m cutting stones.”
Another says:
“I’m building a cathedral.”
A third says:
“I’m helping bring people closer to God.”
All three are doing the same work, but they have very different definitions of their job.
The same idea appears in business. People often think they are selling drills. Customers do not want drills. They want holes.
And even that is not the whole story.
Often they do not want holes. They want to hang a family photograph on a wall.
The farther you move from the task and toward the outcome, the more resilient you become when technology changes.
That is the real lesson of AI.
If you believe your job is typing code, creating data tables, configuring screens, or performing a specific task, the next few years may feel uncomfortable. But if you believe your job is solving customer problems, improving business outcomes, creating value, or helping people achieve something they could not achieve before, there will continue to be opportunities.
The tools will change. They always have.
The people who thrive are the ones who keep redefining their role around the problem, not the tool.
That has been true throughout my career, and I see no reason to believe AI will be any different.
Every major technology shift in my career forced me to answer the same question:
What exactly is my job?
AI is simply the latest version of that question.
So don’t ask whether AI can do your current task. Ask yourself a harder question: What problem do I solve, and how can I use AI to solve it better?
The answer may determine who thrives in the next decade.
CTO Field Notes captures observations, lessons, and questions gathered over three decades working at the intersection of technology, business, and faith.
The theme that connects them all: Observe. Wonder. Grow.
If a note sparks a thought, a question, or a different perspective, I’d love to hear from you.