Why is Agentic Coding so Tiring? An Incomplete Hypothesis

29 August 2026

When AI powered coding was in its infancy - a mere 4 years ago - with the first release of GitHub Copilot, I started to use it on a Python project or two, and I kind of found it to be a sort of Intellisense++. Despite the problems it was definitely a bit better than what had gone before, but perhaps not revolutionary.

During the mania of 2023 I was leading development more than doing development, as Savanta looked to accelerate various elements of its platform and workflows with AI - from survey design and creation, fieldwork and data collection, and then through to analysis and delivery - and most of my use of LLMs was for activities other than coding.

Fast forward to 2024 and I was working at a startup using a mix of the Claude Code agent in VS Code, and then Claude/ChatGPT chat sessions. We were also using CodeRabbit for code reviews. Honestly, it was all sort of OKish, but really not that great. But even then, I started to think maybe I understand how Welsh coal miners felt in Thatcher’s Britain in the early and mid-1980s. I felt like I was about to be made obsolete. I felt like it was the end of my career.

In reality, due to reasons I’m not going to get into here, I was severely burned out and depressed. I took most of 2025 off as a result, and didn’t do much: some DIY, helping organise a local CTO group. At the end of the year I started a fractional CTO role with another startup, which I got really into for a few months from January 2026 to help get things off the ground.

In the interim a lot had changed. AI agents had got good at coding. Not flawless, but really, really good. I remember the feeling the first time I got Claude to one-shot creation of a new feature, plus tests. It probably rolled in at 1500 lines of Ruby on Rails code, and it worked almost perfectly straight away. I found about 10 bugs, many of which were UX/interactivity issues, that needed to be fixed, but I was pretty happy.

But the bigger and more important change was in me: I wasn’t burned out and uninterested any more. I was energetic, engaged, and eager to get my teeth into something. And Claude meant that I could create as fast as I could think of what I wanted to create, or so it felt. I’d still have in my mind a clear idea of the problem and how I wanted it to be solved, but I wouldn’t have to do all the typing in myself.

And that was amazing. It really helped to reignite my passion and enjoyment of building software. I thought it was great, and I still think it’s great. But 8 months in I’ve had perhaps more time to reflect on the experience and, quite simply, had more experience.

A lot of people have talked about how agentic development can be exhausting because, with a team of people, you can create far faster than you can understand everything you need to, especially when you think in terms of keeping your architecture clean and consistent so you can continue to move forward. It’s very easy to feel incredibly productive with agentic coding on an individual level whilst, at a team level, the combined effort is creating a giant mess of technical debt at extraordinary speed.

There’s definitely something to that, and I’ve experienced it. It can feel like the real danger is with engineers who weren’t the best before agentic coding because, when you add that agent, the effect seems to be to magnify all their worst tendencies - like handing a loaded machine gun to a chimpanzee. But actually AI allows people to move so quickly that even amongst teams of very able engineers, slight misalignments can rapidly amplify. The biggest challenge in many softare organisations at the moment is probably scaling agentic developing effectively whilst avoiding those pitfalls.

I think all this does credibly provide at least a partial picture that helps answer why agentic software development can feel weirdly exhausting, but I don’t think it’s the whole story.

There are at least a couple of other reasons.

The first is entirely prosaic: agentic development is still very new. Adoption is uneven and there are still plenty of engineers out there with little to no exposure because there are still plenty of organisations who haven’t adopted any level of AI as part of their software delivery practice. As with anything new, proficiency takes effort and effort is tiring, particularly when the field keeps evolving so rapidly, necessitating further effort to keep up with that evolution.

The other reason I think is legitimately true, but I don’t know to what extent this is due to the way I personally work with coding agents versus other approachs, and therefore whether or not its a common experience.

It boils down to this: I think I find agentic coding tiring because I still have to put in the effort to solve the problem in my mind, and I have to express that solution quite precisely in English (which can take anywhere from a few minutes to an hour depending on what I’m doing), but then I don’t get the sort of meditative flow state pay off of several hours or days of coding before I have to move onto the hard thinking that goes into solving the next problem. I.e., the frequency of those hard thinking sessions has increased significantly. And it also turns out that expressing requirements precisely, so that you get the results you really want, is quite a demanding and skilled discipline in its own right as well. Whereas, of course, whilst code that will execute and deliver the expected result needs to be very precise, a lot of that precision is repetitive, and the domain specific chunks of precision are spread throughout the code generated over a long session as opposed to a shorter, more focussed writing session.

As I say, this might just be the way I use agents. I can believe that any pure vibe coder would read the above and be completely unable to identify with any shred of its sentiment.

Maybe they’re right and I’m doing it all wrong. Who knows this early in the game?

But for me the process is something like:

Understand the problem and why it’s worth solving (and picking the right problems to solve is one of the most important acts in any software business that wants to succeed).
Figure out how to solve it, which might involve picking technologies, discussing different approaches with LLMs or humans (more the former for me in recent months), and deciding how to proceed.
Prompting and building a plan with the agent: expressing with fairly high precision the desired solution to the problem. Asking the agent to come up with an implementation plan, and iterating on that plan until I’m happy with it. This can sometimes take an hour or two, and involves reviewing all the changes it’s proposing to make.
Implementation: I just let the agent run in auto mode (because I’ve already reviewed its proposed changes), and have it build out the solution plus all tests.
Testing, bug fixing: here I’m using the solution myself, making sure it works the way I want, looking for any flaws, bugs, deviations in expected behaviour, and - particularly - UX snafus that haven’t been caught by tests. Also, ensuring CI runs locally without any issues.
Push, open PR and code review: whilst Copilot is reviewing the code for me, I’ll also read through it myself and make sure all the changes make sense. This obviously is more challenging the bigger the PR. I find I can digest up to about 2,000 lines of code without too much difficulty, but beyond this I start to struggle and I’m more looking at structure of changes and where those changes are than reading every line in detail (here I’m relying on the LLM code review to spot any serious problems).
Finally, once the review stage is complete, and CI passes, then we can merge. And in my world the ideal to aim for is always green CI on main === the software is ready to be deployed to production. (Note that I said ideal: making that a reality can be a long and demanding road in many situations.)

Very rarely will I say to an LLM: this is my problem, I want you to go and solve it, without having given some thought as to how I want it solved. Occasionally, when I’m tired, and/or when I’m being experimental or exploratory and there’s not too much riding on the outcome. If the outcome really matters then I tend to keep my agent on quite a short leash in terms of decision-making and really only use it as a way to do the typing out of the solution and tests, but very quickly.

I’m glossing over a lot of details here as well: pre-commit hooks, pre-push hooks, any automated checks or scans you might perform as part of your pipeline (CI is doing a lot of heavy lifting here), traceability (a massive concern in regulated industries), security, and plenty else besides.

I know these things are important but that’s not the point here. The point here is that losing the coding part of software development does, somewhat, rob us of the meditative period of typing in code that, in some ways, I always found somewhat restorative.

Maybe it’s just a case of getting used to it. I suppose time will tell.

Filed Under

Category:Musings

Tags:ai · llms · agents · agentic-development · agentic-coding · agentic-delivery · wellbeing

I'd love to hear your views.

You can drop me a line, or write your own post and send me a link. Anything interesting I receive I'll add here.