Here is a thought that might make working with AI feel a little less alien.

If you manage people, you already spend part of your working life asking someone else to do something that you are not going to do yourself.

You explain the outcome. You provide the context. You agree the boundaries. Then you check the work, ask questions and decide whether it is good enough.

Sound familiar?

That is also a useful way to approach an AI agent. The technology is different. Some of the management skills are not.

So when I say managers already "vibe code", that is the analogy I mean. Not that managing a person is the same as operating a machine. And certainly not that AI will make no difference to management.

I mean that you may already have more of the skills for directing AI work than you realise. You are not necessarily starting from zero.

You already know the shape of the work

Consider the ordinary management cycle: understand the problem, explain what success means, allocate the work, review what comes back, correct it and decide what happens next.

England's National Careers Service describes business project management in familiar terms: planning, organising people and resources, monitoring quality and risks, and adapting when circumstances change. That is occupational guidance, not a measurement of how every manager spends their day.

But it makes the point. The job is not defined by personally carrying out every task.

Perhaps you ask a colleague for a customer analysis. You do not check that they pressed every key correctly. You check whether they used the right information, answered the question and noticed the things that could change your decision.

With AI, I would start from the same question: what evidence would convince me that this is useful, rather than merely finished?

A small distinction about "vibe coding"

The term does have a more specific origin. In his 2025 year-in-review, Andrej Karpathy describes building programs through English while "forgetting that the code even exists".

That is not the model I would recommend for software your business depends on. Delegating implementation does not mean becoming indifferent to what has been built.

My comparison is with supervised AI-assisted work: specify, delegate, inspect evidence, correct and approve. It is a metaphor about directing work, not a claim that most managers are already programmers, or that they can safely ignore the engineering.

We should also be honest about managers who still do plenty of hands-on work. A small-business owner or a player-coach can spend the morning managing and the afternoon delivering. The title alone tells us very little.

What does the research actually support?

There is a useful foundation in research carried out before the current generative-AI wave.

Eirini Kalliamvakou and colleagues' study of software engineering managers at Microsoft distinguished engineers' ownership of implementation from managers' work on context, quality, team conditions and alignment. Technical understanding still mattered; the argument was not that managers could be technically oblivious.

That supports the distinction I am making. It does not tell us what percentage of managers in Britain or Europe write code, and it does not prove that management experience automatically transfers to AI.

More recent research looks directly at delegation. Mara Ulloa and colleagues' ICSE-SEIP 2026 product-manager study combined 885 Microsoft survey responses with telemetry from 731 of those participants and interviews with 15. Participants described being more willing to delegate lower-accountability work, while retaining responsibility for consequential outputs.

Again, this is evidence from a particular company, not a census of European businesses. But the question they were wrestling with is recognisable: what can I delegate, what must I check, and what remains mine to answer for?

A 2025 study of 319 knowledge workers described a shift towards verifying information, integrating AI responses and looking after the task as a whole. The researchers call this stewardship. These were self-reported experiences, not a controlled test of whether managers are better at using AI.

I find that encouraging. Some of the useful work around AI looks less like learning an entirely foreign profession and more like applying familiar judgement in a new setting.

Your knowledge of the business still counts

Imagine a maintenance company trying to improve the way it compares supplier quotations. This is an illustration, not a client story.

A manager may know that the lowest headline price is not always the best option. Delivery time matters. Some quotations cover different items. A missing line is not the same as an item offered free of charge.

Those distinctions are valuable when briefing an AI to produce a comparison or help build an internal tool. They tell it what the work actually means.

A vague instruction would be: "Build me a quotation system."

A useful brief would explain who will use it, which information to compare, how to show missing data, what must never be assumed and who approves a decision.

Here is how I would translate some familiar skills:

A practical skill mapping, not a validated assessment
Management skillHow I would use it with AI
BriefingDescribe the outcome, audience and what an acceptable result looks like.
Providing contextSupply approved information, definitions and relevant examples rather than expecting the agent to know the business.
DelegationGive it a bounded task with explicit permissions, limits and review points.
Quality controlCheck sources, calculations and awkward cases; arrange specialist review where needed.
Managing by outcomesMeasure accepted, useful results and the effort needed to achieve them, not just output volume.
EscalationDefine when uncertainty or a consequential action requires an authorised person to decide.

You still need to learn the tool. But knowing what matters to the business is not something to apologise for because you are not a software developer. It is part of the contribution.

Where the employee analogy breaks

An AI agent is not a new member of staff with a professional history, a colleague network and a human understanding of what it means to let someone down.

I would not assume it knows our unwritten rules, remembers a previous conversation, can access a particular document, or will reliably stop when it reaches a difficult decision. I would check what its actual system supports and make important boundaries explicit.

The UK Government AI Playbook emphasises understanding limitations, meaningful human control, security, appropriate expertise and assurance. It is guidance for government, not a certificate that a business tool is safe. Those are nevertheless sensible questions for a manager to bring to a pilot.

For software, that means someone needs to understand the implementation well enough to judge the risks. A working demonstration does not, by itself, tell us whether permissions, data handling, maintenance or recovery are adequate.

And managing people remains more than allocating work. Coaching, care, trust, disagreement and helping someone develop do not disappear because another part of the job is assisted by AI.

That is why I would say: your management experience is a useful starting point, not an exemption from learning.

Tests and KPIs still need judgement

Managers are used to asking for tests, progress reports and key performance indicators. We should bring that habit with us. But we should also ask whether the test or indicator measures the thing we care about.

For our imagined quotation tool, I would want to try a missing price, a duplicated item and two quotations in different currencies. I would want the tool to flag uncertainty, not invent a convenient answer.

Then I would ask somebody competent to check the calculation and data-handling logic. Asking the AI to write tests is useful; treating its own report that everything passed as the only evidence is not enough for me.

DORA's 2025 software-development research describes AI as amplifying an organisation's existing strengths and weaknesses. Its platform guidance points to testing, security review and deployment bottlenecks that can absorb individual coding gains. This is Google Cloud-led industry research and guidance, not a guarantee of a particular outcome.

My practical response would be to measure the whole job. Did we get an acceptable result? How long did review take? How much correction was necessary? Did the result help the person using it?

A hundred generated files are not automatically a hundred useful things. Nor is a quick first draft the same as a finished service.

This is happening in European workplaces too

A June 2026 study of two early-adopting German technology firms examined 15 interviews and workflow material. It described people retaining control through drafting, refining and reviewing AI-assisted text, rather than relying only on a final approval.

It is a small qualitative study, not evidence that all German companies work this way. It also concerns text workflows, not proof that a code-generation process is secure. What interests me is the recognisable pattern of review and correction.

For people in Britain and across Europe, I think that is a useful way into the subject. We do not have to pretend that our previous experience has suddenly become worthless. We can test where it helps, learn the gaps and involve the right colleagues.

The European Commission's AI-literacy questions and answers are a useful learning resource on understanding the systems people use and the context in which they use them. A management title alone does not establish that understanding, and this article is not a legal compliance guide.

I would like to see learning organised around real work: a small process someone understands, a bounded experiment, a clear reviewer and a conversation about what happened.

Try a small brief, not a leap of faith

Here is the sort of first experiment I would suggest, subject to your organisation's approved tools and policies.

Help me design a simple internal tool for comparing supplier quotations.

Use invented sample data only. Explain what information you need and show me your proposed structure before building anything.

Keep missing information visibly missing. Show where quotations are not directly comparable. Do not choose a supplier, contact anyone, connect to our systems, spend money or deploy anything.

Propose examples we can use to check the result, including cases that should fail or require a person to decide. Explain the limitations in plain English.

That is a learning brief, not a production specification. If you decide to turn the result into a real tool, bring in the relevant technical, security and data expertise before connecting it to business information or allowing it to act.

During the experiment, ask the questions you would ask about any delegated task: what have you assumed, what is missing, why this approach, and what would make it wrong?

Keep a note of what helped, what you had to correct and what you could not confidently judge. The last category is particularly useful. It tells you where support or learning is needed.

Confidence is not the same as blind trust

The 319-person critical-thinking study found that greater confidence in AI was associated with less reported critical thinking, while greater task-specific self-confidence was associated with more. That is an association in survey responses, not proof of cause and effect.

I would take the practical lesson as this: build confidence in your ability to question and evaluate the work, rather than confidence that the machine must be right.

There is room here for experienced managers, newer colleagues and technical specialists to learn together. Knowing the business, knowing the tools and knowing how to check a system are complementary contributions.

We should also protect opportunities for people to develop judgement. Being able to produce a result is not the same as understanding why it is right. I would want juniors practising both, with support, rather than being reduced to forwarding outputs.

The work changes. You do not start again from nothing.

I would not promise that AI leaves management unchanged. It can change what managers build themselves, what they delegate, how teams work and where review becomes the difficult part. None of the research here guarantees a job title or predicts that every organisation will need the same structure.

But I would push back on the idea that a manager has nothing useful to bring until they have become an expert programmer.

If you know how to explain a problem, set boundaries, challenge an assumption and recognise when you need expert help, bring those skills with you. Then learn what is different about this particular tool.

That is the confidence piece I want for Britain and Europe. Not "nothing will change". Not "trust it and hope". Instead: you have useful experience; now put it to work while you learn.

You do not have to carry out every task yourself. You do need a credible way to judge whether the work is right.

Illustrative management loop: brief the outcome, delegate within limits, check the evidence, correct and learn, approve what happens next. A useful starting point, not a validated training model.
An illustrative summary of the article's proposed approach, not a validated training model. Familiar skills still need tool-specific learning and credible checks.

Sources and further reading

Researched on 28 October 2026. The management comparison and practical examples are my interpretation, informed by the supplied research and the original sources below. No study cited here establishes that most managers literally vibe code, that managers automatically outperform other AI users, or that management jobs will remain unchanged.

Related reading: Don't Just Delegate to AI. Work Beside It., Do We Need an Agentic Quotient? and The Rules Are Becoming More Important Than the Code.