Chance Peragine

Reading, Pennsylvania. Still late.

I’ve spent my life building context, and it’s heavily compressed. I know how things really go, even where I’ve lost the details.

The model’s is a million tokens of detail, and none of it lived.

We cover each other’s weaknesses.

This issue is about the two halves, and how I put them together.

At work, I build on Salesforce inside a big company’s rules.

There’s one approved AI chat, and it can’t see any of our systems. Nothing gets installed. Approval for anything new can take months.

I don’t get to change those rules, and I’m not trying to. Big companies guard the data that matters most.

My team knows our org the way you know a house you’ve lived in for years: why a field exists, which flow nobody touches, what the business really means by a word.

But the model only knew what we typed. Every chat started blank, and one good prompt could take an hour to put together.

The model was smart enough. It needed our half.

In use

One web page. It runs offline and sends nothing anywhere.

You point it at the project. It maps how the pieces connect: which flow touches which field, which class calls which.

A short brief, written once, holds what only the team knows. The files hold the detail. The prompt carries both.

You paste it once, into the tool we’re allowed to use. The one rule: no data is ever sent anywhere, and it’s built so it can’t be.

Pre-release

On a big team, a lot of people build flows right in Salesforce, where there’s no version control. Two people change the same flow, and one of them loses their work.

My first plan was a copy of Flow Builder with extra features. The agent read Salesforce’s developer terms first. They forbid copying its interface.

It was right. A few hours later the plan was down to the two things my team needed: see every change, and merge without losing work.

It knew the rules, and I knew my team.

Then it was my turn to steer.

I asked for a diff “like GitHub,” and the agent took me literally. What I wanted was the flow itself on screen, every change lit up in color, and the same view for merging. That became the main selling point.

Built to the bar Salesforce sets for apps that other companies install.

It’s a managed package from my own company, Sunwave Studio, and it isn’t on the AppExchange yet. When I showed it to someone on Salesforce’s Flow team, the advice was to keep going.

These days the agents write most of the code. Two of them, with different jobs.

Opus 5.5 is by far the better builder. But in code review, Sol 6.1 catches bug after bug.

So Opus builds, and sends finished work to Sol.

Opus fixed every one, each with a test that fails without the fix. Sol checked the fixes twice more.

Each covers the other’s weak side. I decide what done means.

I keep trying to make the work cheaper. Never at the cost of quality.

The agents often tell me an idea won’t work. I try it anyway.

For video I tried a different split: Opus made the calls on taste, and the more efficient Sol did the heavy lifting.

The same request for a 15-second ad, three ways. Nothing said which was which.

I dropped the pair that evening. The wrong model can turn out days of work you throw away, and the savings never cover that.

Give each model the job it’s best at. When you can’t tell, test them on the real work.

In development

By September the models were so good that I had become the blocker. Agents finished their work and waited for me.

Ophio is an Android app with a desktop companion. Start real work from my phone, see what’s actually happening, and stop it.

Four questions run through it. Did the agent have its real tools? Was “working” true? Did the answer reach me? Did Stop stop?

Private

For people who know exactly what they want from a 3D model, but can’t draw, model, rig or code it.

Point at the part, pick the frame, say what should change. Drafts never overwrite the original.

The plan is to bring it into Ophio as a plugin.