Imagine hiring a senior developer. On her first day you do not show her where the code lives. You do not tell her what the company sells or who buys it. You say nothing about what matters this particular week. She gets no logins, no colleague to ask and nobody reviewing what she delivers. Then you lean over and say: make the product better. A week later you conclude she was not worth the money.
Nobody would do that to a person. Yet it is roughly how most organisations are using AI right now, and then they conclude the technology is overrated.
The problem is rarely the model. The models are absurdly capable and they improve faster than we manage to change our processes. The problem is that we treat them like a search box when they are in practice a new kind of colleague. A colleague nobody has inducted performs accordingly.
So the shift that matters right now is not a model shift. It is that AI is moving from a tool you use to a coworker you lead. And leadership is something we have a hundred years of practice at. We just need to stop pretending this is entirely new.
A chat window is an interview room, not a workplace
A chat window is excellent at one thing: answering a question from a cold start. That is why the first AI initiative in most companies looks the same. Someone buys licences, everyone gets access, and then management measures how many people logged in. A quarter later the number is disappointing and the conclusion is that staff are not ready.
Look at what you actually asked for. You asked somebody with no knowledge of your business, no access to your systems, no mandate and no follow-up to improve your work in ten minute bursts. The lack of impact is not a sign of an immature workforce. It is a sign that there was never a workplace.
The difference between a chat window and a workplace is context that persists. A colleague who comes back on Tuesday remembers what you decided on Monday, knows where the files are, knows the quality bar and has learned where things usually go wrong. None of that comes from a better prompt. It comes from a setup. That is the difference between asking and hiring.
Nine things a digital coworker needs
When I set this up, for myself or with a client, I work through the same list I would use for a new hire. Nine points. Most people skip eight of them.
A workplace. It needs somewhere the work actually lives. For a technical coworker that is a repository. For an analyst it might be a project folder with data, templates and source material. The point is that it is the same place every time, not a fresh attachment in a fresh email.
Memory. This is the part that makes the biggest difference and the part almost everyone misses. Three short files go a long way. One describing how you work and what good looks like. One describing what matters right now and what is explicitly out of scope. One describing how work is judged before it moves on. Keep them short. They are read every single time.
A brief. Before anything changes you want a proposal. Read the context, think it through, explain the approach, wait for approval. It sounds bureaucratic and takes under a minute, and it saves hours. Measure twice, cut once.
An assignment. An assignment is a task with a visible finish line. "Make the app better" is not an assignment, it is a wish. "Add a sign-up form to the landing page with name, email and company, and show a confirmation after someone submits" is an assignment. Give somebody the first version and they start guessing. At that point you are no longer leading the work, you are cleaning up after it.
Eyes. A good colleague does the task and then checks their own work. Opens the page, clicks through the flow, reads the errors, tests it the way a customer would. That AI can now do exactly this, start what it built and look at the result, is the single most underrated change of the past year. It is the difference between someone who submits a file and someone who takes responsibility for it working.
Review. Work should be measured against a standard, not against a gut feeling. Once the standard is written down you can ask for a verdict in three piles: must fix, should fix, fine to ship. That split is simple enough that somebody will actually use it on a Friday afternoon.
A schedule. This is where it starts to feel like employment. Recurring assignments at fixed times. A morning brief that reads customer notes and open issues and proposes the most useful thing to do today. A Friday review that groups what keeps coming back. It is not glamorous work. It is precisely the kind of work that otherwise never gets done.
Boundaries. A good colleague knows what they can do alone and what they should ask about. The same applies here, and I will come back to it, because it is the one point where management has to be in the room.
Its own skills. When you notice you are writing the same instruction for the third time, it should stop being an instruction and become a skill. The same goes for connections to your systems and for automatic checks that run every time. This is where it stops being a generic tool and starts belonging to your company specifically.
The daily loop
The nine parts are not a checklist you tick off once. Four of them are a loop that runs for every assignment.
You ask for a plan. You approve it or adjust it. The assignment is carried out as one contained change. The work is checked against reality. Then it is reviewed against the standard and you get your three piles. The whole lap takes minutes rather than days, and the important part is that you get small packets to decide on instead of a pile of work at the end of the day that nobody has the energy to untangle.
That is also why parallel work holds up. One session per assignment, never several assignments in one session. Three parallel sessions are in practice three coworkers with the same business context and three separate deliveries you can accept, revise or discard independently. That scales. One giant pile does not.
And once the schedule is in place you get what people call the night shift. Customer feedback accumulates, patterns get summarised, risks surface and the next task becomes clearer, while you sleep. You wake up to context instead of a blank screen.
What management actually has to decide
Everything above can be set up by a team in an afternoon. One thing cannot, and that is the boundaries.
Think of it as delegation, because that is exactly what it is. Some things are free: reading, searching, analysing, proposing, running tests, working in an isolated branch, updating documentation. Some things ask first: installing dependencies, changing the database, touching authentication or payments, deleting. Some things belong to a human and nothing else: production releases, customer data, billing, anything that goes out to a customer in your name.
That split is not a technical question, it is a management one. It is the same question as who may approve an invoice and up to what amount. Nobody finds approval limits exciting, and nobody runs a company without them either.
Two more things belong on the management table. The first is who owns the quality standard, meaning the file that decides what counts as good enough. If nobody owns it, it becomes a document that was written once and never read again. The second is how you define success. If success is "number of active users" you have already lost, because then you are measuring logins rather than work. Define it instead as a specific workflow having changed in a way the customer noticed. That can be proven and it can be built on.
The bottleneck moves to judgement
What happens once the setup is in place is that production capacity stops being the constraint. Things get built, written and analysed faster than you can decide on them. So the bottleneck moves, and it moves to judgement.
That sounds uncomfortable but it is good news, because judgement is what you are already good at. The question is no longer whether you can do the thing. The question is whether it was the right thing, whether it solves a real customer problem and whether you are willing to stand behind it. That work does not disappear. It gets harder, more demanding and considerably more human.
It also puts an uncomfortable demand on the organisation. To lead a digital coworker you have to write down things you have never needed to write down. What "done" means. What is good enough. Who the customer is, in the customer's own words. What you are deliberately not doing this month. Most companies have never articulated any of it, because people fill the gaps out of habit and politeness. A digital coworker does not. It does exactly what you described, and that is mercilessly clear when the description is vague.
That is also why this investment is hard to copy. Anyone can buy the same licences you did. Nobody else has your written quality bar, your customer quotes, your boundaries and your accumulated sense of where things go wrong. There is only one way to build that, one week at a time.
So do not start by buying more licences. Start with a single digital coworker, one narrow area that genuinely moves your numbers, and the nine points above. Give it a workplace, a memory, a clear assignment, eyes to check its own work, a standard to be judged against, a schedule and boundaries it must not cross.
Which is exactly what you would have given that developer on her first day.