How I Actually Work With AI as a Developer

There seem to be two camps when it comes to AI.

One side thinks it is going to destroy everything, take jobs and make developers irrelevant. The other side thinks it is the greatest thing since sliced bread, and that anyone can build software now because they have AI tools.

I think it depends where you are sitting.

Some people find it easy. Some people find it difficult. Some are completely against it, and some are deep into agents, models, automations and AI coding tools.

For me, it has changed the way I work completely.

I am not saying my way is right or wrong. I have just found a way of working with AI that suits me, and this article is about that way of working.

How I Got Here

I did not learn development through the traditional route.

I did not go to university and study computer science, and I do not learn well from textbooks either. I can read enough to understand the basics, but then I want to get in, build something, break it and try and work out why.

Most of what I know came from solving problems for clients.

A client needs something. I research it, find examples, read the documentation, look at other people’s code, try things in a test environment, and eventually build a solution that works.

For a long time I felt a bit like a fraud, because I did not come through the traditional development path. People used to say things like, ‘if you use Stack Overflow, you are not a real developer’.

I used to care about that. I don’t anymore.

I solve development problems for clients. I build things, I maintain them, and I fix them when they go wrong. For me, that is development.

Coding Is Not Development

AI can write code. Sometimes it writes code better and faster than I can.

It can generate boilerplate, explain an error, help with a function, give me a few approaches, write a starting point for a plugin, or work through something I have never done before.

That is useful.

But coding and development are not the same thing.

Development is understanding why something needs to be built in the first place. It is understanding the client, the budget, the existing codebase, the server, the team, the plugins already in use, and the person who has to maintain it later.

AI does not know any of that on its own.

It does not know why a strange decision was made three years ago. It does not know that a technically perfect solution might be completely wrong for a client’s budget or workflow. It only knows what you give it.

So it can be smarter than me and dumber than me at the same time.

On a small coding task, smarter. On the wider development decision, dumber.

AI might be a better coder than me in some cases. It is not a better developer.

How I Delegate Work

I don’t hand over a whole project and let it go wild. I don’t say ‘build this plugin’, walk away, and hope it has made the same decisions I would have made.

I look at the larger task first and break it down in my own head. Then I use AI to break those parts down even further.

A big task can become twenty or thirty smaller ones.

That might sound slow, but it means I keep track of the overall direction. I know what each task is meant to do, why it belongs there, and whether it is starting to drift.

The AI does a task, it gets reviewed, then it moves on to the next one.

I also don’t always ask it to build straight away. A lot of the time I ask for options first: give me four or five approaches, explain the pros and cons, give me your recommendation, and do not write anything until I have chosen a direction.

That is one of the most useful things I do. It gives me the chance to make the decision before there is a pile of code to untangle.

AI Needs Boundaries

I do let it work through tasks on its own, but it works inside boundaries.

I have built a structured harness around the way I work. It has rules for code structure, comments, reviews, reporting and how work gets delivered. I call it the Bishop harness, and I will go into it properly in a separate article.

The important part is that I am not asking AI to replace my judgement. I am trying to put my judgement into the process.

The harness comes out of the things I have learned building and maintaining projects: the way I want code structured, the things that usually cause problems later, the patterns I trust, and the steps that need to happen before I am happy with a piece of work.

So yes, I let it work. I just don’t let it work without rules.

An Example: My Plugins on WordPress.org

I’d wanted to write a plugin and get it onto WordPress.org for a long time. It is the example I keep coming back to, because it shows what this actually looks like in practice.

I started with a boilerplate. Not a plugin, just the shell: a set of classes, a set way of writing instructions, a set way of wording things, a documentation standard, a way of handling changelogs, and the basic tools that get installed on every project, linting and so on.

Then I built a scripting structure on top of it, so the same boilerplate can produce a free version and a pro version of the same plugin.

Around that I slowly added the per-plugin layer. Each plugin has its own signature assets and its own readme instructions, but everything underneath is shared.

The first one took a few rounds to get through the WordPress.org review process. Once it was approved I looked at translations and did 22 languages as a starting point, so every plugin now ships in 22 languages. They all use the same boilerplate, the same changelog format, and readmes that are worded almost identically. I brought in the SVN side of it as well, which is what WordPress.org actually deploys from.

That was the first plugin, and most of that groundwork was mine.

Now AI initialises the project from the boilerplate and does most of the coding inside it. Because the structure is already there, the option pages come out the same, the colours come out the same, the documentation comes out the same. I am not asking it to invent a plugin, I am asking it to work inside a system I have already decided on.

There are four plugins on WordPress.org now, and I manage all of them through that same process. I have a local environment where I install them and test them properly before anything goes out.

What I haven’t done is let it go wild and run the whole thing automatically. I am still in control of every part of it.

It Is Not Always Faster

The honest part is that this process can be slow.

There’s tasks, reviews, feedback loops, reporting, different models and context windows to manage. It can also cost more than just using a coding assistant directly.

But I have used the faster approach as well.

You ask for something. It gives you code. You try it, it breaks. You ask again, you get another answer, you change direction, you find a different problem. An hour later you are not sure whether you are still building the right thing.

That costs time and money too.

My process is slower upfront, but the quality is better. I have more confidence in what comes out, and I understand it better when I have to maintain it later.

Correctness matters more to me than speed.

The speed will improve. The tools will improve, the models will improve. I would still rather have something correct and maintainable than something produced quickly that needs rebuilding in six months.

Find Your Own Way

AI seems to be a very personal thing.

Some people want less touchpoints. They ask for the result, check it and move on. Other people want to be involved at every stage.

I am closer to the second one. I like seeing what is happening, I like getting options, I like keeping context, and I like being involved enough that I actually understand what has been built.

That might not work for everyone. Which is fine.

The main thing is to find a way of using AI that you are comfortable with. Don’t feel you have to let it run on its own because everyone is talking about agents. And don’t avoid it because you are worried about losing control.

Use it in a way that works for you.

What Has Changed

I don’t physically write as much code as I used to.

I read more code. I spend more time thinking about structure, planning tasks, setting rules, giving context, reviewing output, and making sure the work is going in the right direction.

There is a downside to that. My hands-on coding can feel a bit rusty, and I have to make an effort to keep those skills sharp.

But it has made me better at the wider part of the job.

I have to be clearer about what I want. I have to break work down properly, think ahead and make decisions earlier. I have to understand enough to review the output and take responsibility for it.

AI has not removed me from development. It has moved me further into the part where I plan, direct, review and make the decisions.