We ended up building our own test platform to reduce the human bottleneck in the verification loop.

Takes the form of a hermetic test environment that run all our code and infra in a way that matches production. Our tests interact with it from the ”outside”, e.g. by driving a browser, a terminal or making API calls.

We still have coding agents writing those tests but the big difference is that we record the browser and the API calls and can review and verify through a UI without having to do any manual testing. It also serves as a regression test suite with E2E coverage, which is kind of a must to avoid coding agents making assumptions and breaking things.

Not a huge fan of the term ”software factory” but working like this I actually think it’s achievable.

I hope they will get that boost, but I'm afraid that they haven't built credibility so far to convince governments to buy in at the level needed. Their slip away from the frontier might even have made governments more cautious on investing in AI development, which is the opposite of what we need right now.

That's not to say I don't hope they will. It would be incredible if they could do that despite their limited funding and the wide swath of projects they are working on. I do think that lack of focus is going to be a big problem.

One thing I'm inclined to believe though is that the investment being made into compute and research today may not benefit the investors, but it will be net-positive on a longer time scale for the wider populace. A comparison to the internet and the dot-com bubble seems fitting.

And from that perspective I'd also be worried about the bubble bursting before Europe even gets started, as what remains after a bubble would still largely serve the US and China.

Comments URL: https://news.ycombinator.com/item?id=49210143

Points: 5

# Comments: 13

Hi Fabian, In May, we sent you an email announcing that starting today, the Claude Agent SDK, claude -p, and third-party apps built on the Agent SDK would stop drawing from subscription rate limits and move to a dedicated monthly credit. We're writing to let you know that we’re not making this change today. We’re working to update the plan to better support how users build with Claude subscriptions. What this means for you Nothing changes for now. Agent SDK, claude -p, and third-party app usage continues to work with your subscription exactly as it did before today, and there's no credit to claim. Your subscription limits are unchanged. When we have an update, we'll share it with advance notice before it takes effect.

Comments URL: https://news.ycombinator.com/item?id=48546618

Points: 36

# Comments: 12

No code lock-in through SDKs and built on top of AWS with great DX for both developer and coding agents

A bit of a different approach from the classic use case of docker-compose that is often orthogonal to the production infrastructure in some sense.

One thing I've used to great success though is taking an existing project or example docker-compose and simply asking the coding agent to translate it to Specific's IaC. Works a treat, especially as the coding agent can read all the code at the same time and connect it all together.

(also it looks like we were in the same batch!)

Our approach is having our CLI handle port assignments (and pass any connection details/ports along as env vars) and that way being able to spin up “isolated” copies of the local dev environment. Has the added benefit of us being able to deploy the same config straight to production and switch in production database connections strings and anything else needed.

Part of this is a reimplementation of PostgREST, but as a Typescript library. The big difference is that this is designed to help you migrate away from the auto-generated and to an API that is better designed for your actual use case. That’s why this is a library so you can integrate it as part of your backend and gradually replace the PostgREST parts

The storage part is really only for Supabase-js, yeah. The idea being that folks will eventually move to a model where they integrate directly through S3 (if they want)

There has been a lot of talk recently about the reliability of Supabase and migrating away to other database providers (or even hosting Postgres yourself).

I'm a big proponent of writing actual backend code rather than locking yourself into frameworks like Supabase. If you already built all your client-side code around it though, then migrating is not a trivial task.

Replacebase is designed to help with that. It's a Typescript library that you can plug into actual backend code that exposes a Supabase-compatible API so that you don't have to make significant changes to your frontend.

It's designed to be a stepping stone for further migration, letting you switch database and storage providers and eventually move to a bespoke backend architecture without Supabase lock-in (at which point you can also remove Replacebase!)

Would love your thoughts: https://github.com/specific-dev/replacebase

Comments URL: https://news.ycombinator.com/item?id=47154281

Points: 6

# Comments: 2