What the world needs, I thought, is for someone who hasn’t been a professional coder for several years to write their thoughts about coding with an AI assistant.

I realise that is a silly concept, but… as a senior manager what I can say is that I am increasingly being challenged to say “why aren’t my teams using AI more” with all the concomitant magic reductions in costs which must inevitably follow. I hadn’t had the chance to do more than “play” with AI coding assistants but for the last few weeks I have had the chance to fix that. And I have thoughts. 

I’ve been using ChatGPT, Github CoPilot, but most extensively Claude from Anthropic. 

The Good

First of all the tooling itself is developing really fast, Even in the last few months the integrations with VS Code (for example) have moved on in leaps and bounds. The pattern I have settled into with Claude is to have it running in a terminal session, while having my own VS Code open for the same project, database server and everything else in other terminal sessions. It separates things out nicely so I can keep an eye on what’s going on. 

If you have very specific, small scope tasks then there is no doubt Claude can help you move very quickly relative to writing code yourself. The example I’ll give is improving test coverage on an old code base. I asked Claude first to tell me what the test coverage was, and then to create a plan for how to improve it. Then we took a series of steps to increase coverage file by file in the repository. I learned quickly that if you make the request too open ended or not specific enough then mistakes will begin to creep in quickly. 

But the end result was good. I had reasonably well written, understandable test cases that even caught some extreme edge case bugs in this code which has been running in production for years. I was impressed. 

The Bad

Now, I mentioned that this code has been running in production for years. You can imagine that it’s beginning to show its age. I wanted to improve the way in which we talk between the application and the database layer so that we can use more modern (and thus faster) query techniques. So I asked Claude to help me re-architect the connection pooling approach that has been implemented. Again I asked for it to create a plan (which it does in the form of a structured Markdown document which it keeps up to date when it compresses the session) and then we began to work through it together. 

Initially I was impressed, the plan seemed sound and the first edits were roughly what I’d do. But things quickly went off the rails. I suspect I wasn’t specific enough but soon entire files were being deleted and completely re-written. A very complex security model at the core of the application was removed “for efficiency”, and there were multiple hallucinations where I was told everything was fine… it wasn’t dear reader.

I reached the low point when Claude started asking permission to issue git commands which would have reverted to PRs submitted several years ago. 

The Ugly?

And I suspect the obvious conclusion is that we shouldn’t use AI coding assistants.

I couldn’t disagree more. 

What has become more and more clear to me as I’ve been bashing my head against this problem is that I needed to re-learn some of the best practices which I was skipping over. If I had done this work ten or twenty years ago it would have been as part of a team. We would have written user stories to define exactly what it is that should happen and break those requirements down into small, testable pieces of work. 

If I think of Claude (or whichever assistant you choose to use) as a junior engineer in my team, and give it very small, specific tasks then I can use it to its best advantage, which in my opinion is, to do the boring grunt work that I don’t find interesting. And then when it submits a PR, you can be very sure that I will pore over every single line to make sure it’s not doing anything silly.

But this is stuff we should be doing in our teams anyway. So Claude could very well accelerate your development lifecycle. 

Conclusion

So where does this leave us? I think there’s a big “but” which is pretty obvious, and still lacking a good answer. 

If we come back to the work I was asking Claude to do, it did a reasonable job at the simple stuff and then completely ripped apart the complex heart of the code base. I worked on that code base, and that way of thinking for many years and it is (to massively understate it) non trivial in its complexity and richness. How does the next person come along behind me build the levels of expertise and experience required to be able to know that Claude has gone completely rogue when it confidently asserts that it has made everything great?

I know these problems will be solved, but to come right back to the here and now, and the challenges laid down to senior managers… yes you absolutely can and should be using AI assistants, but that doesn’t mean you can get rid of your highly skilled engineers – they are needed to make sure your quality remains. Likewise you need junior engineers if you are thinking more than three years into the future. It does mean you might be able to deliver some features faster though, and that’s never a bad thing. But at the same time you need to be thinking about your talent pipeline 

This famous code comment springs to mind:

/** You may think you know what the following code does.
* But you dont. Trust me.
* Fiddle with it, and youll spend many a sleepless
* night cursing the moment you thought youd be clever
* enough to “optimize” the code below.
* Now close this file and go play with something else.
*/ 

In six months time, I suspect this moment in time snapshot will be out of date, so let’s see where we end up on 2026 and beyond.