AI Doesn’t Know Our Business. We Do.

AI can prototype our workflow. It can draft our requirements. It can generate our user stories. But it has no idea how our business actually works.

It can’t tell us where the bottlenecks in the process are. Our loan officer knows that. It can’t explain why the workaround exists. Our operations manager knows that. It doesn’t know which shortcuts blow up in an audit. Our compliance analyst knows that. It has no idea where customers rage-quit. Our customer service supervisor knows that.

Our best people, the ones who actually know how the work works, often have trouble translating what’s in their heads into something a developer can build. They know where the friction is. They know which exceptions happen every Thursday afternoon even though the procedure says they shouldn’t. They know which approval step matters, and which one is just a bureaucratic leftover from a reorg three years ago.

For the first time, the people who do the work and understand the problems they’re trying to solve can start shaping the solutions. AI gives their expertise a doorway it never had before.

These subject matter experts can sit down with an AI tool and start turning what they know into something visible. Plain language in. Workflow out. Prototype sketched. Edge cases surfaced. User stories drafted.

And when they do that, something shifts. They realize software development isn’t magic. It’s a thousand small decisions that someone has to make. That realization alone is worth the exercise.

Instead of walking into a meeting saying, “we need a dashboard” or “can we automate this?” they walk in with something tangible. Rough? Sure. Wrong in places? Probably. But it doesn’t have to be production-ready. It has to be conversation-ready.

That changes everything.

Developers, architects, and project leaders can see the idea. They ask sharper questions. They spot what already exists, what creates risk, what can ship fast. The subject matter expert starts understanding what building a solution actually involves. The dependencies. The data quality landmines. The difference between a slick mockup and something that holds up in production.

That shared understanding transforms the relationship between business and technology.

We know the old pattern. Business has a need that’s difficult to explain, the technology team tries to interpret it, weeks pass, something appears, the business says, “close but not what we meant,” the cycle repeats. Everyone gets frustrated. Nothing ships.

AI doesn’t kill that cycle. It compresses and turbo charges it. When developers start with a real prototype and a real conversation, iterations can take hours or days instead of weeks.

The AI win is getting people in the same room faster, with something real to react to.


If more people can generate ideas, workflows, and prototypes, we’ll start getting more possibilities than we can pursue. A good problem to have, but still a problem.

Bottom-up energy is powerful. It surfaces solutions from the people closest to the work. It finds problems leadership didn’t know existed.

But without focus, we’ll drown in prototypes. The bottleneck doesn’t disappear. It moves from “we don’t have enough ideas” to “we have no idea which ideas deserve investment.”

That’s on leadership.

Executives, your job isn’t to be the gatekeeper of imagination. Play that role and the old problems come back fast. Good ideas will die in departments, in notebooks, in hallway conversations that never go anywhere. You become the reason nothing changes.

Your job is to be the steward of focus. Create the channel. Invite ideas up. Encourage people to explore, prototype, get specific. Then make the call on what moves forward.

Bottom-up imagination. Technical refinement. Executive focus. That’s a model that AI tools make possible.

Subject matter experts bring better ideas because AI helps them say what they know. Technical teams sharpen those ideas because they understand what durable software is. Executives look across the whole landscape and ask the hard questions nobody else is positioned to ask.

Does this solve a real problem or just an annoying one? Does it scale? Does it duplicate something we already own? Does it create risks we can’t absorb? Is this a strategic investment or a distraction dressed up as innovation?

Not every prototype becomes a project. Not every project deserves to live in our permanent technology environment. That’s not a failure of imagination. That’s how imagination gets distilled down to create tangible business value.


The future advantage won’t go to the fastest movers or the biggest tool buyers. It won’t go to the organizations that treat AI like a cure-all and wonder why nothing changes.

It’ll go to the ones that know their business well, listen hard to the people doing the work, and never confuse creating more things with creating better things.

AI can help us build faster. That’s the easy part.

Knowing what to build and why. That’s still on us.

Photo by BEN ELLIOTT on Unsplash – This is a downwind leg, spinnakers out, boats grabbing everything the wind has to offer. A good metaphor for AI. It can give us remarkable speed. But we’re still in a race, there’s still a course to navigate, and the turns are still ours to make.

When the Disruptors Get Disrupted

For most people in IT, change is constant.

New platforms arrive. Old tools fade. Processes are reworked. Skills must evolve.

In that sense, disruption has long been part of the job description.

Software developers create new and improved tools. They streamline workflows. They automate tasks that once required entire teams. Over time, they have reshaped and disrupted how work gets done across nearly every industry.

This pattern has been in place for decades.

For software developers, something different is happening now.

With the arrival of AI-assisted development tools, including systems like Anthropic’s Claude Code, disruption has begun to turn inward. These tools are reshaping how developers approach their own work.

For many in the profession, this feels unfamiliar.

Software development continues, but the definition and details of the role are shifting. Tasks that once required sustained manual effort can now be generated, refactored, tested, and explained with remarkable speed.

A developer who once spent an afternoon writing API integration code might now spend fifteen minutes directing an AI to produce it, followed by an hour reviewing edge cases and security implications. The center of gravity moves toward judgment and direction rather than execution and production.

When job roles experience disruption, responses tend to follow predictable patterns. Some people dismiss the change as temporary or overhyped. Others push back, trying to protect familiar and comfortable ways of working. Still others approach the change with curiosity and engagement, interested in how new capabilities can expand what’s possible.

Intent Makes the Difference

An important distinction often gets overlooked when discussing pushbacks.

Some resistance grows from denial. It spends energy cataloging flaws, defending established workflows, or hoping new tools disappear. That approach drains effort without shaping new outcomes. It preserves little and teaches even less.

Other forms of resistance grow from professional judgment.

Experienced developers often notice risks that early enthusiasm misses. Fragile abstractions, security gaps, maintenance burdens, and failures that appear only at scale become visible through lived experience. When developers raise concerns in the service of quality, safety, and long-term viability, their input strengthens the eventual solution. This kind of resistance shapes progress rather than attempting to stop it.

The most effective developers recognize this shift and respond deliberately. They move away from opposing new tools and toward advocating for their effective use. They ask better questions. They redesign workflows. They establish guardrails. They apply experience where judgment continues to matter.

In doing so, they follow the same guidance developers have offered others for years.

Embrace new tools.
Continually re-engineer how work gets done.
Move upstream toward problem framing, system design, and decision-making.

Greater Emphasis on Judgment

AI generates code with increasing competence. Decisions about what should be built, which tradeoffs make sense, and how systems must evolve over time still require human judgment. As automation accelerates, these responsibilities grow more visible and more critical.

This opportunity in front of developers calls for leadership.

Developers who work fluently with these tools, guide their thoughtful adoption, and help their teams and organizations navigate the transition become trusted guides through change. Their leadership shows up in practical ways:

-pairing new capabilities with healthy skepticism

-putting review processes in place to catch subtle errors

-mentoring junior developers in how to evaluate results rather than simply generating them

-exercising judgment to prioritize tasks that benefit most from automation

Disruption has always been part of the work.

The open question is whether we meet disruption as participants, or step forward as guides.

Photo by AltumCode on Unsplash