luismori.

AI Coding Workflows

LLM AI Agents Agent Skills Prompt Engineering Developer Productivity
Anticipate the Path: The Simple Reason Rules, Skills, and Agents Work

Anticipate the Path: The Simple Reason Rules, Skills, and Agents Work

LLMs finish tasks when you show them the way first. The human almost always holds more context than the model, so an open-ended request is a maze of guesses — while an anticipated path of steps, constraints, and checks turns wandering into walking. Here's why rules, skills, and scaffolding are all the same trick.

13 min read Updated Sep 11, 2026

Picture two ways to ask a colleague for help.

The first way: “Hey, the deploy pipeline is broken. Fix it.” Then you walk away.

The second way: “The deploy pipeline is broken. Start with the staging logs from last night’s run — the failure is probably there. If it’s the migration step, roll it back and re-run with the old snapshot. If it’s anything else, stop and send me the error. Don’t touch production.”

Same colleague. Same broken pipeline. Wildly different odds of a good outcome.

Now swap the colleague for a language model, and you have the whole story of this article. LLM inference works better — and actually finishes the task — when you anticipate the correct path first. Open-ended requests make the model wander through a maze of possibilities. An anticipated path turns the maze into a marked trail: here are the steps, here are the constraints, here is how you know you’re done.

I keep coming back to this idea because it explains so much. Once you see it, rules files, Agent Skills, system prompts, spec-driven workflows, and guardrails stop looking like separate techniques. They are all the same trick wearing different hats: a human who knows the context sketches the path, so the model doesn’t have to discover it by guessing.

You know more than the model does. Always.

Here’s the uncomfortable starting point: for most tasks, you hold far more context than the AI ever will. You know which system is flaky, which stakeholder is picky, what “done” looked like last time, which shortcut is safe and which one caused an incident in March. The model sees a few paragraphs of text.

Researchers have a name for the shared understanding two collaborators build up: common ground. Humans are constantly maintaining it without thinking — we ask “what do you mean by that?”, we say “got it”, we double-check before acting on a vague instruction. Language models, it turns out, are bad at this. A NAACL 2024 study on conversational grounding found that compared to humans, LLMs generate language with less grounding and instead simply presume common ground — they act as if the shared understanding already exists. Even more telling: training on contemporary preference data, the kind that rewards quick helpful answers, actually reduced the model’s grounding behavior. We trained them to answer fast, not to ask first.

So when you hand a model an underspecified task, it doesn’t pause and interview you. It picks an interpretation and runs. Edwards and Schuster’s 2026 study of coding agents puts a name on this: external uncertainty — uncertainty from ambiguous inputs, as opposed to internal uncertainty inherent to the model itself (a distinction they borrow from Li et al.). Their fix is deliberate machinery — a multi-agent scaffold that decouples underspecification detection from code execution, hitting a 69.4% resolve rate on an underspecified SWE-bench variant. Without that machinery, the default behavior is: assume, generate, hope.

And here’s the part that stings: different models will assume differently. Each one carries distinct priors from its training — what a “normal” project looks like, what the “obvious” next step is, how much to explain versus just do. Give the same vague prompt to three different models and you can get three confident, contradictory plans. That’s my engineering read from watching models diverge on underspecified work, not a measured constant.

What is measured: a 2026 study of tacit human-AI understanding had 241 humans and 200 profile-conditioned agents place concepts along subjective spectra, and found alignment tracked person-level traits — individual characteristics, decision-making styles, confidence — while profile conditioning only partly captured deeper alignment. In other words, when objectives are vague, success hinges on unspoken context the model can’t see. The vaguer your request, the more room each model’s priors have to diverge from what you actually wanted.

This is the maze. Every ambiguous word in your prompt is a fork in the path, and the model must pick a direction at each one, blind.

What “anticipating the path” actually means

Anticipating the path doesn’t mean writing the answer yourself. It means doing the navigation work the model is worst at, and leaving it the execution work it’s best at. In practice, it looks like this:

  • Name the steps in order. Don’t say “migrate the database.” Say: snapshot first, then run the migration on staging, then verify row counts, then cut over.
  • Constrain the outputs. Say what shape the result must take: a file here, a table with these columns, a plan that fits this template.
  • Declare what’s off-limits. Read these directories, never write to those. Touch staging, never production.
  • Define “done.” A check, a test, a verifiable condition — not a vibe.
  • Say what to do when lost. Stop and ask. Roll back. Never silently improvise past a failure.

None of this is exotic. If you’ve written a good runbook, a checklist, or a careful code-review comment, you’ve anticipated a path before. The insight is that for LLMs, this isn’t a nice-to-have — it’s the difference between finishing and flailing. Every explicit step removes a fork from the maze. Every constraint prunes branches the model would otherwise explore. Every check catches a wrong turn early, when it’s still cheap.

The research literature keeps rediscovering this from different angles. Least-to-most prompting showed that breaking a hard problem into easier subproblems and solving them in sequence lets models crack tasks that flat chain-of-thought fails on. Anthropic’s work on question decomposition found that decomposition doesn’t just improve accuracy — it makes the model’s reasoning more faithful, more actually connected to its answer. The ReAct pattern alternates thinking with acting and observing, so each step is grounded in what just happened instead of floating in speculation. And very recent planning research makes the mechanism explicit: the Constraints-of-Thought framework converts each reasoning step into an executable constraint that restricts the feasible action space, and reports lower branching factors plus better accuracy across planning, code, and reasoning domains. Narrow the space, get better results. Same story, fancier math.

Even the official prompting guidance says it plainly. Anthropic’s best-practices docs tell you to be specific about desired outputs, to give sequential steps when order matters, and to constrain reasoning and format explicitly. That’s not style advice. That’s path anticipation, distilled.

Rules, skills, and scaffolding are all the same trick

Now the fun part: once you believe the path idea, the whole zoo of agent tooling snaps into focus.

A rules file (AGENTS.md, Cursor rules, whatever your harness reads) is an anticipated path for every task in your repo: how we structure code, which commands are safe, what “done” means here. A system prompt is an anticipated path for a whole session: who you are, what tools you have, how you should behave when uncertain. An Agent Skill is an anticipated path for a specific task family: the domain knowledge, the scripts, the worked examples, the validation steps — packaged so the agent doesn’t have to reinvent them each time.

This is exactly why skills work, and we now have numbers to back it up. SkillsBench, a 2026 benchmark that ran 87 tasks across 8 domains under matched no-Skills and curated-Skills conditions for 18 model-harness configurations, found that curated skills raised the average pass rate from 33.9% to 50.5% (+16.6 percentage points), with configuration-level gains ranging from +4.1 to +25.7 points — while self-generated skills landed below the no-skills baseline on all three dedicated-harness configurations (-8.1 to -11.5 points). Focused skills with at most three modules beat larger bundles, and comprehensive documentation dumps barely moved the needle (+0.7 points).

Read that again, because it’s the whole thesis in one result: a human who knows the path writes it down, the agent walks it and succeeds. Ask the agent to anticipate its own path from scratch, and you gain nothing — you lose ground. The value was never “more context.” It was the right path, anticipated by someone who knew.

Spec-driven workflows are the same idea scaled up. I previously wrote about how Spec Kit’s six skills behave like compiler passes — each stage transforming one artifact into the next with explicit inputs, outputs, and checks. Re-read that architecture through the path lens and it’s obvious what’s happening: specify, clarify, plan, task-split, analyze, implement. Each pass anticipates the path for the next one, so no single model call ever faces the full maze at once. The “clarify” step deserves special mention: it’s explicit machinery for the grounding problem — converting high-impact ambiguity into recorded decisions before the expensive work begins, instead of letting the model silently presume common ground.

Guardrails and verifiers are path anticipation too, just from the other end. A test suite, a type checker, a policy gate — these are all ways of saying “the correct path must pass through here.” My engineering judgment, backed by the pattern across every source in this piece: deterministic checks are the highest-leverage form of anticipation, because they don’t just suggest the path, they enforce it.

A before-and-after you can steal

Enough theory. Here’s the pattern applied to something concrete: asking an agent to add rate limiting to an API endpoint.

The open-ended version:

Add rate limiting to the /export endpoint.

The model now has to guess: which rate-limiting library? Per-user or per-IP? What limits? Where does the config live? What should the error response look like? Do the tests need updating? Every guess is a fork, and wrong guesses compound — a plausible-but-wrong library choice poisons every step after it.

The anticipated-path version:

Add rate limiting to the /export endpoint.

Path:
1. Check package.json — if a rate-limit library is already a dependency, use it.
   Otherwise stop and tell me which one you'd add.
2. Limit per authenticated user, 100 requests/minute, configured in
   src/config/rateLimits.ts next to the existing entries.
3. Return HTTP 429 with the shared error envelope from src/lib/errors.ts.
4. Add one test mirroring tests/rateLimit.auth.test.ts for the new endpoint.
5. Run npm run test:rateLimit. All tests must pass.

Do not: change any other endpoint, add new dependencies without asking,
or modify the error envelope.

Same model, same task. The second version removes nearly every fork: the library question, the config location, the error shape, the test pattern, the definition of done, and the guardrails. What’s left for the model is genuine execution work — reading code, writing the patch, running tests — which is precisely what it’s good at.

Notice what I didn’t do: I didn’t write the code. I didn’t over-specify (“use exactly these 14 lines”). Anticipation is about the path, not the footsteps. Over-constraining has its own failure mode — a model forced down a wrong path with no room to flag it will fail confidently — which is why step 1 says “stop and tell me” instead of pretending I know everything. The human anticipates; the model still gets to raise its hand.

Where this idea breaks (honestly)

A good mental model should also tell you where it stops working. Three limits worth naming:

A wrong anticipated path is worse than none. If your steps encode a mistaken assumption — the wrong table, the stale API, last quarter’s architecture — the model will now march confidently in the wrong direction. SkillsBench’s variance across domains hints at this: skills helped a lot on average, but 13 of 87 tasks showed negative deltas, and the audit traced the failures to heavyweight pipelines, displaced native strategies, and brittle prescribed solvers. Anticipation amplifies whatever judgment went into it, good or bad. That’s why the best skills are built from observed agent failures and iterated, not written once from armchair theory. Anthropic’s own guidance says to start from evals: watch where the agent struggles, then write the skill that fixes that.

Some tasks genuinely need exploration. Debugging a novel failure, researching an unfamiliar codebase, spiking an open-ended prototype — here the path doesn’t exist yet, and prematurely declaring one just blinds the agent. The right move is a meta-path: anticipate how to explore (time-box it, report findings in this format, propose three options before committing) rather than anticipating the answer.

Humans are the bottleneck — and that’s the point. The SkillsBench finding that self-generated skills land below baseline is humbling. The model can’t reliably anticipate its own path because it lacks exactly the context we’re talking about: your systems, your standards, your scars. Path anticipation is the human’s job in the loop. It’s also, I’d argue, the durable skill of the AI era: the engineers who thrive won’t be the ones who write the most code, but the ones who sketch the clearest paths.

The trailhead

Let me leave you where we started: two ways to ask for help.

“Fix the deploy pipeline” is a maze: dozens of forks, every one a guess, with three different models ready to guess three different ways. The staged version — logs first, migration rollback if X, stop and report if Y, never touch production — is a marked trail. Same model walking it. Completely different hike.

So the next time an agent wanders off, resists finishing, or delivers something confidently wrong, try asking yourself one question before you blame the model:

Did I anticipate the path — or did I just point at the forest?

Source List

I prioritized primary papers, official docs, and benchmarks over commentary. Interpretive claims about what it all means are my own engineering judgment.