Let’s talk about Claude…
There’s something fitting about this particular article being driven by AI — it’s about AI, after all, and I think the honesty of that says more than any disclaimer could. I’ve drafted this with genuine input from Claude, and it is a summary based on the work we have done together. So this isn’t about “look what AI can do”. It’s a straightforward account of what using AI taught me as I went through the process of rebuilding the BMCS site, now that I’m treating an AI assistant as a genuine part of the process rather than a novelty.
Where it’s made a real difference…
The clearest example I can give you is the CSS variable and colour architecture behind this rebuild — the system that ties category colours and portfolio-specific gradients together through custom properties. I didn’t just get handed a finished solution; I got walked through why it was structured the way it was, which meant I understood the reasoning well enough to extend it myself afterwards, rather than treating it as a job done. That’s the difference between being given code and actually learning something. It saved me a genuinely significant amount of time I’d otherwise have spent duplicating near-identical rules across colours and post types. For further context, I’ve randomly used variables in the past but it was only through this exercise that I finally realised how useful and dynamic they can be.
Caching setup was another one. It’s an area with a lot of moving parts — LiteSpeed, QUIC.cloud, conditional asset loading, all interacting with each other in ways that aren’t always obvious — and having something to reason through the interactions with, rather than guessing and hoping, made it far less intimidating and frustrating than it usually is for me. That work fed directly into page speed testing and optimisation, which if I’m honest is another task I’ve never enjoyed. Having a structured way to work through what a test result actually meant, rather than staring at a score wondering where to start, made that whole process something I could actually engage with properly instead of putting off.
The other genuinely useful engagement was investigative — digging into where Astra’s core functionality lived so I could work out what could safely be overridden through the child theme rather than touched directly. The live search customisation is a good example: rather than guessing at which files or hooks were involved, that groundwork was done collaboratively, which meant the eventual fix was targeted and safe rather than a blunt workaround. Between us, we also managed to develop a workaround on the default pagination code where the solution I was looking for did not exist in the Astra developer documentation.
Where it steered me wrong…
I want to be honest here too, because this article would be less useful without it: there were a couple of points during our chats where the guidance took a wrong turn. Usually that came down to me not giving enough context up front, and occasionally it came from an incorrect assumption being made about what I was actually trying to achieve.
A couple of examples; as part of the caching/page optimisation exercise we got into a very long chat about the the poor CLS/LCP scores that needed addressing. The CLS was resolved fairly quickly but the LCP issue created havoc. Based on the screenshots that had been requested, Claude appeared to be going off on tangents suggesting fixes that made no sense to me whatsoever – they appeared to be based more on a theory of what might need fixing as opposed to what actually needs fixing. It took several failed tests and lots of questions (from both sides) to get to something that resembled a solution. And to be upfront, the issue still exists to a degree but I have left it as something I can live with, for now.
Another chat that springs to mind was related to site analytics. I am so used to just adding Google Analytics, I rarely give it a thought. But given I have a very capable AI assistant, there was no harm in asking a question about alternatives. Whilst all very informative and useful, the final recommendations were taking me down a path I did not want to go. It wasn’t until I said “NO, that’s not for me” that it prompted Claude to take a step back and provide helpful suggestions to smooth the path I chose to take (I stuck with what I know).
Neither of those is a reason to distrust the tool. But it’s a reason to stay engaged with what it’s telling you, rather than accepting the first answer as necessarily correct.
The actual takeaway…
If I had to sum up the experience, it’s this: AI has become a genuine learning tool and sounding board for me, not just a way to skip research or writing code myself. The CSS architecture is the clearest proof of that — I came out the other side of that conversation understanding something I didn’t fully appreciate going in, not just with a working stylesheet.
But that only works if you stay actively involved. Some of the conversations I’ve had go way beyond my current knowledge level, and that’s exactly the point where it becomes tempting to just trust the output rather than ask questions and actually follow up on what the code is doing. If you’re learning as you go and you skip that step, it’s easy to end up blindly trusting your AI assistant without fully understanding the potential impact of what you’re actually applying to your site. That’s not really an AI problem — it’s the same risk as copying any code you don’t understand from anywhere else — but AI makes it easier to fall into, precisely because the answers arrive so readily and so confidently.
The habit that’s made the real difference for me isn’t just using AI and it is something I have done since childhood. It’s constantly asking why, and not moving on until the answer actually makes sense to me.
