The Old Analyst Wrote Reports. The New Analyst Writes Instructions.
AI didn't replace analysts. It replaced what analysts produce. The cognitive work is the same. The artifact is different — and that changes hiring.
AI didn’t replace analysts. It replaced what analysts produce.
In 2013, I was mapping 20+ system integrations at a retail chain - writing specs so developers could build them. Last week, I spent three hours writing instructions for an AI agent to do similar work. Not requirements. Not specifications. Instructions - goals, constraints, guardrails, edge cases it should not handle on its own.
The output was a prompt file, not a Confluence page. The work felt strangely familiar.
Here is the uncomfortable truth I have arrived at: bad prompts fail for the same reasons bad requirements fail.
They are ambiguous. They assume context the system does not have. They do not specify what to do at the edges. They do not say what success looks like. They confuse what should be done with how it should be done.
If you have spent years writing precise specifications - if you have learned the hard way what happens when you leave something undefined - you already have a head start. You just need to point it at a different execution layer.
The shift
For 14 years, I absorbed complexity and output clarity. Interviewed stakeholders, mapped processes, found gaps, documented everything so developers, testers, and project managers could act on it.
The job is the same now. The recipient has changed.
| Before | Now |
|---|---|
| Write for humans | Write for agents |
| Document behavior | Define execution |
| Assume shared context | Must encode all context |
| Clarify later if needed | Must pre-handle ambiguity |
A report describes what happened or what should happen. An instruction tells an autonomous system what to do, when to stop, what to escalate, and what to ignore. The cognitive work is the same. The artifact is different.
Where I learned this (without knowing it)
At one company, we went from zero documentation to a documentation-first culture. Defect rate dropped 6x. Not because anyone coded better - because we defined behavior before anyone wrote a line of code. We made the implicit explicit.
That skill - making the implicit explicit - turns out to be exactly what agent instruction writing demands.
Agents do not ask clarifying questions (unless you build that in). They do not read between the lines. They do not have the institutional knowledge to know that “process this order” means six different things depending on which country it came from.
The analyst who spent years anticipating these gaps? That is the person who writes agent specs that actually work.
Stop hiring analysts who document. Hire analysts who can instruct agents.
This does not mean “hire prompt engineers.” It means rethink what “good at analysis” looks like when the execution layer talks back.
The analyst who can write a clean agent spec - who understands that an ambiguous instruction produces unpredictable output - is worth more than one who writes beautiful Confluence pages that no system can use.
The interview question I would ask: “Give me an example where you had to make something implicit explicit. What happened before? What changed after?”
That question works whether the candidate writes for developers or for agents. The analytical muscle is the same.
For analysts reading this
I am not writing this as someone who has figured it all out. I am in the middle of it.
I spent 14 years learning to write requirements that humans could act on. Now I am learning to write instructions that agents can act on. Some of what I learned transfers directly. Some does not. The feedback loops are different - faster in some ways, harder to interpret in others.
What I can say with confidence: the ability to be precise about what you want, to anticipate edge cases, to define success clearly - that does not go out of style. It just has a new application layer.
Be honest: if I looked at your last spec - could an agent execute it without asking questions?