I’ve been working with multiple AI tools both professionally and in my own time for a while now. At home I have a personal Claude Pro account and use Gemini on the web as well as my own OpenAI developer account. I have used OpenAI to help with tasks (“You are an expert in planning activities for Scout Groups....“) and programatically in projects like the WhatsApp Party-Bot. Gemini does research for me and can help with code snippets and understanding, somtimes giving a second opinion to Claude. Claude is my main code assistant.
It’s certainly helped with rapid prototyping and iteration on a project. I was able to work on the Party-Bot, adding features and fixing things on a live system as I received user feedback. Party-Bot now has a traditional web page too, for those who don’t like the conversational UI. This was all built in hours.
Some of my working patterns
My employer uses SpecKit. This reminds me of the old days before Agile when we designed and specified projects! We turned a project around this way. My first project with Polk was a restart on a failing project. We spent weeks planning it. I developed my reputation as “A Danger With Whiteboards” due to the amount of UML that I drew on them. Management worried about time spent without any code being written, but when we wrote the code we delivered a fully functioning system in less time than the failed project had wasted. The system was also robust to change as customer requirements came in.
Agile has always been “mini waterfalls”. I like to point to pictures of Aysgarth Falls in the Yorkshire Dales. In my time leading the Foundations Team in FinancialForce (now Certinia) I’d spend the first half day or day of a sprint with those whiteboards. We’d work on specifying exactly what we were going to implement.
A beauty of this is that any questions that arose could be dealt with before we all went away and worked. Everybody knew what they were doing. I’d insist on what I consider to be “mathematically correct systems” in which we knew what the definition of the system was. Some Agile purists disagreed, wanting strict focus on the User Story at hand. We could design the system with clear contracts allowing differerent developers to split work and come together later – and it all worked in the end!
My WhatsApp Game Bot framework has reached the stage where different teams could go off and implement different subsystems all independently now – but there’s only one of me on this! I’ve been here before. “You need a team. You don’t scale on your own”. The bot can only be split because I have driven Claude to write a modular architecture. If you let it make spaghetti then you cannot factor out parts this way.
Mini-Waterfalls with Claude
Claude tends to create a SpecKit like Story structure, even without SpecKit installed. I’d have it work with me on the research and specification, using Planning Mode to help me work out and write the story. I’d then write the story file and write a planning and task list.
Writing out tasks lists allows me to start afresh in a new Claude Context. Context costs, because we’re paying for tokens. It also can slow things down, and I’ve found that if you give Claude too much information it’s more likely to go wrong. Claude has to be told to tick off tasks as it does them, or it forgets. Keeping the task list up to date allows for better recovery should the session be lost for any reason.
I switch between policing every change that Claude offers and letting it rip with a review at the end. A lot depends on how confident I am with the specification. Policing every change allows me to trigger a change in direction if I see something I disagree with. This saves a big refactor later. Letting it rip could mean not having the work quite as a I’d do it, but having something working then deciding whether to refactor or not. I’ve not had Claude go wildly wrong. It’s easier to delete a broken AI generated branch in Git than it is to tell a team member a day before the end of a Sprint to rework everything!
Habits to Change
This is how I work with humans. I ask a question even though I know the answer. With humans I may keep asking to get to the point. I want the person I’m helping to work it out so that they understand.
This wastes tokens when I’m working with an LLM. I know what I want. I should just demand it. In this case Claude came to the same conclusion that I’d already reached. This was to correct a decision that Claude had made earlier as part of a large refactor, in which it was marshalling enums across the layers. You can’t have switch statements on Game Type buried in multiple parts of the code when all that matters is that Game Type is read from the database and used to find the correct Game Strategy based on name.
Like hitting a golf ball down a course, if you’re not Tiger Woods
The AI isn’t perfect. It doesn’t do things the way I would. But then am I perfect? Definitely not! Development of any system is iterative. I like to think of it like hitting a golf ball down the range. I’m not particularly good at aiming golf balls so I’ll hit off to the side a few degrees or tens of degrees, but the aim is roughly right and I’m moving forward at every stage. I then need to go find the ball and hit it again trying to correct.
The Dynamics of Refactoring
One of the fundamental promises with Agile Development is that we can refactor. The idea is that we must spend time collecting the technical debt that we accrue. Ideally we should allocate time to keeping on top of this and maintaining the system. This is hard to do in a business environment that is always under pressure to deliver. The business wants features. Refactoring is not feature delivery.
Not refactoring is false economy. The system degrades such that working on it becomes slower and more expensive. A good system with good separation of concerns, sensible dependencies, SOLID design is easier to work on. I’m trying to keep the Game-Bot this way because time spent making that foundation allows for faster iteration down the line. If the foundation is good then all I need to do is write the new feature business logic or the new Web presentation layer. I think Party-Bot is going to become primarily a web interface built on top of the same Domain and Business layer as its WhatsApp incarnation.
As Foundations Team leader I kept “Richard’s Red Refactor List” of things I wanted done to maintain the system. We allocated time, sometimes a whole sprint, to clear that list. This kept a system that was easier to work on. Nowadays we have a Technical Backlog in JIRA and pull technical stories into the sprint as needed.
Claude makes refactoring cheaper than it was. Will that still be the case when Claude has made delivering features cheap? I think this will level out. In a team situation we’ll still be potentially disrupting work for a large refactor, so the task of coordinating in a team remains. Claude does remove a lot of the grunt-work – the rippling of change through the codebase if you change a low level interface that everything depends on. (Back in my Java days I found Eclipse’s refactor tools were great for this. I’ve not seen anything comparable in any other IDE since.)
Currently, for this sole developer, refactoring is cheap – or relatively cheap. There’s still an Opporunity Cost…
The plight of the Junior Developer?
£18 per month for Claude Pro is significantly cheaper than a junior developer! This cannot be denied and its impact on the industry is going to be profound.
Claude still needs guidance. My job remains safe – for now. Perhaps it always will, or will for long enough for me to reach retirement, because a fundamental need in software engineering is to nail down requirements. User wants are often fuzzy. Computers, even Claude, need definite rules to determine what the system must do. They need that “system definition”.
So what happens when all the seniors retire? Who will take our place? Who will have learned the ropes and gained the experience? Who will be able to tell Claude it’s made a massive security hole or be able to drive it towards laying out that scalable system with its well designed components?
Maybe AI is just the next Industrial Revolution or Communications Revolution. I lived through the 90s and saw the last one. We take the web for granted now – it’s such an invisible part that underpins so much that a UK political leader once pondered whether the state should be as responsible for ensuring access as it currently is for roads.
Maybe the next junior developer will be someone entering the workplace ready to use the new tools, as a past engineer may have entered the workplace ready to use a CNC machine tool (or MATLAB for the kind of stuff I studied). AI is an automation. Improvements in tooling for the physical world have increased scale. Consider the robotic warehouses we see now. But automation also impacts jobs.
I think the biggest question is whether demand will keep up with increase in supply, as software engineers become capable of doing more in less time.
Leave a Reply