My Experience with Agentic Coding

After months of building an AI coding agent and using it in my daily workflow, I'd like to share my experience with agentic coding, and my takeaways from the journey.

It makes me work more

AI coding agents get more work done, but paradoxically I find myself working harder. When the agent is busy implementing something, I'm already thinking several steps ahead, planning the next feature or architectural change.

I've been spending more time doing work instead of relaxing. I think this happens because the short feedback loop between idea and first draft drastically reduces the initiative energy, which consequently amplifies my agency.

An analogy I'd like to make is that agentic coding is a bit like zone-2 cardio in programming. It tends to make you work long hours with moderate intensity, but the sheer volume that you and the agent accomplish together creates a compounding effect on productivity.

It feels different compared to GitHub Copilot or Cursor

When I first started using AI coding agents, I was surprised by how different the experience felt compared to using tools like GitHub Copilot or Cursor. While both types of tools use LLMs to assist with coding, they serve different purposes and have different workflows. The main difference is that AI coding agents feel more like a pair programmer, whereas Copilot or Cursor feels more like a code completion tool. The former is more hands-off - you can just let it do its thing, whereas the latter requires you to be more involved in the coding process.

When I'm talking about AI coding agents, I'm mostly referring to tools such as Claude Code, AMP Code, or Kodelet - yet another AI coding agent I'm building. Most of them have the form factor of CLI tools with very clunky and antiquated terminal UIs. But the clunkiness somehow becomes a strength because you can seamlessly compose them with other Unix commands, piping input and output, and even performing tasks like one coding agent calling other coding agents, which makes it super powerful and addictive.

In contrast, AI text editing tools like GitHub Copilot or Cursor are designed more like tab-based code completion tools. Sure, they have some agentic coding capabilities baked in, but their subscription-based model means they have to limit token usage to reduce cost-per-unit, which often restricts capabilities and context windows. For example:

1. They are wary and not eager to do any big codebase scans
2. They often only run a few turns of code generation before throwing the ball back to you, constantly requiring your attention
3. They are incapable of doing unsupervised coding
4. Their capabilities are often handicapped by the beautiful IDE UI

My work pattern has evolved significantly. Nowadays, I rarely use text editors to make code changes, but rather use them as code viewers for the changes that agentic AI coding agents have made. I'm doing more code review and providing feedback than writing code myself. In fact, two weeks ago I cancelled my £20/month Cursor subscription because despite its unmatched code autocompletion capability, I found myself rarely using these features, only using these powerful tools as a bare minimum text viewer.

It is super addictive

My usage pattern with LLMs has become somewhat addictive. Sometimes they generate genuinely fascinating and novel solutions, but more often they create seemingly right but practically wrong solutions. The variation in quality makes it more addictive - sometimes I'm craving good results, which leads to increased usage.

The typical experience is having the urge for "one last prompt" at 11pm before bed. But more often, the coding session extends to two or three hours, and I end up going to bed at 1am. This is how addictive it can be.

I started to become "lazy"

In terms of pure typing and programming, AI agents generally make me lazier. Nowadays, if I need to shuffle files around and change function signatures, I'd rather spend 20p asking my agent to do it for me. Subconsciously, I know doing these mundane jobs requires me to pull the repo, checkout a branch, do lightweight coding, push changes, and raise a PR - which makes me tired to even think about it.

I genuinely believe these tasks are counterintuitively just busy work that makes you less productive. You might argue it's unhealthy and over time makes me unskilled and uncompetitive, but generally, if there's a tool that can make you lazy, you'd always opt for it.

Vibe coding doesn't make the cut

As I mentioned earlier, AI coding agents can produce fascinating results, but more often than not, their first draft solutions are either crap or seemingly impressive but practically wrong, which is understandable - no one can come up with a perfect architecture, design or solution on the first try.

One of my other observations is that in the large codebase, models such as Sonnet 4 and Opus 4 often produce suboptimal quick wins rather than maintainable solutions. My hypothesis is that these models are trained on coming up with quick solutions in limited turns during RL.

As a result, if you go entirely hands-free vibe code the solution without looking into the code AI produces, understanding what it's doing, or thinking whether it makes architectural sense, the codebase can rot and become unworkable very quickly.

My advice for agentic coding is that you need to have a clear and decisive stance on what you like and what you don't like. If you see anything produced by an AI coding agent that violates design or coding principles, call it out immediately rather than let it snowball.

Coding agents, particularly those powered by Anthropic Claude models, are very receptive to your suggestions. They're like obedient interns - if you call out things you're not satisfied with, they'll go off and improve the work without complaint. You don't need to feel bad for constantly nudging AI to do better.

When it comes to prompting, vigour beats technique

You probably have already seen countless posts on the internet about "10 prompting techniques every engineer should know". In reality, when it comes to agentic coding, the majority of these tricks have become irrelevant in the past few months. Thanks to the advancements in the model itself, the majority of current frontier models have interleaved thinking capabilities built in, so they are perfectly capable of reasoning through complex problems without the need to teach them. Instead of prompting techniques, what really matters is to provide the LLM with:

• A clear requirement of what you want to achieve.
• Relevant context for the problem statement.
• Some examples of what you want the user/application interface to look like.
• Specific architectural decisions that you have made or prefer.
• Edge cases that you want the agent to consider.
• Conventions that you want the agent to follow.

It might sound like a lot, but practically all you need to do is to just "chat away" with the agent and be as extensive as possible. Remember the end goal is to set the agent up for success, so that it can produce the best possible solution for you.

Context management is an art

One of the most important aspects of agentic coding is context management. The current frontier models have a context window of around 200k tokens, which is a lot, but certainly not infinite. As a result, you need to be very mindful of the amount of information that has been fed into the model.

Speaking from my experience, I learned these techniques through practice. I believe everyone will develop their own intuitive way of managing context. Here are some of my techniques:

1. Iterate architecture design and implementation in separate sessions, so that they use two separate context windows.
2. When doing large code refactoring, try to divide the work into independent tasks and give each task to a separate subagent. By doing so, each task can use a separate context window instead of bloating the main agent's context window.
3. Pay close attention to the context window usage. Always prefer to wrap things up in a markdown file so that you can start fresh again, instead of letting it auto-compact or let the context rot.
4. Generally try to decompose a big task into smaller chunks.

Dev environment and tooling matters

Having a working dev environment setup, tests, linting, namespace hierarchy and consistent coding styles and conventions to follow is beneficial for human developers, because it essentially provides a closed feedback loop for your coding practices. After all it's hard to strive in a dev environment where tests are broken, linting is not enforced, and code styles are inconsistent.

This is also applicable to AI coding agents. The more consistent and predictable your codebase and practices are, the better the agent can understand it and produce high-quality solutions.

graph TB
    A((Plan)) --> B((Implement))
    B --> C((Validate))
    C --> A

    style A fill:#e1f5fe,stroke:#01579b,stroke-width:2px
    style B fill:#f3e5f5,stroke:#4a148c,stroke-width:2px
    style C fill:#e8f5e8,stroke:#1b5e20,stroke-width:2px

Let agent do what it's gonna do

Before using AI coding agents, when I was still using cursor, my approach, like many other fellow programmers, was to carefully curate the workflow and only let AI take baby steps and take over whenever it makes trivial mistakes.

To be honest the hands-on approach works pretty well with Cursor and Copilot, as the workflow is designed to have you constantly engaging. But after switching to AI coding agents, I found that this approach is not only unnecessary but also counterproductive.There are several reasons that you should not intervene:

1. The AI Agent has its own flow, if it does anything slightly wrong or had bad assumptions, chances are it will figure it out a few turns later and correct itself.
2. Whenever you interrupt and make file changes, you actually create a parallel version of the codebase. As these models probably do not have "intervene" in their training dataset, they probably either aren't aware of the changes you made, or down the line get confused and always thought you made the changes and have second guesses.

Now my approach has completely shifted to being more hands-off. I throw carefully crafted prompts and just let the agent do what it's gonna do. When AI agents make mistakes, I tend not to intervene by writing code myself, but instead nudge them toward the right direction.

AI coding agents are good at much more than coding

Right now I'm predominantly using coding agents for coding. But one thing many people don't realise is that they're very good at other tasks. For example, I also use them for system administration tasks and DevOps work. They're excellent at infrastructure as code and troubleshooting problems.

They have other interesting use cases too. These coding agents come with web-fetching tools, so I often ask them, "What are the top 10 news stories on BBC and GB News? Give me the titles and links." They'll come back with a quick snapshot of what's happening today.

I've also seen people on the internet using Claude Code doing bookkeeping which is truly amazing.

This blog post actually comes from transcript I've been recording from dictation over the past two months. Today when I decided to produce this blog post, I simply dumped the transcript to kodelet and asked it to write MkDocs-based documentation. It figured out how MkDocs works and produced it in the desired markdown format. All I needed to do was the remaining 20% minor tweaking after the agent created the first draft.

I genuinely believe that we, as programmers, are the first wave where AI is being innovative in our field. This use case is going to affect other fields as well.

Your experience in software engineering still matters

As capable and knowledgeable as current frontier models are, they're still largely trained in a reinforcement learning vacuum, meaning that they simply don't have real-world experience and scar tissue like us homo sapiens. If you're an experienced software engineer, the skills you've developed over the years are not wasted. When AI goes off the rails, you can use your ability to put it back on track, which requires expertise in software design, architecture, and problem-solving.

For junior engineers, despite many people suggesting that AI will entirely break the career pipeline, I think it's actually a blessing to juniors, as they can learn at a much faster pace because of the pure knowledge these AI tools provide. It almost elevates juniors to mid-level capabilities that would otherwise take many years to develop.

At the end of the day, it's just a tool

Many folks would argue: but it's not AGI! The truth is, neither do I think it is, but who cares! At the end of the day it is just a tool that can make me 3x more productive and take on tasks that I would otherwise not be able to do. Like any other power tool, it is not intuitive, and it takes time to get good at it. The key is finding the right balance - leveraging AI's agentic coding ability while maintaining our critical thinking, architectural judgment, and engineering principles.

I genuinely believe the future isn't about replacing developers with AI, but us becoming more effective by adopting the power tool.