AI integration

What the work covers

Integration is everything around the model: what text it sees, which questions it answers, what your code does with each answer, when a person steps in, and what it costs each month. I build that part for WordPress sites, WooCommerce stores and small internal workflows, starting with one job your team already does by hand.

Where it runs on this site

Two features of this site use Jev, TypeSafe AI's System One model, which answers typed questions (yes or no, one option from a list, a score) with probabilities instead of writing text. Answers like that are easy to check and to act on in code.

• The assistant on the contact and services pages. A visitor's message goes to Jev with five typed questions, and the answers choose a reply I wrote in advance, so nothing a model wrote is shown. It is capped per visitor and per day, stores nothing but a daily count, and offers the contact form with the topic already chosen once there is enough for a useful email.
• Contact-form triage. Each message gets a label (project enquiry, vendor pitch, recruiter or other) and an urgency reading in the admin. The label is advice. It never decides whether a message is kept or sent.

Tools built the same way

Update Forecast reads a plugin release's changelog and every support topic since, then says whether to update now or wait. A topic Jev is at least 70% sure about counts toward the verdict, and the rest are listed for you to read. Forum text goes only into the model's input, never into its instructions, and a topic written to steer AI readers is kept away from the model and flagged.

Sense Check applies the same split to accessibility: rules settle what is certain, Jev judges whether alt text, links and headings mean something, and anything Jev is unsure about goes to a person.

For text a model writes, HuiaHub puts five research engines behind a quality gate that rejects unsupported claims. The first run of every pipeline against live sources cost less than one cent in AI.

Earlier work with language models

I have connected Google Gemini and xAI Grok to AutoHotkey v2 scripts that rephrase text and generate code, and I run local models with Ollama and Hugging Face transformers for private tasks that stay on the machine.

How a project runs

1. Pick one workflow and measure it as it is: how many items a week, how long each takes, and how often it goes wrong.
2. Decide what the model may do alone, what it may only suggest, and what a person must approve. Anything sent to a customer, or anything that changes money or records, gets a person by default.
3. Collect real examples with personal data removed, including awkward and hostile ones, and test a few models on them before choosing one.
4. Build the smallest version that does the job, with logs, a confidence threshold, a spending cap and a switch that turns it off.
5. Run it beside the current process for two weeks and compare the numbers with step 1. Then roll it out, change it or stop.

Privacy and running costs

Before anything is connected, I write down which text leaves your site, which provider receives it, whether the provider keeps it, and who can read the logs. API keys stay on the server and never reach the browser. When text should not leave your infrastructure, a local model is an option, usually with some loss of accuracy and a hardware cost. Running costs depend on volume and on the model, so the estimate comes from your own examples.

When a rule is the better tool

If the logic can be written down (an order over a limit, an empty field, a date in the past), code is cheaper, faster and easier to test than a model. In that case I will say so and write the rule.

---

If you have a workflow in mind, tell me what it is, how often it happens and what a mistake would cost. I can tell you whether a model fits and what a first version would involve.