Vibe Solutioning: automating the solutions workflow with Claude Code

Draft. This is the public version of the internal "Vibe Solutioning" guide I authored at Salesforce as one of the earliest internal advocates for Claude Code. Names and internal specifics are generalized.

Solutions work is mostly translation. You sit between a customer's messy reality and a platform's clean abstractions, and your day is spent turning one into the other: discovery notes into architecture diagrams, architecture into demos, demos into enablement decks, enablement into follow-up. Most of that translation is mechanical. Very little of it is the actual thinking.

Vibe solutioning is the practice of handing the mechanical translation to an agent so you can spend your scarce hours on the parts that need a human: judgment, trust, and taste.

Why an agent, and why in the terminal

The instinct is to reach for a chat window. That works for one-off questions, but solutions work is not one-off. It is a repository of context: prior engagements, reference architectures, naming conventions, the specific way your customer talks about their own systems. A coding agent that lives where that context lives, with the ability to read and write files, run commands, and keep going without you re-pasting everything, changes the economics.

Claude Code in the terminal gets three things right for this workflow:

• It reads the whole working directory as context, so your reference material is available without ceremony.
• It takes multi-step actions and verifies them, instead of returning a wall of text you then have to execute by hand.
• It is scriptable, so the workflows you discover once become workflows your whole team runs.

The loop

Every good vibe-solutioning session follows the same shape:

1. Load the context. Point the agent at the discovery notes, the org metadata export, the last architecture doc. The more grounded the agent is in the real engagement, the less it invents.
2. State the outcome, not the steps. "Draft a future-state integration diagram that respects their existing MuleSoft investment" beats a list of clicks.
3. Let it work, then verify. The agent's first pass is a draft, not a deliverable. Your job shifts from producing to reviewing.
4. Capture the workflow. If it worked once, write it down as a repeatable prompt or script so the next person does not rediscover it.

That last step is what turns a personal trick into an org capability. The guide exists because the loop was worth standardizing.

What to automate first

Start with the work that is high-volume and low-judgment:

• Turning raw discovery into a structured requirements table.
• Generating first-draft architecture diagrams from a description.
• Producing enablement and follow-up material from an engagement's artifacts.
• Building throwaway demo scaffolding so the demo idea, not the plumbing, is the constraint.

Keep the human firmly in the loop for anything that touches trust: security posture, compliance claims, and anything a customer will treat as a commitment.

What I learned advocating for it internally

Adoption is a trust problem, not a tooling problem. The engineers who adopted fastest were the ones who saw the agent verify its own work and caught it being wrong in front of them. Transparency built more confidence than any demo of a perfect run. That lesson, more than any single workflow, is why the practice spread.