Episode 46: Build versus buy in the age of AI

Hey, can you see me? Yeah. Well, I didn't expect you to just jump on. Oh my god. Nobody expects the Spanish Inquisition. Yeah. You know what it is? Uh, is it Monty Python or? Yes, I was about to call you, what is it, a Luddite Luddite? Somebody who's culture, deprived? You know, a lot of it came about because I think of the steam revolution in England,

and people were destroying the steam machines because it was taking away work. Very much like AI today. Very much like I had today. AI's not taking away jobs. No, it's just displacing people. I don't believe that, to be honest. I believe AI is going to take away a ton of jobs, and it's not just going to displace people. Did you see the latest blog post of Anthropic? Uh, yeah, you mentioned that was, I didn't, I didn't look at it, but you said it was Baller.

Hot take of the podcast. Um, if this isn't proved that enterprise SaaS is dead, then what is a bloody AI company is rebuilding complete version control, hosted version control. Oh, yeah. Can you just dig up the link because I'm struggling at the moment? Are you like to share the screen? I think I've got definitely a case of AI psychosis. I felt like my brain was changing inside my skull yesterday because I was, I was, uh, basically context switch, switching between 3 pretty intense projects.

With the Opus 5.5 and my brain was just turning into, Well, it wasn't turning into mush. It was basically working harder than ever. You know this whole, you don't goofed up internet meme? No. So there's this girl who was on Instagram or TikTok? I think it was Instagram before TikTok and she was acting all gangster. And one of the things when you talk about your brain turning into slush. One of her quotes was like, I put the Glock in your mouth and put your brain and make a brain

slushy. And then the whole internet like started harassing her and like, you know, doing SWAT calls and until her father came on. And then he was like, y'all don't know who you're dealing with. Y'all done goofed up. And then I became the next meme. That was horrible. Anyway, when you talk about brains that she's, my mind goes to Glocks. My brain didn't turn to much. It was just working really hard, I think. It's not like I dropped the ball or anything.

I was just, I mean, are you exhausted from working with AI? I guess I'm on my 2nd coffee, so I feel fine. Ask me again in an hour. I want to share. Okay, I want to share my screen. I want to share myself. I'm working harder than ever. Okay, you're going to share that Claude article. Oh, thanks. I was going to share something else, but now you make me share the Claude article. Okay. Yeah. So what do they do? Like, we... Where did you go? We have we've made a rust version of Git or something insane.

Oh, uh, well, I think it's kind of like in line with their previous like bottleneck articles, as you called them. Everything is a bottleneck, reviews, a bottleneck. I is a bottleneck, and version control is a bottleneck. These are not AI written articles. No, they're not. They're not. So, um, anyway. Yes, they moved on from, I mean, it's in line of like we, we, we rebuilt CI, like they talked about CI as a product, um, meaning that it's not just GitHub Actions

workflows, but it's, um, you know, actually a full-fledged, like workflow engine that builds and, and, you know, they, they're doing metrics. I believe it's like a product internal product, right? Uh, and and Scion, the thing they built, is basically a Monorepo version control system where they made a couple of um, challenges to the Git design, like they cut down some constraints. I think one of the very interesting ones was that they don't want the client and

server, um, symmetry. So the client doesn't need to carry all of the server capabilities, which allows them to rewrite the server internal logic without, you know, redeploying clients. And, um, and then a lot of it is based on like event orchestration and, um, you know, derived use and materialisation of uh, certain queries. So clients only know what they need, and the server is basically providing a

bunch of views that the clients can query. So to do like, uh, commit uh, history views and things like that, allowing clients. Yeah. And and also, like inside the report, inside the blog post, there's some interesting, um, information such as like spanner and cloud um, object storage or blob storage. So I think they're fully on GCP with this. I didn't know like Anthropic. Yes, kind of sounds like GCP, yeah. Yeah.

So it would be very interesting. I'm sure that somebody paste this article into fable and like build me Scion internally. This is not clear to me, like, what is the actual workflow then? Like, what? Okay man. So the main point that they're trying to make is like at the scale that they run, they have a large monorepo cloning it. Like it's with the amount of time, agents that are running and cloning the data, they would have betabytes of data transferring over the network. So one of the main things I want to focus on is like when an agent needs to start working,

clone the minimal things that the agent needs, right? And then it can query, and it 1st always looks what it already has locally, and only asks the server for like new files or other information over the server protocol. So I think that's like a very nice way of decomposing the, you know, But like, I thought, the last YouTube video of Claude was like, hey, I closed my laptop litter now, Claude is running in the cloud. I mean, essentially, we're getting to this, where the stage where, where Claudus and

the agents are connecting to a monorepo and everything's there. It's not local. Yeah, yeah, absolutely. That's still the case, right? Everything, well, um, I think that's generally the pattern that agentic systems need to take, right? Everything is background agents. Everything is in the cloud. And one of the main things they highlighted in this article as well is Git is with the idea that it works fully offline. where here they broke that down and it says, no, our cloud, it

has the initial, has the assumption that everything is available remotely. So there is a natural connection and we can, you know, we can always get data over the network. So we don't need to make everything work offline. I think that's also very important. Okay. You know, like a couple episodes ago, you told me about the agent client protocol. Is Claude using that? It's different, right? I mean, it's, it's more, if you're, if you have a harness that implements

capabilities and then you want to expose a user interface on top of that, your user interface will be the client and and your agent harness um will be the server that exposes capabilities. So on Kiro, when you have your interface with your chat and, you know, the ability to create widgets and publish artefacts and all that, all of those tools and those capabilities, um, like the artefact, for example, that can be displayed in the chat, is advertised back to the

harness, so that when the agent works, it knows that, oh, I can create an artefact, and I can announce it like with this tool, and then the agent client protocol, you know, makes that discovery mechanism so that when the harness uh, decides to to do something like, hey, I have made an artefact, then the chat knows how to render it. The same way, like, I think one of the coolest things was I was trying to look like, how does Kiro handle like ask user question? Because for example, ask you as a question, which you get in Claude Code every time the model

wants to ask you a question and you want to present something nice and Claude Code with like multiple options, maybe multi-select or individual. That's that's a model display that is the user or in this case, the client is user interface, right? Um, that you want the model to be able to call, and then the, the client, the user interface presents it to the user so that the user can easily interact with it. And I was looking at can we can I update Kiro to do the same? And it turns out that Kiro does something much nicer because the agent client protocol has

this concept of advertising options and when the response from the model comes with like option one, two, three, Kiro would detect those, the UI would detect those options and would render them like little badges. And I think when I talk to you about ACP and Kiro and what I did when I adopted the open. I mentioned that to you, that that was already there, and it's so much nicer than, like, it just very simply. You click on it, it gets right. Am I right, just to assume that Claude has their own protocol and they're not using this open one for...

Yeah, we don't know. Like, their harness is not open, right? I mean, if you would look at where would agent client protocol be important? It would be OpenCode. Like, for example, OpenCode is a terminal UI. And when they added ask user question, they had the concern because they couldn't just edit for the terminal because their clients ran in the web browser and run in different areas, like a phone application. So those are all the clients of the harness, right? So they built it, and I would assume OpenCode, I don't know if they had their own protocol or

adopted the agent client protocol, but that's what the agent client protocol is. Forgive me, I'm not, I can't quite remember if we talked about this before, but like, to me, I don't really see a major difference between, uh, using Claude and Codex and, uh, And even OpenCode, I mean, I haven't used OpenCode in anger for, for a while. I don't see a major difference. Like, am I, am I just a complete noob or like, because I know, I know some people that use Claude with, um, with open AI.

They use some sort of proxy and they say like Codex sucks. You got to use Claude. And I'm like, I didn't even see what, what they're talking about, maybe I should ask them. Like, why? I mean, the whole reason that Anthropic doesn't, I mean, the whole reason that Anthropic lockdown, these subscription accounts, and Claude Code, to be only used with, I mean, you can, you can set up, set up an, a proxy and an LLM engine so that that Claude Code talks to your own version of GLM 5.3

or Deep Seek 4 pro or flash. But the whole reason Anthropic said that you shouldn't do that is because their models are trained with the harness and the tools that are available and therefore they perform better in their own harness. That's in the opposite way, actually. That's why you can't use Claude Anthropic models with OpenCode. That's why they say you can't use it because it's not a good user experience, which is bullshit, of course, because it's up to us to decide.

But still, the other way, which is like, yeah, Claude Code is great because they landed like so many tools and capabilities inside. Again, why would you want to use it with Deep Seek for Flash, when you know that, for example, Fable Today, um, is very fine tuned on Claude Code and and understands very well. How to spend a background agent, how to send messages, how to receive messages from background engines. It's, it's crazy how fast Claude Code is iterating right now. I mean, like all their blog posts about we are merging.

Everyone now is talking about we're merging 500 PRs a day. Um, you know, cursors saying it, Anthropic is saying it. Yes, it is mad. I mean, the impact, you know, the impact of AI is, is we're living an interesting time, is the impact of AI, is yet to really be felt in a way. Uh, but there are signs. There are like some crazy signs, like, okay. On homebrew, there's been all these, uh, new packages that I've noticed, like photograph,

video craft, there's basically, um, an AI version of Photoshop and AI version of Premier right now, all the, the whole Adobe stuff has been completely replaced. I mean, yeah, everyone's talking about it. It's kind of crazy. I mean, like, okay, sure. It's then the story is like, oh, this guy was so angry with Adobe, cancel, cancel procedures where you get charged for cancelling at an absurd rate. So he rebuilt the whole adobe suite. I was like, oh, nice story. Anyway, can we get back to this interesting technical article?

Because we were complaining? That Anthropic didn't put out deep technical articles, and I think this by far, and maybe it's because it's platform engineering related, and it's CICD and its version control, if it's super exciting for me. I found this super interesting article. So the 1st 2 things that we talked about was that they make the assumption that clients are always online, right? That the client can always go ask the server for data and that client. Like the SHH dynomist, right? Yeah. And then another thing is, um, I think I might have skipped about a

lot of this stuff. But what I liked, I shared some quotes, which is what they took away from engineers, because this is how we got into this article, right? I say, like engineers role is being displaced. I mean, they said again, we started this around April. We had about 5 engineers working on this. They were working fully agentic. And they found that most of the time, the engineers were there to really say no to Claude.

And I think you notice that a lot. Yeah. Um, that that cloud, when you give it like restrictions and rules, those rules, they they are there for a reason to to make sure you get like no duplicate code and other types, other rules. There's reasons why you put those rules there. And then they start backfiring. They start making the job hard for Claude. And it starts to overcomplicate the code. It starts to make really, um, difficult workarounds where if you

would just loosen the rule a little bit. The code would have been so much better. Um, so so they talk about how they use adversarial reviews. And then here they talk about one review resulted in Claude adding excessive validation and complexity. And I think you see that a lot. When you when you go for these adversarial reviews and you make the rules very strict and then it goes in this this back and forth between the implementer and the verifier and the fixer and then the verifier and the fixer. Claude usually puts in a threshold on how many times that interaction can happen, and then it

stops after 5 iterations. So like total is 10 runs. But by the time it stops, I've often found the code is like so complicated because there's this concept back and forth, like you're not handling this education. you not doing this. And then, so they said, like, that's where skilled engineers today need to step in and basically pick up on like areas where the code has become way too complex. I mean, I could I could look at like a PR that I was just

reviewing a 2nd ago, sitting here. Yeah, the one thing I found quite annoying at work is that we use quite a lockdown version of Claude Enterprise. We, for example, we use the enterprise feature, which is made by Anthropic. But of course, when you start using, uh, various development tools in the Claude sandbox, you don't have access to like, you know, dot cash

directory and then all of a sudden UV is like controlling the environment and sit overriding everything so that they can use the tempter. And then sometimes that comes into code and then you got really complicated code and you're like, all because it's working around the sandbox environment, that anthropic provide, which I find incredibly annoying. As long as they don't find a message board and starts enlisting other agents to find a solution to the problem, I think you're good. But that's exactly like what they found with agents, right?

The point I'm trying to make is that, like, a lot of these productivity unlocks happen when you trust Claude, and you give it a bit of a wiggle room, I feel. That's one of the things that Lauren and Matt Pocock talk about when they talk about. that was a great podcast. I mean, really good. They also talked about like getting buying into the trust when you start trusting the agents to be able. And then now they're sharing a lot of like skills that help you clean up.

I rolled out a test audit skill that I took from OpenClaw across several repositories, and it has really improved the tests that get like delivered, even on contributors PRs. I just, you know, tell Claude, run the test audit, and it really goes like, because, you know, agents like, we love tests, right? I mean, we, as platform engineers in develops and, you know, automated testing is like important. You know, we want agents to get tired feedback loops with different layers of testing versus, you know, and unit testing versus integration testing versus end-to-end

testing, as you as your trust grows into the into the features being delivered. But what ends up happening is agents writing a bunch of tests, and maybe, like, they discuss the types of tests, actually, Matt has a nice talk about the types of tests, like tautological tests, tests that just validate themselves or heavily tied to the implementation. And so this test audit skill from OpenClaw that I started rolling out really helps identify these and variidates that we are really testing for behaviour and less on the

implementation. We're both in the infrastructure field, and I do feel... With infrastructure engineers like ourselves, we have to be a bit more patient, right? Because how many times, have you like Terraformed something or stood up some infrastructure and it wasn't quite, There was some, you know, there was some lag, and, you know, the DNS wasn't propagating or something, and then you were getting errors, but like you, but, but you were experienced to know, you just had to be a little patient, and then it

would come online. You know what I mean? It's like, Testing in infrastructure is not quite the same as testing in application development. I like to think, but I could be overstating it. I mean, I find that I have like, this is a large, um, Terraform and infrastructure monorepo, and I am, I have built a very tiered architecture of running local tests versus deploying into the accounts, into sandbox environments, or ephemeral environments, and

then validating things, and then tearing everything down, and I think that, you know, full integration testing and infrastructure is very, like, underdeveloped. A lot of people are not doing it. And I think it brings in men's value and it brings even a lot more value when you have agents working on it. Because I was amazed. I got the question to if I could help with something. And within 3 hours, I had built a complete, you know, new piece of infrastructure and and... this test here that you put up on the screen.

I can see that it's got all the logic to wait, which you need. Yeah, sort of health. So Terratest. So this is one thing, right? So HashiCorp, they built Terraform test command and people were like, great, you don't need other ways of testing infrastructure anymore. But the thing is, if you adopt a Terratest, you know that what HashiCorp delivered with Terraform test is not nearly enough to be able to do a proper, you know, environment assertion. And if you build your tests with Terratest, which is a Go testing

framework based, um, you know, library basically with basic SDK functionality that allows you to, you know, spin up things into AWS and then run some assertions and then tear everything down. So here I'm not too happy with some of this. Like it's running the AWS CLI to describe the service like... It should not do that. It should really use the SDK from Terratest to describe the service. I haven't actually given that feedback here. But one of the things... What is wrong with AWS CLI? I mean, uh, because I was just saying Terratest gives you the AWS

uh, gives you a whole bunch of modules and one of those modules is a full AWS assertion uh, module. So you have Terratest AWS here. Yeah, that gives you like the ability to describe the service. in the end. Yeah, that is a mistake and that's the stuff that I need to suss out, right? I need to look at this. Like, for example, what is this? Why is it doing the ECR login as part of this? And not liking the GitHub Actions workflow, for example, like if you need an ECR token, then I think the workflow should set that up.

So this type of details I don't want in here, it also makes it like annoying. Well, you want to be you want to be able to run the test locally too, right? Um... Yeah, I know anyway, yeah, I guess I guess I would normally put that in make targets. So I would have like one make Target so that if I want to run it locally, I would I would run those. All right, like Targets. Is that your SSR login? I think the other other directories do that actually. But I wanted to see, I really love this, actually.

This was interesting. I never seen this before. It built a Go type struct for all of the outputs from a Terraform stack, and then it built a load and command that loads the terra, like Terraform, um, you know, the options is basically a snapshot of what you use to run Terraform apply. So it reloads and then reads every outbook from that stack using the Terratest capabilities. So it just builds up a fully typed struct of the outputs of a Terraform state that

is the ephemeral environment that it spins up to run tests again. So I thought that was really cool. Definitely because of it, like it uses the required. That means it's a Go test assertion, that if this output is not available, it immediately fails the test. So I like that. When I read this, I'm like, oh, cool. That's really cool. Um, there was a whole bunch, and I don't know if it already... Oh, journalctl? Oh my lord. I'm not sure about this, man, but, uh, Well, at this point, I

don't really care, right? I have like 5 packer image builds with assertions and they have like patterns that I build over 2 years manually. And at this point, if the test pass, the smoke test pass, I know it works. I'm not maintaining this code, right? I'm just going through this to eliminate like things that are honestly nitpicks because me saying, oh, this is an inline bash. I don't like it. I want to change it. That's a nitpick. You know, it works anyway. Who cares? Yeah, I'm just a little bit...

I mean, especially in infrastructure. I'm trying to get to a point here. Okay, sorry. Where is it? I'm trying to find, because I made a comment on something, and I think it might have already pushed the refractored code, I can't find it now. Fake intake. Ah, it built a fake intake client here. Oh, for Datadog. Yeah, oh, it already did it. So I'm a little bit, okay, so the previous version of this was

worse. It was like running SSM command. Um, so basically this test spins up an EC2 instance and validates a Datadog um, proxy. So it actually spins up an EC2 instance that's baked with the capabilities, like a mock service and the compose and everything and then sets up the log forwarder. So I'm using vector.dev to log forward everything. And then I'm spinning up a full fake intake. And fake intake is what Datadog uses to validate a Datadog agent. So it's a public docker image that you can run and it's gonna intake everything.

And then it has even an um, a gRPC client. So you can use the fake intake client to, which is Go SDK, to basically validate that everything is, um, you know, arriving and to query the intake, that everything is arriving, the logs, the traces, the metrics, that everything is working is expected. So I'm baking an AMI as a base layer for everyone to do the log shipping, everything, um, against this um, internal endpoint. And in this case, he's setting up a tunnel and then he's using the fake intake client

to basically validate that everything is there. that all of the the logs, the traces, the metrics are being shipped correctly. So yeah, it's a bit, it's absolutely insane, but look, it took like, you know, less than an hour. to create this. So I'm like, okay, cool, you know? Yeah, the big problem is every code line that you had. Never mind. I see I see where you're going with. The quick side note, is there a good alternative?

I mean, would for you viewing logs, is there a good alternative to Datadog? So you asked me the question about how do you view logs in CloudWatch? I mean, like, I don't. Yeah, I gather that, but like, so you actually, like, hit live and Datadog to, to, to get a good understanding of your, of your emperor at, at work or? How do you prefer to do it? Because, yeah, I'm not, I'm not a.

I think Datadog always just, I find like, expensive, so I'm like, just looking for alternatives. Yeah. Um, I mean, Well, we don't have to get into it. I don't really know what the question is here. Well, alternative to viewing logs, but never mind. We can get back to this thing. So skilled engineer saying no. Yeah, um, skilled engineers, um, very often we found that the role of engineers was to sell, uh, tell no to Claude that uh, that the agents will violate cause system constraints to

certify a pattern. And then, you know, you need to identify this. And I think what they really do well now with Claude Code is you have this site agent, which is, you can, you should know, like you have, you get the tip. If you use Claude Code, there's a tip pop up and it says, hey, you know, we have a new plug-in that's using Claude mods, the Claude Code mods feature that runs a side agent and watches the logs for you. So as the agents are working, It may it may pick up something like, hey, um, you should know that. The agents have deployed a capability that will cause this and

this problem. And then it will pick like pop that up. So it uses Claude Code mods. Um, I don't know if I have one uh, activity. There's a few plug-ins that I just came on my radar that I've been bookmarking from various... So this one is pop plugged in. I mean, like it's built in. Yeah, here, heads up. You see it here? I can't zoom in here.

Oh, well, I can't if I do this. Oh, yeah. So, that is interesting. Um, let me see. Is there another one here where I can see? Where? Is there any heads up? I mean, that's unfortunate. the only one. So in this case, the side agent has detected that, you know, if I press one, it's going to give me the full information of the problem, and then I can take

that into the main session to discuss it with the main agent. So so the 2nd agent has like keeps it context clear and and make sure that we don't miss anything. So it's, it's, again, this whole view here. It basically, it's a separate view from the main view. Oh, wow. What is this called again, sorry? This is, you should know, which uses the new Claude Code moding. So they added moding, which allows you to basically modify the terminal user interface and

create your own window. So this whole terminal user interface has been, I think they adopted the same thing as OpenCode, right? So they are way more powerful. Like, you get these little, I don't know if you can see these little, like, on the side, track of, like, the tool calls and the output, so you can see, like, happen. no that's incredible. Did you listen to terminal? Yeah, I'm not sure if this is cmux or Claude Code, but I think because I just updated cmux this today as well. So, um, I'm running the latest cmux with the latest Claude Code.

And, yeah, I mean, it has been an absolute blast. Like, it's crazy. Have you tried any of the the cloud official plug-ins because the skills are one thing, but the plug-ins are like also kind of next level, I'd say. Yeah, so you should know is also, I don't know if this is a plug-in. I think it is a plug-in, but it uses something what, they said basically we release a new feature Claude called Claude Code MOT, and we have a you should know, plug-in that uses

Claude Code MOT to basically modify your Claude Code to be able to show these little side agent, you know, information. I thought it was really cool. So, it feels like software development is just starting again, you know, like, or there's so much cool stuff to take in here. Oh yeah, I love this section too. We are completely rethinking our priors. Um, which is.

Yeah, um... They talked about like A hard look at how workflows designed for human skill no longer applies. Um, things like, you know, where we, where a lot of organisations are spending time on like doing, uh, what was it? Yeah, yeah. So basically, like, They started to move things more towards smoke tests and pre-deploy automation testing, which I thought was great because this is

something that I haven't in a recent project. Probably automated testing, like a smoke test. Right. Yeah, because because what's the point of like having all those tests running before the PR merges, you might as well merge the PR and then a smoke test block the deployment and then the next PR coming. I think that's kind of like the gist of it, right? Yeah, yeah. You don't want a global lock and emerge queue and all that if you can just keep on merging and then just oh, something broken. So, This this is an interesting, I think we've we've covered most of the article.

So back to my whole take. I said that if this doesn't improve that enterprise SaaS is dead, then I don't know what is. Because if an organisation, like Anthropic, which obviously has access to really good AI engineer, resources, but its main functionality is to deliver code is not like leveraging a partner or an enterprise to provide version control and CICD and deployments.

Then why would, like, another company depend on those organisations, like, I really think SAS is probably for like startups that need to iterate and focus on the product to deliver, and that don't have a lot of money, and, um, I mean, they don't have as much money to, like, dedicate AI resources to build services that are not their primary product. So you're trying to, wait a minute, if I, I'm interpreting what you're saying, Vincent, by

saying that if you're big enough, you should be building, not buying. Yeah. So this is actually funny because I had that discussion at work. about build versus buy at what point? I think that the question of build versus buy today in an enterprise very much is leaning more towards built. Well, I don't think that's controversial to say that. I think everybody knows that today you can build a lot more internally. And the main arguments against it was,

if you build, you're not, you're going to have to maintain, right? You're going to have to build all of those features that were, you know, built by the SAS over years because it's their area of expertise versus if you build something silly, small, can work fast, but then to maintain becomes a nightmare, right? But when you operate at the size or the scale of an enterprise, like entropic or other organisations like Uber, they are way more focussed on build, right? I think we already know that from grab as well, right?

Well, I mean, Anthropic, I'm sure they have the resources, but like, I'm just thinking from my, from my experience working at clients, they, they often want, they definitely want a buy solution because the team is, is a skeleton crew and uh, they want to focus on other things, right? So when AI came around, people were like, organisations are going to fire engineers because they can outsource to agents before they would outsource to offshore

countries. Now they outsource to agents, so all of that offshore dies and, you know, gets pulled back in. like they used to fire people. Um, And then you have other people at the time, I think, around last year, when there was this huge layoff layoffs already happening or early this year, when layoffs happened, where they were like, instead, if I have this budget for headcount, then I'm not gonna fire the people, I'm gonna amplify the people, and we're just gonna deliver more features with the same amount of people, not layoff half of the people to deliver at the same

rate, right? Because then we're just gonna die in a competitive market. So there's these 22 angles. And your argument is basically what you observed is you have skeleton crews. They are barely, you know, staying afloat and they're trying to buy as much as possible. I think the tricky thing is I'm probably gonna badly explain this, but like, in any company, you're gonna have some people that are like AI

red-pilled, like myself, and then there's gonna be people who are not. And, uh, What I'm trying to say is that, like, you can't assume that your engineering team is just gonna get those productivities with AI. It's quite a journey, isn't it? So I think That is gonna change, that the build, that adoption,

that people that resist adoption are gonna be less and less. I mean, I think we already see that, right? I mean, people like ThePrimeagen and others that were very against AI. like, I loved recording. I love doing this. Um, and then people are like, I mean, you know, I love my new role as an architect and as an engineer, reviewing code and AI is amazing. This was another takeaway from this article that the feedback of most of those engineers working. It said that they, like, I think 60 or 70% said that the agent is writing better

code than them. And I think that's the sentiment that you see in Reddit a lot more now, right? Yeah, you shared that LinkedIn post from the incident.io, didn't you? Yeah, this... I mean, I'm sure it's going to get there, but like, what I'm trying to say here is that. I mean, I'm probably being a bit dark here, but like what's likely to happen is that. A lot of companies are going to go slow.

If we rather go slow with less people, then fast with the same people and augmented with the act. Exactly. There's probably going to be quite a trough of disillusionment and go slowness for a lot of companies, and the companies that are AI native. I mean, to be honest, like, even AI native companies, I'm not sure they're pulling it out. So I think I think this depends on where is the company in its lifecycle. Because you have a lifecycle, right? And I also think that you are biased with the clients

that engaged your the organisation that you work for. Because there are a tendency to go towards that. You know, like we are, we're going to get consultancy company to help us because we can't do it in-house. Therefore, they already have a tendency for like we're not going to build or anything. Exactly, exactly. There's definitely some biases and preconcent. trying to find where they show the pre- the, like they started around April, like around Claude Mythos. They mentioned how many people there were.

And then they mentioned the feedback of those engineers, of them, basically seeing that the code is delivered by agents is better. But better than what they would write. But back to your point, like, I said, one thing is the, the, the, the bias of the, the enterprises you interact with, and 2nd is also the life cycle, because even if a company is acquired, like what, what I hear now is happening with HashiCorp, uh, and IBM, getting completely gutted. I mean, this is often aboard, like a big enterprise, acquiring smaller

companies, and they want to cut as much of the resources and much of the cost, keep all they basically bought the customer base, right? They bought all the people that already use the product. They bump up the cost of the, of the subscription and they don't, they want to go slow and cut the cost. They don't really look for innovation. They just want milk what they have. Yeah. I mean, there's a lot, there's so many factors. facets to this. I've been actually pairing with a guy this week and last week.

And, It's a bit, You know, usually when you pass with someone on code or something, you, like in the old, the good old-fashioned days, I don't know if you've done classic pairing, but like, you know, you switch the keyboards and things like this, and you work like that, and of course, there's some ramp up time. But like, I don't know if uh, I feel like I'm doing it wrong or something like that, but like, with, with AI, there is so much going on, right?

There's different tools, there's different plug-ins, there's different skills. There's like lots of context switching. There's lots of pauses. Oh, yeah. In fact, the pauses were enough to break. like this guy I'm working with, I'm trying to like, enable him so that he can do the stuff that I do, but like, but often with the AI software development, as you know, like, you're in one work tree or something, and then you kick off something, and then you can't just sit there pairing, waiting for it to finish, right? You want to contact shift to something else, which you're not...

And the whole. Yeah, the whole pairing experience, the whole, uh, working with someone experience is absolutely broken and like, if anything, I feel that he's probably more frustrated about everything, then, with, you know, without me or something, like, I, I basically just, like, I work with many clients through my career, and I usually feel that when I'm pairing with somebody, I'm, uh, I'm sharing good practises and ways of working.

But at this point, I'm not sure I'm doing it because it's just so wild, AI. Like it's just, there's so, it's just crazy. Like, I'm changing my the way I'm working myself all the time. Yeah, yeah, no, and every release, a new capability comes out and eliminates something that you have to start changing the way you work anyway, right? Like what we just said. Um, you might have had this workflow where you go back scrolling to what happened in the past, you know, while you were working on something else, the idea of,

um, of this, you should know, is you have to go back less, um, and other people, like, as I use the show me skill recently, quite a lot, because I'm like, I don't want to go scroll and read anymore. I want to, I want to visually show me what is happening. Um, lately. That's really what I... So many changes. Like, like, uh, there was an X post by law on this this morning for a skill, uh, where she, where basically she was arguing that you should remove comments

because comments can be quite misleading. And, and that's true because, like, I've noticed that some people make changes and they put lots of comments in there and I'm like, nah, this is not really helping us. Oh, yeah. I mean, so fast. But like you said, these skills, they're temporary, right? I mean, we had skills to simplify the words used by Opus 5.0, then 5.5 came out and you needed less of that. The same reason why earlier you said Claude Code.

Um, you should use it with like with the open AI models because Codex sucks, but Claude Code itself, added like a terse output feature that was necessary for 5 and then 5.5, they probably removed it again because they fixed the output capability. And the same with the comments. We now, I have a rule in my dynamic workflows. Opus implementer, Opus verifier, and Sonnet, comment reducer, who is responsible to go through all the comments, and he has a couple of rules, like comments are not journals.

Comments are, you know, version controllers for journals, comments that do not add anything on top of the max 5 lines, should be also removed. Common should never be like, should ideally be tree lines, maximum 5 and never more. This is the type of like common reviewer that I had. It's not the same as Lauren, who says remove the comments because it's back door or ways for agents to work around. Like, a commons. If you start having to do and like we'll do this in the future, the agent will keep start

putting to do everywhere. right? So you got to eradicate. Anyway, let's go. let's not get focus on the comments. I was just using it as a silly example as like what's happening now in this time as a temporary workaround. It's, it's so, everything's happening so fast and uh, and I don't want to put, I don't want to car shade on my colleague. I mean, I feel like, um, it's not, it's no fault of his own that, that, that, like, but at the same, it's like, it's a fault on me. Like, I don't know how to explain. Or to encourage someone to basically,

uh, just experiment all the time. Um, yeah, it's like quite a big mindset shift and and it's very difficult to work with someone on this sort of stuff. It's very difficult to be aligned with someone. I mean, if you and I were working on something, being AI red-pilled. I'm sure we're going to have quite big differences in the way that we want to work with AI. absolutely. It's crazy. But, but also to add to your point earlier about like pair programming and today,

like I have, I find that the workflow encourages people that can switch easily and it forces you to switch all the time. But it also makes it so that if I have a large amount of text to read and go through, I will read the 1st few paragraphs and my mind is like, let me go see if another session is waiting for something. Because this is taking too long. And this is like, this is ADHD. I can't get through a massive document anymore because I'm like, hold on a minute. That's probably a session somewhere that's waiting for input that I can get going faster.

Exactly. reading this stuff. I mean, that's my life right now, but like yesterday I was, I was not only doing that. I was also uh, contact switching with a colleague trying to, like, explain that the way that I was working was not completely bonkers. And, and, it is, man, it is. What we're doing is bonkers. It's just, it's just like, Um, I don't, but there's probably, I mean, is there going to be an, is there going to be like an

endgame for this? It's going to be crazy. What the hell is this? You don't hear my audio, do you? I don't. So there's this thing. That's also bonkers. So, you know, Bun just did like massive releases since they one after the other, right? This also and the guy Jared? Bun just did another release, bun.sh, sorry, Bun. Yeah, because Bun is the Vietnamese.

They just did another one. Format, I think. Yeah, they released Bun FM bun fmt. Like go FMT. Honestly, I love, you know, people love go because it's like one stop shop for all of capabilities? Yeah, the standard library, the tooling is incredible. So at Band, I feel like is trying to emulate go, right? Yeah, so they landed the checker, um, which, when Theo announced his TypeScript, um, rewrite into Rust, his TypeScript compiler, rewrite into Rust,

he compared the performance of his TypeScript rewrite against Dunn, type checker, and it's slower, but he says, I am, I have the full type script implementation, that means some of the effects, like requirements that I need to run, the type checks around that are also working for me where this is something that Bun does not support. So he has like a niche for his thing. The reason why Theo did this rewrite into Rust is also super interesting by the way. But anyway, so Bun launched a checker, so you can run TypeScript check without a TypeScript

compiler now with Bun directly. And then, sorry, they launched the formatter. So you can run the, um, you know, you don't need prettier or OX, which was the um, other formatter to, to, to do the formatting. So you don't need prettier anymore. And people are loving it. Yeah, I, I, um, So the guy, Jared, who, who's doing all these night breaking releases, next breaks, speed, releases. I know how to say it. He shared this thing. He says, I think we need more exploration of this type of things.

So he, um, you're right. He built a language. I still don't get what this is. So this is like he built a programming language that is looks like TypeScript, writes like TypeScript, reads like TypeScript, but compiles to bun. Sorry, compiles to rust. And then for some reason, all of his sample programmes. are using like Bun.serve examples and so on. So, so did he take the types? Did he take the rust, like the bun? Language parser and then just compile straight

to run, um, to a binary via rust? I don't know. This is just too confusing for me. I don't know what this is. Um, but, This is so interesting because when you have all of this in Rust, then you start having the capability to compile it to WebAssembly and to run it in the browser or to run it on these workers, which is one of the things that Theo brought up, which is why he's so excited about the TypeScript compilers in Rust, because now he can run those TypeScript compilers in worker environments,

which is leads to the Cloudflare acquisition of Deno, right? So like, why did Deno acquire, sorry, God acquired by Cloudflare? And why are they so excited about what they say the same thing, which is a completely different way of building applications in the web, which I'm totally unaware of? And both of these threads were like, everything's connected, Kai? Everything's connected. Yeah. Well, I, well, I'm just thinking, of course, I'm going back to my client perspective where I'm, I'm a consultant on, uh, working

in big enterprises. The, Maybe it's because I'm also doing security engineering nowadays. The things that we care about in a big company is like, um, you know, is, do we have secret scanning in place for everything? Do we have SAST? Do we have DAST? And all these new tools, all these new tooling, um, don't seem to be hitting the mark on the enterprise stuff, if you ask me. I mean, of course, Datadog has solutions for all these things and at great prices, so does

GitHub. But I'm just thinking as a language, like, for example, if you were to create a bun, or even, even, I could even probably nitpick a go. The, the go security tool tooling just seems like, um, Well, it's not part of the language, like, I, what I'm looking for, and yeah, if you, if you see anything to let me know. Like, I'm looking for security type affirmations that you can make in code.

Like, with this, with bun, for example, I know you mentioned there's a linter, but can you, but when you push a binary, can you, can you do like a, you know, an SBOM to say that like, yeah, this thing's been scanned and there's no secrets and like, this is the kind of thing that's important in enterprise, this is what I'm trying to say. And we need to make those sort of affirmations or we need those. We need those capabilities in our software development lifecycle with AI. You mean those enterprises, they adopted confluence, and then you find project teams working

with Excel spreadsheet to find, whereas the status of the release. Exactly. Exactly. I mean, man, that's almost mean. Actually, not the other day, I was, I was, someone was asking me, oh, I, I've got Claude running, but how do I, how do I work out, which tickets have been closed by this release? Because I'm the release manager? And I was like, right. So you're, you're not completely, you're non-technical, but you're the release manager and you don't even know what a commit is. Well, I'm just being facetious there.

But, like, it's kind of brutal, though. Yeah. So there was this. Those are the things that enterprises need. Yeah, so there's this interesting tread also related to like non-technical technical. Um, where somebody was like, you know, get ups, the whole premise of GitOps is to basically version control, um, you know, as an audit trail to see who approved when it merged, how it got deployed. These things are really important. Yeah, and then, and then, you know, you have to deal with

compliance auditors and and basically I had to tell my, I was, my CTO was pressuring me 4 years ago before all this AI, um, about, you know, we need to do an audit, quarterly audit for security because we are like, um, we need to be compliant and I'm like, no, but like everything is in, is in Terraform, Everything is in Git. Everything's in Terraform. he's like, there's no auditor is going to look in Git. You know, you have to present all of this in like, you know, PDFs of vector of diagrams.

But at the same time, I think that's changing, right? What you just said, release manager, not being technical. I think engineers are becoming product managers and product managers are becoming like engineers. They need to know, they need to be able to work with an agent, right? Either you're going to fire the engineer who doesn't manage your product or you're going to fire the product manager who doesn't know how to use version control. The last half hour we were talking about, how engineering is going to be affected.

Like, we haven't really even touched on how product managers and delivery managers and And Jira people are going to be affected. It is. It's nuts. It's absolutely nuts. Yeah, but we had this discussion a year ago, and you said, like, oh, as they have a sort of platform, we are in the best position. I said, no, it's whoever can adopt. Um, I still think that platform have a great opportunity because platform right now across Enterprises is kind of the way you enable AI for other people to work.

So if you're in platform, you have the opportunity. Here's a scenario. Maybe it's a bit bizarre, but like, The way that I understand a lot of what I do is like a separation of you this. I do something, and then you, the new, you approve it, Vincent. You do something and I approve it. That's the basic concept that a lot of enterprises go by. Why? Why? It's because no one, no one person has, you know, the keys to the kingdom. Like, you know, one, one, one, one, one, one principle, Sarbanes–Oxley,

separation of duties. Exactly. Which is a compliance like financial, like financial regulation. Yeah, like any large enterprise is probably going to adopt something very similar. So, with that basic premise set, The question is, is like, can an agent be the approver? Probably not, right? There's no, like, there's no order to compliance ISO check is going to say, oh, no, that agent. I don't think today you can, because the agent context can be

manipulated by a human. You cannot say that that you, you, you, you reach the four-eye principle with one agent today, unless that agent context is completely controlled. I still believe it's too dangerous for a human to manipulate the agent. You're answering my question in a way because you're saying that you can't trust the agent. That means there's always going to be that human component to it, and it's always going to be really difficult in light that humans are not going to be super aligned in

the, in the busy AI world that we're living in. I mean, I don't know. Um, I think this is something my colleague asked me months ago and I said, no, it's fine, but today when you when you put it like that, because when you initially ask the question, I'm thinking about the reason of of requests, like reviews, right, code reviews, what's the purpose of code reviews? It's not really like a compliance separation of duty. It's about shared knowledge. It's about being being, you know, not.

That's blowing out the water now, of course. Yeah, that is no longer the case. Um, you need to code review, is the agent is the one that deliver you as a human needs to keep track. You need to produce the artefact to understand the change and be able to defend, because you're ultimately responsible for the change, and you must be able to present the... Yeah, so. So like, let's let's think about this in a way. Like, can you go back to that Tov thing? I think that was a, that was an interesting graphic there on the tov.sh.

Like, yeah, you have you, um, at the top, well, no, the one where it says like, yeah. So you have your TypeScript, your check, your C, your binary. Okay, this is just the right, this is a, uh, This is not a very baked idea, but like, In enterprises, a lot of the time, You might just have a binary, right? Like the delivery manager essentially works with a binary.

It would be great. I'm just thinking, I'm just thinking aloud that, like, it would be cool if the binary had more context in the sense that, like, a delivery manager can say, you know, the difference between this version one binary and this version 2 binary are these features and things like this. This would make enterprise deployments a lot easier, because a lot of the deployer manager I was speaking to the other day, he was sort of like having to, and since this is a complicated enterprise software,

there's lots of components, he had this like unenvious struggle of trying to piece everything together, to have like a change log, so that he could make a software delivery, to pass a certain milestone or delivery goal or something like that. And it's a really hard job. And I'm just thinking, our tooling, Our tooling, Has to change a lot to make this easier. Anyway, I probably, we probably, I probably, Talked about enough.

I, um, Because you started this whole thing about enterprises cannot work. Like a lot of these, when I talked about workers and and Bun and Deno joining Cloudflare, you said none of these platforms seem to be built for enterprises, where the way that you built and deploy software is very controlled with all of these things, the problems that you highlighted, right? That's how you got into this, right? Yeah, yeah. At least I haven't I haven't seen those innovations yet.

Like, I mean, I want to see those sort of innovations where I do think the enterprises are going to break, though. I mean, there is a lot of a lot of shadow IT happening. A lot of teams want to move faster than, you know, what platform can deliver, um, with all this AI, um, you know, what's happening is product managers start to build their own POCs, want to deploy it quickly. They find, you know, these services to go and deploy. Um, there are, that was an interesting posts from the same guy from Massdriver

talking about, um, auditors. They don't want to see get, they want to see an overview. He also talks about like products, doesn't want, sorry, like product managers. They they want to deploy. They don't want to know about how your platform works. They just want to, you know, they have something vibe coded. They want to deploy it, right? And I think When I say enterprises are going to break. They are completely disjoint. I don't know, maybe it's because I just think AI is just aggravating this whole, you know, I

think that's what the Phoenix Project is about ultimately, right? The break between people building and deploying and people maintaining like operations and dev, isn't it? Like engineers. I don't know. Well, there are so many natural sort of monopolies, like, you know, banks, all the big enterprises that we know, like, like, if you're running a bank, Vincent, like, You want to deliver perhaps new features to your customers so that they can, I don't know,

uh, close their account. don't know, don't probably don't want to do that. a terrible example. But it's, it's just wild to think that, that with, if you're using AI, AI agents to do everything in a, in a banking context. So I think that's that's the... I think. Agents, background agents, they will no longer be on the laptop.

They will join um, the engineering effort as an engineer. They will have an identity on behalf of an engineer who's responsible for the work that delivered that engineer role, starts dealing, you know, very close to product, product ownership, and basically being able to translate or being able to suggest features and build them out with the agents and present them. And basically those agents, they take on the identity of engineers, with all of the, you know, for enterprise adoption, with

all of the controls around the identity of the operator who's responsible for it. So all of the enterprise practises of, um, can this go who signed off on this? It will need to take on agents as identities, but They, I don't think they will have a full fleshed identity. I think they will be attached to a human and the human is responsible for them. And that also means that another human is to approve that 1st human.

It could easily get political because, like, a lot of enterprises I've observed are structured in a way that, like, Uh, you know, to shield responsibility. I mean, responsibility and ownership in a lot of enterprises is like uh, A huge problem unto itself, right? I mean, problem is maybe the wrong word, but like it's a it's a tricky thing to manage, right? Anyway, I think, I think I've ranted

long enough. I think I got to actually get busy with some stuff. Yeah, man, I'm excited about it. excited. I had too much fun a lot of things to figure out. But there was one thing that when I started talking about workers and the reason that, like, some people are so excited, like, about Deno joining Cloudflare and YTO is so excited having a rust version of the TypeScript compiler or the TypeScript engine, being able to run it on these nodes, you know, like isolates.

Basically, Node.js is a runtime, that, you know, is a runtime in the chrome is a runtime on the on the server, and and being able to to do all of the work, like even agents, being able to run the type script, checker, and compilation, on Node.js gives you powerful node. Sorry, powerful sandboxes for agent, for agents to work, and workers, built-on workers, the ability to deploy applications that are globally distributed, like basically what Deno Deploy was trying to build, uh, and

then they build Saudi, uh, a threat to to the, you know, paid offering of Cloudflare, and then why, you know, when people, when they read the acquisition, they think, oh, Cloudflare is going to kill it. And they said, no, this is perfect because a lot of our customers, they want, um, they don't want lock-in, they want the ability to self-host, sell the, is that capability, and we are basically, they're going to shut down Deno, the runtime, but I don't think they're going to shut down

sell the. Like it legit becomes a self-holsted way of of running some of this new way of building applications, the Claud Flair workers way. Reading all of this makes me really think I need to invest a lot more time in understanding exactly what is this deployment mechanism. What is this way of building applications? I mean, to me, it sounds a little bit like Lambda having a little Node.js runtime, doing your little thing. It does sound, but it's more like, it's more like edge functions like cloud

front edge, not lambda. It's, it's, you know, Cloudflare, there, even when it'll be a set lambda, which is we're going to provision a container to run a piece of code, and then we're going to, you know, scale those out. That's kind of what lambda was initially, right? And then you had this function as a service that basically rebuilding on top of Cuban 80s, iron function or whatever, there was a whole bunch of them that tried to build it. But of course, AWS has a lot of optimisation capabilities, network interfaces are prepared,

everything. Well, amazing, Lambda, much faster than whatever you can do with Cubinities, custom resources. And then something else came, right? Cloudfront was there. Then Claude Flair launched these, like, keep... I dont know if that was workers, but the ability to to have functions run at the edge. When it'll be as closed from launch lambda at the edge, it was not comparable. It was extremely slow. It couldn't do most of the things that you could do with cloud front functions. Like lambdas at the edge, couldn't hit other endpoints or things like that.

So then they launched another capability called cloud front functions, which is much closer to Cloudflare workers, I think, or... I've never heard of this. Is this new? Yeah, uh, it all, Cloudfront function is really cool because you can have a KV, like a global key value. So you can do like, um, you can have the workers when a request comes in on cloud front. They can hit like a map, a dictionary, they can do counters and then I build all the

integration tests for it for terror constructs. I had a lot of fun with it. What did this come out? Like 4 years ago? Okay, the 1st time I'm learning about it. Oh. Like I have edge functions here. And you have like KVS. So you can have a KV store. You can do AWS key value store, and then you can put in a secret and you can do a jot verification. So the edge function will actually run the,

the, the KVS jaws verification here using the, the jot secret. So you have a global cache, you have a globally distributed. Okay, okay. It sounds functional. It sounds a little bit better than... It sounds a lot better than limed at edge, but yeah. Oh, absolutely. You can do a lot more with this. But then that has grown significantly because this is like 4 years old. Now Cloudflare and if you have Superbage, they have H functions with uses Deno. So if you have super base, you can build your postgress as a rest, and then you can have functions that catch the incoming requests and do things, which to me was super like messy

and hard to understand. It feels very broken way of doing. I don't quite understand. While we're talking about this runtime, are you envisioning a future where... No, T.O. and Cloudflare are... They're saying Theo on his on his YouTube video about why he's so excited about TypeScript compiler in Rust and being able to run it on isolates and on V8, the Node.js runtime that runs Chrome. He says that this is the new way of deploying up and building applications.

Like it's a complete new paradigm of how you build and deploy applications at the global scale. And like I said earlier, I feel like I'm missing out on this deployment mechanism. Okay, so it's like a future where everyone has their own little Hermes agent or application to their own... No, it sounds different. I think it's very relevant for when you run agents in sandboxes. So you generally want an agent to run in a sandbox and often you use isolates, like V8

isolates to run agents in because a lot of these agents they can run into like can be written in TypeScript and run on JavaScript on top of QuickJS or whatever, some very small JavaScript execution and engine, and you can then build edge proxies and things around that to sandbox them. So you can, yes, maybe you were right when you say Hermes agents. They're like little agents that run... Oh, and if you haven't, you should definitely try. more like short-lived background workers. Because I think there's a big difference.

Between a Hermes agent and a small and a short-lived background, like an agent that comes in doesn't work and goes away. I don't quite, well, maybe I'm sorry, my brain is probably fried. Why do you want an agent to come in and go away? Like, for which use case? Serverless, I guess. But why would you want like a non-deterministic thing

to do something and then go away? Like, what's? Oh, you have a lot of cases where you want agents to do the work, but when they're not needed. Like, I have the Hermes agent running on my on my machine at home, it's always on, but I would need, like to see how much of the time is actually doing something. Oh right, right, right. Well, like... That seems like a detail to me. I was gonna big up Grokbot because I thought that was a very good implementation. It's like, for people who don't want to run Hermes, you just use Grokbot and you, you can

easily isolate and spawn different, um, bots or keep them around if you want them. Different capability. So that's the thing. I think... I think... Hermes and Kiro Crew, they're always on. Like, I even have a PR that, um, I didn't land, which was to have ephemeral, like, uh, spot instance, Kiro, and they said, no, that's not a use case for Kiro. Kiro is not spot instance, it cannot be terminated. It must be available all the time. It's an agent with memory, with dreaming, with

all kinds of capabilities, background tasks. It's not something that comes in and goes away. Um, I don't know how they build Grokbot. But they maybe build it more like ephemeral agents, that you can spin up, and maybe they load all of the, you know, memory files temporarily, and then when they're done, they go away, which is a lot harder to build, um, and make it reliable, right? So I think in those areas, you want things that like, like these JavaScript kind of capabilities that, you know, start in milliseconds and do the work and

go away like they're, they're super fast to do whatever. Yeah, maybe you're right. Maybe there is something to explore, like... Um, Because it becomes a little bit more manageable than a long running session, doesn't it? Like you can, if it, if the agent comes and does one thing and disappears, then you kind of have a, you kind of have a better starting point to, to review what actually happened. This is something that I really like.

When you said, like, why would you something to go away? I immediately thought about reverse up time as a secure, um, it's about residency, right? If you have a long running instance, um, if something gets a foothold on it, it, you know, that's why normally when you want to make sure something is secure, you just cycle it. You cycle it very aggressively. Um, as long as whatever is persistent, is not writable by the wrong process, then if you cycle it, it should uh, it should allow you to to

basically reduce the residency of whatever can, can, can take. I think I like that idea. This whole, like, uh, thermal agent type thing. Yeah. Never heard of this guy again, huh? After the whole Kubernetes controversy. But I really, I really need to click some approvals and, uh, and look at my agent, uh, an orca.

Are you using Orco or using a herder or using something else even? I just showed you updated cmux and Cloud. Oh, amazing. So, so, I think we can summarise, what we talked about the anthropic blog post and how they, how I set SaaS for enterprise is dead. You said it depends on the lifecycle and... Yeah, the software life cycle is being thrown in the air, man. And then we talked about the problems with human, like, a lot of um, gatekeeping

and reasons why processes are so manual and why they are hard to change. And then we talked about, I think the exciting news of, you know, TO talking about building TypeScript compiler in Rust. I tell them one of the other cool takeaways aside from his old reasoning of why he built it and why he didn't talk about the Deno acquisition at that time. His video was recorded before. Um, the Deno acquisition use, but I found the news is kind of

very linked because he talked about this new paradigm of how you built and deploy applications. And then at the same time, the Deno post here, uh, from Cloudflare, talk specifically about why they acquired Deno and why celld is such an interesting, um, technology, which I haven't even explored threat. And as far as I understand, celld is the way to run those workers outside of Cloudflare. So that's why that was interesting. So those 2 things. But another thing from Theo was the the cost, he said he had been trying to do this with uh with codex and open AI for for months.

And then when a new version, like maybe 5.5 came out, maybe a month or so compared to like 4 months of um 96% or 90% uh coverage with with the with the codex and open AI models and then just with Opus 5.5 able to reach the target and unable to release this thing within one month. Like, he said, the capabilities of the model with opus 5 for 5 is like so much better. And the cost also was won, like 100s of 1000s of dollars on Codex API credits if he was

paying the real API cost. And then on opposite, it was just 20 K. Um, if it would, if he was spraying. Yeah, I mean, it's using a max plan, isn't it? But whatever, yeah. Yeah, and then on the call last time, we had a call with some people and they said, all these, these, these API numbers are fake because the companies are trying to make their acquisition, like their valuation worth it. So they're... I thought it was an interesting view. to think of it that way.

So I think that's that's everything we covered. and why you want to do sandboxes. Yeah, and then this tough thing, I really don't know what it is. Um, it's very funny. He puts a song on the website, so you can go and listen, and that he has a whole animation for it. I, yeah. Oh, wow. You even get like, when you click, you get like this animation. It's pretty cool. I find it funny because when I built error constructs, I also made a YouTube music video.

I was like, it took me like a week to do that, you know, doing terminal animations, you know, with Suno generated song, and then I recorded it all with like terminal capture, and then I posted it on YouTube, and it was crap. And then I see this and it's like right on the web page. Oh, yeah. Do you read hacker news? Like, did you see that Felix Rieseberg homepage thing? That was intense. No, what's that?

Sorry. Rieseberg? What the hell? He's got a... no, it's not him. Um, just go to hacker news. news. ycombinator.com. I find it very toxic. Really? I think I read it for a while and then I saw every single thread with the same neck beard response and I was like, after this, I don't want to read this. Okay, number 11. I mean, this homepage is intense. Oh yeah, I've seen that. I've seen it on Reddit like 2 weeks ago, stupid hacker news.

A few. There's another one that was really, did Lando Norris? Lando Norris has a really good homepage. Oh, no. Formula One homepages, man. No, the thing is, Lando Norris homepage was posted as one of the, yeah. One of the... Like, from a UX perspective. Look at this. Oh yeah, yeah, yeah.

I've seen that one. But F1, I'm Beijes, always been like that. Although the Lando Norris is very negatively in the news lately. He made some really stupid remarks in Baku, and then again, and then he drove into his teammate in the Singapore Grand Prix, which cost them a lot of points, and then he started grilling in, he made fun of the interviewer when they asked him questions. So Lando Norris right now. Anything he does, he's being trashed. Oh, by the way, I'm going to be in this time next week I'm going to be in Malaysia.

I was trying to organise some runs to attend, but I got a, I got some, I got a Facebook message from a friend to say that like, oh, do you know it's really bad haze right now, you can't go running? I'm like, really? What is a haze in Vietnam? I had, there was a lot of, like, smog above the city, and I honestly thought that I was having a lot of trouble and sickness, like, sinus issues, um, a few weeks back.

I haven't noticed it much now, but the whole Singapore haze situation. Um, apparently someone in Indian, like in, they complained that Indonesia needs to get the forest fires under control, and then Indonesia said, yeah, but, you know, all the other months of the year, our trees provide oxygen. So you shouldn't be complaining. And everyone was going mad. Well, Well, the, I mean, in Malaysia,

I plan to do some running and eating, and the running thing seems to be off the, uh, Of the plan. But when you were in Singapore, you also had, you you witnessed smoke there, no? Yeah, it was bad, but the last few years. Well, during COVID, it completely went away. was amazing. from my window, practically. which is insane. Like it was never very clear. And then thanks to COVID, it was clear.

Thanks to COVID, there was a full earth cleanse, I think. You know, air travel reduced, people on the transportation was gone. The whole nature recovered for like a year. There's other things that came out of COVID that were good, right? Aside from older people. But I'm just a bit, I'm just, I'm just a little bit depressed because I'm going to be there on holiday for 10 days in smog. It's probably going to be mad. anyway. Okay, let's end it. I really need to get back to things.

All right. Thanks to Vincent for chatting with me. Yep. See you. See you bye. Bye. Bye.