cnj

What was your prompt? Literally "Push the project further"? Then the behavior wouldn't be very surprising.

As you probably know, you have the Plan Mode available - personally I'm also a big fan of the OpenSpec workflow. If you've agreed with Claude Code on a much tighter plan, and then it started signing a contract, I'd be concerned.

No, I'm Chris :) But if you know Yosh well, would be happy to connect and compare notes!

I've had Claude Code drive DaVinci Resolve before in three ways: - Generate .otio files that are imported. Unfortunately, .otio doesn't fully support everything Resolve can do. - Resolve has a scripting engine. Claude can write Lua scripts, then execute the script (through UI Automation) - Computer Use. It's quite token intense, but it works.

I didn't try it, but for the paid version, someone also built a MCP server based on the scripting engine.

I'm programmatically adding analysis to sim racing lap guides, therefore my flow is probably different from the usual editing flow, but I have to say I found Claude Code + Opus to be quite capable of making edits with computer use.

The problem I have: The CEO (and the investors, or the whole industry) is obsessed with ARR per employee. That's the key metric (in their mind).

It doesn't matter how much the employee costs. Let's assume you can hire two Juniors or one Senior for the same salary. If you have to optimize for ARR per employee - you can only hire one person. And if you have the choice between hiring a Junior or hiring a Senior... you're going to hire the Senior.

Goodhart's law fully applies here.

It never occurred to me that Goodhart's law could be applied to betting, but here we are :)

I predict that Anthropic will clamp down on the heavy agentic use of Claude Pro, the cost gap between Claude Code and this approach is HUGE...

Anyway, I'm doing the same - one extra tip is to use the "project" feature of Claude Desktop to give your coding assistant some context - use it similar to .cursorrules.

> The data exposure was discovered following an internal investigation conducted voluntarily by Kaiser Permanente. The company discovered that online trackers used on its websites and mobile applications were transmitting certain types of personal data when users interacted with its services.

I have respect for the individuals that started this investigation, and the ones that made sure this is publicly disclosed. This could have easily been swept under the carpet.

Actually, that they uncovered this on their own and publicly disclosed it sounds like they have an above-average privacy culture in place.

I know the odds that the person(s) who kicked off this investigation are reading this comment are very low, but if so: Kudos, well done!

I think your criticism of the term is somewhat valid, in the end these are just back-ends with APIs :)

However, the point the platforms are trying to make is that their APIs have been written with the explicit purpose of building a frontend ontop of them later on.

A lot of the old-school platforms have some APIs as well, but they are meant to e.g. import products or export orders. They are not meant to implement a frontend on top of, because they have a frontend engine as part of their monolith, and many functions you need to write a proper frontend will not be available through their APIs.

So the term "headless" means "we have APIs, and they are designed for you to build a frontend on top of".

Full disclosure: I work at commercetools, another player in the space.

The movement towards "headless", API-first platforms has a lot of steam. So much so that older platforms (e.g. Salesforce) are jumping on the bandwagon to stay relevant in the market.

That said, I know there are a lot of startup-focussed readers on HN. This trend is for larger companies who want to really own their customer experience, including their own frontend. You'll have more flexibility, and using an API-first platform will be a lot less work than writing your own backend, but... it's still more work.

If you are small, you need a quick MVP etc. going with a Shopify or BigCommerce is the faster way to start selling. Once you've got a good stream of revenue and you're feeling these platforms are too rigid, looking for an API-first platform is a good idea!