Why Is Experimenting with Agentic Coding Challenging?

I've been asked a few times why I haven't really dived into agentic coding yet.

I already use AI regularly when developing software. I use it to generate simple pieces of code, brainstorm more complex implementations, discuss architecture, review ideas, or simply get a second opinion.

So why stop there?

Why am I still manually coding most of my projects instead of handing tasks to an AI agent?

I can think of many reasons, and some of them are probably very personal. But when I started thinking seriously about what was holding me back, most of those reasons kept coming back to one simple answer:

Cost.

And I don't mean only "AI tools cost money." That's the obvious part.

Cost affects how much I can experiment, how I learn, how quickly I become frustrated, and even how willing I am to change habits I've developed over years of writing software.

When you're trying to learn something as new and rapidly changing as agentic coding, those effects start piling up.

You have to spend money while you're still learning how to spend it

Using AI as a coding assistant is relatively simple.

I ask a question, request an implementation, review the answer, and decide whether I want to use it.

Agentic coding is different. Instead of simply answering a question, the AI may need to work through a task: inspect files, understand the project, make changes, run commands, see what failed, and try again.

That usually means more usage.

And more usage means more credits, tokens, or subscription limits, depending on the service.

The problem is that the beginning is probably when I'm going to use those resources least efficiently.

I still need to learn how to communicate tasks effectively. How much information does the agent need about my project? How much is too much? What should it be allowed to do?

Then there is all the terminology.

Models. Agents. LLMs. Tools. Context windows. Prompts. Permissions. Tokens.

You gradually realize that installing an agent isn't the same thing as knowing how to use one.

There is a lot to learn, and learning requires experimentation.

But experimentation means making mistakes.

You give too much information. Then too little. You write a bad prompt and try again. You choose the wrong tool. You ask for something that consumes far more resources than expected. You spend an hour configuring something only to discover that it wasn't really what you needed.

Normally, that's how I learn technology.

I try things. I break things. I figure out why they broke. Then I try again.

Here, however, the meter may be running while I learn.

Then cost becomes a motivation problem

Imagine buying some credits for a powerful AI coding service and deciding:

"This weekend I'm finally going to figure out this agentic coding thing."

You install the tools, connect everything, and start testing a few tasks.

Initially, it's exciting.

Then you realize you're consuming your available usage much faster than expected.

You're still learning how to structure requests, so you repeat things unnecessarily. Maybe you're providing too much context. Maybe the agent goes in the wrong direction and you spend even more resources correcting it.

Eventually, you hit your limit.

Fine. You wait.

Later, you continue experimenting, get a little further, and eventually hit another limit.

After repeating that cycle a few times, something that started as an interesting learning experience begins to feel like you're constantly watching a fuel gauge.

The analogy I keep coming back to is this:

It's like buying a Ferrari to commute but having no money for gas.

Every time you have a little money available, you put some fuel in it and finally get to drive.

It's fast. It's exciting. You immediately understand why people love it.

Then the fuel runs out and the Ferrari goes back into the garage.

Do that enough times and the Ferrari itself starts becoming frustrating.

And that's a problem when you're learning because motivation matters.

If every learning session ends because you reached a usage limit instead of reaching a natural stopping point, it's easy to associate that frustration with the technology itself.

"This is useless."

"It doesn't do what I need."

"I'll just code it myself."

Maybe those conclusions will eventually be correct.

But did I really evaluate the technology?

Or did I evaluate what it feels like to learn the technology while constantly worrying about its cost?

Learning without a clear road is expensive

The obvious solution would be to follow a structured learning path.

Take a course. Follow the steps. Learn the fundamentals. Then start experimenting.

Except there isn't one obvious path.

Agentic coding is moving incredibly quickly. Different people use different tools, models, workflows, and completely different levels of automation.

One experienced developer recommends one approach. Another seems to do almost the opposite.

And that's assuming you already understand the vocabulary.

What exactly makes something an agent?

Where does the language model fit?

What is actually responsible for reading and changing files?

What is context, and why does everybody seem obsessed with managing it?

Why are tokens so important?

How much autonomy should an agent have?

I'm not going to answer those questions here.

They're actually part of the point.

There is a learning curve before I can even evaluate agentic coding properly.

And from what I've seen, most people who are already comfortable with these tools learned the same way developers learn many other technologies:

They experimented.

They tried things, failed, changed their approach, tried again, and gradually developed a workflow that made sense to them.

But learning by experimentation requires freedom to experiment.

If every wrong turn consumes a limited resource, I start becoming afraid of wrong turns.

And if I'm afraid of wrong turns, learning becomes slower and a lot less enjoyable.

We're back to cost again.

There is another cost: changing how I work

Money isn't the only thing making me hesitate.

I became a developer because I like solving problems.

I also genuinely enjoy writing code.

There is something satisfying about understanding a problem, designing a solution, implementing it, watching it fail spectacularly, figuring out why, and eventually seeing everything work.

Agentic coding changes that relationship a little.

If AI starts doing more of the implementation, my role starts moving toward describing tasks, providing requirements, reviewing changes, finding mistakes, and deciding whether the result should be accepted.

In other words, I move a little from developer toward manager.

And I don't have a problem with being a manager.

I've worked as a manager before. I enjoy managing people and projects, discussing problems, helping people find solutions, coordinating work, and seeing a team turn an idea into something real.

But managing an AI doesn't have quite the same appeal.

There is no team to develop. No person to mentor. No discussion where somebody brings a different perspective because of their own experience. No satisfaction from watching someone grow into a role or become better at something.

I'm mostly describing a task to a machine and checking whether it did what I asked.

That can be extremely useful.

I'm just not sure it's particularly exciting.

There is also a slightly uncomfortable question hiding underneath all of this:

If the AI implemented the solution, can I really say that I built it?

Of course, software development has never meant doing everything ourselves.

We use frameworks, libraries, documentation, examples, open-source projects, Stack Overflow, colleagues, and countless abstractions built by other people.

Still, this feels a little different.

An AI agent can potentially participate directly in the reasoning and implementation that I traditionally considered my work.

I don't think this concern is always conscious.

I certainly don't sit in front of my computer thinking:

"I'm experiencing an identity conflict because an AI wrote my Service class."

It's probably much simpler than that.

Sometimes I just don't feel motivated to hand over the interesting part.

And then there is trust

Even if I accept the financial cost and become comfortable with changing how I work, there is still another blocker:

Trust.

If I ask AI to generate a small function, I read the result before using it.

If it's wrong, I fix it or throw it away.

Simple.

With agentic coding, the promise is different.

I want to delegate more.

And delegation only becomes useful when I trust whoever—or whatever—I'm delegating to.

I don't expect an AI agent to replace a senior developer. It doesn't need to.

If it could reliably handle small, repetitive tasks like a junior developer, that alone could be incredibly useful.

But there's an important word there:

Reliably.

If I give an agent a small task but need to constantly watch what it's doing, repeatedly remind it about requirements, verify that it didn't change unrelated things, and inspect every decision because I'm afraid it misunderstood something...

Maybe writing the code myself would have been faster.

That's another kind of cost.

And unlike token usage, it's much harder to measure.

It's the cost of supervision.

But trust isn't only about whether the agent makes mistakes.

It's also about understanding where I can trust it in the first place.

What kinds of problems can I reasonably delegate?

How complex can a task become before I need to break it down myself?

When can I give the agent a goal and let it work, and when do I need to provide detailed instructions?

Where does it need supervision?

And perhaps most importantly: how do I know when I've reached the limit of what the agent can reliably do?

Those are harder questions than simply asking whether the generated code works.

These blockers reinforce each other

This is why I don't think hesitation around agentic coding can simply be dismissed as developers being resistant to change.

At least that's not what it feels like to me.

The problems feed into each other.

Cost limits experimentation. Limited experimentation makes learning slower. Slow learning makes it harder to understand what the tools are actually capable of.

Meanwhile, the ecosystem changes so quickly that it's difficult to know what to learn first.

Then there is the workflow itself. Moving from implementation toward delegation changes which parts of development I'm actually doing.

And if I don't yet understand where the agent can be trusted, I compensate by increasing supervision—which reduces the productivity benefit I was trying to gain in the first place.

What I'm trying to understand isn't whether agentic coding works.

Clearly, it can work.

The question for me is how far it can go for the kinds of problems I actually solve.

Can an agent implement a small, isolated feature? Probably.

Can it understand an existing application well enough to make changes across multiple parts of the system?

Can it investigate a bug when the cause isn't obvious?

Can it make a good architectural decision when there are several technically valid options?

Can it recognize when my requirements don't make sense?

Can it stop and ask the right question instead of confidently moving in the wrong direction?

Maybe some of those things can be delegated completely.

Maybe others can be partially delegated.

And maybe some are still better handled by me.

I'm not looking for a point where the agent suddenly does everything.

I'm trying to find the boundary.

What can I delegate? What can I partially delegate? What should I still do myself?

And how do I know the difference before wasting more time supervising the agent than I would have spent solving the problem myself?

For me, that's where trust really starts.

Not trusting that the AI will never make a mistake.

Trusting that I understand what it's capable of, where its limits are, and when I should—or shouldn't—hand it the problem.

So how do I get around them?

Recognizing these problems doesn't mean I want to avoid AI or agentic coding.

Quite the opposite.

If these are the things stopping me from exploring it properly, understanding them gives me somewhere to start.

If cost limits experimentation, maybe I can find a way to experiment without paying for every mistake.

Local language models are one possibility I'm interested in exploring. They don't need to replace powerful cloud models. Maybe they can simply give me somewhere to learn, make mistakes, and understand how all these pieces fit together without constantly watching a usage meter.

If following somebody else's workflow doesn't work for me, maybe I don't need to copy it.

I can find my own path, understand the pieces gradually, and decide which approaches actually fit the way I develop software.

And if handing everything to an AI makes me feel disconnected from the solution, maybe agentic coding doesn't have to mean removing myself from the process.

Maybe I decide where the agent helps, where I review, and where I still want to make the decisions myself.

These are possibilities, not answers.

Before choosing tools, building workflows, comparing models, or deciding how much autonomy an agent should have, I want to understand what I'm actually trying to solve.

That's what this journey is about.

Not proving that AI should write all my code.

Not proving that local models can replace cloud services.

Not finding the magical prompt that suddenly makes an agent perfect.

I want to understand where these tools can genuinely help me, where they can't, and how I can tell the difference.

And maybe documenting the process will be useful to someone else trying to figure out the same thing.

Cost is where the problem started. But understanding what that cost affects is where the interesting part begins.