Last week I asked Claude to write me a technical proposal for a client.
It produced an impeccable document in forty seconds. Clean architecture, three-environment cost estimate, timeline with milestones, risk analysis. Perfect formatting. Professional language.
I threw it all away.
Not because it was wrong. It was technically correct—probably better than what I would have written off the cuff. I threw it away because that client, three months earlier, had told us in a call that their CTO had been fired after a failed project with an approach similar to the one being proposed.
You won’t find that in any dataset. It isn’t in any prompt. It’s an organisational scar that lives in the memory of the people who were on that call, and it changes everything: the tone of the proposal, the choice of solution, even the words to use and the ones to avoid.
The AI had produced the right answer to the wrong question. That’s something it does brilliantly.
The invisible work
I lead in a deliberately small company. My job, on paper, is making decisions: which product to build, for whom, with what priorities, by when. If you looked at my job description, a language model could do ninety percent of what I do. Maybe more.
But the job description is a lie. Like all job descriptions.
My real work is made of things that don’t sit in any backlog or any project document. It’s made of silences during calls—that moment when a client says “yes, fine” with a tone that means “no, this isn’t fine at all, but I don’t feel like arguing right now”.
It’s made of lunches with a colleague who hasn’t been delivering for two weeks and who, over a second coffee, tells you they’re going through a hard time at home.
It’s made of the decision, taken at eleven at night, not to reply to a provocative email from a stakeholder and to wait until morning, when the words weigh less.
None of this is computable. And I don’t think it’s only a problem of missing context that gets fixed with a longer prompt or a more sophisticated RAG.
It’s a different kind of knowledge. It’s situated, relational, almost embodied.
You know a meeting is going badly because you feel the tension in the room. You know an estimate is inflated because you know who made it. You know a requirement should be refused not for technical reasons but because accepting it will push the product in a direction it can’t come back from. And you know it because you’ve been in that direction three projects ago, with another client, and you have the scars to prove it.
AI works on what is explicit. My craft lives in what is implicit.
Four things I can’t delegate
I tried an exercise, partly out of curiosity and partly out of fear: identify the parts of my work a language model, however advanced, can’t do.
Not the parts it can’t do yet. The parts that, by how it’s built, it probably can’t do. Or at least not in the same way.
I found four.
The first is reading people
I don’t mean assigning tasks or doing performance reviews. An Excel sheet can do that, often better.
I mean the real part. Understanding that a colleague who suddenly starts producing sloppy work doesn’t have a competence problem but a motivation problem. And that the motivation problem comes from the fact that in the last three sprints you put them on activities they considered below their level.
And that they didn’t tell you because they’re afraid of looking arrogant.
And that you know it because you’ve known them for four years and you know how they react when they feel undervalued.
This causal chain isn’t written anywhere. Half the links have never been verbalised. They exist in the space between two people who have worked together long enough to understand each other without speaking.
Managing a team isn’t optimising resources. It’s navigating the emotional complexities of a group of human beings who spend more time together than with their families.
And doing it without manuals, without metrics, often without even noticing.
The second is understanding what a client actually wants
Not what they say they want. What they actually want. Almost always two different things.
A client asking for a document management system often doesn’t want a document management system. They want their boss to stop asking where files are.
A client asking for a mobile app wants to prove to the board that their division innovates.
A public-administration client putting out a tender for a digital platform often needs something much simpler—but the tender was written by copying one from another municipality with completely different needs.
My job is to dig under the request until I find the need. And the need is almost always political, organisational, emotional. Rarely technical.
You get there by asking questions that have nothing to do with technology. Who will use this system? Who decided it was needed? What happens if we don’t do it? Who gains and who loses?
These are questions an AI doesn’t ask, because it doesn’t know if and when they should be asked.
Maybe that’s the part that worries me most. It isn’t that the machine answers badly. It’s that it answers well to a question that maybe no one should have asked that way.
The third is weighing context that isn’t written anywhere
Every product has a story. Not the one written in the documentation, which is the official version. The real story is made of compromises accepted because the budget ran out, of features added to please a stakeholder who later changed roles, of choices that were wrong but are now so entangled with the client’s processes that removing them would cost more than living with them.
When I have to decide whether the next release should rewrite a module or add a feature, I can’t ask a model.
Because the right answer depends on who uses that module, how they use it, what was happening on the project when it was built, what the current relationship with the client is, and whether that client will still have budget for phase two in three months.
An AI can tell you what the ideal roadmap is in the abstract.
A product leader knows what the right roadmap is for that product, with that team, for that client, at this moment.
The difference between the two is the difference between a recipe book and a cook.
The fourth is saying no
It’s the most important and the least technical of all.
Saying no to a feature that looks reasonable but will lead the product into a dead end.
Saying no to a client who wants an impossible timeline, knowing you’ll lose the contract.
Saying no to a stakeholder pushing for a fascinating pivot that would destroy two years of accumulated value.
Saying no to yourself when enthusiasm for a new idea is making you lose sight of the fact that your users need something that works, not something innovative.
No is an act of judgement that requires courage, context, and responsibility.
AI never says no. It can’t afford to. Its design is optimised to be helpful, to give answers, to resolve.
But sometimes the most useful thing is to stop. Sometimes the best answer is “we don’t do it”.
And no prompt in the world can teach a model when that moment has come, because recognising it requires something no training set contains: the weight of consequences on your own shoulders.
The amplification paradox
To be clear, I’m not saying AI is useless. That would be dishonest as well as stupid. I use it every day. My team uses it to produce, document, analyse. We save hours, days, weeks, months. Deliverable quality has gone up. I wouldn’t go back.
But there’s a paradox I see emerging that worries me.
The more AI handles the “producible” parts of the craft—documents, analyses, specs, code—the more value concentrates in the “imponderable” parts: decisions, relationships, the no’s.
And those are exactly the parts you don’t learn by reading documentation or taking courses. You learn them by failing, observing, sitting in a room with other people for years.
The risk, I wonder, is that a generation of professionals grows up delegating the executable parts without ever passing through the phase where those parts teach you the craft.
Writing a wrong proposal, running a demo that falls apart in front of the client, losing a contract because you underestimated a requirement—these aren’t only training pain. They’re the process through which you develop the intuition that later lets you make the decisions AI can’t.
Skip that step and you arrive at the negotiation table without ever having felt the weight of a wrong choice. At that table, AI can’t help you.
The craft that remains
My craft is changing. It isn’t disappearing, it’s changing shape.
The time I used to spend producing deliverables I now spend reasoning about what those deliverables should say.
The time I used to spend looking for information I now spend deciding what to do with it.
The time I used to spend on repetitive work I now spend talking to people—colleagues, clients, users.
It’s a shift up the value chain, and in some ways it’s a liberation.
But it carries a new responsibility, which is maybe an old responsibility seen with different eyes: don’t confuse speed with competence.
The fact that a tool helps me produce more doesn’t mean I know more. It means I have more time to apply what I know, or to discover what I don’t know, if I’m honest with myself.
AI knows what was written.
My craft is knowing what wasn’t written, and often what can’t be written.
As long as that’s the case—and I suspect it’ll be the case for a long time—the craft remains. It changes shape, changes pace, changes tools.
But it remains.
What AI doesn’t know about my craft is, in the end, what makes it a craft and not an algorithm.
Key takeaways
Tacit knowledge (relationships, phone calls, side comments) is precisely what leaves no written trace—and therefore isn’t digestible by an LLM.
An experienced consultant holds together the requested project, the real problem, the client’s internal politics, and the history of the relationship: a strategic synthesis that can’t be automated.
AI accelerates formal writing, not the decision about what to write and what to leave out.
Scaling consulting like an industrial pipeline produces deliverables that are technically correct and politically blind—the client pays twice.
Questions & answers
What's the "tacit knowledge" AI can't replicate?
The knowledge that’s written nowhere because it comes from years of relationships, mistakes, specific conversations. Writing a proposal for a client requires knowing that the real decision-maker isn’t the signatory but the shadow IT manager, that last time someone took offence at a specific phrase, that the company is in a delicate moment that isn’t in the brief. No LLM has access to this—and without it the “perfect” proposal is wrong in the ways that matter.
Can't a model that reads the entire contact history figure it out?
In theory, yes. In practice, no—because tacit knowledge isn’t in the documents, it’s in people’s memory. The 7 p.m. phone call, the side comment in a meeting, the “don’t put this in email”—this information leaves no written trace precisely because it’s important. Trusting an LLM with what was written means working with a small fraction of what counts.
What does an experienced consultant do that an AI model can't?
Hold simultaneously in their head: the formally requested project, the client’s real problem, the client’s internal politics, the history of the relationship, their own delivery capacity, the economic constraints, the long-term sustainability. And synthesise all of it into a proposal that works on every level, not just the technical one. AI can help with the formal writing—the strategic synthesis stays human.
Can this tacit knowledge be made explicit?
Only partly. Every attempt to encode it in documents or CRMs captures the surface and loses the nuance. That’s why serious consulting is still a craft of people talking to people, despite the tools. And why “consultants” scaled to industrial pipeline ship projects that are technically correct and politically blind.
The author
