Imagine a ticket that says: "Make the project page better and filtering faster." A human engineer would walk over and ask three questions. A coding agent will not. It will pick an interpretation, generate a confident implementation, and hand you something that compiles and looks reasonable.
That is the heart of the problem, and the reason problem solving may be the biggest topic in software for the next couple of years.
The intent gap
Microsoft Research gives this a name. In Intent Formalization: A Grand Challenge for Reliable Coding in the Age of AI Agents (Shuvendu Lahiri, March 2026), the intent gap is the distance between a natural-language request and the precise behavior the user actually wants.
This gap has always existed. What changes is scale: agents can generate code so fast that there are far more chances for the implementation to drift from the intent, and the drift is harder to see because the code looks right.
The paper's proposed direction is intent formalization: turning informal intent into checkable specifications. It describes a spectrum rather than one technique, from lightweight tests that catch common misreadings, up to full formal verification. The stakes it names are blunt: whether AI makes software more reliable or merely more abundant.
How ambiguity travels
In a human-only workflow, ambiguity tends to get caught early because someone has to write the thing and notices the hole. With agents, the chain can run end to end without anyone noticing. A vague requirement becomes plausible tickets, which become prototypes, tests and code, each step consistent with the previous one and all of them built on the wrong reading.
That chain is my illustration, but it matches a pattern visible in McKinsey's August 2026 study of the agentic product development life cycle. Among its 334 product and engineering leaders, only 25% of senior respondents saw meaningful AI acceleration and 30% reported that team productivity had fallen. The organizations pulling ahead shared four themes: they rewired their processes, redesigned roles, built verification mechanisms that keep pace with faster work, and invested in change management. Verification and clear definitions are on that list for a reason.
So the sharpest way to put it is:
AI doesn't just scale execution. It scales ambiguity.
And therefore:
The quality of the solution is increasingly bounded by the quality of the problem definition.
What Microsoft changed
Microsoft's internal story, told in Engineering the Frontier Firm, is a good practical example. Individual developers got faster with AI tools, but team productivity did not follow. Their answer was spec-driven development: a living specification, kept in version control, becomes the single source of truth for business intent and acceptance criteria before implementation starts.
The workflow they describe has six stages: define the business problem, clarify ambiguities, create a technical plan, break the work into traceable tasks, validate alignment, then implement. Note where the first two stages sit. Clarifying ambiguity is step two, before any code. One of their engineers sums up the failure mode of skipping it: speed without direction is expensive chaos.
I wrote about the tooling side of this in Kiro and spec-driven development and EARS notation.
A before-and-after example
Take the vague ticket from the start. Turned into checkable statements, it might become:
- When a user selects a tag, the system shall show only projects with that tag.
- When filters change, the system shall reset pagination to page 1.
- When only the page changes, the system shall not refetch the project data.
- If no project matches, the system shall show an empty state with a way to clear the filters.
Each line is something a test, or a reviewer, can verify. An agent given these has a vector, not just a direction of travel. The "shall not" line matters most: it states what must not happen, which is exactly what a vague request leaves out.
Problem framing, specification and evaluation are one skill
The five questions from the product engineer post line up in a sequence:
- Framing: what problem, for whom?
- Specification: what behavior counts as success, and what must not happen?
- Evaluation: how will we prove it worked?
In the past, three different people did these at three different times. Now that agents handle the middle step in minutes, the people who can do all three well are the ones whose agents produce useful work.
Practical habits
- Ask the clarifying questions first. Tell the agent to list its assumptions and open questions before it writes code, and answer them.
- Write the "must not" list. Boundaries are cheaper than debugging.
- Turn requirements into examples. A concrete input and expected output removes more ambiguity than a paragraph of prose.
- Make tests the specification. The lightest form of intent formalization is a test the agent cannot ignore.
- Review the spec, not just the diff. If the spec is wrong, a perfect diff is a perfect mistake.
The next post covers the other half of the loop: Evals are product analytics for probabilistic software.