The demo always lands. You paste in a slide deck or a policy PDF, wait about thirty seconds, and the authoring tool hands back a finished course — sections, knowledge checks, a quiz, a narration script, the lot. It is a real capability, and it removes hours of clicking. The question worth sitting with is what it removes those hours from.
Building the course was never the part of the work that took longest, or the part that decided whether the training did anything. A team that could already turn a stakeholder’s 63-slide deck into a tidy Rise 360 module in a week can now do it in an afternoon. That is a genuine saving. It is also a saving on the most mechanical, least consequential stretch of the job.
The part that was never slow
The expensive work happens before anyone opens an authoring tool. It is the conversation where a request arrives as a solution — “we need a course on the new expense policy” — and someone has to decide whether a course is the answer at all, or whether the policy is just written badly and needs two paragraphs and a link. That is diagnosis, and it is where the real time goes: reading the actual process end to end, then finding the one step in a fourteen-step task that is causing most of the errors.
Faster production does nothing for that. If it changes anything, it makes the diagnosis easier to skip. When a course costs an afternoon instead of a week, the quiet pressure to ask whether it should exist at all mostly disappears — the request comes in, and it converts straight into a module, because saying yes is now cheaper than the meeting where someone says “this isn’t a training problem.”
A generated quiz still reports the way every quiz reports: completion fires when the learner reaches the last slide, not when they can do the task. AI writes the questions faster. It does not make the green checkmark on the dashboard mean any more than it did before.
More content was already the problem
This is how an organization ends up with more training and no better outcomes. The library grows because the marginal course is nearly free to produce, and every incoming request now becomes one. A year later the same LMS holds four hundred modules and a completion report that says everyone is trained, while the managers who filed half of those requests still cannot get their teams to do the thing the training was supposedly about.
Most L&D teams already know this trap. They live inside it, usually because the intake process rewards shipping a course over refusing one. The worry with cheap generation is not that it invents the problem. It is that it removes the last bit of friction that used to slow the problem down.
The bottleneck in L&D was never how fast you could build a course. It was deciding which courses were worth building.
Point it at the hard part
None of this is an argument against using AI. It is an argument for aiming it at the work that is actually hard, which is exactly where a learning team rarely has enough time. The same models that draft a passable module are genuinely good at the things that get cut first when a timeline slips: reading forty pages of standard operating procedures and surfacing the eight decisions a technician has to get right; rewriting a stakeholder’s dense source into language a person can hold in their head; drafting the branching scenario everyone skips — the awkward escalation, the edge case the deck leaves out — instead of the single happy path.
In each of those the model is doing analysis and first-draft work under a designer’s judgment, not standing in for the judgment. That is the line between AI that makes a team more capable and AI that only makes it faster at producing things nobody needed. The first raises the ceiling on what a small team can take on. The second lowers the cost of the exact mistake the intake process already made too easy.
The useful question
So when the next AI feature shows up, the question is not how much time it saves. It is which part of the work it saves that time on. A tool that shortens production is welcome, as long as everyone remembers that production was the part that was already working.
The part that was broken — deciding what deserves to be built, and showing it worked once it shipped — is still there. Still manual, and still most of the job.