Ad Hoc Prompting Is Now the Slow Way to Work

For a year, AI work on your team probably looked like people typing clever prompts into a box and hoping. That worked for demos. It does not scale. The people shipping real agent work now build structure around the model: harnesses, plugins, tuned tool servers, and grounded retrieval. Let me catch you up on what turned into real craft, and where your team is exposed if you skipped it.

Stop typing "dear agent, please fix this bug"

A harness is a wrapper you build around a model for one repeatable job. Claire Vo built one live for her company ChatPRD: a Sentry bug-debugging harness using the Claude Agent SDK, with custom adapters for Sentry, Linear, GitHub, and Vercel. It gathers evidence, finds the root cause, and files the follow-up work. No hand-typed prompt each time.

That is the shift behind the line "it's not the model, it's the harness." The same model gets much better when you give it fixed steps, real permissions, and a clean place to put its output. Vo's advice is worth stealing: build a harness for any repetitive, structured workflow, and structure the artifacts so the whole team can use them, not just the person who ran it.

Two failures that look the same but aren't

Here is a trap worth naming before your team hits it. Divy Yadav splits the work into two disciplines: harness engineering and loop engineering. Harness work wraps the model in guardrails, tools, and permissions so bad behavior is hard. Loop work decides what to do next, when to stop, and how to remember between runs.

Mix them up and you get two different broken agents that share one root cause. A weak harness gives you an agent that does unsafe things. A weak loop gives you an agent that spins forever, or one that never moves without a human typing. When your agent misbehaves, ask which piece is actually missing before you tune prompts. You are usually short one, not both.

Packaging the setup so it travels

The one-off setup problem is getting solved too. Nick Babich describes Claude Code plugins as a portable workflow kit. Without them, you wire up a skill here, a hook there, an MCP server somewhere else, plus project rules, all by hand in one repo. Fine for tinkering. It falls apart across a team.

A plugin bundles those pieces into one package you can install, update, share, or ship through a marketplace. That is how a good setup stops living in one senior person's head. If your best AI workflows only exist on one laptop, plugins are how you make them team property.

Fewer tools, tighter answers

MCP servers are the connectors that let a model talk to your data and systems. They fail in a sneaky way. An API returns a 400 and a developer fixes it. An MCP server fails silently, Babich writes: the model picks the wrong tool, guesses parameters, or floods its own context with junk. The user just sees a slow, expensive, or wrong answer.

Performance breaks for four predictable reasons: too many tools exposed, vague tool names, huge responses, and loose schemas that invite guessing. The fixes are dull and effective. One engineer rebuilt a Postgres connection as a custom MCP server and deleted 2,000 lines of code by cutting the custom API wrappers he no longer needed. Read-only queries, typed functions, tight schemas. That is the whole game.

Grounded answers or nothing

For anything a regulator or customer might check, the model cannot just sound confident. RAG, or retrieval-augmented generation, hands the model your actual documents first, then asks it to answer from that evidence with a citation. Anthony Usoro's guide is blunt about why: a bank verifying a rule or a hospital citing a protocol needs a source, and an answer without one is a liability.

The craft lives in the boring middle. Bad chunking, cutting a passage mid-clause, silently strips the detail that would have changed the answer. Usoro also pushes hybrid retrieval, mixing meaning-based search with plain keyword search so exact codes and clause numbers do not get lost. Angela Shi's pipeline shows the ceiling: on a 45-page car-insurance policy, it returns a dollar figure and the exact lines, 54 and 55, it came from.

The deep cut

Every piece here points at the same move, and it is not fancier prompting. It is making the model's job smaller and more checkable. Vo's harness fixes the steps. Yadav's loop and guardrails fix the behavior. Babich's MCP rules cut the tool menu. RAG hands over the evidence and demands a citation. You are trading a clever wide-open model for a narrow one you can audit.

So the real question on Monday is not "which model." It is "can we show where the answer came from, and can someone other than the author run this again." If the answer is no, your AI work is still a demo. Pick one repeatable workflow, wrap it, and make the output travel. That is the difference between a party trick and a tool your team keeps.

Three questions for your team

• Which repeatable workflow are we still hand-prompting every time, and who owns turning it into a harness or plugin this quarter?
• When our agent breaks, do we know if it's a harness problem or a loop problem, or do we just rewrite the prompt and hope?
• For any answer that touches a customer or a regulator, can we point to the exact source line, and if not, why are we shipping it?