Mackenzie Jackson: Hello, everyone. Welcome back to another episode of The Secure Disclosure. I'm here with James. James, thank you so much for joining me here today.
James Hawkins: Thank you for having me. I'm CEO and one of the founders of PostHog. I wanted to talk, maybe to start off, if some people here don't know what that company is, what does PostHog do? Why did you kind of fight to start that company?
James Hawkins: Sure. Yeah. So I'm actually technically co-CEO, so I run it 50/50 with Tim. I'd actually argue he's more CEO-y than me at the moment. But yeah, we started it because me and my co-founder wanted to start our own company, start something from scratch. And we pivoted loads and loads of times. And every time we tried a new idea, we kind of got pissed off setting up all of these third-party tools to understand our user behavior. We're both, my co-founder is very technical. I've got more technical over time, I would say, but these tools just felt to us like they're not built for engineers to use. We kind of had this belief that engineers aren't tapped out in terms of the contribution they can make inside of a company. So, for example, product managers traditionally would decide what gets built, what's on the road map or whatever. And our belief was, we think engineers actually have a pretty good idea, it's just no one asked them or let them weigh in. But there's a reason they're engineers, they have gone deeper than other people. Because I think they might be smarter, they're harder working, they're better problem solvers potentially. And so we should probably listen to what they care about. And so we kind of had this belief that engineers could be really good at deciding what to build. And so let's build a bunch of tools for them to understand user behavior to help them be better at product, basically. So yeah, we pivoted a bunch, got pissed off every time, and then eventually went, actually, let's just ship a really developer oriented version of product analytics. That is where we started. And then our product strategy has hugely shifted since then.
Mackenzie Jackson: Yeah.
James Hawkins: But it got us. We built an open source version. We put pricing on the pricing page on our website. We did magical stuff like that. Someone paid for it. I remember looking at SpaceX's website around when we launched. And I was like, SpaceX on their website, you can literally price how much it costs to deliver a payload into orbit. And yet, B2B SaaS companies can't seem to put pricing on their pricing page somehow. So we want to be able to at least price a software product without a sales team extorting you, basically, for as much as they can get. So yeah, we just, this is a sort of thing that we felt wasn't being done very well. And we felt like there's going to be potentially a group of people who are going to be interested in knowing, engineers who are interested in knowing how their stuff is being used. And that's kind of where we focused and that's kind of how we got it off the ground. It's kind of like cutting out a whole bunch of processes in the middle because ultimately engineers are going to build something, then a whole bunch of marketing people are going to analyze and do stuff.
Mackenzie Jackson: Yeah.
James Hawkins: And then it's going to go back to the engineers.
Mackenzie Jackson: Yeah.
James Hawkins: For them to be able to implement.
Mackenzie Jackson: Yeah. But if you give them direct access to the goals that they're trying to achieve, then that makes a whole lot of sense that actually that's a better workflow.
James Hawkins: We actually got this guy called Charles, who joined PostHog. I think he was employee nine or 10. And he's done pretty much everything at some point or another at PostHog, apart from engineering. And he wrote a post on just collaboration sucks, basically. He's like, I probably torched my career by writing this, but it's now become kind of a meme internally.
Mackenzie Jackson: Exactly.
James Hawkins: But don't collaborate, basically. It just creates a lot of process back and forth and extra communication. It's expensive to collaborate. Sometimes it is definitely needed, but I'm being really mindful of not defaulting to sharing everything with all your colleagues and being willing to kind of lone wolf something a little bit further, or just doing the extra. I think a lot of people do things like meetings because they basically can't be asked to come up with something themselves.
Mackenzie Jackson: Yeah, yeah. Make them feel like you're doing something too. Yeah, exactly. You feel like you've been productive even though you've achieved nothing.
James Hawkins: Yeah, it's a way of procrastinating, I think, almost. Good procrastination.
Mackenzie Jackson: Which is appealing to everyone.
James Hawkins: Yeah, we do believe that there is perhaps a lower way of getting stuff built. And we think engineers could pull this off, but they probably just need a little bit of a holding hand through it. And that's kind of where we've focused our efforts.
Mackenzie Jackson: Yeah. And it's a very similar kind of story to how Aikido started too, because we had this idea of no security for developers. Yeah. Because ultimately, they're the ones that deal with this. But you have these tools that are kind of built for security people. And what security people want and what developers want are fundamentally different. Security want every single alert ever, so that they have all the information. Developers want to fix what's broken. And so it's interesting to see that that workflow came through both ways.
James Hawkins: Yeah, I think that's almost exactly a parallel example, basically. I can see even in PostHog, our security, where the developers are very secure team. We do have a couple of focused security people now, but it is very collaborative with the engineers, I would say. And I think that's working quite well for us at least at this stage. I want to get into some of the more spicy things.
Mackenzie Jackson: Yeah. So famously, you guys are open source. Well, open core. Yeah. That's challenging right now. Why did you guys decide to build open source? Because it seemed counterintuitive sometimes.
James Hawkins: So I think if you're building for, you know, the generic startup wisdom of like, build something that your users actually want. So then you think, well, if you're building a dev tool or something for developers, I would say it's objectively better that it is open source than it is not because developers can then inspect the code. So they can just see what's going on. They can ship fixes if they, sometimes I think there's a real developer thing of like, oh, this stupid piece of software I'm trying to use has got this niche bug that I understand could actually just fix. Or if we're supporting them, so if they raise a ticket or there's a bug or something, instead of saying like, yeah, we promise we'll care about this at some point, you can go, here's the issue in GitHub, just follow along, basically. So it's much more transparent, builds trust, and it forces you to do the right thing more as well because people can literally see everything you're doing. And so if you've got hideous slop in your code base or something, everyone can see it. And so it kind of, it means you have to work a little bit harder. It's a bit like having your homework marked by the teacher where you kind of know that like, well, someone's going to look at this thing and judge us on it, which actually forces to about drop the fundamental product in the code base in the first place. So I think it's always better by default and then you have to think through the commercial side of what are the downsides. Like your options are closed source and source base, source available where you have something that's non-permissive or truly open source, like MIT or Apache. And our perspective was like, well, we don't see a good reason to go, well, thinking from a user and a product perspective, like if we're targeting engineers really specifically, compared to our competition who are not, I mean, closed source is pretty lame from like that would be a very lame move, I suppose, basically. So basically, needs to be open source. And then it's like, well, we either have a choice of permissive or non-permissive. We kind of realized that, I think if you're something like a database or piece of infra that AWS could basically just run if hosting is kind of a competency of the company, it's a much scarier decision to go permissive because then you, if you're successful, you're going to have a lot of competition. I'd also argue though, is it really a, like, if you're from the perspective of two people who have no revenue or customers or anything, is it really a problem that you build a billion dollar company and now you, now you have AWS competing with you? I'm like, that sounds like a good spot to get in relative to having no one caring at all. So, you know, it's a bit like arguing, you know, I don't like the curtains in my five-star hotel or something.
Mackenzie Jackson: Yeah, yeah. And then the author.
James Hawkins: So I'm just like, I would just lean strongly towards being permissive as far as possible. If you are like a pure database or something, maybe non-permissive makes sense, but we've got tons of applications. We have tons and tons of front end and buttons and stuff. Really it's things like, and now increasingly with AI, it's really the data that we have, this proprietary data, which means we can do a better job of building things like agents or in future doing things like model training and so on. And I think that's really where our moat will come from. And the fact we also have like lots of distribution, we have good brand, we have good history of doing the right thing for developers. So, the actual code I don't think matters. The other thing that's interesting, if you do non-permissively licensed open source, you're one prompt away from Claude just copying, going, hey, like use this for inspiration, do not copy the code, and just build the same product. It'll just do it. And so I'm like, it's kind of meaningless now, I'd argue.
Mackenzie Jackson: It does feel like that with AI, right? You know, like the barrier to entry is getting lower so that like, and it's all that you say, it's the data, it's the branding, it's the trust that you that you have. That can't be that can't be forked.
James Hawkins: Yeah, the code's getting commoditized. And that's like branding and stuff is getting disproportionately important, I think, as a result. Or our data, which then isn't obviously your data isn't available publicly. So, it's those two things from my point of view, at least. But there is another side to this, which is something that we're seeing a lot of at the moment, which is the security side of it. Open source is kind of, with AI and security, open source always kind of breaks first in a lot. We've had a guy on the show, Daniel Stenberg, who was the creator of curl. And he's dealing with kind of AI slop reporting that's coming in with these things. Cal.com have just closed source because basically, the TLDR that I see is that they're terrified of vulnerabilities being made apparent. How are you dealing with those security issues and having open source?
James Hawkins: It has been extremely stressful. There are really good tools for breaking into software that are coming out, including just basic Claude, for example. The thing that's changing is that there are tools coming out that can chain together multiple obscure vulnerabilities to break in in a way that would be very challenging for a human being to realize that there is an exploit. And so we had a really large debate over this. We did have a Cal.com-style debate. We just wound up concluding in the opposite direction to them. I can totally see why they made that change. It's kind of, it's actually frustrating to watch a little bit because on the internet, a lot of criticism was, oh, they're just trying to like force more people onto a cloud product to make more revenue, whatever. I just know, like, I'm friends with Peer Rich from there, and I just know that it's not the case and it is, we, they think that their stance was that it is better for their security. Up until we took the opposite decision in the end and we kind of concluded that like, well, open source flashes out any potential issues we have. It forces us to be super on it with security in general. We have a very strong culture of this and all that like much, much stronger like, always had a good culture and now it needs to be extremely strong, but it kind of forces us just to do a good job. And we're like, well, what's going to happen is if we're not open source, we may have a security issue. It's kind of just delaying it. Like at some point, we become big enough to become like a massive, we've already been targeted repeatedly, but then we become big enough to be a super juicy target like Equifax was, for example. So it's like, well, I'd sooner have like smaller issues in smaller doses right now than build a company that's a hundred times the size and has a major catastrophe in future or something like that. So, yeah, our perspective was like trying to, you're kind of just deferring. You'll have those problems sooner if you're open source because you're more exposed. But those problems don't go away by being closed source. You're just deferring until you're a bit bigger and then you're still going to have the same problems. And so we kind of felt like it's probably better to just deal with this now, a bit like going to the dentist regularly rather than waiting until you have to have a root canal.
Mackenzie Jackson: Yeah. Yeah, for sure. Thanks for bringing up that trauma. I went yesterday and I'm still processing. So you thought you were doing a podcast? For me, this is therapy. I completely understand. I totally agree with you that like the deferment process makes sense. But I also, like, there's so much uncertainty around everything. And you know, it's, would you have the models that are coming out from Claude like Methos? And I mean, I believe that that is going to be a fantastic model. I think it's great. I also believe that the best marketing you could do is to tell people that your product's too good to release.
James Hawkins: Yeah. Yeah.
Mackenzie Jackson: So, so I think, you know, like there's a couple of things that may be true there. But it is kind of the uncertainty of knowing. And at least for right now, you kind of have some certainty in that we know the tools that we can use right now. We know where they're at, but we don't know what's going to come out. Yeah. Methos version 10.
James Hawkins: Well, yeah, I think if, if we ever train like, we won't stop model training. We're just trying to work out how to do that in a way that's acceptable from a user perspective and stuff. So we're not doing it yet, but we want to start. But if we ever do like a coding model, for example, I definitely want to call it like Exterminator, Death Star.
Mackenzie Jackson: Yeah.
James Hawkins: It's going to be a little bit more extreme still.
Mackenzie Jackson: Yeah. Extinct Ocean or something.
James Hawkins: We're probably spending much more on security than we would have been had there not been the explosion of AI. I kind of feel like it's one of the changes. Like, well, AI brings with it the ability to write code now hundreds of times faster than you ever could before, which saves a bunch of money. But you then need to put in things like more spend on security. More spend on like at the moment, reviewing code, but that will probably start to change as there are better and better review tools coming out and so on. But yeah, you just have to, you just have to accept that that is the cost of AI. But the benefit massively outweighs it from our perspective. Like we don't have to have 100 engineers working on security. We have to have a handful very focused on it, plus a good culture of it everywhere else, basically.
Mackenzie Jackson: I'm going to briefly interrupt this episode to thank our sponsor of the podcast, Aikido Security. Aikido Security is your complete code to cloud security solution. It secures everything from the first line of code that you write all the way through your supply chain, your dependencies, and of course, Aikido is also a leader in AI pen testing and AI code auditing. So make sure you check them out today. You can start for free at akido.dev. All right, enough about that. Let's get back to the episode. When it comes to kind of writing the code there, you've kind of touched on it that you guys are getting these massive productivity gains with generated code. How do you approach that style in your company? There was a post from Coinbase's CEO today who basically said that they're releasing a huge amount of people obviously due to the ability set code has. And then everyone took that as like, oh, Coinbase is vibe coding. Which I mean, it's 2026. I don't know if we really need to have that conversation, but you know, how do you approach? How do you approach that? And kind of, was it, is it scary to release those guardrails like of kind of introducing AI and AI coding and then seeing how this is going? And it's become much easier as a developer to cut corners, basically.
James Hawkins: So, which is also partly why it's nice it being open source, so people know. And like we'll just get, we will get immediately dinged if we do something stupid, which I'd argue is kind of the benefit of open source. It's a bit like, I don't know, driving along a road on the edge of a cliff or something. You're really have to pay attention kind of thing. But that's probably safer than driving on a dead straight road where you're going to fall asleep or something in practice, maybe. You have to be able to trust your team more. I think the kind of companies that this would disproportionately affect in a bad way would be, well, I think a lot of it comes down to your attitude around hiring. Our philosophy has historically been we want a smaller team with where we spend more on people. They have more experience and they're stronger engineers. Like, not, again, it's not just experience. It's kind of the quality of workmanship or whatever. But on the whole, the average level of experience is higher because we felt that, hey, this will help us keep initial, when we're younger, when we're less focused on security and more focused on getting off the ground and so on. It would have been like, this means we can continue to move quickly at scale because we won't incur as much technical debt as people are making good design choices. The implication though that's really, that's become more and more relevant with security in an AI age is there we can trust our team to not introduce vulnerabilities as much. Whereas if our model was like, we want to hire a crap ton of people and pay them like kind of badly and the level of the bar is just lower and it's more of a numbers game. I think it's, that's when you would be having major problems if you're especially you're an open source project or something as well. And I think that's a tempting, I think it's tempting for a lot of people because they see that AI generated code can do amazing things and non-technical person can now generate code and push it to production and something works.
Mackenzie Jackson: So, the temptation to hire massive on a lower level, it is there, but I think it takes understanding of kind of knowing what can actually.
James Hawkins: Really not there. Like, no, no, now it's just like, no, you, I just know how that would be a train wreck. Like, I think people are like, oh, well, there'll be non-technical people building big startups and stuff. And my still think it's a bit like running to me, it feels like running a nuclear power plant or something, right? It's like, no, I really want someone who like understands how the engineering in this thing works because, I don't know, like AI is very spiky. It's exceptionally good at some things and exceptionally stupid in lots of other areas. A human's job is basically to be not spiky now where you have to be well-rounded. Overall, does this approach make sense? Is there anything stupid that that is missing? And the answer's going to be yes quite often. So, yeah, it's more and more important that you're able, you have people who are strong enough that you're able to trust and you also give them the, like, I think another failure mode I would imagine is probably happening in companies now is exec realizes you can ship quicker, puts more pressure on shipping, and sets deadlines and stuff. And you don't give the engineers the space to double-check everything, basically. So, just making sure you have like, again, we're really big on engineering autonomy where part of it is letting engineers decide what to build. It's not just features. It's also, hey, I think I need to think about the security of these endpoints harder and so on. So, like, making sure engineers actually have the freedom to get the security right is disproportionately important now compared to what it would have been a couple of years ago. Security's always been important, but it's just got much more important, basically.
Mackenzie Jackson: Yeah. Yeah, definitely. And it is, it is crazy, too. The thing that concerns me most about code, and I know this from my experience, is that when I go deep, five coding mode, at some point I lose track of what's happening behind the things. If something, if we extrapolate this to a production level system that other people are relying on, something goes wrong, like I have no idea what's happening, and all I can do is just prompt, hope prompt, hopefully I write the right prompt that's going to fix it. And I think that is, someone said something interesting that AI compounds confusion in, in companies and code bases. And I was like, I really, I like that, that analogy, is that you still need those key people that understand everything that's actually happening and to go through it, because there's a risk of losing track of actually how your tool works.
James Hawkins: Yeah, and I think that's sort of the, that's why you need technical people still, I think, basically. Like, you have to have someone who's got the system in their head, even if it's not line by line, but like they get the, the architecture's being well thought out and so on. And otherwise, you're just going to prompt like scalability or whatever. This is probably much less relevant at this. Like, if you can try and get something off the ground, but as soon as you've got like real users, production data, blah, blah, blah, that's when I still think you need pretty technical people. Or I feel like they just have a fundamental advantage over non-technical people. And that's sort of what we try and focus on with a lot of our product development is like we're trying to help engineers get better at product. They already can code. That knowledge is just like an advantage. And it does feel wrong that today's state of the art is a bunch of prompts, turn your computer off, wake up, and you're starting over from scratch. The other thing we think about from a code perspective is steering. Like in product development, the bottleneck used to be writing code. Maybe a good engineer would do like one pull request a day, for example. Then it became QA. Like maybe now you can do five pull requests a day or eight or something if you're really going for it and you're spending your time just reviewing what the robot has done for you. I feel like that area is going to get solved, basically. Like I'm seeing interesting techniques coming from our engineers. We're building functionality around like review. And I like that to me, that seems like a solvable problem where that will no longer be the bottleneck either. So then you're like, well, what's the next bottleneck? And I feel like then you're like, well, if you suddenly you're doing 100 pull requests a day per engineer or something like that. I feel like an engineer's job starts becoming more like what my job is at PostHog, where it is sort of context, direction, learning from what we're doing, and just like course correcting. And so it's more about kind of goal setting and stuff. So we're thinking about like long-running agents that have all this company context. And if basically, if you didn't have any kind of long-running overview of what's going on, the product will just spiral and go off the rails in some stupid direction. And so I think, you know, about how you can kind of have a long-term goal and game plan for your product. I think it's something no one has solved yet, but we're starting to think about this a lot more.
Mackenzie Jackson: Yeah, definitely. And you're actually not just thinking about it, you're also building products to help build products, so I guess. Because I wanted to talk about your release of your your kind of your PostHog code that that's come out. What, because I think a lot of what we're saying here around context and that I read in in kind of the vision for this feature that you had. So like, what what was behind that? Why go into this space? Because it, it feels a little adjacent to what you're doing, but I think it makes sense into the long term, term goals.
James Hawkins: Yeah, I think I think we've kind of got, we really had a huge amount of back and forth over whether we should go in this direction or not for an extended period, like, I would say probably more than a year. From first principles, basically, we think it is more valuable for our, from a customer perspective, we think it is more valuable to literally do their job for them than it is to give them a sense of what they should work on. That would be my argument for why like Anthropic is crushing Databricks, even though Databricks historically is a super world-class company. It gives you like a sense of what's important in your org or whatever. Anthropic just means you can click a button and then go drink a coffee and wait for the robots to do your thing. Like, the latter is like, it's part of the human condition, basically, that you don't want to spend much energy. And so, I feel like if we can do people's job for them in certain places, we can automate a bunch of it completely, that is just fundamentally better for our customers. It's really easy I think then to think, well, there's like super competent companies that are shipping amazing models and coding products and stuff. And that's true. But again, one of the other lessons we have had has been, competition actually, it often doesn't matter or can be a positive because it educates the market that this is now possible. We've always been in really busy industries and markets. We've often come in years and years and years after the first people, like sometimes six or seven years later, and we've been able to start winning by doing a better job of kind of trust and brand and distribution or like putting things together, like multiple products together that have not historically been together. We thought this is pretty similar, where it's like, well, if we're helping people build better products, what are the fundamentals of that? It's like, understand how our product is being used, get feedback. And you know, feedback could come in the form of I'm watching session recordings, it's broken, like the UX is confusing people, it could be errors, it could be stuff that's going on in your logs, it could, it could be a survey, whatever it is. And it could be support tickets. There's lots of different forms of this. Then you have to do something with that feedback, build something, give your new version back to your users and just keep going around this loop. And I'm like, well, we're missing, we want to offer like the full thing to our customers for the same reason that like when I buy a car, 0.1% of people want to buy an engine, a steering wheel, and whatever. And then they start driving, they're like, oh, like I forgot the brakes. And that's how I think a lot of that, a stack feels at the moment, where there are really cool things you can like duct tape together with like automations and skills and models and whatever. And like different MCPs and things. And to me that feels like everyone's, everyone's like doing 3D printing or something, which is really cool and really hyper flexible. At the end of the day, I think the bulk of the world just wants to spend like a couple hundred bucks a month and this thing is now just solving bugs for them. They've just had to press go. And then they can focus their energy on stuff that AI is bad at. Like it's pretty poor at being creative because it's trained on what has already happened and can't really reason that well. And that's where we think humans are going to spend more and more of their time, the same way my job is like that today. More so than our, as our engineers are having to deal with like all the bugs and problems and stuff. Whereas I think in the future, like our engineers are going to be able to think more, focus more on this long-term game plan for a product. And we'll just automate away the kind of 80% of the work or whatever, which is like issue, issue, issue, issue, issue, sort of thing. It's kind of how we think it will unfold.
Mackenzie Jackson: It's super interesting what you're saying because it kind of comes back to what we first talked about. You first talked about like why you created PostHog, and it was because hey, you wanted to give engineers data. Like essentially, give them the ability to be able to fix it. Now, this direction actually feels way more organic talking to you because you're giving AI the direct access to the data that it needs to generate code to fix stuff. So, it actually feels like kind of a natural extension from it. Would that be kind of a fear?
James Hawkins: Yeah, I think we kind of did think about it and we're like, well, it just seems odd that these things are, it's understandable these things are separate because no one has got tons of data and then also models in the same house or whatever, but we kind of thought putting this together was means you can end up with a self-driving product. You can try and do it through I've connected a bunch of MCPs together in a clever way, blah, blah, blah. Blah, blah, blah, but then I just know from as a company that has worked on trying to detect issues, find problems, bugs, and all this stuff. There's just, I just know, and even from where we are today, there's going to be so much freaking work to make it work, to do a good job of not creating noise, basically. Like right now we're using like computer vision to watch session recordings for you to detect bugs and blah, blah, blah, blah. But we're like, well, we still think there's a better version of that which is to like train a model that can do this much faster, much higher quality. It'll have more nuance. Like it'll have all of the, it'll have access to things like the logs and stuff in the session as well as like visually or whatever. I don't think you could sort of bootstrap your own sort of system together here, but I just feel like there's going to be so much work to do a good job with the quality of this that it just won't be possible to kind of replicate in the same way that like, you can 3D print a phone and buy the components and stuff and then it looks quite cool, but Apple is going to have something more polished to use that's got fewer problems with it. And so I think it's more the latter where it's like it's cool the former exists though for sure and it gives you lots of ideas and concepts and it's nice that to be able to let users kind of do both where it's like, well, like with the PostHog code, for example, there's, you can, there's a whole MCP store, so you can add like third-party MCPs in, you can add third-party data in to our signal detection. And so we want people to have flexibility, but we do want to put a lot of work into how we handle data to do a better job. But yeah, we hope it works, basically.
Mackenzie Jackson: We've been using it internally an awful lot.
James Hawkins: And we only shipped publicly because we, it's actually very tough to get our engineers to adopt a tool like this internally because everyone gets emotionally invested in particular text editors for some reason.
Mackenzie Jackson: Exactly.
James Hawkins: And so you kind of like, okay, we need to work out once we can see this is taking off internally. And one of the things that really helped us is we shipped a Slack integration internally that's going to come out in the next few weeks or whatever. Because we kind of realized like actually if we really focused on the less creative engineering work, those tasks are easier to automate from a coding perspective. They're easier to one shot because it's not like you're building a massive infrastructure thing. You're fixing like a UX annoyance or something. And that's the kind of thing that because the model's getting stronger, we can see people coding through Slack. So the moment people are PostHog are using PostHog code quite heavily, but they're using Slack like again, I don't have the data off the top of my head, but I think they're like roughly similar, like the number of pull requests through our Slack integration as through the actual desktop app. And again, I'm like, well, why are code editors all desktop apps right now? And I think that's a relic that's the past and forming the present where back in the day, because when writing the code was the bottleneck, you want like a developer wants to have like a big screen with like eight files open at once to see how different functions would interact with each other or something. And I'm like, well, that's sort of gotten as a problem statement. Like I'm like, well, do you even need a screen today at all? Like why can't I just like phone PostHog or something to build something? Because if you're able to trust the model more, like why would you, you just don't need to look at it. And so we're like, well, we actually think the direction of travel for PostHog code is that it should get increasingly headless feeling where like, yeah, sure there's a desktop version, but like you might be coding in Slack, WhatsApp, or literally calling it is what we're thinking. Because I can just see that's the direction of travel for our own engineering team who are increasingly doing things through Slack. I also think it's an interesting way of collaborating. Where like if you're building stuff like the paradigm of kind of GitHub, like get pull, whatever is collaborating involves pulling a bunch of files onto my computer line by line, looking for mistakes or problems or errors and commenting and stuff then pushing everything back. Whereas the nature of the collaboration is changing. Like you're not collaborating around 10 files that have been changed. You're collaborating over like the overall design of something. And so I think again, a lot of, I think the direction of travel for this is that it will start feeling more like working, basically working with code. I think we'll start being like how you would work with a human colleague in Slack where there might be like three human beings and two agents working together in a thread to get a pull request over the line for example where you're all chatting a bit about like, okay, can you just like tell me a bit more about the API design here or what the front end should look like or something like that. So, yeah, there's all this stuff that we're keen to explore and build out into. What we've got out the door so far is the fundamentals, is that we have an agent orchestrator that we have cloud and local based coding. We have it connected to your data, but we're only now at the point, like it's very much like the product is not done. It's a beta for a reason. Like we think there's so much we want to pour more innovation into what we're doing there. But the concept, the underlying thing that's different between what we've built and everyone else is our focus is we want to give you the best place to build a better product. We're not interested in just being the best place to code. Everyone else is unbelievably good at helping you generate code better than ever before. But our, we don't care as much like we're happy for other people to kill each other to be the best coding model. Our point of view is like, well, we want to be the best environment for building a better product, basically.
Mackenzie Jackson: Back to your mode, what you're talking about, the open source and stuff is data and and it's all of that which you have access to. You have the context. The only comment that I'm, I'm, you're freaking me out a little bit, but I do, I love the direction. My only comment is once we've figured out PostHog code, can you build a replacement for Slack? Because I feel, because I hate it. I don't.
James Hawkins: No, I honestly think it could go in that direction. Like where it's like, well, okay, we should start embracing something like Slack. But like I could see the desktop app starting to actually feel a lot like Slack. And then it's like, well, maybe. Because also I think it's kind of like where work happens with Slack, right? And it's like, no, it doesn't. It like freaking happens on like in GitHub at the moment or whatever. And I think it's a bit of a like, yeah, I, I feel like GitHub becomes like the back end. It's almost like S3 or something. Well, like this is just supposed to be store code. And then like, but I do think that could be how it ends up feeling. Where because as AI gets more human, like it has like it has long-running agents that have context, you trust the work of the model. You help make the model a bit less spiky and less stupid, basically. And the model is also getting more intelligent itself, then working with it, I think, will feel more like working with a human. And like Slack is a good UX for working with humans. And that's is probably quite good for working with the really smart agents, too. And humans kind of combined together. So I could see it feeling like Slack at least, even if it's not like directly related or something. These are all the types of things you want to like experiment with. And our point of view was like, well, instead of building this in a bubble for another year or something, we just want to start working with our user base to get more reaction. The thing that's been really interesting is even from early users we've talked to, they've been pushing us to innovate more. Like one guy actually told us, he's like, I wish you guys, this is a couple months ago. He's like, oh, I kind of wanted something more extreme from you guys, kind of thing, still. Which is really encouraging to hear, because I think often it's easy to feel because companies like Anthropic or OpenAI or whatever, it was so outrageously successful, it's very easy to feel like, oh, we don't have the, they're just like dominant. We should just let them dominate everyone. And it's like, well, no, they're also like fallible human beings behind those companies. No one's got AGI yet, kind of thing. And so it's very easy to feel like you're like couple of very fancy companies are like leading the whole world or whatever. And it's like, no, no, no, like we are, we have a bunch of incredibly good engineers who are really quick. They all have good taste in these products. We should trust ourselves to innovate more. Which is one of the challenges we have. Like PostHog has not been particularly innovative historically. We've shipped. We've just gone directly with the market already is, basically, very effectively. And we've realized like, well, the AI stuff we built it relative to, I would say pretty much all our competition, or at least the majority of it, I would say is the strongest. And now we want to press on that a bunch as hard as we can and basically go a bit nuts and see what happens. But if you're innovating, it's scary to do that without bringing users along for the ride. So we want to make sure we're not, we don't get totally like detached from reality, basically.
Mackenzie Jackson: Yeah. It's wild. You've picked a really impressive path to kind of go down there. And I think like it may not be, we'll see. Yeah, yeah, yeah. Well, it's going to be, it's going to be a wild journey, I suppose. I, I want to start wrapping it up because I don't want to take up too much of your time, but it's been really fascinating to go, to go through it. But I'd like to finish with a game that we play called Would You Rather. Right.
James Hawkins: Okay.
Mackenzie Jackson: And the game basically was that I give you two options. Both options are absolutely going to suck. Okay. And you have to pick one.
James Hawkins: Sure.
Mackenzie Jackson: So, would you rather all of the PostHog code base gets destroyed today and all the server, there's no way of getting it back, right? But you can bring it back, but you can only and you can use AI and you have to do that. Or you keep all your existing code bases and you cannot use AI anymore to generate code. Which would you rather? Um, start again with AI, continue with no AI.
James Hawkins: I would start again with AI. I think it's an easy question, to be honest.
Mackenzie Jackson: Oh, really? Okay, well, there you go. There you go. There you go. I need to go, I need to pick a harder one then.
James Hawkins: Yeah, I'm sure like our team is sitting there going, what is wrong with him? It seems easy to me. I just had to boss people around so we built this stuff.
Mackenzie Jackson: Yeah, it would be a bad day though, I'm not sure if you woke up and it was all gone. All right, let's do another one then. Would you rather have all your dependencies for all your your open source dependencies all automatically upgrade to the latest version like, so no pinning versions, so there's risks of malware, there's risks of breakage. Or you pin all your versions currently right now and you cannot upgrade them. No upgrades.
James Hawkins: Yeah, we've been too burned by dependency problems before. Right. Yeah, I think, you know, ideally, well, then nothing would change and no upgrades, I think.
Mackenzie Jackson: I, I think that's a smart question and it's because someone said to me when I asked them this, they were like, well, at least if I don't upgrade them, I can do mitigation. Like if a vulnerability exists, I can work around that and try and build. But if I'm upgrading automatically, there's no mitigation that I can do.
James Hawkins: Yeah, and I also think like, I don't like having, we don't like, I mean, again, we're probably like a bit paranoid as a company in general, but we, I feel like if you've got a dependency where you're desperate for the dependency to introduce new features or something so that hence you want the latest version or whatever, you've kind of got like a supply chain risk problem of like, oh, now we're dependent on some random company. Doesn't feel good. Like perhaps you should have rolled your own in that case. So yeah, stuff not changing too much, I think is a good thing, probably. Like we upgraded Django recently, which was like some ridiculous project, everything would be broken.
Mackenzie Jackson: Especially in today's world right now with supply chain attacks are just always happening. All right, I'll do one more. You've, you've answered pretty quickly, you're pretty confident in your answers. I like them too. But okay, so would you rather have complex different passwords for everything, but stored in notepad in your phone? Right? Or have one complex password that you use for everything?
James Hawkins: Yeah, probably stored in my phone and then, yeah, I would go for the former rather than latter, I think. Well, what's the thing? I guess like if you have one password for everything, you are completely screwed if you lose it if you have it on on phone. Yeah, I think you're less likely to have a physical object cause your downfall than someone gets one of your passwords online somehow through fishing or something. So, that would be my argument. Just don't, wouldn't leave the house. That's the easy way.
Mackenzie Jackson: Well, James, thanks so much for coming on the podcast. I appreciate it. And yeah, all the best with changing everything. I'm really excited to watch what you guys are doing at PostHog with a lot of humor as always. So, don't get too serious.
James Hawkins: That's where it goes wrong if we start getting gray hairs on your face. Austin gets like starts using long words and sounding fancy. Suddenly he's up. But yeah, thanks for having me.
Mackenzie Jackson: Thanks so much, James. Appreciate it.
More memorable quotes:
- "SpaceX, on their website you can literally price how much it costs to deliver a payload into orbit. And yet B2B SaaS companies can't seem to put pricing on their pricing page somehow."
- "If you've got like hideous like slop in your code base or something, everyone can see it. And so it kind of, it means you have to work a little bit harder. It's a bit like having your homework marked by the teacher where you kind of know that like, well, someone's going to look at this thing and judge us on it, which actually forces to about drop the fundamental product in the code base in the first place."
- "It's a bit like driving along a road on the edge of a cliff or something. You're really have to pay attention kind of thing. But that's probably safer than driving on a dead straight road where you're going to fall asleep or something in practice maybe."
- "AI is very spiky. It's exceptionally good at some things and exceptionally stupid in lots of other areas. A human's job is basically to be not spiky now where you have to be well-rounded."
- "It does feel wrong that today's state of the art is a bunch of prompts, turn your computer off, wake up, and you're starting over from scratch."
- "It's part of the human condition, basically, that you don't want to spend much energy. And so, I feel like if we can do people's job for them in certain places, we can automate a bunch of it completely, that is just fundamentally better for our customers."
- "I think the bulk of the world just wants to spend like a couple hundred bucks a month and this thing is now just solving bugs for them. They've just had to press go. And then they can focus their energy on stuff that AI is bad at."
- "You're fixing like a UX annoyance or something. And that's the kind of thing that because the model's getting stronger, we can see people coding through Slack."
- "Why are code editors all desktop apps right now? And I think that's a relic that's the past and forming the present where back in the day because when writing the code was the bottleneck, you want like a developer wants to have like a big screen with like eight files open at once to see how different functions would interact with each other or something. And I'm like well that's sort of gotten as a problem statement. Like I'm like well do you even need a screen today at all? Like why can't I just like phone PostHog or something to build something."
- "Working with it, I think, will feel more like working with a human. And like Slack is a good UX for working with humans. And that's is probably quite good for working with the really smart agents, too. And humans kind of combined together."
