Article •
Claude Code, Agentic Coding, and Getting the Juice Out of the Lemon
Agentic coding, not so much a hype term
By now, I am sure we have all heard the words: agentic AI, AGI, your jobs are all in danger, and every other dramatic phrase currently being fired out of the tech cannon.
There is, admittedly, a lot of hype.
But beneath the noise, some genuinely game-changing tools have come out over the last year. One of the biggest, in my opinion, is agentic coding.
Or, to put it less professionally:
Vibe coding grew up, got a job, and started opening pull requests.
Agentic coding is the use of AI coding agents that can do more than just answer questions or generate snippets. You give them a goal, context, and access to tools. They can inspect a codebase, edit files, run commands, debug errors, read logs, use documentation, interact with connected systems, and iterate toward a working result.
The standout tools for me so far have been Claude Code and Codex. I am sure there are others worthy of attention, but these are the ones I have spent the most time with.
Claude Code in particular has changed how I think about software work.
There is a lot one could write about here, and I am sure much smarter people already have. But my biggest takeaway is this:
Skills + MCPs + understanding your own workflows is a crazy unlock.
What do I mean by that?
First, /Skills.
A Skill is basically a packaged set of instructions for the AI. The point is to notice a task you keep re-prompting Claude for and turn that into something reusable.
Instead of repeatedly saying:
You package that context into a Skill so Claude knows how to behave automatically.
That saves tokens, time, and mental energy. More importantly, it turns your own repeated patterns into infrastructure. I imagine there is already some strange little skill economy growing somewhere on the internet, with people trading “how I work” files like Pokémon cards.
Then there are MCPs.
MCPs are essentially connectors that give Claude access to tools and systems: Google Drive, Jira, n8n, GitHub, databases, internal docs, whatever your workflow needs.
This is where things start getting slightly ridiculous.
Recently, I was able to tell Claude something like:
That is not a normal sentence to say to a computer.
It could look at the ticket, understand the task, inspect the workflow, connect the necessary Google Sheet, and help me move the work forward. Stuff that would normally involve a few annoying little context-switching loops suddenly became one continuous thread.
That is the real magic, I think.
Not “AI writes code now, therefore developers are dead.”
More like:
AI can now sit inside the workflow.
It can move between the task, the code, the docs, the data, the automation, and the deployment process. It can help close the loop.
But there is a catch.
You still need to understand what you are doing.
Not perfectly. Not at senior engineer level. Not “I built Linux from scratch” level.
But you do need a decent understanding of the technicalities. You need to know enough to tell when the AI is being clever, when it is being useful, and when it is simply larping.
And more than that, you need clarity of thought. This is something I have seen the strongest examples of at work
I should be clear: the people I am thinking of are technical. Very technical, in some cases.
But I do not think the reason they get so much value out of AI is simply because they know more syntax or have more tools. That helps, obviously. But it is not the whole thing.
The real difference is clarity of thought.
They know how to break a messy problem into pieces. They know what context matters. They know when an answer is hand-wavy. They know how to test assumptions. They can tell the difference between “this sounds impressive but not quite feasible” and “this actually solves the problem.”
There is probably a strong overlap between people who become technically strong and people who develop that kind of thinking. Technical skill rewards precision. Debugging rewards patience. Good engineering rewards the ability to hold a system in your head and reason through it.
So yes, they are technical.
But the juice does not come from the technicality alone.
The juice comes from the way they think.
AI seems to amplify that. If your thinking is vague, the AI gives you vague magic. If your thinking is clear, the AI becomes a very strange and very powerful extension of that clarity.
That, to me, is the actual skill gap.
Not just:
But:
Can you say what good output looks like?
Can you give it the right context?
Can you spot when it is wrong?
Can you validate the result?
Can you understand the workflow well enough to automate it?
That is where the leverage is.
Agentic coding rewards people who can structure ambiguity.
And honestly, that makes the whole thing feel less like “AI is replacing work” and more like “AI is changing the shape of work.”
You still need taste.
You still need judgement.
You still need domain knowledge.
You still need to understand the business process.
You still need to validate the result.
The agent can ride far, but someone still needs to hold the reins.
And maybe the best part is that it is also just really fun!
There is something game-like about it. You give the agent a quest. You equip it with tools. You improve its instructions. You unlock better workflows. You watch it fail, adjust, retry, and eventually get somewhere useful.
So my current feeling is this:
Agentic coding is no longer just a hype term. It is quickly becoming part of the world we actually work in.
The people who benefit most will not necessarily be the people who know the most syntax. It will be the people who understand their workflows deeply enough to explain them, automate them, test them, and improve them.
Which is incredibly exciting
Anyway.
The horse is already running.
Might as well learn the reins.
Peace out, dear reader.
There is, admittedly, a lot of hype.
But beneath the noise, some genuinely game-changing tools have come out over the last year. One of the biggest, in my opinion, is agentic coding.
Or, to put it less professionally:
Vibe coding grew up, got a job, and started opening pull requests.
Agentic coding is the use of AI coding agents that can do more than just answer questions or generate snippets. You give them a goal, context, and access to tools. They can inspect a codebase, edit files, run commands, debug errors, read logs, use documentation, interact with connected systems, and iterate toward a working result.
The standout tools for me so far have been Claude Code and Codex. I am sure there are others worthy of attention, but these are the ones I have spent the most time with.
Claude Code in particular has changed how I think about software work.
There is a lot one could write about here, and I am sure much smarter people already have. But my biggest takeaway is this:
Skills + MCPs + understanding your own workflows is a crazy unlock.
What do I mean by that?
First, /Skills.
A Skill is basically a packaged set of instructions for the AI. The point is to notice a task you keep re-prompting Claude for and turn that into something reusable.
Instead of repeatedly saying:
“Please write this in our format.”
“Please follow this structure.”
“Please remember these rules.”
“Please handle this workflow this specific way.”
You package that context into a Skill so Claude knows how to behave automatically.
That saves tokens, time, and mental energy. More importantly, it turns your own repeated patterns into infrastructure. I imagine there is already some strange little skill economy growing somewhere on the internet, with people trading “how I work” files like Pokémon cards.
Then there are MCPs.
MCPs are essentially connectors that give Claude access to tools and systems: Google Drive, Jira, n8n, GitHub, databases, internal docs, whatever your workflow needs.
This is where things start getting slightly ridiculous.
Recently, I was able to tell Claude something like:
Go to Jira, check my tickets, look at the related n8n workflow, inspect what still needs to be done, and continue working.
That is not a normal sentence to say to a computer.
It could look at the ticket, understand the task, inspect the workflow, connect the necessary Google Sheet, and help me move the work forward. Stuff that would normally involve a few annoying little context-switching loops suddenly became one continuous thread.
That is the real magic, I think.
Not “AI writes code now, therefore developers are dead.”
More like:
AI can now sit inside the workflow.
It can move between the task, the code, the docs, the data, the automation, and the deployment process. It can help close the loop.
But there is a catch.
You still need to understand what you are doing.
Not perfectly. Not at senior engineer level. Not “I built Linux from scratch” level.
But you do need a decent understanding of the technicalities. You need to know enough to tell when the AI is being clever, when it is being useful, and when it is simply larping.
And more than that, you need clarity of thought. This is something I have seen the strongest examples of at work
I should be clear: the people I am thinking of are technical. Very technical, in some cases.
But I do not think the reason they get so much value out of AI is simply because they know more syntax or have more tools. That helps, obviously. But it is not the whole thing.
The real difference is clarity of thought.
They know how to break a messy problem into pieces. They know what context matters. They know when an answer is hand-wavy. They know how to test assumptions. They can tell the difference between “this sounds impressive but not quite feasible” and “this actually solves the problem.”
There is probably a strong overlap between people who become technically strong and people who develop that kind of thinking. Technical skill rewards precision. Debugging rewards patience. Good engineering rewards the ability to hold a system in your head and reason through it.
So yes, they are technical.
But the juice does not come from the technicality alone.
The juice comes from the way they think.
AI seems to amplify that. If your thinking is vague, the AI gives you vague magic. If your thinking is clear, the AI becomes a very strange and very powerful extension of that clarity.
That, to me, is the actual skill gap.
Not just:
Can you code?
But:
Can you explain the problem clearly enough that a very powerful, very literal, slightly insane machine can help you solve it?
Can you say what good output looks like?
Can you give it the right context?
Can you spot when it is wrong?
Can you validate the result?
Can you understand the workflow well enough to automate it?
That is where the leverage is.
Agentic coding rewards people who can structure ambiguity.
And honestly, that makes the whole thing feel less like “AI is replacing work” and more like “AI is changing the shape of work.”
You still need taste.
You still need judgement.
You still need domain knowledge.
You still need to understand the business process.
You still need to validate the result.
The agent can ride far, but someone still needs to hold the reins.
And maybe the best part is that it is also just really fun!
There is something game-like about it. You give the agent a quest. You equip it with tools. You improve its instructions. You unlock better workflows. You watch it fail, adjust, retry, and eventually get somewhere useful.
So my current feeling is this:
Agentic coding is no longer just a hype term. It is quickly becoming part of the world we actually work in.
The people who benefit most will not necessarily be the people who know the most syntax. It will be the people who understand their workflows deeply enough to explain them, automate them, test them, and improve them.
Which is incredibly exciting
Anyway.
The horse is already running.
Might as well learn the reins.
Peace out, dear reader.