1 - I Gave It the Code and Not the Org
On December 28, 2024, I prepared a Markdown file, gave it to Claude along with my code, and asked him to produce an integration piece.
The requirement was considerable. An external system would send a request body containing a multi-object structure, which had to be mapped to several Salesforce objects simultaneously, with all changes committed in a single transaction and any failures properly managed. I needed a parser class and an error log that would function even if half of the payload failed. The response sent back to the external system had to be structurally altered based on what occurred during the write operation.
I wrote the parser, and it was good; in fact, it was better than I would have built that same evening, and it turned out to be more careful about transactional boundaries than I had expected.
The model did not account for my organisation's unfamiliarity with my custom objects and fields, the inherited error log structure, or the expected integration behaviour when a payload was only partially valid. I had to explain all of this - often more than once - because a single explanation was never enough.
2 - The Time Went Somewhere Else
The feature took much longer to complete than it should have, and most of that extra time was spent on tasks other than actual engineering.
I spent an inordinate amount of time just describing an object's structure so the model could generate a few correct lines of code. Each session required re-explaining the same context as the day before because neither the markdown file nor the chat window could retain organisational context. This constant need to re-establish context stalled progress and made it clear that the real issue was not with engineering, but with process.
I initially believed the problem lay in how I was prompting. I thought that by refining the file, giving clearer instructions, or better organising context, I would eventually eliminate these difficulties. But no matter how much I improved my explanations, the need to explain never went away. It took me several months to realise that getting better at prompting is not the same as eliminating the need to prompt altogether.
The model wasn’t the limiting factor since it was capable of producing Apex by December 2024; the problem was that it couldn’t see what it was writing Apex against, and I was the only link between the two. That limitation set up the next shift in the story, where someone else named the pattern.
3 - Someone Else Named It
In August 2025, during its second week, I read Dan Shipper and Kieran Klaassen’s article on compound engineering and listened to their episode on the AI sandwich.
The idea behind the sandwich is simple, and I have never managed to do better than it. People are in charge of the two ends: deciding what is worth building and judging whether the final result seems right. The agent deals with the middle section. The advantage isn’t speed; it’s that each time it goes through the middle it leaves something behind which improves the following pass. That was the bridge from prompting to process, and it led directly to the next step.
Looking back, I see that naming the work ‘prompting’ shaped how I approached it. For eight months, I manually supplied context and called that process "prompting," which limited my thinking about how to solve the problem.
4 - I Spent the Next Year Building the Middle
I began building that in the same week, and the first thing I constructed wasn’t a plugin; it was a sequence.
First come the ideas, then the planning, then the work, then the review, and then there’s the stage that I referred to as compound. I acquired the insights during the run and saved them to a properly formatted file rather than letting them disappear at the end of the session. The arrangement involved humans at both ends, according to the sandwich idea. There were gates in the middle, since an agent that never stops is merely a quicker way to get it wrong. That structure is what made the middle worth building, and it led into the compounding loop.
The step that concerned me was the compounding one. Each time I solved a problem, a file was left behind. The following run would read those files before carrying out any research of its own. That was the entire stake - the loop should be better each month, even if I hadn’t become any smarter in the meantime.
It went through several versions, most of the changes involving removals. In the current version, command-based routing has been removed, and everything has been moved to skills. The agent now selects the appropriate step from a description rather than me having to remember a command name. There are sixty-eight skills, under them sixty-one specialist personas.
I also worked on what appeared to be a detour and wrote a converter which would allow the same skills to be installed in Cursor, Codex, Copilot, Gemini, Windsurf, and a few other services. I didn’t want a working method that was only available within one vendor’s tool.
It lasted from August 2025 until mid-2026; by then, I had not built anything, knowing what Salesforce was going to launch, and that brings the story to the page that changed the frame.
5 - Page 259
Finding what matters.
The release notes for Winter ‘27 run to 1,010 pages, and page 259, in Headless 360, records an official Claude Code plugin. That matters because it shows what the platform can solve.
It can be obtained from the marketplace, identifies the Salesforce DX project it is part of, and provides Salesforce-specific skills and organisation through hosted MCP servers. It has a language server which notifies the agent when its Apex code will not compile before deployment. At the same time, Salesforce described Agentforce Vibes 4.0 as a complete re-engineering, rebuilt on its coding-agent platform with Claude and Mastra underneath.
I went through that page twice not because I was surprised that Salesforce would take this action, but because of what they have built; the plugin provides the agent with the org object metadata, the API context, and live validation against the actual compiler.
The platform has resolved my December 2024 problem as a product: it provides competence, not a method. That distinction is the central claim the next section develops.
Headless 360 releases updates monthly, so most people who read the Winter ‘27 notes will not encounter them.
6 - Competence Is Not Method
The distinction I arrived at only became clear after I had installed both, and that was where the difference showed itself.
Salesforce has provided the necessary competence. The plugin makes the agent proficient in Salesforce by familiarising it with the platform; it can see the organisation's real compiler and then correct it. That is why this platform is better positioned than anyone else to develop it, and that is the basis for the next contrast.
It does not include a method of operation; there is no gate to go through, no point at which it stops and requires a decision on my part, and nothing that becomes smarter as a result of being used. If I run it on a Monday and then again on a Friday, it will pick up where it left off on Monday.
I applied my own loop to a requirement that I had intentionally filled with traps. I added up the closed-won amounts, recorded the date of the most recent one, and then sent an email to the account owner. There are five ways to get it wrong, and each will compile.
Claude didn’t write the trigger; instead, it checked whether a native roll-up summary would actually be legal in that organisation, trying out a dry run that didn’t make any changes, rather than assuming it would be, then received an answer, then separately verified the second half and returned two declarative fields together with a record-triggered flow.
An official Salesforce plugin has found that the custom roll-up is unnecessary, as the native Roll-up Summary addresses the issue.
Apex written: none - what my plugin inside Claude Code has found when one of the research agents used in that run achieved a time of two minutes and four seconds by itself. If I had used a single-shot answer, I would have obtained a competent bulkified trigger in a fraction of that time, and that is a real cost which I am not going to pretend doesn’t exist. A language server can only advise me on whether the code I have written is valid; it doesn’t have any opinion about whether I should have written it. I should have written it, and that leads into the final distinction between their advantage and mine.
7 - Theirs Is Better Than Mine
About what they constructed, they win, and the victory isn’t close.
My plugin includes skills and personas that have a deep understanding of Salesforce patterns. Knowing patterns is different from a compiler pointing out that I’m wrong; it involves a fact-checking stage, whereas I have some very well-read advisors. I’m narrowing the gap between the two by using verification gates rather than by setting up a language server, since it would be a bad idea to reimplement a compiler that I don’t own, and I prefer to state that clearly rather than have someone else point it out.
8 - The Half That Stays Open
I have been in favour of agentic Salesforce development for two months, mostly expressing this view publicly. In August, the hand-work I had done had become infrastructure, since that is precisely what ought to happen to any task no one should be doing by hand.
So here’s the claim I’d defend. The platform will own competence and keep getting better at it, because org context and compiler feedback are exactly what a vendor can solve once, for everyone. The remaining question is who owns the method, and that leads to the final section.
The approach is different: when to stop, what to check before making a decision, and when the correct result is actually no code at all are subjective judgments. A vendor who has to serve all customers must remain neutral. A neutral approach isn’t an approach at all; that part remains open to whoever carries out the work. That is the half that stays open.
I am incorrect; Salesforce might include an opinionated workflow in the next release, in which case I’ll have to rewrite this paragraph.
Until then, the useful question has moved. It used to be whether the agent could write the code. Now it’s whether the code needed to be written, and that’s the first thing I’d ask any tool to prove it can answer.
The Salesforce Development plugin is available at salesforce-development@claude-plugins-official and is documented on page 259 of the Winter ‘27 release notes. Compound engineering is Dan Shipper and Kieran Klaassen at Every. My own plugin is on GitHub, and it addresses half the problem, not the whole.
