Why AI Clicked for Me

There’s a strange divide when people talk about AI.

Some people are completely sold on it. Some say it’s useless. Some say it’s going to replace every developer. Some say it can’t be trusted with anything important.

I understand all of those reactions.

I’ve seen AI do genuinely impressive work. I’ve also watched it confidently do the wrong thing, invent facts, miss the obvious, get stuck in loops, and produce code that looks perfectly plausible right up until you have to run it or maintain it.

But AI works for me.

That’s the part that matters.

Not because I think it’s magic. Not because I think it’s smarter than everyone else. And definitely not because I hand it a task, walk away, and assume the result will be right.

It works for me because I’ve gradually built a way of working with it that fits how I already solve problems.

AI isn’t a replacement for how I work. It’s an extension of it.

I Never Learned in the Traditional Way

A lot of my friends from school ended up in IT. We went in different directions: CTOs, system administrators, developers, infrastructure people, and people working on the marketing or business side of technology. Between us, we cover a decent stretch of the industry.

I started in web design in the 1990s, early enough that the web still felt like a different thing entirely. I left that part of the industry for a while around the dot-com boom. There was a huge amount of competition, and I moved back towards systems administration.

Eventually I came back into web work, and then into WordPress development. That became the place where most of my experience joined up: websites, hosting, servers, client work, maintenance, PHP, plugins, WooCommerce, and the practical side of running systems that people actually depend on.

Here’s the thing though. I have never really learned in the textbook-first way.

I don’t read a book from cover to cover, finish a course, and then feel ready to use the thing. I start with a real problem. Something needs to work. A client needs an answer. A server is unhappy. A plugin needs to do something WordPress won’t do out of the box.

Then I research. I read documentation. I look through examples. I test ideas. I break things. I fix them. I carry the useful parts into the next problem.

That’s how I built my skills.

For a long time, that made me feel like a bit of a fraud. It’s easy to assume everybody else took a cleaner route through technology: formal training, a proper computer science background, a list of things they can quote from memory.

Eventually I stopped thinking that way.

A client doesn’t hire me because I can recite the answer before I start. They hire me because there’s a problem that needs solving. I investigate it, work through it, deliver something useful, and move on.

That is real work.

When AI started getting louder, I watched it with interest, but I was also sceptical.

At first I used it the way most people do: generally. I experimented with prompting. I asked questions. I tried bits of code. Some of it was useful. Some of it was rubbish.

And there was so much noise around it. It was going to steal every job. It was smarter than everyone. It was dumber than everyone. It was either the future of all work or a fancy autocomplete that would be gone in a few years.

So I stopped listening to most of that and made two assumptions instead.

AI is probably better at coding than I am.
AI is also dumber than I am.

Which sounds contradictory. That’s exactly the point.

AI can hold an enormous amount of syntax, patterns, library knowledge, and implementation options in its head at once. It can produce a first pass quickly. On a narrow coding task, it’ll often write something faster than I can from scratch.

But it doesn’t have the lived context around a problem. It doesn’t know the client. It doesn’t understand why a strange decision was made three years ago. It doesn’t know which shortcut is fine in this project and which one turns into a support ticket six months from now.

And it doesn’t have that instinct developers build up over time: the feeling that something is going to behave badly before you can properly explain why.

It can be better at coding than me without being better at developing than me.

That changed everything.

Coding Is Not the Same as Developing

I think this is where most people get stuck with AI.

They hand it a big, vague instruction and expect it to behave like a complete senior developer. It gets something wrong, so they decide the whole thing is useless. Or they get one decent result, assume it can do anything, and start letting it make decisions it has no business making.

Neither approach works for me.

Coding is only one part of development.

Development is also understanding what the actual problem is. Choosing the right scope. Knowing the platform. Thinking about security. Handling edge cases. Deciding what not to build. Dealing with technical debt. Reading what a client really needs behind what they asked for. Knowing when a result needs another pair of eyes.

That’s still my job.

I don’t need AI to replace me. I need it to work with me.

It can help me produce code. It can help me research, review, document, and think through options. What I don’t want is for it to pretend it understands the whole problem just because it can generate a convincing answer.

So I started thinking of it as a version of myself. Not a perfect replacement, and not a dumb tool. An extension.

Maybe it’s me 2.0.

The Balance Has to Fit the Person Using It

If there’s a real secret to working with AI, I think it’s this: find the balance that works for you.

Some people want a very human interface. They want to chat with the model, check every move, and stay close to the work.

Other people are happy to give a system more room. Send the task through, let it work, come back when there’s something worth reviewing.

Neither of those is universally right. The right way is the one that leaves you comfortable enough to actually use the tool properly.

The less control you want to give up, the closer you stay to the work. The more you want to hand off, the more structure you need around the AI before you can safely trust it with anything real.

That was the shift for me. I stopped asking how to make AI work the way everybody else wanted it to work, and started asking how to make it work the way I work.

That’s when it started being useful.

Where This Leads

That way of thinking is what eventually led me to Bishop.

Not Bishop as a single clever prompt. Not Bishop as a gimmick. Bishop as the beginning of a harness built around planning, roles, review, escalation, and context. That’s the kind of applied workflow design I want to keep developing alongside my WordPress work.

But that came later. This came first.

The moment I stopped treating AI as either a genius or an idiot, and started treating it as something I could shape around my own process.

That, for me, is the real point.

Listen to other people to understand what’s possible. Learn from their tools, prompts, models, and workflows. But don’t assume their way of working has to become yours.

Build your own relationship with it. Find the balance between human judgment and machine capability that makes sense for you.

That’s where it starts becoming useful.

In the next article I’ll get into how Bishop actually started: why a single developer agent wasn’t enough, how the first review loop got stuck, why I split the developer role into junior and senior agents, and how the first real harness began to take shape.

I Never Learned in the Traditional Way