Do I need a technical background to get good results from AI?

No. The skill that matters is describing intent precisely: what outcome you want, what constraints apply, and how you will know it worked. That is the same skill as briefing a capable contractor, and non-technical managers are often better at it than engineers.

A written, reusable set of instructions that tells an AI assistant how your organisation does a particular job. Instead of explaining your process every time, you write it once and the assistant follows it. The difference is getting a good result once, versus getting it every time.

What is the difference between a skill and a plugin?

A skill tells the assistant how you work. A plugin, or MCP server, gives it reach into the systems that hold the truth: your code, your documents, your ticketing system. Skills supply judgement, plugins supply access. Most disappointing results are missing one or the other.

Is it safe to let AI do real work?

It is safe when nothing reaches production without a human approving it. In our own delivery, AI proposes and a person decides: every change arrives as a pull request, automated checks run first, and a human merges. The AI never applies anything itself.

How long does it take to see a difference?

Writing down the standards for one repeated job takes an afternoon, and the improvement is immediate because you stop re-explaining. The larger gain, where AI does the unglamorous work around the task, follows once the checks exist.

Getting started with AI: skills, intent, and how to brief an agent

Most disappointing AI output is not a model problem. It is a missing brief and a missing set of standards. Here is what to write down, and what to check.

Why is AI output so often mediocre?

Because the assistant has no idea how your organisation works, and because most requests describe a task instead of an intent. Both are fixable in an afternoon, and neither requires a better model.

I run a delivery business on AI. It builds client websites, sets up infrastructure and writes the evidence that auditors ask for. The work is good, and none of that is because I found a clever prompt. It is because the AI is told how we work before it starts, and because nothing it produces reaches a client without a person approving it.

Here is what actually makes the difference.

Intent, not task

The most common mistake is asking for a task.

“Add a contact form” is a task. The assistant has to guess the rest: where the messages go, what happens to the data, whether you are collecting anything a regulator would care about, what the page should look like.

The intent version: “Let a prospect reach me without publishing my email address. It should store nothing we would have to protect, send to the address we already use, and match the rest of the site.”

Same length. The second one can be checked, because it says what success is.

Prompt vs brief

A one-line prompt gives the assistant nothing to check its work against, so it guesses. A brief with intent, constraints, evidence and a definition of done produces work you can hold up against what you asked for.

A good brief has four parts, and you can write one in a minute:

Intent. The outcome, and why it matters. Not the steps.
Constraints. What it must fit: the tools you already run, the rules you are held to, the budget.
Evidence. Where the truth lives. Point at the real files, the real documents, the real ticket.
Done. How you will know it worked. If you cannot write this, you are not ready to ask.

The fourth is the one people skip, and it is the one that turns a guess into something reviewable.

Skills: write it down once

If you find yourself explaining the same context every time, you have found a skill.

A skill is a written set of instructions that an assistant loads when it does a particular job. Not a prompt you paste, but a file that lives alongside the work and applies every time. Ours cover things like building a client site and setting up a new client’s content system. They encode the boring specifics: the stack, the naming, the checks, the order things happen in.

The change is not that the output gets better once. It is that it gets better every time, including when someone else asks, or when you come back in three months having forgotten the details.

Start with one job you do repeatedly and do not enjoy. Write down how it actually gets done, including the parts you would tell a new hire. That is the skill.

Plugins: give it reach

Skills tell an assistant how you work. They do not give it access to anything.

Plugins, and the MCP servers behind them, connect the assistant to the systems that hold the truth: your repository, your documents, your ticketing system, your cloud account. An assistant reasoning about your infrastructure from memory is guessing. One that can read your actual configuration is not.

The practical test: if a colleague could not answer the question without opening a system, the assistant cannot either. Give it the same access, or expect the same guess.

Where each piece sits

Four layers. The model supplies raw capability. Skills and plugins supply your way of working and access to your systems. Checks decide what is allowed through. What comes out the other end belongs to you, with the reasoning written down.

The part nobody enjoys

Everything above makes AI produce more. None of it makes the output safe.

That is the check, and it is the part I would not compromise on. In our delivery, AI never applies anything itself. Every change arrives as a proposal, automated checks run against it, and a person merges it. When something is wrong, it is wrong in a pull request rather than in production.

This matters more than it sounds. The risk with AI is not that it produces rubbish, which is obvious and easy to reject. It is that it produces something plausible and slightly wrong, which is only obvious later. A check that a person actually performs is what catches the second kind.

The loop

Brief, draft, human gate, merge. Work that fails the gate goes back to the brief rather than straight to another draft, because a rejected draft almost always means the brief was incomplete.

Notice where the rejection arrow points. When the output is wrong, the instinct is to ask again, slightly differently. That is how people spend an afternoon negotiating with a machine. The better move is to go back to the brief and work out what it failed to say, because that fix holds for every future attempt.

Where to start on Monday

Take one job you repeat. Write down how it is actually done, the way you would brief a new starter.
Rewrite your next request as intent, constraints, evidence and done.
Decide what a human must approve before anything is considered finished, and make that step real rather than assumed.

That is the whole method. Understand what is actually needed, protect it with standards and checks, and improve it because the output is yours and it keeps being reviewed. It works the same way for a €25-a-month website and for a system a regulator will inspect.

If you want a hand putting it in place, book thirty minutes. No deck, no discovery workshop.