What AI Can Do for Instructional Design. What It Can't. And What It Probably Shouldn't — For Now.

There are three different questions buried in every conversation about AI and instructional design, and most people only ever answer one of them. What can AI do. What can't it do. And — the one almost nobody asks, maybe because nobody feels qualified to answer it yet — what shouldn't it do, even in the cases where it technically could.

I don't think anyone's actually qualified to answer that last one with certainty. AI in this field is still in its crawling phase. What follows is where my thinking currently sits, not a rulebook — best guesses and emerging patterns, not settled conclusions. Ask me again in a year and some of this may look wrong.

Here's why I'm even willing to try, though. I've watched this exact cycle before, more than once. Gamification showed up, and within a couple of months of average IDs getting their hands on it, conference stages were full of people declaring it the biggest thing to happen to the industry since eLearning itself existed. A few months after that, nobody was talking about it anymore. AR and VR did the same lap — the breathless keynote, the vendor booths, the case studies — and then the quiet fade once the cost and the clunkiness caught up with the hype. Both were real tools with real, narrow use cases. Neither one changed how the average ID actually worked day to day.

AI is not doing that lap, or at least it doesn't look like it yet. The closer comparison isn't gamification or AR/VR — it's the release of rapid authoring tools like Captivate and Storyline. Those didn't just add a feature to the toolkit. They changed the actual workflow of the job, for everyone, permanently. Nobody today builds a course the way they did before rapid authoring existed, and nobody's debating whether that shift was a passing trend. AI looks like it's headed toward that same category — a genuine overhaul of what we do, can do, and should do — rather than another gamification-shaped fad that quietly exits the conversation by next spring. That's a guess based on the shape of the thing so far, not a certainty. But it's the reason I think the "can / can't / should" question is worth sitting with seriously right now, instead of waiting to see if this one blows over too.

Start with what it can't do, because that list is short, and it's the part I'm most confident about.

AI cannot conduct the interview. It cannot sit across from a warehouse supervisor and notice the pause before she answers the question about why the new process keeps failing, and follow that pause instead of the transcript. It cannot walk the floor doing a job shadow, watching how the actual work happens versus how the SOP says it happens, and catch the gap between those two things that nobody wrote down because nobody thought to. It cannot conduct a Level 3 evaluation in the field, watching whether the training actually changed behavior on the job, months after the course ended and the survey scores stopped mattering. And it cannot build a meaningful interaction or activity, in either ILT or eLearning, because meaning isn't something you generate from a prompt. It's something you earn by understanding what the business is actually trying to fix. It can absolutely create an interaction — the question is whether that interaction is tied to anything real. Ask it for one and, left to its own judgment, you'll likely get a matching game: flip a card, find the term, find the definition. What you actually need is a scenario that forces someone to apply that definition the way the job requires it. AI can build either one. It has no way of knowing, on its own, which one you actually need.

Now, what it can do — and this is the part everyone's already using whether or not they're being honest about it. Feed it the results of those interviews. Feed it the comments from an audited training program, the findings from that job shadow, the data from the L3 evaluation, the hard numbers on what it costs to develop and deliver the training versus what it saves once it's actually working. Give it that input, as prompts and as data, and it can generate an output — a course outline, a needs-analysis report, a design document, a first-pass structure for how the training should be organized and why. That's not nothing. That used to take days of staring at a blinking cursor, turning forty pages of interview notes into a framework that made sense. Now it takes an afternoon, because the raw material was already good — a human went and got it the hard way — and the AI's job is just to help organize what a human already found.

Which brings me to the question I don't think anyone can answer with real authority yet: not what AI can do, but what it should.

Here's my current thinking, offered as a working hypothesis rather than a rule. In the ADDIE model, Design is the outline, the framework, the general direction — what the training is going to be, how it's structured, why it's built that way. Development is what happens after the client approves that design: turning it into an actual, usable product. My instinct right now is that AI belongs in Design, and probably shouldn't be doing Development on its own — but I hold that loosely, because the tools are changing fast enough that this could look outdated within months.

Here's the reasoning behind the instinct, for what it's worth. AI tools right now can already generate a working prototype, a mockup, a slide deck, in minutes, from a prompt. That's genuinely useful, and I use it. But there's a difference between "AI can produce something that looks like a finished product" and "I'm comfortable letting it be the one that finishes it." The Design phase is fast, iterative, disposable — you're supposed to throw away nine outlines to find the tenth one that's right, and AI seems like a genuinely good tool for that kind of rapid, low-stakes exploration. Development, at least so far, still feels like where the craft lives — the judgment calls about pacing, the decision to cut a scene that tested fine but felt wrong, the thousand small choices that separate a course that technically covers the content from one that actually changes behavior. Maybe that changes. Maybe in a year the tools get good enough at those judgment calls that this whole distinction stops holding up. Right now, though, handing off Development entirely doesn't feel like it saves time so much as it swaps a slow, thoughtful process for a fast, thoughtless one.

So here's where I've landed, for now: use AI to cut into the parts of the job that were always just overhead — the time-consuming, expensive, repetitive stretch of turning raw analysis into a workable outline. Be more careful about handing off the part of the job that was never overhead to begin with. Whether that turns out to be the right line, or whether it looks naive a year from now, probably comes down to the same test I'd apply to gamification or AR/VR if I were being honest at the time instead of in hindsight: is this actually changing how the work gets done, or is it just the thing everyone's talking about this quarter. I think I already know which one this is. I've been wrong before, standing on a conference floor, watching something get declared the future.