The near-term AI crash projects nobody is building
Ethan Mollick argues that AI good enough to improve tutoring, healthcare second opinions and government services already exists, yet nobody is running the programmes. The lesson for enterprise leaders: the constraint is ambition and delivery discipline, not model capability.
The frustration worth taking seriously
On 6 November, Ethan Mollick published what reads like a complaint and is really a strategy critique. His point: the energy in AI is flowing toward frontier capability, while almost none is going into “near-term, achievable crash projects” that use today’s models to fix old, intractable public problems at national scale. He names four: universal tutoring to support classroom learning, second opinions in healthcare, financial literacy and scam avoidance, and making government services easy to access.
Two things in that list deserve a pause. First, these are not futuristic concepts. Every one of them has been attempted before, with humans, at public expense, and failed to scale. Second, Mollick is not speculating about them from the outside. He spent twenty years building tutoring and financial literacy programs, and says the binding constraint was always the technology. His claim is that this week’s models have quietly removed it. “We should be more ambitious about trying to solve hard problems,” he adds, “rather than waiting for a nation of geniuses in a data center to solve them for us.”
For anyone deploying AI inside an enterprise, that post is uncomfortable, because the pattern he describes is not confined to governments. It is the default allocation of attention in most AI programs, public or private.
Boring problems, unclaimed value
Watch where enterprise AI budgets actually go. They concentrate on whatever is demonstrable in a board deck: chat assistants, code generation, marketing content, frontier pilots attached to the newest model release. Those projects matter, but they are competitive hygiene. Every peer is doing the same thing, so the marginal advantage shrinks each quarter.
Meanwhile the “tutoring and scam avoidance” equivalents inside a company sit unowned: the onboarding program that drops half of new hires, the claims triage that burns senior adjuster hours, the compliance question everyone emails three departments about before trusting the answer. These are exactly Mollick’s category. Long-recognized, repeatedly attempted, previously capped by the fact that you could not be in every classroom or every call center at once. That cap was a staffing constraint dressed up as a technology constraint, and current models genuinely dissolve it. The reason nobody ships them is organizational: they are unglamorous, the vendor shortlist for them is empty, and no product launch will ever announce them.
What a crash project actually requires
Mollick is careful about the hard part, and enterprises should copy his discipline, not just his list. A crash project is not a pilot program with a different name. Three traits distinguish it.
It starts from a validated failure, not a capability search. Tutoring did not scale because it was expensive per student. The AI deployment is credible because it attacks the specific cost that killed the prior attempt, not because the technology is interesting.
It commits to measurement before rollout. “You would want to do careful design and studies before rolling things out,” he writes. National programs cannot audition forever; they need study designs agreed in advance, with the explicit willingness to find that the thing failed. His own line, “those efforts might fail,” is the sentence most enterprise AI governance frameworks are structurally unable to utter, even though it is the honest precondition of any real study.
It uses the models that exist. No dependency on frontier breakthroughs. Scoping to current capability is what makes the timeline credible and the budget defensible, and it inverts the usual posture: most corporate AI roadmaps wait for capability to outrun governance. A crash project lets governance catch up to capability it already has.
The allocation question
Strip the post down and it is an argument about portfolio mix. If near-term, achievable, high-stakes applications are being underfunded relative to frontier chasing, then the interesting strategic question for a leader is not “which model” or “which vendor” but “what share of our AI effort is pointed at problems we already know matter, versus capabilities that merely feel consequential.” Most programs cannot answer that share, because nobody has ever asked them to compute it.
That is a genuinely tractable piece of work. Take your deployed and planned use cases. For each one, ask whether it addresses a problem that failed to scale for staffing reasons, whether a study design could falsify its value claim within a quarter, and whether it needs a model that does not exist yet. The use cases that survive all three questions are your crash candidates. They will rarely be the ones in the pitch deck.
Mollick’s frustration is aimed at labs and policymakers, and it lands on them. But the same misallocation runs quietly through enterprise programs that have budget, data and operational problems matching his four categories almost one for one. The national version needs public ambition. The company version only needs a leader to notice that the constraint was never the model.
If your AI portfolio is dominated by capability-led pilots and you cannot name the share pointed at validated, unglamorous bottlenecks, that gap is the strategy conversation worth having. Book a strategy consultation and we will work through the allocation with you.