Not that long ago, I was convinced AI was a solution in search of a problem. Lately I think I'm beginning to figure out just what problem that might be. And more importantly, I'm focusing more on how use an AI to produce real, legitimate solutions. Not unsurprisingly, it's not at all what I thought it would be. In the words of a song by the Grateful Dead.

Sometimes the light's all shinin' on me

Other times I can barely see

Lately it occurs to me

What a long, strange trip it's been.

-- Truckin', 1970

I'm not all the way there yet, but I'm certainly nowhere hear my starting point. And, there's no going back no matter how strange it feels.

Truckin' on the Road

My own trip began with a categorical dismissal of AI. I didn't think it was a useful tool for Access developers. You know the criticisms; you've made them yourself:

• AI makes mistakes
• AI forgets important details
• AI doesn't work the way you prefer to work
• AI hallucinates
• AI is syncophantic
• A human can do everyting the AI does, and do it faster and better.

But contradictorily

• AI is going to take our jobs

All of that is true in one way or another in some circumstances. However, in a very important sense, it is beside the point. If answering questions, writing a love note to your significant other, finding the most common method of grafting new branches on fruit trees or drawing pictures and making music is all you ever ask of an AI, all of its foibles go with the territory. You learn to deal with it or you stop using the AI.

Importantly, those issues are inherent in an episodic work style. You dip in, get an answer and dip back out. Episodic AI simply doesn't create an opportunity for determining context, establishing scope and requirements or criteria for success. If you manage to scoop up a useful, accurate answer on the first try, great. If not, you do it again. Over and over until you luck into something.

However, that's not how AI fits in my work these days. I doubt I'm alone in that, far from it. I am not sure that many other developers are still doing that. I still think it's worth talking about.

We're Project Managers, Software Engineers, and Developers

We deal in projects. We need to gather requirements, create specifications, build out, test and maintain applications. How we interact with an AI assistant is, therefore, quite different from episodic questions. At least, I think it probably should be different and that's what I'm driving at today.

Let's dig into that.

Fundamentally, I believe there are two distinct ways to work with an AI within a software project.

• One approach is hanging on to the episodic approach, submitting isolated requests to an AI Chat model for information or artifacts for the specific task in front of us right now without regard to what came before it or what comes after it.

We can treat the AI like an on-call consultant to whom you describe a problem in hopes of getting enough feedback to do some work. Or perhaps it's more like an online technical forum, but one where you don't have to wait long for an expert to come along and read your question, hoping they have something useful to offer when they do appear.

The truth is that, without context, the AI is not going to do much better than a random person reading your forum post and making assumptions about all the details you left out.

Believe me, the AI is probably not going to bother clarifying what you really meant.

• The other approach is to ask the AI Agent to investigate the problem itself within a properly described context.

I'll elaborate more on the pertinent characteristics of Agentic AI later on in this article. First, let's see why I consider episodic consulting to be a hazard.

Episodic Consulting

The difference between episodic consulting and Agentic AI is not how smart a model is. It's how they are grounded.

What it's standing on

The consultant knows only what you put in the message box. Its answer is shaped and limited by the accuracy and completeness of your problem statement.

Misremember a column type in a table (and don't bother to look it up), describe a stored procedure's behavior or parameters a little wrong, and you'll get confident, well-reasoned advice about a system that doesn't exist. Like an auto mechanic diagnosing a problem over the phone, the AI has no visibilty to the real situation.

Why is that wrong and dangeruous?

• You use that advice in your actual code. If the AI got lucky, you get good code. If not, oh well.
• Your skill and knowledge are the integration layer. It's still on you to figure where and how to use the AI's response.
• Your ability to test closes the verification loop. You still have to figure out how to test the code and then run it.

Moreover, this isn't a two-way street. The episodic consultant never finds out whether it was right if you don't tell it! You can cuss about the mistakes and the rework you have to do and then actually do the rework, but that doesn't help the AI do better next time. It won't even know about it's failures.

Where we're arriving today is instead based on establishing a working partnership with an Agentic AI.

Agentic AI

When you set up an Agentic AI, that agent moves inside the process.

It reads the actual schema you are refactoring or the multiple-function module you're splitting up. It knows all of the datatypes in tables because it sees them for itself. It reads your error handling and compares it to the standard error handle in its DesignStandards.md

It runs the actual refactored stored procedure and evaluates the results. It sees an actual error text if one is thrown.

It's inside the feedback loop instead of outside it. It can discover that some or all of your premise was wrong before it even tries to answer a question, and it can act, watch the result, and correct itself — closing its own loop rather than handing you something to test later.

It takes more preparatory work on your part to stand up an AI Agent and feed it the information it needs to do its job. That's an investment you have to justify for yourself. I have decided it most definitely is valuable.

An AI Agent sounds like a straight upgrade over an episodic AI, but there's another angle to consider.

The hazards of over-reliance on AI Agents

The thing that makes the agent more capable — it is deeply involved in the actual work — is exactly what makes it more dangerous when it's wrong.

An AI consultant's worst case is bad advice you read, check out and discard. You don't spread it throughout a project until you know it's the real deal. You're in control, for better or worse.

An AI agent's worst case is a plausible, confident, wrong edit committed across multiple files. You can't throw away that mistake. You have to stop and undo it.

With a consultant you have to invest in framing the input well in order to be confidant you'll get usable output. Plus you own the verification.

With an agent you invest in constraining the blast radius, as Claude likes to call it, of a bad decision and making its actions reviewable and reversible:

• source control so every change is a diff you can reject
• scoped credentials so it can't reach further than the task needs
• context files that pin down the project's real conventions so it isn't guessing
• changes small enough that you can actually read and digest them.

It bothered me for a while that I was establishing so much infrastructure just to manage the work the AI was doing, until the day that infastructure kept an invalid assumption out of the database.

It sunk in: that infrastructure isn't overhead you tolerate for the agent's sake. It is the working relationship. The price of letting something act on your behalf is that you have to make its acts discoverable and reversible.

Here's where it can become awkward

Let's say you misrepresent a problem early in the planning or design. You leave out a critical factor, or you describe something wrong. The agent can see both your statement of the requirement and the actual code. How does it handle a conflict?

Less reliably than you'd hope, and it helps to be precise about why.

Sometimes it's a factual error. You misremember that a stored proc returns a scalar value; looking at the database, the Agent can plainly see it returns a result set. There the code wins outright — it's what actually runs — and a well-behaved agent should defer to it. More importantly, it should say so rather than silently override your description. I've had that happen; sometimes it's okay and I am grateful. Once, though, the AI silently executed what it could see, even though I wouldn't have let that happen had I realized my mistake, or better yet, had the AI informed me of my mistake in time to head it off.

Other conflicts are about intent. You state in your DesignStandards.md for that database that a column should never be null, yet the schema as built did allow null, and there's null data sitting in it right now. Neither the schema nor the documentation is authoritative there. They each tell you what is from their own point of view. The agent can't resolve the conflict that by reading harder. It can only surface it and ask.

Here's where the nature of an Agent AI comes into play. Mixing Factual Errors and Errors of intent is a common failure: treating a question of intent as if the data silently overrides it, or treating a settled fact as if it were still negotiable because of your inaccurate framing.

The deeper problem is the way AI agents are trained. The agent is trained to be helpful and to follow what you tell it. Your framing of a request is a strong component. When the schema or code or data contradicts you, the path of least resistance for the AI is not to flag it — it's to quietly reconcile behind your back.

Sometimes it reconciles in your favor, inventing an explanation that makes your wrong premise fit what it sees. That's dangerous.

Sometimes it reconciles toward the code and silently uses the real schema or data or code. That's safer. However it nevers reveals your mistaken assumptions and guarantees repetition of the error. Either way the conflict gets smoothed over instead of raised. The capacity to catch your error is reliably there. The inclination to make your responsble for your own problem is not.

What is my final destination on this trip?

That's still evolving, but I've come to some conclusions about what that should look like. I do know that being effective means learning how to manage an AI Agent, not a chatbot.

That, in turn, has a lot to do with how much I trust the AI to work autonomously. Early on, knowing that we're still standing on less firm ground and looking out over unexplored territory, it's even more important to proceed as if the AI Agent is bright, but quite naïve.

There's less code and fewer objects built. The Agent can't push back if your framing doesn't make sense. Your project description has maximum leverage at exactly the moment it's most likely to be incomplete.

The context files you write up front to orient the agent are claims about reality, not observations. If your early premise is wrong and you encode it in a CLAUDE.md, you've handed the agent authoritative-looking documentation of your mistake — and it will propagate that against the actual schema instead of catching it. The artifact meant to ground the agent becomes the thing that ungrounds it.

What actually helped me

• Giving the agent permission to ask questions. Swallow your ego if you have to. I did. I adopted a skill that has the agent question my assumptions until we agree we both understand the goals of a project. The skill for that is called grillme.

• Taking the time and formalizing the entire process. In another place I wrote about the journey from "Cowboy Coder to Citizen Developer". That's an apt metaphor for what I'm doing now. It's more exhilerating to ride the open range, but somebody has to round up the herd and get them into the home corral.

• Discovery followed by action. Working from a known appliction or body of code, I learned to invest the time it took for the agent to read the schema and report what it found. We both need to know if discovery squares with what I told it before it touches anything. Again, swallow your ego and reconcile conflicts out in the open. The AI is pretty non-judgemental, most of the time.

• I also learned to ask questions about what Claude was proposing. Lots and lots of stupid questions. An assertion gets deference from an AI. A question invites the contradiction you actually want.

• Context files are fluid works in progress right up until the code is real enough to check them against that code. More than once, we discovered that something we had memorialized turned out not to be true for keeps. I learned to explicitly and regularly ask if our documentation was still consistent. See my previous blog on AI memory.

I'm sure that this journey will lead to some place I can barely imagine now. AI is just that powerful. Keep on Truckin'.