AI in your development process, not in your product

Two very different questions

"Do you do anything with AI?" has become the standard question. The problem is that it's really two questions that have nothing to do with each other, and the answer to one is "yes, a lot" and to the other "only if it really pays off".

The first question is: do you use AI to make software? The second is: is there AI in the software you deliver? They get mixed up all the time, even by people who set aside budget for it. And that's exactly where it goes wrong, because the place where AI delivers the most today with the least risk is not where most of the money goes.

By day I lead three PHP teams and in the evenings I freelance under my own name. In both roles I use AI heavily. But where I use it differs on purpose, and that distinction is the whole story.

AI in the process: the workshop

In the build process, AI is a powerful accelerator for an experienced developer. Not because it takes over the thinking, but because it takes away the boring work around it, so there's time left for the thinking.

Concretely, where it earns its keep for me:

• Exploring an unfamiliar codebase. Instead of half a day clicking through folders, I have AI map out the structure and point to the places that matter. I check, but I no longer start from zero.
• Tests and refactors. Repetitive, well-defined, and exactly where a model is strong. I write the intent, the model types it out, I'm the final editor.
• Data migrations and one-off tooling. Throwaway scripts that have to run perfectly once; set up fast, checked critically.
• Bigger jobs with agents. Work you can split into parallel subtasks I hand to several agents, while I stay the coordinator and the conscience.

The common thread: the value scales with your judgment, not the model's. A senior who knows how it should be done uses AI as a lever. A junior who can't judge the answer uses it as a crutch, and builds something wrong faster. AI in the process makes good developers faster; it doesn't make weak code good by itself.

And yes, I'm honest about the limits. The model makes up nonsense with confidence, it doesn't know your domain, and it has no idea what happens in production when things go wrong. That's why nothing gets through without review. But within that boundary the gain is huge and the risk low; if something goes wrong, it happens on my screen, not at the client's.

AI in the product: what the client gets

As soon as a language model ships in what you deliver, everything changes. The mistake then happens not on my screen but with the user, and the user has no review step. The bar is much higher there, and the honest question is usually not "can we?" but "should we?".

A lot of "AI features" in small and medium-sized businesses are a chatbot slapped onto everything. That rarely adds value and almost always adds risk: wrong answers in a confident tone, cost and latency per request, and a user who starts distrusting the company after a single hallucination. An LLM in your product isn't a feature, it's a responsibility.

When it does make sense, I build around it instead of relying on it:

• The human has the final say. In Mithril, AI pulls action items and decisions out of a meeting, but always through a review screen; nothing becomes true on its own.
• Generate, don't decide. In Aura, the model drafts SEO texts, but the owner approves them and can overwrite them. The AI does the typing, not the judging.
• Safety nets and honesty. Fallbacks for when the model is down, an interface that shows uncertainty instead of hiding it, and determinism where it has to be.

The underlying rule is the same one I build all my plugins by: the unpredictable part belongs behind a tight, tested boundary. An LLM is the unpredictable part, par excellence.

Why this distinction saves money

For small and medium-sized businesses this isn't philosophy but arithmetic. A lot of budget is being burned right now on product AI that adds risk without demonstrable return, while the safe and big win lies elsewhere: building faster and cheaper with AI in the process.

So when a client asks "can we do something with AI?", my first answer is usually not a feature but a question back: which problem are you solving? Often the honest outcome is that we keep the product simple and leave the AI in the workshop, where it brings the build time down. That's less exciting to brag about, and worth a lot more.

That's exactly why my first answer to "do you do anything with AI?" is a conversation rather than a demo. Not every question deserves a language model; some just deserve good, boring code that keeps working.

Where I draw the line

In short: in the workshop I'm aggressive with AI, in the product I'm conservative. That seems contradictory, but it comes from the same place: respect for what the technology can and can't do.

AI in your development process makes you faster today, without your client carrying the risk. AI in your product can be great, but only if you know exactly why it's there and what happens when it's wrong. Knowing the difference between those two is, I think, what AI in 2026 is really about.