Sam Goodwin - Alchemy

Speaker A: What if we had infrastructure as code and bindings for the whole cloud? Well, now the cloud is a library. That's it. Like, that's, that is the conclusion. The whole cloud becomes a library. And now the only thing stopping you from using the whole cloud is which accounts you have. That's it.

Speaker B: Hello. Welcome to DevTools FM. This is a podcast about developer tools and the people who make them. I'm Andrew and this is my co host, Justin.

Speaker C: Hey everyone. Uh, we're really excited to have Sam Goodwin back with us. Uh, Sam, it's been a little while. Uh, so last time we talked about Alchemy, this infrastructure as code project that you're working on a, um, lot of cool stuff you're doing back in the day. And you've just recently released Alchemy V2 and we're really excited to talk about that. Um, but before we get dive in, would you like to refresh our listeners and give another introduction to yourself?

Speaker A: Uh, sure, yeah. Uh, Sam, uh, Goodwin. Been working on a product called Alchemy for the last two years, but my background is very much just cloud software. Spent roughly eight to ten years at, uh, Amazon. Uh, he said Microsoft there, uh, Amazon aws building stuff with the cloud. So I've just been doing that for so long and I've always been opinionated about how you should do that. So that eventually led into starting my own company. Lots of different iterations on ideas, eventually landing on Alchemy v1, which got a bit of a, bit of a spark going with some users. And now Alchemy V2 takes it to the full fruition of what I've been dreaming for the cloud.

Speaker B: Yep, sweet. Just to fill our listeners back in who might not have been with us back then, can you, uh, fill us in on what Alchemy V1 was and like what it set out to do?

Speaker A: Yeah, so it was a infrastructure as code tool built natively in TypeScript. So if you've used infrastructure as code before, it's always multiple different layers. Right. You're either working with a service like Confirmation, or you're working with another tool chain called Terraform, which is its own custom language, uh, for infrastructure. And then there's tools on top of that like Pulumi, uh, sst and they build on top. And yeah, you just end up with this complexity explosion. And so I built Alchemy V1 was like, hey, look, this is not that hard. Let's just write some functions that stitch together infrastructure. And that's what I built there. And it was all about Async code. Um, and it threw away one of the most important things of infrastructure's code, which is planning. And I think that was both a good thing because people love just like ripping, but also a bad thing. I think it like, limits the scale of the product. So Alchemy v2, which we can talk about a bit later, fixes, uh, some of those problems while keeping it still native Typescript, um, but takes it a lot further. Um, and really goes into the AI story. In V1 I was experimenting with, like, the idea was infrastructure as code is all in these old tools because no one wants to go build all the resources. That just takes so long and it's boring work. But at that time, AI was just getting good enough to the point where it could write them. It, uh, wouldn't write them perfectly, but it would do a pretty good job. So that was what I pushed into that. I was like, hey, let's just build our own resources. Let's do away with the past. Uh, and that has now become supercharged with Opus 4647. Resources really do print themselves now. So taking, uh, things further in the

Speaker C: new version and when we're talking about resources here, it's like really APIs to whatever service you're deploying to.

Speaker A: I really should clarify, uh, resources mean like configuration of what's called your control plane. It's like, oh, I've got a database with these settings, I've got this many EC2 instances with this much memory. Or it's all the work you have to do to go configure. That is what we call infrastructure as code. Or they're cloud resources. But a resource is really just anything that has a create, update, delete, lifecycle. That's what it is. Um, and traditionally it's really annoying to stitch those together. So people built infrastructure as code tools that automate the stitching part. Uh, and then everyone built on top of that. And now I think we burn that to the ground and we build up again AI, because we don't need, uh, I need to pass anymore. Because that breadth of infrastructure as code can be covered with AI now. And now a few people can build it.

Speaker C: So you've been at this for what, about a year? Ish.

Speaker A: I think Alchemy V1 was February or March of 2025.

Speaker C: Nice, nice.

Speaker A: And it was very cloudflare oriented and sort of got my wedge in there.

Speaker C: Yeah, very, very cloudflare oriented. That was like one of the things that sort of caught my attention, uh, when you were first Releasing it, um, now you're like hitting a lot more like cloud targets. Um, and also like another big change of V2 is you're building it on effect. And maybe, maybe we should just talk about effect, uh, first, because, like, that's a really important baseline for this. So what does effect and why are you using it?

Speaker A: Yeah, I kind of buried the lead there. Yeah. Alchemy v1, we call async alchemy. It's not v. V1 is like, you know, one generic way to say. Honestly, we call it async Alchemy internally. And then there's Alchemy effect, which is rebuilt on, obviously. Effect. What is effect? Okay, uh, geez. Uh, I've been asked that question a few times. I don't know if I'm the guy to say it, but, you know, it's. It's almost its own programming language within, uh, within TypeScript, but it's for modeling concurrency safely is what I would say. So it's an effect is basically a promise. You can think of it like that. It's an analogous, um, but it has more information about it. It's got a return value just like a promise, but it's also got errors that can be thrown. So you know, at the type level, which errors can be thrown. Uh, which means you can get instant feedback for like AI. If you don't handle an error, it's a type error instead of a runtime error. And that's obviously better for feedback to the AI. And it also has information about its requirements. So it's like, oh, in order to run this effect, you also need this database, you know, or you need this logging system or whatever. So you can model all that with an effect. And it has this concept also called layers, which are a way to sort of compose little components together and then you stitch it all together into an effect and you can run it. And that's effectively your program. Right. Um, so there's a lot of great things in there that we really need. So first off, Alchemy v2 is really all about AI. And effect is a neat. Is something we need to do AI. Well, we're calling the like, the whole tagline is zero to production right now, which is like, how quickly can you go from a blank screen to actual production ready discipline, you know, uh, streamlining, all of that. And the one big part of it is AI needs to be able to iterate really quickly and for that it needs feedback. So that's all about pushing as much of it into the type system as possible. Uh, and then building good tools, tools around that. So Effect allows us to model more in the type system that you just can't do with Async code, but also it allows us to build really, really good resources. Because most of the time when we're building asyncalchemy, you're flying blind. You're working with a cloud provider you call some API and they never model the errors. You just never know. You never know until you run it what the errors get. Um, but with Effect, what we started doing is we built this other project called Distilled, which is where we're using AI to generate effect native SDKs for every cloud provider we can think of. And it goes and patches all the errors. And once you have all that, you can just ask Opus to build you a new resource and it will use the distilled SDK and gets all the feedback and it can do the really annoying things like retries. One of the biggest things you need to handle in infrastructure as code is eventual consistency, which is basically, oh, I tried to do this thing and then do this other thing, but it hasn't propagated yet, so I need to wait or I got a little error here that blipped. Let me just retry that. Let me retry it. On this policy in alchemy v1 that was all generated like just while loops and crap from AI, uh, with. With effect, they've built those primitives into the framework so you can just be like this effect retry with this policy while this error and it becomes declarative. So you take something that's really complex like retries, schedules, jitter, uh, all these things, and you put it into one declarity function. Call that AI can just use everywhere. So all the code now looks the same. Call this Effect with this retry policy. Call this effect with this retry policy. And now the resources just work. So, and that's the, that's like the big lift we get like that effect native SDKs generated by AI is our pipeline to then AI generated infrastructure as code. If you can solve effect native SDKs, you can basically solve infrastructure as code and generate the whole surface area. So we're going for gcp, Azure, aws, Cloudflare, everything, and we're doing it by generating Distilled and then propagating that up to output. Uh, so there's a lot I could talk about with why we use Effect, but that's like, the first thing is like, it's just really good for building reliable applications.

Speaker B: Yeah, it seems like the errors are Probably a huge part of that, too. Like, I found that in my AI AI coding journey is that the feedback loop needs to be super tight and being able to model those errors, that. That seems like it was probably a huge lift. Like, distilled sounds like, uh, to. To my untrained ear, like, just an enormous amount of code. So, like, how much are we talking there? Like, how much code have you been pushing with AI?

Speaker A: Uh, too much that ts, like, you can't compile it with typescript. You have to use TS Go. You have to use TS Go, uh, and cursor choke. So you got to move to Zed.

Speaker B: Oh, man.

Speaker A: So it's a big repo. The insight there was everyone's got, like, these cogent tools, and they work for the one spec they've been tested against. And then you realize that, like, there are these things called open API specs, but they're not even real people. They're not actually real specs. People just make it up as they go. There's no standards. Most companies don't put their errors in there, but most people don't even model APIs the same way. You know, they really just, uh. It's a suggestion. It's not really a spec in my experience. So these tools, like stainless and stuff like that, they don't work that well. But the realization is you don't need them. The code generator is AI writing code. So all we do is we just have a script that will go and get the spec, throw it into an agent that we've sketched out. We've basically built this little script, um, that will generate the SDK and it will deal with all the edge cases. Like, oh, this API models things in this way, and it just, like, adapts to it. So each one is, like, custom handwritten. That's the thing. It's like you don't build one code generator and then go apply it to every SDK. You just build a custom one for every SDK and that's what actually is needed. So, like, there's millions. I think I had like a 3 million line PR once in there. Uh, there's. But, like, that's not all AI generated. That's deterministic code. We're using AI to generate code that then generates code. It's like double lift, right? So you get this double leverage, and that's how you get into the millions of crazy lines of code. Um, but yeah, that has been really cool to see happen. And again, just reconfirms my idea that, like, breadth is solved by AI Like I've got, I've got a process right now where I'm improving 50 resources at the same time. One prompt, 50 resources at the same time. Usually before AI, it'd just be me sitting there working on one resource. Okay, I gotta get this retry logic better, uh, because it's not working now. I can do that, but scale to like 50, scaled to 100. Uh, yeah.

Speaker C: Software engineering is a challenging job and it's harder when you're forced to constantly context switch. You have email in one tab, Slack in another. Five different Google sheets. So many accounts to keep track of, it can feel like half the job is just dealing with organizational overhead, when really we just want to be writing code. That's where Macro comes in. Macro is a tool to cut through the noise. It's a workspace built for engineers. It's one place for all your emails, your tasks, your chat and your documents. The best thing is the source code's available. So if you want to peek under the hood to see how it works, you can definitely do that. If you want to extend it, feel free. The back end is in Rust and the front end is in Typescript. It's easy to extend to make anything custom. And the cool thing is Macro will pay contributors for any features that they land. So if your team is tired of bloated project management, or maybe you're just like starting fresh and you just want one tool instead of many, give Macro a try. It's fast, it's fun, it's a better way to build. Sign up@macro.com and get $100 off your subscription using DevTools100. So it seems like distilled really is the uh, underpinning of success for alchemy. You need that conn to these resources, to these like, services or whatever to, you know, have infrastructure as code, be a useful utility. Mhm. Um, and there's a lot of code there. Um, so you've talked about the code generation strategy. Um, how do you test all of that? Or how do you, like, you know, how do you. What, what gives you the guarantees that it is like, reasonably correct?

Speaker A: Well, we have a, uh, process called error discovery where AI will basically use the, the APIs and run into all the errors and then pat. And it does that, it does that interactively and then it writes tests for each of the errors that it finds to guarantee that it finds, that it finds the errors. But we also have, uh, we work backwards from Alchemy now it's like now that we've got it to A step where we've got SDKs generated pretty well. I actually just have AI work on Alchemy and then when it finds bugs and distilled or missing errors, it submits a patch back. So you get this like, beautiful working backwards from requirements experience. Like we don't have to go cut the whole problem. It's like just work backwards. Uh, so Alchemy is sort of paving the way there. We do the best we can and then we just have a flywheel that just continuously improves. Continuously improves. And you run the Alchemy test and that's basically the whole. That's exercising everything you could about a resource. Right? Create in this way. And then I update in this order. And I did that first and that second. Like all those different edge cases are captured in Alchemy. So we run into those errors all the time and it really just battle tests and hardens. Distilled. You can get by without distilled. Like, I wouldn't say, uh, you know, we couldn't build Alchemy without it, but it does pay to have a really beautifully typed performant effect native SDK rather than every. Every time you have to go figure out how to bolt on to some existing API. One's generated with stainless, one's generated with some random thing. They're all weird and they never really

Speaker C: help you that much.

Speaker A: So, yeah, uh, I don't know if we want to move on to it straight away, but like for now we've just talked about infrastructure as code. Alchemy v2 is far more than infrastructure as code. We actually call it infrastructure as effects. Uh, which has a whole new meaning in my mind, uh, which basically merges runtime code and infrastructure code into one is what it does, uh, in a way that's principles or builds on top of infrastructure as code. And then you layer on the application code and then you basically get inferred infrastructure from your application code. So the feedback loop for AI is the type system is guaranteeing your infrastructure is correct. So that whole class of problems is erased. Now it's if it compiles, the infrastructure is correct and then you can just instantly run the tests and that tells you the runtime's correct as much as you can. And now you're already pretty close to production. And then you generate resources for observability and monitoring and you turn on observability in effect. Something I forgot to mention, uh, is OTEL comes for free almost in effect. If you were to do OTEL without effect, it's so much work. But in Effect, you could like, we can already give you spans, we automatically give you all the spans and then you can just annotate it with data. So we have beautiful metrics now. So that's all part of production, right? Production is not just writing an app and getting it out there and getting it deployed, it's maintaining it, it's monitoring it. You know, that kind of stuff.

Speaker C: Yeah, having opentelemetry before support can effect is pretty cool.

Speaker A: Yeah.

Speaker C: Um, yeah, I want to, I want. This is like a thing that I wanted to ask you about very explicitly. So to kind of recap what you said. We have infrastructure code which, if you've used Terraform or any other infrastructure code product, you've written that. And then we have application code. It's like your, you know, express handlers or whatever. And what you're saying is you've married them together where it's like in the same file or whatever. Potentially you have this infrastructure code and inside that infrastructure code you have the application code. And you get these like type guarantees from infrastructure all the way down to the application level, which is like really cool. Um, is that like, oh, horror requirement. Must you like, have these things together? Um, and what are the sort of like ramifications for like application level code?

Speaker A: Right. So I would say what we've done with alchemy is we built the right layers, right? Like, we're not the first tool to marry them together, but I think we're the first tool to marry them together in the right way. So if you use other tools, um, I would call them walled gardens, you know, like they've Encore or Nitric, they've gone out and they've solved this narrow set of problems and they've married infrastructure and runtime. And if you stay within that walled garden, you'll have a great time. But like, like any application, you never stay within the walled garden, right? So, but like, so our foundation is the pragmatic infrastructure as code. So you can deploy Rust, you can deploy Python, you can deploy anything. It, uh, it's not. You don't have to go and use this sort of married environment, uh, to get value out of alchemy. Like the bottom of that is just async. Alchemy with yield star instead of await is really what it ends up looking like. You get the same thing. You can still write your normal code, your normal way, whatever. Um, but then you can up level and you can be like, okay, let's move into, instead of working infrastructure, writing infrastructure and then going and writing my runtime code Let me just write my runtime code and have that define my infrastructure. Uh, and we do that via, uh, what's called in effect? It's called, I learned recently, I just went on their podcast. It's called the constructor pattern. This pattern is like magic. I think if you go and learn effect, it might take you a few times, but if you really start to grok, like just the flexibility and the repeatability of the constructor pattern, um, you'll understand alchemy too. It's based. That's what it's another word for a layer. But basically it's an effect that when it runs in the closure of the effect, it declares its dependencies. So basically think of it like setting up its state and then it returns the implementation. Very similar to like a React component where you'd be like, use effect, use callback, whatever. And then you'd return the DOM that reacts to it. Right. Kind of the same shape. It's like, okay, declare my dependencies, return the implementation of the service. We do that. So you just declare your dependency like database read, access, write access right there. And then you use it and then you just throw that in Alchemy. And Alchemy will automatically deploy and configure all those bindings and infrastructure and policies and things like that for you. But all you did was say, give me read access, call, read, give me write, access, call, write, set up my database connection, use my database connection. Everything reduces this very simple, very like. The best analogy is probably a React component creating a function declaring dependencies, using them, returning them. Yeah, so that's been like. That's what allows us to basically generate least privileged policies. Like AI naturally generates code in this order. It'll like, declare my dependency, use it. Declare my dependency, use it. Now you don't have AI going over to a terraform script and being like, uh, star policy permissions for everything. There you go. I have solved your problems. You know, you don't have this problem. It's like the code, just the permissions and the infrastructure emerge out of AI writing the application naturally. Yeah.

Speaker B: Are there other benefits that come from tying those two things together? Like in, uh, Alchemy V1, you didn't have that. So I'm sure a lot have emerged as you guys have built this out.

Speaker A: Well, you can. The best thing that I think is what comes out of is components. Like, so we, we packaged up Better AUTH as an NPM library. You just install it and you go, I want better auth on D1, or I want better auth on Postgres or whatever. And that brings infrastructure and business logic as a component that's basically like an embedded service. That's what people love about better auth is they can just embed that in their application. Well, let's take that to the absolute extreme. I want to distribute whole components of applications. Everything that's a SaaS right now can become a layer and I can just plug that into my effect program. So that's, that's really the unlock. With Alchemy you couldn't do that. You could have a component with some resources and then you'd have to go and wire up the info. You know, the application code, they just disconnected. You couldn't do them together. Uh, now I think we call it SaaS as NPM. I think I was talking about that last time. But this really makes it real, right? Uh, I can ship policies, application code that can be customized, configured just like any component. The benefits that you get from shared cn for God's sake, you know, in uh, ui, look at that. You can just spin together a UI because of something like shad. Well, we're going to do that for backend. Now I think about like AI sits down and goes generate me a company with payments and DNS and email handling and authorization and blah blah blah blah blah. Oh, and make sure it's production ready and give me auth. You know, Alchemy is probably the only tool that could realistically do that in one prompt. And uh, it's because of this model.

Speaker C: That's pretty awesome. The um, other thing that I, that I liked from your tweets about this was the like making sure you had the right permissions. Like you've set up the correct like IM permission for some AWS resource is like it would actually the type check would fail if the policy was wrong or something. That's like pretty interesting.

Speaker A: Yeah, well I've, I've, I, I went into a deep rabbit hole on that design, um, and ultimately went down the wrong road and then had to flip it on its head. But it's still the same result is you literally just can't do the thing that you want to do. For example, you try to get an object from a bucket that you don't have permission to. It's just physically impossible. In Alchemy effect, you have to declare the dependency or else there's no function to call. And by declaring the dependency and getting the function, you get the permissions, you get the infrastructure. I really want to hammer uh down is the order of those operations is What? AI loves AI. I brought this up on Effect Podcast too. Or affect office hours. AI likes to declare utilities first and business logic second is what it likes to do. And it annoys me so much. It always declare these shitty little insignificant functions at the top of my file and then the real thing at the bottom. So this leans into that as like insignificant helpers and bind it dependencies at the top and then use it. So it really aligns with that sort of left to right, uh, generation that AI has. So it just iterates. Ah. And then also our test suites just automatically deploy and rerun the tests. So AI can just sit there and just edit the code. The infrastructure builds itself, builds itself, builds itself. The tests are running, it's responding to the errors and boom. Now you have production, uh, ready service pretty much. Right. Um, on our website we have a prompt you can copy. Just drop it like it's. The getting started button is basically a copy button. It'll copy a prompt, paste it into your coding agent. It'll just interact with you, ask you what you want to build and you can build. It'll build the whole thing. I've seen on day one like we had like 50 people jump straight to CICD. Like I've never seen this. Like straight away our metrics are showing there's already all these projects in GitHub CI because it's because our tutorial, they've just gone all the way through to the bottom. Uh, so I'm going to add on to that next. I'll add observability and then suddenly they'll all have observability. It's like scripting this little open source community. We put out tutorials and tools and then their AI is integrated and it's like, it's incredible what's possible these days.

Speaker C: So one of the things that you mentioned earlier, from the big difference between V1 and V2, so in alchemy Async, you were sort of just like imperatively setting up like services, right? You're like, it was just basically a fancy wrapper around the APIs. Um, so it's like I'm gonna set up a R2 bucket or whatever and then you know that's set up and you move on things. And Terraform, I'm not sure if Terraform really is the one that uh, made it famous. But like all, pretty much all the infrastructure as code products now have these like plans. So it's like, here's the things that I'm going to do to set up and this order and like, you know, like gives you a chance to like see what's going to happen and then it like does it in this like sequence. Um, and so you mentioned like in V2 you have some sort of plan mechanism. So what does that look like? Um, and maybe as a follow on like how did it affect and or your new approach, like make that easier or possible or.

Speaker A: Yeah, yeah, well you're right. Like it's an older idea. Alchemy just did away with it. Uh, because we leaned into like if you await, ah, the resource you can get back the actual values. If you look at things like pulumi or SST or cdk because it's all planning based, you weren't able to get the string. Like I got the worker URL. Well, in Alchemy, Async alchemy, you would await the worker and you'd get it back and you could just print it. It was there. Uh, but of course that came with the. I had this massive assumption that everyone would know how to control their own concurrency. And I looked at everyone's application, it was literally just await, await, await, await. I'm like, oh, okay, that's uh, that's a problem because that those things can run in parallel. Right. So they're not running things in parallel. And then when they would destroy because there's no plan, it would just blow it all away. Right. Uh, which I think was very appealing to a certain group of people, like very hacker minded people because you could put that in an API and you can just like await, promise all and do really interesting scripting stuff. Right. But it ultimately ends up being a huge problem where one, you're writing suboptimal infrastructure as code. That's slow and could be quicker if you knew that if you did parallelism. Right. Um, but also we love to be able to tell you what we're going to do before we do it so that you can review it because otherwise, whoopsie daisy, deleted the database. You know, that's a very real thing. But with Alchemy, you know, we lean into, we didn't innovate here. We just copied the output model from Pulumi, which I think is the right one. CDK is different. This is the right one. It's basically like it's output of T, it's a boxed container and it's a value that you can't get until deploy time. But you can use it to string together the dependencies. Like you can say the property out of this resource goes into the property of this other resource. Right, so it lets you model that connection, but then it only actually flows, uh, when you run the planning and when you run the engine. Uh, but that allows us to see the graph and then tell you everything that we're going to do. Um, we extended it a bit with our concept of bindings. So we extended infrastructure as code. There's not just resources, resources also have bindings. Um, and bindings can be circular. So we also solved the problem of circular dependencies. Like so imagine having two workers depend on each other in every infrastructure as code tool like CDK Pulumi. You can't really do that. You have to work around it. Um, in alchemy we design v2, we specifically design circular dependencies. I wouldn't say effect helped us with any. Effect helped with, um, replacing Async local storage. So like, if you yield a bucket, it's yielded in some stack, it's yielded in some context. Right, but where does that context come from? Well, effect luckily allows us. They have a concept of effect context. We can just use that to model, hey, which stack I'm in. The effect can just grab it and it knows what stack it's in. In asyncalchemy we used Async local storage for that. But that doesn't run in the browser. So it's like straight up just like, oh, okay, now we're coupled to Node. But like my dream infrastructure as code tool should run anywhere that JavaScript runs. And with effect we can do that now because we can do these complex context and we can decouple from the underlying underlying platform and give you something that could run in a browser. Right. Um, so yeah, I don't know, went off track there a little bit. But like that just went into planning, uh, old school output model, but then extended the engine for circularity and bindings. Like really borrowed the word binding from Cloudflare. I love their binding system, but it's really annoying that it's just for their cloudflare system. Alchemy V2 is basically bindings for the whole cloud and between any component of the cloud. You can bind an S3 bucket to a Cloudflare worker, you can bind an R, uh, two bucket to a lambda function to an easytool and it all looks the same. Right? So taking that all the way is like, what if we had infrastructure as code and bindings for the whole cloud? Well now the cloud is a library. That's it. Like, that's, that is the conclusion. The whole cloud becomes a library. And now the only thing stopping you from using the whole cloud is which accounts you have. That's it.

Speaker C: Um, yep.

Speaker B: Cool. Let's move on to talking about testing a little bit on your homepage. You got some big claims there. No mocks, no fakes. Uh, I'm assuming this is because you can tear everything. You, uh, can build everything up and tear it all down really quickly. But can you, uh, go into some of like the nice properties that Alchemy has, uh, for testing and like, how much, how fast is it, how much does it cost in practice? That sounds like a lot of doing stuff and doing stuff ain't cheap.

Speaker A: Yeah, uh, you're, you're right. Like we. That because the, the way that you create a stack is you export default from a file, but because it's effect. The thing that I should mention about effect is effect is pure, which means when you call a function that produces an effect, it does nothing. Which is great because now I can put them anywhere and I can import them and I can refer to them. In asyncalchemy, you couldn't do that, right? It wasn't pure. If you imported would do stuff, you know, that's not good. Uh, so we can just, we just import that and you just literally go before all deploy. I should, maybe I should show the screen.

Speaker C: I don't know.

Speaker A: Uh, yeah. So Alchemy has a testing, uh, feature that allows you to sort of import your stack. And because it's an effect. See here, this is our stack. Uh, this is just an effect. It's pure, which means calling this function doesn't do anything. It's just a data structure, which means if I import it now into my test, nothing happens. You know, I have more control. In Async Alchemy, you would import the stack and it would run the stack and we had to do all these hacks to work around it. It's not good in Alchemy effect, it's just pure. I can import it. And then as you can see here, I can call this before all function, which has a return value, which is probably uncommon for what people are seeing, but it makes a lot of sense. This gives you a return value, which is just another effect that will give you the output properties of this stack. So if you see this stack here, we're returning URL, branch, um, id, hyperdrive, id. Right. Uh, that's what comes out of this before all are your properties. It's the result of this deployment. And then in your test you can just yield that. So you can write a test, very normal, with an effect, and then you can just get the values and for example assert that it's a string, but more interestingly, make uh, requests against it. Right? So here I am making requests against the uh, um, against the real infrastructure. And if I run buntest, hopefully I'm logged in. You'll see that it starts creating the infrastructure as part of that command and it will run requests. Maybe it'll succeed, maybe it'll fail, um, and then it should tear it down and you'll see that the tear down is happening in the after all. So I give you control over um, when it runs. Like if you don't want to destroy at the end of every test. So here we've got two tests that passed. We created all this infrastructure and we destroyed it afterwards. But if I'm like, oh, you know, I'm iterating, please don't destroy it as a user. I can just set up this convention of no destroy, run it again. It'll redeploy the infrastructure and this time it won't destroy it. Which means on the next run it's quicker. Right? It's just doing an update. Um, so that's like nice little control you get ah, out of just everything being effects. So very quickly build your stack, all the infrastructure is correct. Very quickly put together a test, test its behavior, start running it.

Speaker B: Right.

Speaker A: So if I run this again, it'll, it'll update this time? Yeah. So you asked about cost. Cost is always going to be use case specific, right? Um, if you're using Cloudflare in the way that I am here, this is Cloudflare in Neon. So I'm deploying a Neon database, connecting, uh, managing it with Drizzle and using Cloudflare workers. The cost of this is very, very low. So a dev stack, probably zero. Actually I think it might be close to zero. But if I was deploying an EC2 instance per test or per developer, you know, it could get more expensive. But that's where you sort of progressively choose to simulate things locally, right? Like, oh, uh, for my tests I'll just run the postgres database locally instead of Neon instead of planetscale. Right. Cause at the end of the day it's the same behavior from Drizzle's perspective. So that, you know, you can take some of those heavy things and we can help you emulate them locally. We started with less emulation this time because it's just so much easier to test in the cloud and our use cases are very cloud friendly. But as we get more into AWS and these expensive services, you Know, we'll probably need some simulations for things like that. Yep.

Speaker B: And I'm sure that'll require a lot of AI agents making a lot of simulated local things, right?

Speaker A: Uh, yeah. Well, I have plans to turn every can I get when AI gets smarter. Once we have Drizzle, if we've got Drizzle as like the perfect spec of every cloud, well, the next step is like implement the APIs. So then we just go and we jump straight to, like, generating local stack, generating local emulation. That's kind of the dream there. I think as AI gets smarter, we'll do more stuff like that. It's like, hey, take the cloudflare Drizzle SDK and build a local version of every API. Something like that.

Speaker C: Distilled for that.

Speaker A: Oh, uh, yeah. Sorry, just. Did I say. Did I not say distilled?

Speaker C: Yeah, you said drizzle. I was like.

Speaker A: I sometimes. Oh, yeah, you're right. I sometimes say that. I don't know why it's such a similar word, I guess. But, yeah, here's distilled what it looks like.

Speaker C: Yeah.

Speaker A: Um, I did a lot of speaking about code, but maybe I should just jump in and show you what I meant by, like the bindings, because I feel like it. It's probably not that clear if you're not looking at it. So for the people who are on video, let me just show you what a binding looks like. This is a binding here. We have a hyperdrive and we just bind it to the worker. So the way that you do it is you just yield star the binding and now you have it, and then you just set up your database connection with Drizzle. So this is our, uh, Drizzle postgres connection. So this is like. Remember that constructor pattern? Declare your dependencies, return the implementation. That's what this is, dependencies, implementation. And here I can just select this and I get this type safe users object. Right. So that's all the infrastructure just flows for free there. Um, the application code can't be written if you misconfigure it. Like, if I comment these out, instant error. Right. Uh, so I just wanted to just quickly touch on that. We can go deeper if you'd like, but for now, I'll stop sharing the screen. Um, did that help you understand what I mean by the testing story, like, against real infrastructure and possibly local emulation if you need it?

Speaker B: Yeah, definitely.

Speaker C: Yep. It's pretty interesting. I mean, you know, you have this problem often is that, uh, your tests are usually a simulation of reality, and it's like hard to say Will, you know, it's not a true end to end test. I guess. You know, it's not really testing. Like is that, would this work in the service? So having it uh, an infrastructure set up, do your tests on actual infrastructure, tear it back down is a very uh, interesting approach.

Speaker A: And you can do that in. Oh, sorry, go ahead.

Speaker C: No, no, no, go ahead.

Speaker A: Oh, and you can. And that same test run in cicd and you get uh, and you get a different environment per pull request. So you write all your tests locally, iterate, iterate, iterate and then put it up in a pull request and that'll run in a GitHub action and it can deploy the infrastructure and it can you know, um, run all the tests and then tear it down when the pull request merges or closes. That's the setup that we have right now. And then when you go into main, you know, off it goes to production. Uh, and that's where we can get into things like blue green deployments and phase rollouts and all that good stuff, which is things we plan to automate without. Um, everything that you would expect a good disciplined production team to do will come for, come included in Alchemy V2 for you.

Speaker C: That's awesome. I think maybe this is a really good point too to transition to. So you started this Journey, Alchemy M v1, this open source um, ah, toolkit for just like the, or uh, imperatively like deploying infrastructure is very simple, sort of from scratch. You've learned a lot, you've adopted effect, you're like leaning into AI, you've done a lot more generation, you have a lot more coverage, it's safer, it's more buttoned up now. Um, so it sounds like, yeah, we're getting to a good point with the sort of like core of like what Alchemy is and it sort of begs the question. It's like so this is uh, this is a startup, you've, you've raised some, some money from vc. Um, what is the, what is the next step here? How do you. Yeah, where are you taking this?

Speaker A: Well, the next step is that the economy collapses and I don't have to worry about it anymore. Uh, I don't know, it's a very funny story. Like I think it's so typically me but like there's something about Alchemy that is almost anti money in a way. You know, uh, not that I want it to be that way but like if you reduce every SaaS application to a library, what are you Left with, right, um, you have to find something that you can provide to users that adds value by being managed. Because most SaaS that I've seen is like, oh, it's self hostable. Like it's not really like it's self hostable if you're willing to spend like a hundred steps setting it up and blah blah, blah. But with Alchemy, everything that we build will build with Alchemy. And then I'll be left with the question of like, well, do I uh, open source it or do I put it on a managed service and charge for it? Right, and how do I answer that question? Like what's the. Just there could just be. Well, I wanna like, I wanna, I wanna make money. And that might be a fair answer because you know, for a good tool to survive, it needs to make money. Also there should be things that can add value by being managed. Like for example, Secrets I think is one that could add value by being managed. We have a concept called Profiles where we sort of let you set up profiles with all the OR credentials saved for each of your cloud providers that you're using. Um, but at the end of the day it's still hard to onboard teams and you've got to go out and reach for something like Doppler or some other secrets management thing. People get by with one pass. I think we could integrate that directly into Alchemy as a service. So like your application, your code and its secrets are all one unit and we could sell that as a service and then sure, I could give it to you as a library, but there's still always the responsibility of managing secrets properly. Um, which could be something that you know, like and then compliance and all that good stuff, right? Of like making sure that this is actually a working secrets manager is something that is worth paying for and outsourcing the liability to rather than like, oh, I just installed some library, you know, oops, I lost the master key and now they're all gone or oops, I leaked it and someone has it. So like that's an example. I'm pretty interested in building my own observability stack as well. Uh, I'm using Axiom right now. It's okay, it's good. But I think given that we have so much built in understanding of your applications architecture in the code, I think we can do build a really great observability story, um, and just stretch that across all your cloud services, all your accounts and just integrate it into Alchemy. Uh, so like those are like my sort of Stable, steady sort of ideas that I think, you know, if you got ten thousand, hundred thousand users and then like one to five percent of them paid, you know, you probably got a sustainable business. Uh, not sure I have radical ideas, uh, that I've spoken to with a few friends. Remember how I said once you reduce everything to a library, the only boundary between you and the cloud is your account? It's like, well, what if you could get rid of the account? Uh, so, like, I'd love to sell a managed service that allows you to just, you know, like you saw Cloudflare just released. AI agents can create accounts. You know, uh, that's going to happen more and more with MPP x402. These sort of like online payment services. Like, what if, what if alchemy just took care of all the accounts and now you can just use the cloud? Oh, I want PlanetScale. Use PlanetScale. Oh, I want AWS. Use AWS. That could be really cool. You know, if I imagine this world of AI generating alchemy apps and infrastructure, and the whole economy is built on these autonomous applications, well, someone has to manage connecting all those things together in some way. Um, is everyone going to manage their own accounts or is this something that could be built there, like a cloud wallet? You know, a wallet for my API keys for my, for my access to, um, interest. Interested in that area, Going to let it evolve a bit more, see how it goes. But that, that could be a really interesting, interesting product. Just an ephemeral cloud. Just like, sorry, ambient cloud. That's always there. And all you need is one account, which is the Alchemy account. And now you can just use it. Yeah, but to be honest, I don't know. Uh, like, this feels like talking with my wife about this all the time, but AI feels very, like, destructive and deflationary. It's like, who makes money when there's an AI that can build anything within a few days? We're not quite there, but I think it's. I'm an AI maxi. I believe it's happening. I think you can see it happening. The things that we're just doing with AI is progressively more. Where's the value in anything?

Speaker B: Yeah, that's been a big issue. I, uh, was listening to the Hard Fork podcast and they had Andrew Yang on and I had forgotten that, like, he had run on the premise of AI is going to take all of our jobs and we need UBI to fix the problem. He was just kind of like, just really just like three years ahead of the issue.

Speaker A: He was on it.

Speaker B: He was on it. It's like perfectly accurate. It's like, I feel like that's like the end goal of all. This is a much different looking world than we currently live in. And that's ah, where a lot of the fear lies with me for sure.

Speaker A: Yeah, yeah. And I. And then there's my product, which is just straight up, like, my product makes so much more sense in a world when you sell CDs, you know, when software was distributed in a box, right. It's like, why don't we go back to that world? Like, why does everything have to be a subscription? Why don't you just pay a license? Like, what's wrong with licensing software? Um, this open source is so strange. It's like, it's where so many brilliant people come together and just give away their work for free. Is that sustainable? Like what, what these people need to get paid, right?

Speaker B: Yeah, I think we found unequivocally, no, it's not sustainable after, uh, 160 episodes. No, no, nobody's found the sustainability curve yet.

Speaker A: Where's the carpenter that's like just, you go to his house and you can just grab the, he's like, he's putting out tables and you can just go snag, you know, it's free. That's what, that's what GitHub is, right? It's like, oh, I spent two years working on this. Oh, thanks bro. Cheers. And now with AI, it's like, oh, cool, I'll copy that. Off I go. You know, uh, I don't know, it's very odd to me. Like, but these like, uh, online payment stuff is interesting. Like, maybe things will change. Maybe people will pay to like visit a website to download a package. Like, maybe everything just gets micropayment and everyone's okay with it because there's no other way to make money. You know, like, NPM downloads are actual money. Like, why not? Right?

Speaker C: Maybe, Yeah. I think that like, there's always going to be, uh, the space to get paid so that somebody doesn't have to worry about something, you know, that, that you are taking care of something that they can trust that you are, you know, taking responsibility. Um, and I think like in the, in the infrastructure space, it's like, okay, so me as an amateur dev, I come through and I like use alchemy and I use AI and I spin up the service and it's deployed to AWS 2 to 2, no idea what I'm really doing. Um, and then, you know, at some point that Bill comes due, it's configured poorly. Like there's some major um, thing, there's some sharp edge and I think the thing that you have that's interesting is like this sort of intrinsic knowledge of all of these platforms and their sharp edges. And um, that's a thing that like is valuable, right? And it's like this interesting opportunity for you to figure out like okay, I have this tool that like makes interfacing with these cloud services basically go to zero. But like it does not reduce the pain of being on the cloud services. You know and there's like, there is this sort of like trust and um, help me like get that last mile of like yeah, I want to build a service online and I want to like make a digital business or whatever. But also I like need to trust that I'm not going to get like a $10,000 AWS bill and uh, you know, a few weeks or something.

Speaker A: You know we thought there's other ideas that kicked around. Like the idea of selling m, uh, like support agent like on call as AI. Uh, right. It's like hey, what about like reviewing the infrastructure, maintaining it, responding to alarms, things like that. It's like sure, you could get called code to do that. Like maybe, maybe we can do something beyond, beyond that. Or you know, going all the way would just be like well I know everything about all these cloud providers and I know how like terrible they are in many ways. Like build your own, you know, build uh, build your own on top of existing infrastructure. That's what Vercel did. And then, or pull a railway and then go raise 500 million and build your own hardware. There's things you can do. Like I was talking about it with Michael and Aldi. It's like let's just get cloudflare but bun instead of worker D, let's go build that. That's uh, you know, build, just move into infrastructure as well. But the problem is like the limitations are just like endless. Like where's the. For me like just focusing on production ready services, getting like a really core use user base, both like open source, but also building some like relationships with teams that I'm working with which can translate into like support plans to help, you know, they keep me alive and then I keep them alive. And then from there emerges like monetization ideas, observability secrets. Compliance I think we could do compliance is a big one. You know, like I can give you types and uh, classes that help you build compliance systems. But what about like guaranteeing compliance? Some of these, some of these contracts that you see thrown around to like, build a compliant thing for the Department of Defense or whatever are pretty, pretty crazy. But could I build you a system of tools and services that go zero to FedRamp? Just, hey, I want to build Fedramp thing. And in healthcare or in government, alchemy should be like the greased rail to get there. And there's going to be so many ways to. To find ways to monetize and add value to that chain. That's not just libraries, I believe.

Speaker B: Yeah, that all sounds exciting to me. The observability stuff sounds exciting. I found it very helpful in like my side projects just to have like a. All that stuff in one place and I have AI ask it stuff and like, my problems are just kind of magically solved. It's a. It's a crazy experience. Crazy world we live in. But thanks for coming on the podcast and talking to us about Alchemy v2. It seems like you put in a whole lot of work. It's a big new vision and I'm personally excited to try it out. So thanks for coming on and talking about it.

Speaker A: Yeah, thanks, Andrew. Thanks, Justin.

Speaker C: Thanks, man. Love to see all the work and, um, how far you have come. So it's cool. Keep it up.

Speaker A: Thanks, man.