Nobody skips development plans because writing prose is difficult. They skip them because working out what somebody actually needs takes an hour of real thought per person, and because you cannot write an honest plan for someone whose current capabilities you are only guessing at.
That matters when you introduce AI to the problem, because writing is precisely the part AI is best at. A tool that drafts development plans is automating the cheapest step in the process. It will produce more plans, faster, and if nothing else changes those plans will fail in exactly the way the handwritten ones did.
What was actually expensive
Three things cost something when you write a plan for one of your people, and only one of them is the document.
The first is finding the real gap. Not what they would like to be better at, but the thing currently getting in their way, which usually has to be assembled from scattered evidence: feedback that arrived over two years, work they routinely hand off, the projects they never get asked to lead. Nobody has that in one place, so it gets reconstructed from memory in the ten minutes before the conversation.
The second is knowing what they can already do. A manager's picture of their team is largely frozen at the point each person was hired, because nothing has systematically updated it since. You cannot name a next step from a stale picture, which is why so many plans aim at something the person could already do or something they are nowhere near.
The third is giving up the work. Somebody has to hand over the vendor evaluation, make the introduction, or accept that the first attempt goes badly. That one costs the most and is the least automatable thing in the entire process.
Where AI genuinely earns its place, in order
Four points, and they are deliberately ordered by how much they are worth. Drafting is last.
- Assembling the evidence. Pulling two years of scattered feedback, review notes, project history and self-assessment into one picture and saying what it points at. This is tedious, it is the reason the hour per person never gets spent, and it is work a machine is well suited to because the difficulty is volume rather than judgement.
- Asking better questions than a busy manager will. A structured interview that actually probes what somebody wants and what they avoid takes forty minutes of skilled attention. Done well by a machine, the thirtieth person gets the same quality of questioning as the first, which is not true of any human interviewer at 5pm on a Friday.
- Translating a quality into a capability. "Be more strategic" into "own the quarterly roadmap trade-offs and present them". This is the step most plans die at, it is a language problem, and language is exactly what these models are good at. It works best as a challenge rather than a request: ask what piece of work would demonstrate this, and reject the first answer if it is another adjective.
- Keeping it alive. Noticing when an activity was finished, prompting the review after the real attempt rather than at quarter end, and putting the plan back in front of somebody when the relevant work appears. Most plans die of being forgotten, and forgetting is a problem software has always been good at solving.
Drafting the document is genuinely useful too. It is just worth being clear that it is the convenience at the end, not the reason to do any of this.
The part it cannot do
A plan only becomes real when somebody gives something up. The current owner of the work has to hand it over. Somebody has to put this person on the agenda, accept a slower first attempt, and say out loud beforehand that it will be slower.
No amount of generated text does that. It is a decision with a cost attached, made by a person with the authority to bear it, and it is the exact point where plans stall in a way that later gets described as a motivation problem.
This is worth being blunt about, because it is where an AI-assisted process can quietly make things worse. The plan looks complete. Everything is filled in, the phrasing is good, the activities are specific. What is missing is the only thing that was ever hard, and a well-formed document is very good at hiding its absence.
The practical defence is small: every plan names what somebody other than the learner has to do, and that line gets read out loud to that person. If nothing is asked of anyone else, nothing has actually been planned.
The failure mode nobody warns you about: thirty plausible plans
Generate plans for a whole team in an afternoon and you will get thirty documents that all read well. That is the problem.
They will be fluent, confident, and quietly interchangeable, because the model is working from a role title and a handful of generic signals and producing the most probable plan for a person of that description. Swap two names and nobody would notice, which is the test worth running before anything is sent.
A handwritten bad plan announces itself: it is short, vague, obviously rushed. A generated one has none of those tells. The polish is what stops anybody noticing that no diagnosis happened, and it is why the output being impressive is not evidence that it is right.
Three checks catch most of it. Does each plan name something specific to this person that could not be true of their colleague. Does it start from a gap that is costing them something now rather than an aspiration. And could somebody who does not know them look at the finished work and agree it was done.
What to hand the model, and what to keep
The split that works is roughly the one you would use with a good analyst who has never met your team.
- Give it the evidence and ask what pattern it sees, rather than asking it for a plan. The useful output at this stage is a question you had not thought to ask, not a document.
- Give it a draft goal and ask it to attack it. What could this mean that I did not intend, what would falsify it, what would somebody have to see to agree it happened. Models are better critics than authors here.
- Keep the decision about what the person is ready for. The model can tell you what evidence exists; whether that adds up to readiness is a judgement with consequences for somebody's career, and it belongs to a person who will still be there in six months.
- Keep the conversation. A plan the person first sees as a finished document reads as something decided about them. The generated draft is a better starting point for a conversation than a blank page, and a worse substitute for one than nothing at all.
- Be straight about the evidence. Assembling a picture of somebody from two years of their work is a different act from writing a document about them, and people can reasonably feel differently about it. Tell them what went in. A process that would embarrass you if the person read the inputs is not one to run quietly.
The real win is coverage, not quality
Here is the argument I would actually make for doing this, and it is not that the plans come out better.
When a plan costs an hour of a manager's scarce thinking, the manager writes two, for the two people they already have the clearest picture of. Everybody else gets a form filled in during review week. That is not a character failure, it is what a fixed budget of attention divided by nine people produces.
Drop the cost of a serious plan and the arithmetic changes. The seventh person on the team gets one that is actually about them. That is a bigger shift than any improvement in the wording of the first two, and it lands on precisely the people who currently learn that effort does not change what they get asked to do.
It only holds if the manager still reads them, still has the conversation, and still gives something up. AI moves the cost of preparation, not the cost of commitment. What you save on the first should be spent on the second, and if it is simply pocketed, you have built a faster way of producing documents nobody acts on.
