Prompt Crafting Is Overrated. Here Is What Actually Matters.

Ethan Mollick's July 22 observation that prompt crafting is overrated lands differently when you watch enterprise teams spend months on prompt libraries while AI adoption stalls. The bottleneck is not the prompt — it is the missing clarity about what the team is trying to accomplish.

On July 22, Ethan Mollick posted a short, direct claim on X: “Prompt crafting is over-rated, ask for what you want.” The context was AI disproving a longstanding mathematical conjecture using prompts that amounted to “do a breakthrough,” “continue the search,” “enough, do it.” No elaborate chain-of-thought scaffolding. Simple directives. The model handled the rest.

Mollick’s observation is correct, and the enterprise angle on it is the part most commentary misses.

ishikawa
  Why AI pilots disappoint
    Specification
      Outcome undefined
      No success metric
      Scope never closed
    Process
      Prompts over-engineered
      No evaluation loop
    People
      Stakeholders misaligned
      No owner for outputs

The rundown: what Mollick is pointing at

The claim is not that prompts do not matter. It is that the obsession with prompt crafting as the primary skill in AI work is misplaced.

As frontier models have improved, the gap between a carefully engineered prompt and a plain-language request for the same outcome has narrowed. The model can now infer formatting preferences, required reasoning steps, and output structure constraints from a clear statement of intent. You still get better results with more context and clearer framing — but the marginal return on optimization past a baseline has dropped significantly.

The math research example illustrates this clearly. Researchers directed AI toward an unsolved problem with minimal instruction. The model did not need structured chain-of-thought scaffolding to engage seriously with the problem. It needed a clear goal. The instruction “do a breakthrough” reads as a joke, but it produced results — which says something real about how frontier models process intent.

For the working software engineer

The practical implication is that evaluation infrastructure matters more than prompt optimization at this stage.

The question to ask about any AI workflow is this: can you reliably distinguish a good output from a bad one? If the answer is no — if evaluation is informal or absent — then prompt tuning will not converge on a reliable system. The team will iterate prompts in response to individual failures without knowing whether any given change improved results across the broader workload.

A basic evaluation loop — a set of representative inputs with known good outputs, run on every change — gives you something prompt optimization alone cannot: visibility into whether you are actually improving. Without it, prompt iteration is anecdote-driven. With it, it is engineering.

The prompt is one variable. The evaluation suite is what tells you whether optimization is working.

For business owners and operators

When an AI initiative is not producing useful outputs, the diagnosis almost always points to one of two places: the model genuinely cannot do what is being asked (rare at the frontier in 2026), or the team does not have a shared, specific definition of what a good output looks like (common).

Prompt engineering obsession is often a symptom of the second problem. When success criteria are vague, every output looks partially wrong, and the instinct is to modify the prompt. The team iterates in pursuit of a target they have not clearly defined. This can run for months without converging.

The productive intervention at the business level is to do the specification work before prompt iteration begins. What does a successful output look like? How is it measured? Under what conditions does the AI handle this better than a person, and when does it need human review? Those questions answered in writing, before the first prompt is written, will compress months of iteration into weeks.

My take

The prompt engineering bottleneck is usually not a prompt problem. It is an outcome definition problem wearing prompt engineering as its costume.

I ran into the exact pattern during an engagement at a class-action settlement administration company where I served as principal architect. The project was technically well-specified — a customer-facing case management platform with clear architecture. What derailed it was a question nobody had resolved before development began: which stakeholders from the legal teams on opposing sides of each case would have access to what information.

The administration company sat as a neutral third party between opposing counsel. Granting selective access was politically sensitive and legally complex — every case had different stipulations. Rather than resolve that decision up front, the team moved forward and let it follow the project through every phase. Features touching access control were built, rebuilt, stalled, and revisited. The technical implementation was sound. The outcome definition was not. The project eventually had to be replaced.

The parallel to AI work is direct. A team without a written definition of what a good output looks like — under what conditions, with what acceptable error rate — will spend months iterating prompts against an undefined target. The model is not the problem. The missing specification is.

Mollick’s observation is really pointing at where the difficulty in AI adoption lives. It is not in prompt syntax. It is in getting the team aligned on what success looks like before asking the model anything.

Frequently Asked Questions

If prompt engineering is overrated, should we stop investing in it entirely?

Not entirely, but the investment profile should shift. Instead of building elaborate prompt templates for every scenario, invest in two things: first, clear outcome definitions for each use case — what does a successful output look like, and what does a failure look like; second, evaluation infrastructure that tells you when outputs meet that bar. A team that can reliably define and measure a good output will outperform one with a sophisticated prompt library but no clarity on what it is optimizing for. Some prompt structure still matters — context, format guidance, and constraints are legitimate — but the pursuit of syntactic precision above a basic level has diminishing returns faster than most teams realize.

What is the most common reason enterprise AI projects stall beyond prompt issues?

Stakeholder misalignment about the intended outcome. This sounds abstract but plays out concretely: the technical team builds toward one definition of success, the business stakeholders have a different definition in their heads, and neither definition was written down. When the outputs land, everyone is disappointed for different reasons. The prompt gets blamed, but the prompt is not the problem. The project needed a shared written specification of what the AI was supposed to do, under what conditions, and how a good output would be distinguished from a bad one — established before the first line was written.

How do frontier models change what prompt engineering needs to do?

Frontier models in 2026 have enough language understanding and task inference capability that they can fill in significant gaps from intent alone. Earlier models required more explicit instruction about format, reasoning steps, and output structure. Current frontier models can infer much of that from a clear goal statement. This does not mean structure does not help — it often does — but the marginal return on prompt optimization beyond clear goal articulation has dropped significantly. The AI can now do more of the translation work from intent to execution. What it cannot do is infer what you want when you have not decided. That part still requires human clarity.