Two Years of Building with AI - An Honest Review

I started using AI for development work in July 2024. It began the way it did for most people, with a browser tab open on ChatGPT, pasting code in and asking questions. I moved to Claude fairly quickly, and since the start of 2026 I've done most of my work in Claude Code.

That's long enough to have formed some opinions, and long enough to have made most of the mistakes.

It has changed how I work and I wouldn't want to go back. But it comes with habits you have to build on purpose, because when it goes wrong it does so quietly.

More or less everything. Finding solutions when I'm stuck, talking a problem through, chasing performance issues, diagnostics, boilerplate, implementing changes across a codebase, reviews, migrations, throwaway scripts.

Claude Code is particularly good at generating and migrating code. An Umbraco 13 to 17 migration on a large site is mostly mechanical change with a few genuinely awkward bits buried in it. AI gets through the mechanical part quickly, which leaves me free to concentrate on the parts that need judgement.

I also use it for estimating. Point it at a codebase or a brief, get it to work out what actually needs to change, and use that as the basis for a ball park figure. It'll often flag things I'd have missed, or bits I hadn't realised needed covering off in the quote. That doesn't mean I take its numbers at face value, the pricing is still mine, but as a way of making sure nothing obvious is left out of a proposal it's earned its place.

This is the one I feel strongest about. Whatever comes out of the model, your name goes on it. When a client rings in three years because something has broken, "the AI wrote it" is not an answer.

So review everything. Not line by line at the level of every null check, but enough to know what has been produced and why. Enough to explain it to somebody else and change it later without starting again. If it isn't something I'd have been happy to write myself, it doesn't ship.

I also never let AI commit. Every change gets reviewed by me before it goes into source control. The commit is where something stops being a draft and becomes part of the project history, and that call belongs to a person. It's also the last natural checkpoint in the workflow. Hand it over and you've lost the one place where you're guaranteed to actually look at the output.

You develop a feel for this. There's a point in a session where the answers get a bit too confident, or the approach starts wandering away from what you asked for. You can usually sense it before you can explain it. Trust that. Stop the run, push back, change direction. Don't let it carry on down a path just because it's already three files in.

Don't assume it's right, either. Question it. Ask it to fact check itself and show you where in the docs or the source something is defined. It will hallucinate, and it does so most convincingly in the areas you're least equipped to check.

Anything fast moving is a risk. Framework versions released after the training cutoff are the obvious one. It will invent an API that sounds exactly like something that ought to exist, because the shape is right even if the thing isn't there. Recent Umbraco versions catch it out all the time.

Which is why you still need to know your stack. You can't review what you don't understand. Knowing the frameworks, knowing how things normally behave, knowing what a red flag looks like, that's what separates using the tool from being led about by it. If something looks wrong, say so. Usually you're right.

This is what I'd warn people about hardest. It is very easy to let it take over. It's quick, it's competent, it doesn't get tired, and there's a real pull towards handing it the hard bits and just reviewing the result. Do that long enough and your own edge goes without you noticing.

So keep coding. On purpose, even when it would be quicker not to, and especially on the harder problems. Let AI do the tedious work and stay involved in the interesting work.

Your skills are your fallback. You want them there when the tool is down, or the answer is wrong, or you're somewhere with no signal and a client's site is off.

Keep the number of parallel tasks low. It's tempting to have three or four running because you can, but the context switching costs more than you gain. You end up reviewing everything badly instead of one thing properly.

Get it to save sessions to disk so you can pick them up later. Long jobs rarely finish in one sitting, and having the state written down means you can walk away, deal with something else and come back without rebuilding all the context in your head. It's a help when you return to a job a fortnight later and can't remember what you'd already ruled out.

Take time away from it. This work can get obsessive in a way normal development doesn't, because there's always another prompt and always something else you could be running. Set your own limits and switch off out of hours. It'll still be there in the morning.

When you're generating written content, tell it explicitly to use your tone of voice. Say you want natural human writing with no AI speak, no emojis, no em dashes and no bullet lists. It will still need editing, but you start much closer to something that sounds like you. Everybody can spot the default voice now and it doesn't do you any favours with clients.

The most useful thing I've done recently was attending the Effective Claude Code workshop run by Dylan Beattie and Emmz Rendle. It's worth a look if you're past the basics and want to work out what the next step is: https://claude.rendle.dev/

What came out of it for me was spec driven work using OpenSpec, and running more than one agent at a time. The idea is that you agree what's being built before anything gets written. You explore the problem, produce a proposal with the requirements and a task list, and review that rather than reviewing a pile of code after the fact. Catching a wrong assumption in a proposal takes five minutes. Catching it after it's been implemented across a dozen files takes the afternoon.

Once you've got a decent task list, handing parts of it to separate agents starts to make sense. The thing that makes it work is giving each one its own files so they aren't standing on each other, and making the instructions self contained, because they don't share your history or your context.

That might sound like it contradicts what I said about keeping parallel tasks low, but it's a different thing. Several agents working through one agreed plan is not the same as me juggling four separate conversations and half remembering what each one was doing. The spec is what holds it together. Without it you've just got more ways to generate work you'll have to unpick later.

I'm still finding my feet with it. Review discipline matters more here, not less, because it's easier to end up with volume.

I've had a few conversations with people who seem almost embarrassed about how they're using AI, or apologetic that they're not doing it the clever way. There's no need. We're all on a different journey with it, and the right approach is whichever one works for you.

If you don't have much experience behind you, it can be hard to follow what AI is generating and why. Doing it yourself will teach you it far better. Use AI for the research, get it to fact check itself, be specific about the version you're working with, then get it to review what you've written. There's no harm at all in doing the coding yourself. It's a tool. Use it to help you along and learn from it as you go.

And understanding the fundamentals matters more than the implementation detail. Knowing which way to approach something, or spotting that an architecture is heading the wrong way, is worth more than knowing the exact syntax. Some of that only comes with experience, but it doesn't much matter how you get that experience.

Give it the real context rather than a description of it. Point it at the actual files, the actual error, the actual config. Vague input gets you plausible output, which is the last thing you want.

Be careful with anything touching infrastructure or live environments. Code you can read before it runs. A command against a production server is a different matter and I always read those properly before pressing return.

Small steps beat big ones. Ask for a change, check it, commit, move on. Long unreviewed runs are where problems pile up on top of each other.

And keep a record of why something changed, not just what changed. AI is very good at producing a working fix and quite bad at leaving behind an explanation that will still make sense to you in eighteen months.

I use it constantly and my work is faster and better for it. You just have to keep checking, and never quite trust it.