A lot of organizations right now are dealing with the "Claude says..." problem.
It's not that you should never include any AI generated text in a conversation with other engineers, but you mostly shouldn't.
AI is a tool to help you understand/debug/review yourself, but you shouldn't be conferring authority to your AI (because it doesn't understand anything and is often wrong in the text it spews), and you shouldn't be running an AI for other people, they should run it themselves.
You can just look at the diff when you do a pull request, no prayer needed, and if you want it to be “surgical” in that way, your prompt (and agents.md) can be specific.
You can also unit test the function to better assure behavior didn’t change.
I’m fine with bulk review, it just has to get reviewed before a merge. You don’t need to review the LLM output as you work except as it aids you to work.
LLM editing should be done to produce deterministic output.
That is, the LLM should produce a diff, and the user should accept the diff. It seems like a bad pattern to just tell the LLM to edit any long document without that sort of visibility. Same goes for prose as for code.
For my marketplace, I was friends with someone who could make it look like not a ghost town for the supply (an established game store with lots of trading cards in stock). Then, we struggled to get more sellers. Then, we found channels to get selllers, which were basically software systems we could build integrations with. The integrations de-risked the proposition for sellers enough to get more traction. Eventually, if you have growing volume, the supplyside just starts coming on its own mostly, and you focus on retaining sellers and growing buyers.
For your marketplace, you could bring the supply-side by Fedexing stuff when you don't have a carrier. You'll have to lose money on the initial shipment, until you can route the jobs to the supplyside. This assumes you think the typical use case for this isn't smuggling.
The amount of jobs may be low enough at first that you can be like "You said Cairo to London, that will be $N." Then, if you can fill the job manually by finding someone somehow, then you add them to the platform and they do the job. If not, you send a prepaid mailing package with a Fedex label to the recipient and they ship it easily, and you subsidize it so it seems like a great deal to them.
Limiting geography seems like a good approach too.
We use Mercury’s treasury account to get yields on cash, and what appeals to me is it is easy to manage. I don’t have to worry about setting up processes to move money around and it’s integrated with my bank account, and we wouldn’t want to switch even for a higher yield… the operational burden is more important to us than yield.
I think the yield is about 3.2% based on how we set it up to be as liquid as possible. We could have accepted less liquidity for more like 3.8%
This doesn’t read to me like it was personally written by one person. It’s not Dario we should read this as being written by, it’s Anthropic as an entity.
This is neat, I have a simple CSS effect that I apply to foil cards on my Magic card marketplace site, but I have wondered what it would take to replicate all the different foil effects that a Magic card can come in to be both more varied and more true to life, in a performant way that fits into my CRUD svelte UX.
This almost exact thing happened with me with a hiking app I used to make. We had a 7-day trial when you started the app, but we shipped a release that broke this and made all the paid features immediately paywalled. This led to a big increase in sales and we got rid of the trial forever.
It’s possible that our trial might have worked better if it were like modern iOS trials that start charging you after a certain period, but ours just let you use the paid features for 7 days and then lapsed, and it stifled sales. My theory was people urgently needed the paid features (mostly to download maps for a coming trip) so the trial got in the way of them paying right away.