EPISODE 1845

[0:00:14] SF: Hello, and welcome to another SED news. This is a different format of the SE Daily podcast where we basically just take a spin back through the last kind of few weeks of tech news, obviously, especially software news. We look at things like the main headlines, we look at Hacker News. We just kind of dive into one topic in the middle there as well, which we'll get into, which is kind of the state of being a developer today. I've got Sean Falconer with me, as usual. 

[0:00:39] SF: Hey. Hey, Gregor, great to be back on this. I'm glad our pilot episode went well enough that we're back to start an official season here. 

[0:00:46] GV: Yeah, exactly. Exciting. Thank you to the listeners for listening to it enough. That means that this gets to continue. So thanks so much for that. And obviously, any feedback, please always find the respective socials at the end and you can ping us and let us know what you think. Yeah, how are you, Sean? How has been the last two to three weeks? 

[0:01:04] SF: It's been good. I've been at Snowflake Summit this week. I know we're going to be talking about some Snowflake stuff later. Databricks is moving in basically tomorrow to take over the exact same location in San Francisco. I'll be there next week. I actually have three talks next week and a whole bunch of different meetings and stuff like that. It's going to be a pretty intense week, but I'm excited to talk about all the stuff going on there. I mean, it was - at Snowflake launch, like a hundred products. It's getting to be like an AWS Reinvent where it's impossible to even keep up with all the things that they're doing. 

[0:01:33] GV: Yeah, awesome. Yeah, I'm back in Singapore. The last episode I did from Scotland. It's been a very hot May in Singapore, even for Singapore. Yeah, very hot and even dry. And, yeah, I'm just crunching through a lot of code stuff right now. But as we'll probably get into, crunching through code is a lot of piloting a space rocket right now in terms of cars. So you're just going to sit there and make sure it's not doing anything funny, but letting it do the hard work. We'll get into that. 

But anyway, let's get on to the mainstream headlines. We're going to be looking at a couple of things. We're going to be looking at Deel and Rippling and what's going on over there. And we're also going to be looking at Databricks and Snowflake. We might kick off with Deel and Rippling. Yeah, it's been a funny one going on there. Have you been following along with any of this, Sean? 

[0:02:21] SF: I hadn't. And then, of course, I knew that you were interested in talking about this, so I kind of looked it up. And I was like, "Oh my gosh. Let me get the popcorn." 

[0:02:28] GV: Yeah. 

[0:02:29] SF: This is something that you see in movies and stuff like that. So maybe you can help provide some background and context for that. But I do have some thoughts on it. 

[0:02:37] GV: Yeah. So this came up on my radar about two weeks ago when, effectively, an employee that is supposedly a Rippling employee. And let's just backtrack for a second. Who are Rippling and Deel in the first place? They are these HR automation platforms. Rippling, I would say, maybe has this sort of slight more cache, if you'd like to give it that. The CEO was the ex-Zenefits CEO. There's a whole bunch of drama there. And we can always vaguely talk about why this also plays into it. 

But, yeah, Rippling. If you're in the US, you probably know a bit about Rippling. But if you're not, then it's sort of you get to just white-glove, have someone onboard all your employees. Whether it's through the IT system or payroll. They'll even deliver a laptop to your employee preloaded with all the necessary security and software, et cetera. Very cool platform and sort of service. Deel is kind of the same thing, but I would say there may be a little bit more kind of on the - in theory, sort of the steady as she goes kind of thing with compliance and so on and so forth. 

Okay, so the deal here, just to use a pun, is that there was a Rippling employee. However, it turned out this Rippling employee had been kind of spying on his own company, effectively paid by Deel to do this. And this came out as this person in Ireland, I believe it was. And it's been reported that this person sort of was confronted in the office and literally threw his phone down the toilet. It's proper spy novel stuff. 

[0:04:05] SF: Was there any smoke bombs or anything like that? 

[0:04:07] GV: Yeah, exactly. I mean, and I'll be honest, quite frankly, it didn't sound like there was a lot of money involved here. We're talking like - I don't know. It was like $5,000 a month or something. So it seems like quite a big risk to take for what's ended up happening. But what's now happened is that - so Deel is under fire for this, like corporate espionage, et cetera. 

[0:04:26] SF: Feels like an HR violation. 

[0:04:28] GV: Right. Yeah. I mean, at the very least, yeah. And then we've got Deel countersuing, but they're kind of doing it on the, "Well, rippling, you've got people pretending to be customers, but they're clearly just there to be spies." And I think this is where it all kind of unravels a little bit for the Deel side because I think, Sean, it's fair to say that this is just pretending to be a customer. That's been part of the playbook in tech since forever, right? Yeah. 

[0:04:52] SF: Yeah. I mean, I think that even if you look at some of the stuff that was going on and some of the heyday of the Uber and Lyft ride-share wars, there was a lot of, I think - or at least I heard. I'm sure you can find out some confirmation. But from what I remember anyway, there were situations where people were paid or received something to essentially go into, say, a Lyft car and then try to convert that driver to be a driver for Uber and so forth. So there's a lot of this kind of like shady business that tends to happen in tech sometimes, but I've never heard of a situation like this. I'm sure it happens. 

Actually, there was podcast I listened to a couple years ago on the Jordan Harbinger Show that I think the title was struggling actor to corporate spy. And it was about this guy's journey who was an actor or trying to be an actor in LA, basically. And he took this gig, this job, where the job was essentially to try to infiltrate different corporations and essentially do this kind of corporate espionage. And they would hire these actors to do that because they're actors. And he took it because he just needed the money and stuff like that. And he turned out that he was like really good at it. It was really, really fascinating podcast I recommend taking a listen to. But it kind of reminded me of that. It's this thing that you maybe hear about from time to time, just a rumor of a rumor, but I've never seen anything in the news quite like this. 

[0:06:08] GV: Yeah, likewise. I'm even aware of sort of people that have pretended to be customers on products I've worked on and so on and so forth, but nothing like this. Where I think in the case of the Rippling employee that was doing this for Deel in theory, it was something to do with Slack channels was kind of what gave the whole game away that they set up within Rippling. They set up a Honeypot Slack channel, but then that sort of got that person in there. And yeah, it all just sounds a bit ridiculous. 

And yeah, this doesn't look great for Rippling, I would say, especially. Well, I say especially. It doesn't look great for them either, because, yeah, the CEO was the ex-Zenefits CEO. There was a ton of stuff that went on there. And two sides to every story. 

[0:06:50] SF: That place was scandal central. 

[0:06:51] GV: Right. Right. Exactly. Scandal central. And yeah, Parker Conrad, that's the CEO of Rippling now. He's come out in public before this landed to tell his side of that story. And, sure, there are always two sides of every story. And YC, Jessica Livingston, very much backed him and sort of believed he was kind of set up a little bit by investors to sort of take the fall for a lot of what was going on at Zenefits. 

But at the same time, here we are again, another massive drama company where he's the CEO. Yeah, it just doesn't look great. And yes, it's had some funny sort of side effects that apparently - I don't know which company it was, but, apparently, a new security startup launched and they actually spoofed this spy story in their marketing. It's sort of flowing through the zeitgeist at this point. 

Yeah, we're going to see what happens. It probably will set some precedent for companies in the future for how far they wish to take it when it comes to this sort of, is it espionage, or is it just sort of the tech world? Well, I guess we'll find out. 

[0:07:47] SF: Yeah, it feels like one of those things that ends up, I don't know - disappears behind closed doors. Some sort of deal happens that the company's come to some sort of understanding. Money exchanges hands. No one necessarily knows all the details and stuff like that. 

[0:08:00] GV: Yeah, exactly. Moving on to the next main headline. Yeah, this is all around Databricks, Snowflake. You're the man to talk to about this, Sean. What's going on there? 

[0:08:10] SF: Yeah, as I was saying at the start of this, we're in the cusp of the Snowflake-Databricks takeover of San Francisco right now with their two major conferences back to back here in San Francisco. But in the last couple of weeks, first, Databricks announced that they acquired the database company Neon. And then Snowflake, I think it was the first day of Summit, announced that they acquired Crunchy Data. Both of these are cloud-based, essentially managed Postgres. 

I don't know which was happening first. I wouldn't be surprised if one company was moving to acquire one of these companies. The other one got wind of it, and maybe that escalated things. But Neon was acquired at a billion dollars, rumored anyway. I don't know if it's public yet or all the details on that. And Crunchy Data was like 250 million. And then Neon's like about 140 employees. Crunchy, around 100 employees. I'm not sure the traction of both companies, but essentially similar moves by both of these huge data players in the data and AI world. 

And I think there's a couple of ways to interpret it. One is that these companies are interested in owning essentially all potential movements of data. They've historically focused primarily in the data tier of the business or in the analytical area of the business. Focused on AI workloads, and analytics workloads, and running a warehouse or a data lake, and so forth. And this is a movement to more of the transactional database OLTP. 

Snowflake did launch something a couple of years ago called Unistore, which was supposed to be sort of one query engine that could query both transactional databases and analytical databases. I never heard of a lot of people using that. But historically, this hybrid database model has never really taken off as a category. It's kind of hard to market because you essentially are trying to sell to different types of users. You have your analysts. And in, certainly, the Databricks world, maybe the data scientists and so forth. And then the people who are building applications are building on sort of traditional application databases. It's kind of like two different worlds. 

But my take on it, and I think what a lot of people are writing about in the news, is this is more about motivation around owning data in relation to AI agents. Agents need both, essentially, historical data that maybe exists in the lake, or maybe you want to use this historical data to build up a model yourself or to even use in some fine-tuning, sort of off-loading mode. 

But when you have the agent sort of operating in a customer-facing application, you're probably not necessarily going to be reaching back to these massive columnar stores to pull that data. It doesn't necessarily make sense. You need a smaller representation of that data that is designed essentially for something like row-level access or ephemeral spinning up on databases and stuff. 

Neon talks about how almost all their databases are actually provisioned automatically through agents. Agents are actually provisioning these things, using them for short-term storage for whatever reason, maybe message passing, short-term memory, stuff like that, and then blowing them away. They need some sort of application to sort of serve that need. 

And there's this new area also that's cropping up that could also relate to why they want to invest in this is around this idea of a context store. In sort of traditional ML, you have something called a feature store that represents through your vectors or your features that you can store, and you can have quick access to that from a model. And a context store is this sort of build off of that idea that, for particular agents, I want to - it's almost like a caching layer for the context that's relevant to the agent and type of work that it's going to perform. 

I think it has a lot more than that. I actually wrote an article about the sort of Databricks-Neon agent connection a couple of weeks ago. It got a fair amount of attention, but it's kind of interesting. Two of basically the same moves within a couple of weeks of each other from two of the major data companies. 

[0:11:55] GV: Yeah. I mean, certainly the timing seems a little bit too coincidental on that front. But I mean, yeah, Postgres has been having its moment certainly over at least the last year. I'm sure you and I used Postgres for a long time, but then suddenly it's kind of come back in a big way. I mean, the version of this that I use and know best is Supabase. And I'm curious, do you have any read on - was any of this sort of influenced by how successful in theory they're getting as well? I'm aware that they've - I think they just closed their series C, if I'm not mistaken. Or it could even be D. This is where the letters - or just they've gone from B to C at least within the space of about a year or something. 

And the reason that they claim that they've grown so fast in just the space of a year is the agent side of things where - and we're going to also get onto this in the main topic in terms of AI coding tools. And they're basically just spinning up instances of Supabase. And a lot of the users don't even realize that's kind of where the data is living. Is there any sort of part of that in this as well? When you talked about agent, is it sort of that side of things? Or is it more directed, you think, by the user? They kind of know that they're using Neon or Crunchy Data? 

[0:13:03] SF: I wouldn't be surprised. I mean, I think that if Supabase is getting a lot of traction there, I'm sure the powers would be that these companies are paying attention and that kind of stuff, because everybody wants to get into the agent market. And if you're as big as Snowflake and Databricks, then you want to own a lot of that market. And I think that one of the things that people are finding out is that data requirements for AI agents and gen AI applications in general is different than traditional ML, where traditional ML is about building models. AI agents and gen AI apps is about building software on top of models. 

Essentially, while you're interacting with the model, you're going and retrieving, essentially, the data relevant to the model to craft a prompt to correctly contextualize what you want. That changes sort of the requirements, where a lot of times I don't think you can rely on - for many, many different types of applications, rely on that data necessarily being available in the warehouse because you're waiting for some ETL pipeline to essentially finish to deliver it. But that could be like a stale representation of the world by that point. Whereas if I shift that problem sort of left to the operational state, and I have an application store that I can essentially have that context available to me, then I don't have to wait for that pipeline to land in the data warehouse or even reverse detail it out and stuff like that. I think they're trying to essentially shift up the value chain to own more of the operational state so that they could serve these agent use cases. 

[0:14:33] GV: Yeah, yeah, that makes a ton of sense. Yeah, in terms of that sort of on-ramp into these larger data stores. That makes a ton of sense. 

[0:14:40] SF: Especially when you see the theme of agents potentially spinning up databases for sort of short-lived work. Because, especially, if the context window has a certain limitation, I might not want to dump some of that context into a database temporarily and then retrieve it later in the conversation, especially when you start to get into these coding agent scenarios where they might need to have churned through a lot of code that could potentially represent too many tokens to send within one inference pass. But they want to cache some representation of it to still have it on hand. And then maybe they throw it away at some point. Are you going to really spin up an entire warehouse to do that? It kind of worked? Probably not. 

[0:15:18] GV: Yeah. That makes a ton of sense. Yeah, super interesting space. I'd say Postgres has just sort of come back. I don't want say to come back with a vengeance. But it's always been a really great technology, and I think often sort of misunderstood as to the power of it over, say, just a basic MySQL database. Or indeed, MongoDB kind of had its time. I don't think MongoDB is having its time at the moment. I think a lot of people are becoming less sensitive to how and where they store the data from a dev perspective when you've got things like Supabase. And I assume people like Neon kind of taking care of a lot of the bits of Postgres that was a bit annoying, things like migrations. When that's all taken care of, then actually the underlying technology feels more powerful than perhaps what MongoDB can ultimately give you, unless you're always running on MongoDB's Atlas, and that is expensive. It's kind of interesting. 

[0:16:10] SF: Yeah. And also, the relational databases have adapted to support a lot of the things that you liked from the NoSQL databases like a MongoDB where you have like JSON representation. 

[0:16:20] GV: Exactly. 

[0:16:21] SF: But then you can query against it. And actually, Oracle, I forget what they call it. They have a new functionality where, essentially, the JSON NoSQL representation is almost like a view on top of the relational database. You can have both essentially within one database. There's been a lot of innovation that's happened in the relational world to adapt to those demands. So then it becomes just a feature, essentially. 

[0:16:45] GV: Exactly. MongoDB was kind of, "Hey, we're JSON. You just dump JSON in. And, look, it's a database." And exactly when that stops being a unique feature, as you've called out, yeah, their moat kind of shrinks quite drastically. And it's interesting that MongoDB have basically just decided that their whole business is just around the hosting effectively and just trying to drive people to Atlas. Yeah, interesting space. Thanks for highlighting that one. We'll watch along and just sort of see how those products integrate or potentially don't. That's always the interesting part of acquisitions. 

Moving on to kind of our main discussion topic for today, which is just quite frankly the state of being a developer today with the tools that are available. And I think we're talking a lot here about, especially Cursor, but also the others, things like Windsurf and Bolt.new, et cetera. 

And certainly, in the last month, I mean in the last couple of months, things have really been on a tear in terms of the advancement of these IDEs. And yeah, I think it's just sort of a good place to take a minute and see why are we even here and how are we kind of feeling about this as developers. Yeah, I mean, I guess what's been your experience so far, Sean, in terms of any of these tools? And sort of how far back does that go? 

[0:18:03] SF: Yeah, I mean, I primarily use - I do have Cursor, and I played around with it a bit, but I don't use it sort of day to day. I think if I was coding all the time, I would 100% be using these tools. For the amount of coding that I do, which is more sort of at this stage in my career, proof of concept, demo, sort of vision stuff, I get away with using Claude directly, or ChatTPT and stuff like that to help me write some of those things. And the efficiency gains are massive. And this goes beyond coding. I think you're doing yourself a disservice if you're resistant to these tools, because they are massively efficient. 

But my perspective on this has always been that developers, engineers are paid what they're paid, essentially, to solve problems. And I don't think these tools, at least as of yet, really solve the problem for you. You have to direct them to solve the problem. You're still doing the problem, but they can help you implement, essentially, the solution much, much more efficiently. 

I think that it gives an opportunity for junior developers to contribute faster and senior people to probably avoid some of the more tedious work by offloading some of that stuff to AI. And then I think when you get into stuff like PR reviews, which are now also seeing levels of automation, there's things around people are trying to do stuff with like SREs and stuff like that. Those jobs don't necessarily go away, but they help, I think, fix some critical issues. 

With PR reviews, I think a lot of people don't enjoy that experience. I remember when I interviewed the CTO of SourceForge, Beyang, he said that no one's ever been promoted for giving a great PR review. It's not necessarily something that everyone enjoys spending their time on. They would rather be coding and contributing in that way. 

And then I think with SREs, I don't think anybody loves getting woken up at two in the morning because a page - and then sort of starting with a blank page, other than the fact you have it at work. If you can have something, help do some solutioning, gather some material, even figure out, "Do I need to wake this person up or not?", that seems hugely valuable to me. 

[0:20:05] GV: Yeah, definitely. Yeah, I mean, I think on my side, I guess, yeah, I'm coding most days. And yeah, I mean, certainly I was one of the, I guess, first, pretty early to save Copilot inside VS Code. And I think most developers would look back on that and go, "Yeah, that was interesting. But there was just a lot of not terribly smart code coming out of that." But that was obviously super early days. 

Now I started using Cursor maybe back in November, December. And yeah, I think the tedium was the thing, functions that you just kept rewriting. And frontend work is actually a lot of where I kind of put it to work to begin with, because I didn't fully trust the backend logic could be - I guess I just didn't want to trust it to that. But on the frontend, you can kind of see, "Is this what I was trying to achieve?" And stakes are just much lower in terms of how bad can this be? Again, so long as you've kind of set things up in such a way, like, "Oh, I choose Svelte and SvelteKit." I don't particularly want Cursor to kind of decide for me, "Is this going to be like a React app or something?" 

[0:21:01] SF: Right. Yeah, yeah. 

[0:21:03] GV: And then, yeah, fast forward to certainly the last month, and I'm just kind of a little bit blown away by actually just the sophistication of the sort of solutions it comes up with. But we're still talking sort of a 10-shot, if you want to call it. A 10-shot process here, where I can go from zero to having a fairly meaty feature implemented within one, if not, max, two days. And that's it. It's just kind of overseeing a 10-shot process. And there it is. 

But as you call out, Sean, it's about giving it the direction of what you're trying to achieve. And even small things where I say, "Well, actually, we want this data cached locally." And then it's approached to local caching. Well, you kind of have to tell it, "Do I want this in local storage, or do I want this in IndexedDB?", for example. 

I think coming back to the kind of the junior developer point, yeah, there's still a lot for junior developers to be able to learn here where they still are going to have to learn the approaches that make sense even if they're not potentially learning, if you want to call it, the hard way, the code that actually had to be written to achieve this.

[0:22:04] SF: What's your perspective on if everybody can build some of this stuff or build some level of it where they don't necessarily need to understand quite as many of the nitty-gritty details? They kind of just need to understand the direction or the outcome enough to build a direct the IDE or the model to essentially generate something that's going to be correct. How do you feel about that in terms of an impact on overall state of developers in the future? Are we reaching a place where no one's going to understand sort of what's happening under covers, and it's all about prompting in some fashion? 

[0:22:40] GV: That's a great question. Yeah, I mean, I can give what I think and feel at the moment, which is obviously one very small perspective. I am concerned that developers kind of into the future are not going to be able to potentially problem solve quite the same way. Because I guess I'm concerned that coming to it now feels just like I just want this feature without really understanding - right. But how does this feature - how should it work ultimately? 

I mean, the local caching thing is - go back to that example. If I had implemented this feature without ever having coded anything in my life, I would have been like, "Oh, this is great. It does the thing. It pulls the data, presents on the page. Boom. Done." And actually, the experience is made immeasurably better because of local caching. Now I'm still trying to get my head around at what point will a sort of new developer coming in, where will they learn these concepts? Is it just through pure curiosity? I do hope it's that, where the tedium of coding stuff that was just kind of grunt work I hope translates - if you take that away, I hope that translates into people taking that time and going and being able to kind of really study up on the concepts that they're trying to sort of achieve with. 

And I guess sort of have a larger breadth of knowledge across coding generally than they might have been able to. I think we're kind of probably going to see the end of, "Oh, I'm frontend. I'm backend." I mean, a lot of people, of course, said they're full-stack for a long time. I'd have often argued before these tools that full-stack was still a bit of a, "Yeah, I mean, but you're probably better at one than the other, aren't you?" These days, with something like Cursor, I believe full-stack is a very credible thing you can probably say now. 

[0:24:18] SF: Yeah. Yeah. I mean, I think they're really incredible at the frontend stuff. And I think part of it is there's just a lot of reference material that exists on the internet to train models on in relation to that. I haven't tried this myself, but I suspect that if you wanted to try to, I don't know, build your own driver or something that was a little bit closer to the hardware, maybe they're not as successful there because there's just less references available for it. And it's not that they couldn't help at all, but you probably have to do a bit more work as the person to get them to do what you want. 

Whereas if you want to spin up a form using whatever, React frameworks, Svelte, whatever, Vue, they can jam that out pretty quickly for you. And I know a lot of people, friends of mine, that have always thought of themselves as backend developers are now contributing some UI in sort of their own projects and stuff like that. But that would have been too scary for them historically. 

[0:25:15] GV: That's interesting. Yeah. Again, set up the project with the framework. For example, on the frontend, got Svelte, SvelteKit, Tailwind. I then add in a component library, daisyUI. And once you got all that kind of decided, then Cursor, for example, is pretty good at then just cranking out exactly what you intend. You can still sort of say, "Hey, make it more elegant, literally." And off we go. It becomes more elegant. 

I think on the backend, yeah, it's a good point. It's definitely where I put more caution when it comes to just letting it kind of do its thing. But again, I think if you set up your project with tenants, for example, as I mentioned previously, using Supabase. I wrote a little middleware piece that would sort of always understand who the user is and deal with that kind of off piece. Now, Cursor always wants to go off and do like an admin call to Supabase. And I'm like, No, no, no. You got to use the helper." 

And I know in Cursor, you've got rules and you can sort of set it up and tell it to always use these things. But, and I think this is the big but, back to your question sort of junior developers. I'm not clear and sure at what stage that sort of new developer will learn, "Why shouldn't I be always calling the database with the admin keys?" Which is unfortunately the default, it seems like, unless you set it up otherwise. Yeah. 

[0:26:28] SF: Yeah. I mean, I think the counterargument is that people have been concerned about that ever since we've been moving to any sort of higher level abstraction. Back when people started writing C, assembly developers were shaking their fists at these new-fangled kids writing things in C. And they'll never understand how to, I don't know, move memory between different areas of the cache manually or something like that. And then from there, C, Java, and then people said the same thing about Python. Or even moving from using Emacs and Vim, to IDEs like Eclipse, and IntelliJ, and stuff like that. 

And then we've had things like Intellisense IntelliSense, or code completion and all these types of tools. And with each iteration, people have complained about the same sort of thing. As far as I can tell, it hasn't destroyed too many countries, and civilizations, and people's careers so far. I think the argument, I guess, is this is just another version of that, is just a huge step function in terms of what we've seen previously. 

[0:27:27] GV: Yeah, absolutely. I mean, to kind of slightly wrap up just this bit of the discussion, there was a good - I mean, I think it's quite opinionated. But it was a good article by one of the guys fly.io. It came out at Hacker news a few days ago. And I think that he framed it pretty well, which was just sort of saying, "Look, if code is meant to be a craft for you, unfortunately, the world just doesn't kind of operate like that anymore. You need to be a little bit precious about the code that you're writing, unless it's a craft, a hobby project. And quite frankly, just kind of get the features done and obviously well." And I think that's where these tools do come into their own, because a lot of development, unfortunately, is tedious. And it's that stuff that we often have tried to avoid. And I'm sure, quite frankly, these tools can help more. 

I think coming on to the IDE point, generally, you mentioned IntelliSense. I mean, I remember back in the day paying what feels like a lot of money for a JetBrains IDE. And now, a lot of people migrated over to VS Code for various languages, which obviously was open source, or "open source" and free. And now, we're coming back to paying for IDEs. And sort of, yeah, what's your take on that in terms of could open source come back again or - 

[0:28:37] SF: I actually had a conversation about this this week at the Snowflake Summit. Someone brought this up. And I think it's because Windsurf had a booth there. It sort of sparked this conversation. But I don't know in the long run what is the future of these AI-powered IDs as a business. I think there's huge value in them, just like there was with even the initial first wave of IDEs from 20 years ago, there's clearly value. And in the early days of that value, people can charge for it. But at some point, that becomes a commodity. And I don't know what the mode is for any of these particular IDEs. Do all of them is sort of become similar and one person can switch between them and there's not really like a stickiness to it? 

And overall, dev tools is a hard market to make money in, period. Because developers don't like paying for those kinds of tools that is just sort of the tools of the trade of doing business. They don't mind paying for infrastructure, and hosting, and things like that. But in terms of helping me write my software, people don't generally like paying for a lot of those tools. 

[0:29:43] GV: Yeah, definitely. I mean, at the moment, Cursor Pro is about $20 US, which seems very reasonable, quite frankly. I've had a quote from a good developer friend saying they would happily pay $200, not $20. I really hope they don't get up to $200. But I could see a world where versions of Cursor potentially cost that and businesses will pay for it, quite frankly, if the efficiency gains are there. 

[0:30:06] SF: Yeah, that's true. I mean, even if you look at something like ChatGPT, people are paying for that. And arguably, the prior equivalent of that might have been like a Google search. And you paid for it, but you paid for it in terms of your ad clicks. It's a different business model. And maybe we're entering a new wave of business models where people are willing to pay for these premium services that are ad-free and so forth. 

[0:30:32] GV: Yeah, that's kind of the state of, I guess, being a developer at the moment. We didn't, I guess, particularly touch on tools like Windsurf and Bolt.new. Just a very brief might take on those or maybe that there are a little bit more in that vibe code category. Perhaps more people that wouldn't have maybe normally coded. And this is how they're kind of on-ramping to that. But I no doubt will see some sort of developments there. 

I mean, I'm aware that Bolt.new's technology behind the scenes is pretty cool because they do a lot locally, basically. And that's sort of how they are able to run it at cost that makes any sense for anyone. I don't think that's the case with Cursor where obviously you're literally choosing Claude 4 or whichever, and that's all being run by them, which is probably costing a lot of money. 

[0:31:14] SF: Yeah. I'm wondering what the CAC to LTV ratio is with this $20 a month. 

[0:31:20] GV: Yeah, I'm genuinely a little bit concerned that that's just not going to hold. But I mean, even if they doubled it, I think it's absolutely still worth it. Does it ever reach something like $200? I think that'll be a question mark. 

Let's move on to our next regular segment, which is just taking a little spin across Hacker News from the last few weeks. Sean and I just like to kind of pull out a few things that have kind of popped up as we go about our daily lives. Yeah, I might kick off with there was a fun one called Japan's IC cards are weird and wonderful. And this caught my eye because I have traveled in Japan and I used to live in Hong Kong. And as I learned from this article, the technology used by the transport system, these cards, it's actually the same technology between those two places, which is different to how a lot of other countries have gone about their tap and go. 

And what I found kind of fun and fascinating about this was just that this is a technology I believe developed by Sony, but it was not actually used in Japan initially. It was actually used in Hong Kong initially. And Hong Kong houses think of the Octopus card. And the Octopus card was pretty much the first sort of mass-adopted tap transit card, but could also be used in 7/11 to pay for things. 

The key thing to this technology that I wasn't super aware of was just that it's a slightly different standard of RFID. And the key bit to it is speed. And this idea that these are very congested cities. If the barrier doesn't open within a sort of 10 milliseconds of you tapping that card, then you're going to have lots of cues in subway stations. And I'll say I witnessed this firsthand in Hong Kong where people just don't even think about. They just tap and they know the barrier is going to open instantaneously. Yeah, I hadn't really dived into the technology behind something I've used many times in my life. And this was a nice little article on that. 

[0:33:17] SF: Yeah, I think it's really interesting how, because of a congestion and sort of trying to optimize for like human flow, they had to essentially invest in this different way of doing those cards and using NFI. I think that's really interesting. Because if you live in the US like I do, public transit only exists in a handful of cities. And many of those cities are not great, typically. There's not like a pressure to essentially really try to optimize these types of things. So they just don't. You end up with like a version of technology that is inferior to what they're doing elsewhere. 

[0:33:51] GV: Yeah. And it's funny because I live now in Singapore and they do have their own - a tap card system that was just for the subway and the buses. I never got that because by the time I moved here, like quite a few other cities, you can just tap your bank card or your phone with Android Pay and Apple Pay. The thing is, that is definitely slower. I mean, I put my phone next to the thing and there's always a bit of a kind of will it, won't it open the barrier? Most times it does. But it is no way the same reliability where you can just put that card and just walk at the barrier and know it's going to open. It's just not the same thing. 

[0:34:28] SF: You got to go full stop. Or you're going to crash into something, essentially. 

[0:34:32] GV: Yeah. Yeah. And I mean, Singapore is not as congested. Now that I know that it is categorically faster to use these cards that were developed by Sony, I think about every time I go through the barrier now. Yeah, what caught your eye on Hacker News, Sean? 

[0:34:44] SF: Yeah. So one of the ones I pulled, it was posted a couple of days ago, was this post about comparing the system prompts across different Claude versions. And you can actually look up, there's like a GitHub repo that will show you the full Claude system problem. 

[0:34:57] GV: Yeah, right. 

[0:34:58] SF: It's like 23,000 tokens. It's pretty massive. But I think in this particular update, a couple of things that was interesting was it shows how they're really using the system prompt to shape sort of how Claude acts based, I think, on what they're seeing from a user behavior. Essentially, in between training cycles with the model, they can release new versions where they use the system prompt to trick the model into doing the things that they want, where they can set the tone, set the policy, the personality. 

There's some interesting things in there where they explicitly remove flattery in your responses. It says we'd be more direct. It's actually very similar to like a lot of the times the things that I put in as my prompt is like, "Stop writing like a marketing person and be direct, and concise, and stuff like that." 

And they use a lot of these kind of behavioral hacks in different versions. In some of the old versions, they had to do things to explicitly instruct Claude on how to do like word counting and how to avoid things like bad poetry. And then they have been able to improve the model through training to solve for those use cases. And then they remove those instructions, essentially, in the prompt from the future versions. 

[0:36:13] GV: Yeah, I saw whether it was this one or something similar. But yeah, I mean, there's the fairly prolific blogger who keeps popping up, Hacker News Simon Willison. And he's written a bit about this as well. But yeah, pretty fascinating. I mean, I would say until two, three weeks ago, I wasn't even that aware of the fact that there was this massive prompt that is the model, if you know what I mean. Okay, you've got the data, but you've got this huge prompt that effectively being run every time that you then add your prompt and so on. 

[0:36:39] SF: Yeah, and it's going to eat up some percentage of the context window, essentially. 

[0:36:44] GV: Exactly. Yeah. The thing I'm still trying to get my head around is just the temporal aspects of models. And they seem - again, I'm talking, I guess, mainly about OpenAI's models at the moment, but finding that they just still struggle big time understanding the time. If I put something in and say, "The day is June 6th, 7am right now," and then you give it some data, and the data says today, but the date on it was yesterday. It still says today. It's like, "Oh, today, da-da-da-da-da." Well, yeah. I think that's an interesting one where I'm curious if there's any models out there that are really tuned on the temporal side of things, because I haven't seen that in these. 

[0:37:21] SF: Yeah, I don't know if it's a good question. I'm not sure. I think some of that stuff is tricky. It's not surprising that the model makes mistakes. Yeah. 

[0:37:29] GV: It's frustrating, but I quite like the fact that I found something that it doesn't do very well yet, and I find that kind of fun, and how to try and solve that. 

[0:37:38] SF: Yeah, I've found with certain models, a lot of times if you're asking for certain lists, certain models don't do a very good job of that. If you say, "Hey, I want 25 things that match the specific characteristic," the first like five, six, seven of them will be good matches, and then it starts like slowly deteriorate over time. There is some confusion that tends to happen with the models when they have to do, I think, longer output. Of course, if you're throwing a lot of information at it as well, sometimes it can lead to confusion. 

[0:38:09] GV: Another just brief one that popped up, which is I think just also good, is a sort of PSA for people to go and use themselves is Have I Been Owned or Pwned, however you want to say it, 2.0. Thank you to LaurenDB for posting that one. This is the service Have I Been - I'll just say owned, for the sake of argument. Have I Been Owned 1.0 has been running for a long time. It's where if you are wanting to find out if your email address or phone number has been found in a hack, you can just pop it in. And it's a free service to use for an individual if you want to kind of run it on a domain crossword company that tends to cost some money, which makes sense, and there's a very good API. 

But it hasn't really had any updates in a long, long time as Troy Hunt, the founder, I believe, says. 2.0 is quite a big deal. Yes, only the UI has just had a major lift and sort of much more intuitive in terms of looking through what might have happened with your data. Just reading that, I hadn't maybe appreciated, there are some hacks where, in a good way, if you want to find out that you've turned up in this hack, they will email you the result as opposed to you finding your results publicly. 

And to be quite frank, the main one they should talk about, of course, is Ashley Madison, which was a slightly controversial dating site. And that makes sense. You shouldn't really be able to just go and find anyone's email address and check if they were using that site and also got hacked. Yeah, I think, it's a great service. 

And one thing they also talk about, they've dropped username and phone number searching, which is interesting, because they just said it's become too cumbersome to kind of be able to run that reliably. Yeah, that's a sort of interesting update. Yeah, go check that out. And obviously, if you have never used it before, always a good one just to go and run your personal and work email through just to double check if you've turned up anywhere. 

[0:39:58] SF: One thing they did talk about in the article about the new version of the website is they did a lot of AI use essentially to generate the frontend. 

[0:40:07] GV: Ah, yeah. Okay. 

[0:40:07] SF: Okay, back to what we were talking about earlier. 

[0:40:11] GV: Yeah. I mean, that would make sense. Just sort of sidebar. Yeah, I did a pretty fun thing, which was new landing page for a product I'm working on. And I just had Cursor look at both the backend and frontend repos, and I said generate a landing page based on all the features of this product. And it was absolutely fantastic. Within one hour, I had a landing page. And within five hours, I had a landing page I was like happy to publish. Just incredible. Yeah, it doesn't surprise me that they took that approach, which is pretty cool. 

[0:40:38] SF: Awesome. 

[0:40:38] GV: Anything else from your side on Hacker News, Sean? 

[0:40:42] SF: No, I don't think so. 

[0:40:43] GV: Cool. Yeah. Well, that was a nice little spin through things. As we kind of wrap up and just look ahead in terms of normal programming, yeah, I'm aware that we've got anyon_e laptop episode coming up. That's with Byran Huang and myself. This was a fascinating episode. I was alerted to Byran from Hacker News. We talk about in the episode, it's the number one kudos of all-time article on Hacker News, except for this other one that he highlights, which was it is technically number one, but it's only because the user had found a hack as to how to hack Hacker News and get it to the top. Byron's is actually the real number one article of all time. 

It is an open source laptop. And that might not sound particularly credible, but if you listen and potentially watch his video afterwards, just the level of detail and craftsmanship that went into this laptop. And as it sounds, it's all open source as a repo, as to how to build this laptop. It's just incredible. And the kicker is that he's in high school or he's just finished high school. Yeah, I think I just can't recommend that one enough. 

Moving on, we're going to have, I believe, the challenge of AI model evaluations or evals with Ankur Goyal and yourself, Sean. Yeah, what's that about? 

[0:42:05] SF: Yeah, Ankur, he's the CEO and founder of a company called Braintrust, and they're focused on how do you build evals, essentially, for gen AI applications, and AI agents, and so forth, which is something that a lot of companies end up kind of rolling their own solutions to that today. There's just new crop of companies coming up like Braintrust that are focused on solving this problem in like a more systematic way. 

[0:42:28] GV: Yeah, I'm going to definitely listen to that. I want to get a bit more up to speed on sensible ways to eval or use evals. And then we're also going to have back to some of our video game content. We're going to have WayForward games with Tomm Hulett and Voldi Way. And that's of course with Joe Nash. Yeah, tune in for that. I don't think we've had quite as many video game episodes this year. That's one of the next ones coming up. Yeah. 

As always, thank you for tuning in to SED News. This will be, hopefully, a monthly installment. Just look out for us around the start of each month and catch up on what's been going on. But yeah, anything else you want to call out, Sean, before we wrap up? 

[0:43:08] SF: No, I think we covered it all. There's much going on in the world these days. It's hard to cover everything. But I'm looking forward to getting back with you next month. Yeah, absolutely. 

[0:43:16] GV: Yeah, absolutely. As Sean says, far too much to catch up on, but we do our best to try and hit the high notes. Thanks again for tuning in, and we'll see you next month. 

[END]