What is Vibe Coding? The New Way Developers Build Software with Zowie Langdon

Hi everyone, my name is Patrick OQ and I'm very happy today because with this episode we're going to have hit 200 Beyond Coding podcast episodes. Thank you so much for listening. Normally say that at the end, but thank you so much for listening and being here in the 1st place. Today's episode is a very special one. It's a with a dear friend of mine, Zoe Langdon, and we start off talking about vibe coding. If you're interested, check it out. Today's episode is a great one.

Enjoy. You mentioned vibe goading specifically and I've talked to you about it also off the show.

And I've talked to other people and their their view and maybe it's because of the environment they work in, but their view is that it's not as great and they don't use it yet or they're surprised by what it can do now because they haven't been using it. And I'm like, man, I am missing out because I think it can be actually quite great when it comes to early stage product development and continues delivery on a more smaller scale rather than potentially for

large scale. But then there's still benefits to be had there. Yeah. Whereas like the the the aggregate leaning is it is it? It's not as good as I thought it would be. Yeah, that's the that's the thing. Or it just doesn't do what I want it to do. And I'm like, OK, but have you actually tried or did you try once and then that's it, the outcome is not there and

therefore you'd leave it? Because for me, I continuously go and there's a whole dialogue that goes there and eventually I get there or I get 95% of the way there and it's damn good. Yeah, yeah. No, absolutely. I think I very much relate to this. I remember I was working with like a very visionary person and, and he, he got extremely excited about GPT 3.5. He was not a coder himself. He primarily used it to produce content or like, you know, review things, etcetera.

And he was so excited that he kind of, he nudged me to start trying it out and I tried it out for coding and he thought he was already sending me messages like this is going to change everything. I think, you know, we can build anything and like 10 times faster. And I was like, I was quite skeptical. So I tried it out. There's a GPT 3.5 and I thought it was absolute garbage, like unusable. It made-up a lot of like functions and libraries, stuff that I, yeah, like, really unrealistic.

And I, and I noticed that it took me kind of like three to four months before the FOMO kicked in again. I was like, oh, I have to try this thing again. Still pretty bad, but I do think when I speak to a lot of lot of developers for some reason, maybe more so the seniors that obviously over time you develop taste, I think taste in code and also certain pride in like how you like to approach things and and I I, I mean, I relate to this.

I have this to some extent. So you know the first time you see a bad code, you're you kind of you usually write off the whole thing like, OK, this is this bad. But I have to say that I think, I mean, let's say three to six months ago, I think we've kind of hit a tipping point where now and I'm, I, I, I do identify as a vibe coder. Nowadays, like yeah. Yeah, it was quite confronting like a month ago. I think I realized like, yes, I think this, I think there's no way back.

We can go into that later. I think the the subjective experience of like coding has completely changed for me. And I personally, I would say it's a little bit less enjoyable. There's different things that you get from it. But yeah, I, I have to say that I think unless you work in a very niche domain, imagine smart contract development where like the risk are very, very high and you need to, you need to probably understand and evaluate and review every line of code quite thoroughly.

I, I, I can imagine, you know, and that's also not a huge amount of code that you produce on average. So high stakes and low, low amount of lines of code. It makes sense to not use vibe coded stuff or maybe you can use it to review things. But other than that, I would say that the quality of the code that I produce is similar in in what I with vibe coding is similar to what I would produce myself. It's it's a lot faster.

But I have to say, you have to work through like a good week or two of pretty bad stuff sometimes. Like it really, it reminds me of just learning a whole new ecosystem where you initially start out, I don't know, imagine you go into the Python And data analysis ecosystem, right? You don't know anything. You don't know Python, you don't know Pandas, right? You write your first lines of code and you think, oh, this is awesome.

And then you, you know, Fast forward one week, you realize that the stuff you wrote a week ago is pretty bad and you, and that that process of learning, you need to give it time. You can expect yourself to be a good developer in that area within like a month or weeks. I think it's kind of the same like I've, I've, I've become a lot better at knowing how not to use and how to use these kind of kind of tools.

So yeah, I think yeah. I wonder what your perspective is on that as a as a not so vibe coder just yet, but. You and I spoke I think a couple of weeks ago and then coincidentally last week I had innovation Day where we get one day, no client work, you just do whatever you want. Cool. And I had just we had a hackathon with ING prior and I won VR goggles.

So this is pretty cool. I can combine something and I can build something and I've never done it and I will vibe got the shit out of it this space. So I brought the VR goggles. I, I pitched my ID. I'm going to do a Rubik's Cube in VR.

I'm going to make a game. I'm going to see how this goes because I did some research and also a colleague of mine jumped on. He didn't jump on, but he gave me some, some info to look at. I was like, OK, so I started, I downloaded the cursor because I didn't even have it. I was like, what is this development workflow going to be? Because also it was a bit

confronting, right? I give a lot of advice as in know your tool set, know your IDE, know your hotkeys be as effective as you can be, because those are all things you can learn basically, and those are going to make you comfortable roducing. I was not comfortable with cursor yet I was like, OK, let's figure this thing out and then I I even started with V0 because I saw that online.

Let me start with V0. I want to make a game blah blah blah, and it could not display what it was trying to do because those packages don't really align that well. So I was like, OK, I, I generated a cube and then I went to cursor. I was like, OK, this is the cube I need to do it in VR and some of the packages that V 0 gave me weren't really VR related. It was like a button enter VR and then it didn't really do that. So then cursor fixed that immediately.

I opened it on the browser on my VR goggles and I had AVR Rubik's Cube. I was like this pretty damn good like this is what I was going for. Then I was going back and forth with regards to the interaction and I, I have, I still have it within one day. I couldn't get the interaction right because I was like trying to explain how a Rubik's Cube works, right? I have 9 cubes. The plane needs to move and I'm like, how am I going to kind of convey this information on how I

want the interaction to be? The closest I got was, I have a cube, I have my controllers, I got the button stuff, right? Like if I click this, if I point to this, it's going to move. But then it would move one of the cubes instead of a whole play and that's it. I got the whole cube, I got the colours, just the interaction within a day. I didn't get to, yeah, but I got damn close and I was using a lot of stuff which I haven't used before, which was pretty cool.

I could easily, I could even go through the code and see like OK, I can, I can see the patterns, I can see where it does what. And the interaction was also kind of the grey area with it when it comes to my own knowledge, where if I were to fix that, I would either have to get into that or do a little bit more back and forth.

Yeah, super interesting. It's funny because that you use the example for a Rubik's Cube. I remember seeing a video where someone and they they probably wear some kind of prompt master, but they were able to one shot. So like one prompt get a functional Rubik's Cube working, albeit not in AVR setting.

So just in the browser. I don't think I'm, I'm that level yet, but it's what you just described is I would say I'm still figuring this out as I go because obviously the like the really good vibe coder cursor stuff. And then the models especially that are now available in their Gemini 2.5, I think is the one that I use most now. The experience of giving it one or two prompts and then getting close enough, like, I don't know, I'm 40% there kind of

result. And then just I, I always, I describe it as like walking on an asymptote. It's like you try to get it there, but, and you're constantly very close to get, but it just doesn't, it doesn't work. And then, and then it applies to fakes. And you know, the model replies like, Oh yeah, you're right. This is indeed a problem. Here's the solution. And the solution is, is truly not so confident. And I feel like this I, yeah, I don't know, I had a hard time accepting that process, right?

Because, but I do think that I, I remember wasting truly, I remember wasting like a day on solving this problem. Like I was trying to build this whole feature into, into my into my app. And I gave up after day because I was, I was so close to getting it there, but it just kept breaking. And the problem is that, of course, you know, the the more it code it rights, the, the more time it will take you to, to review whatever it's done. So I was putting off that work, obviously.

So you're trying to fix it just by prompting more. And, and that, that cycle, I think is really unproductive and kind of disappointing. But then I decided just to throw away everything and use the learnings from what it had done wrong to write a much better prompt. And I got the result like I wanted in like 15 minutes. And, and that was a really, that was an important insight. Like I oftentimes when you code yourself personally, right?

And you, I don't know you, I remember this, this, this really exciting feeling of just coding, coding and not testing it. And then it's actually working like, holy wow. Holy cow. I, I, I wrote like code for an hour and everything works. If, if your code is like almost functional, then obviously the tendency is just like dive into the code and fix it incrementally. And then you're, you're there. And then I don't know, maybe you'll fix some tests or you clean it up a little bit.

I think that mental model just doesn't work for vibe coding. Like if I noticed that if, if, if you're not already 80% there after one shot or two shots, maybe it so far in my experience, it's unlikely that you'll get to the 100%. Probably just have to reset and like start over because it will somehow like it will just deepen some of the problems there in

the in the base code, yeah. So, but so if I take this and I would use this in production, let's say I already have an existing app, would I then try and create because I have a commit with that standpoint, right? Then you do one or two prompts and then you're trying to achieve a certain outcome. Is that the reverting point you're you're talking about? Would you revert to that previous commit? Or are you talking about like

starting something from zero? No, yeah, for imagine I have an existing project and I don't know, I'm trying to build a new feature and it's like 60% there and I, I don't know, try two or three, four more prompts to see if I can get it better. And if it's not there, then I will just check out the whole or I don't revert because nothing is actually in a in a comment yet. So I can just like check out yeah, previous comment and that's it. And let's go back. Or you could consider stashing

and then. And if, if you're like maybe stashes of versions, yeah, yeah, that's gonna be messy. Yeah, yeah, that gets messy really quick. But sometimes you feel like, oh, maybe there's some real value in what I have, you know? You know the feeling. Yeah, what's in your tool belt nowadays? Is it cursor? And you already mentioned Gemini 2.5. Yeah, I was really late with adopting cursor myself. Yeah, actually compared to I'm. Later, don't worry. I guess I'm in good company.

No, I used, I used Claude. So I was for a while, for like a good three months. I, I was switching back and forth between models. So I I used TPTA whole bunch, specifically O3 mini high and O1 before that. So quite slow, but high contexts or a big context size and also just like actual chain of thoughts of reasoning much better results slow. That's kind of kind of lame. I ended up playing brilliant or like kind of games to keep myself busy and solving actual. Problems in between, yeah.

Because I was just waiting and then I switched to Claude and after that because, and the reason I did that and not use cursor is because I was able to, I knew my whole code base, right? So I was able to be very specific and intentional with what context I provided to lay out the whole problem. So, you know, I would start with like, this is what we're going to be doing.

This is all the related code. I want you to look at these bits of this code and maybe I would paste in some documentation. So I would really stage everything really well for it to do its thing. And then I would ask it to write the code that I needed. And then I would like, I don't know, maybe make some suggestions to update it. And then I would just copy the code into my, into my code base.

And that worked really well because I was able to, yeah, I was able to carve out like a very specific context and domain for it to kind of like NAV to allow it to navigate to it's problem, but through my, my constraints. Whereas with what I noticed with cursor, at least in the beginning, you can specify files as context, but I was not always able to get it to focus on the things that matter to me most. Sometimes it would also search in, in other files.

So, and one thing that still sometimes bugs me is, is if you like nowadays, you have this agent mode where we'll just start writing code. I, I, I, I realized that it's, it's usually just not ready yet. Like I need to really prompt a couple of more iterations to really get it to reason through. So once that was better in in cursor, like more or less a month or two ago, especially with these with Gemini 2.5 and claw 3.7, I switched the cursor and that works really well.

But I do still like I prompt what I wanted to do, you know, taggling all the files, potentially give it some documentation. If I know that there's like a library involved that is not that popular. So then I probably need to provide some extra docs. And then I, and then I just don't allow it to write code for like a couple of prompts and write me a development plan. I review what it needs to do, maybe give some feedback and then it comes out with the actual stuff.

And then I say you can apply it and then usually it's pretty good. Interesting. But I just hold off applying any code and it works really well. And now also I've been using Junie from Jetbrains. Very slow, but overall better. Has potential. Yeah, really, it does have potential, but it's it's even slower. So more brilliant games in the meantime. I mean for me I was just, I was like, OK, how can we get this done the fastest? And I was trying to kind of boot force it.

So whatever it would suggest, it was going way too fast with the rest of cursor. I would just be like apply and then kind of the, I was the monkey testing kind of the feedback. I was like, Nah, Nah, the colours are all of a sudden gone. I'm like, where did the colours go? Basically with my Rubik's Cube? I, I didn't think of kind of, yeah, the seniority aspect of it.

Like let's talk through this. What is your plan and what is the outcome we're trying to achieve and repeat it with me and we're going to go through this like as I'm mentoring maybe someone else. When you were going through that, I was thinking like, how did I learn? And I was very much, I learned on the job and it was very much focused on trying to solve something. And it was huge fulfilment when I did that.

And I felt like I, I lacked to a certain point fundamental knowledge because my colleagues were going faster than me. And when I would pair a program, I would be like, OK, I can see they have like better fundamentals. They would just maybe not Google as much or maybe they would reason out their thoughts 1st and explore multiple options before doing any hands on. And I feel like I should do that with vibe coding then as well. Now explore the options.

Actually zooming out before doing any hands on stuff. And that's what it sounded sounded like when you described it to me. That's a really good way of looking at it. I hadn't actually considered it from that perspective. When I think back to also my early days, I, I remember I needed to, I think I did the best work away from my computer and just thinking about, I don't know, a problem and like, I don't know, writing it out, sketching it out, thinking through whiteboard, whatever,

talk to someone. And then once you like abstractly solve the problem, then actually go write the code much better. And I also obviously had times where I was trying to brute force it myself and I just didn't break, break stuff exactly like an LLM does. So that's a really good way of looking at it. Like it does actually exhibit some kind of human ish traits in that sense. Yeah, interesting. Yeah, I, I mean, I'm a fan, right?

But I'm also not a scientist. Like I see developers as they fall into kind of. Yeah. How do you say that? Archetypes. Some people, I call them the scientists, developer scientists, they love languages and they would just pick up another language or they would do the most elegant solution for them specifically. Very subjective.

You can already see by the way, I'm talking about this like that's not me. I'm trying to get something done and achieve a certain outcome and to a certain degree is whatever it takes, right? If I have to duplicate code instead of kind of refactoring and having one solution that fits 2 cases, I would, I'm in the mindset of you can duplicate, it doesn't matter unless you have 3 cases.

Then we can talk about kind of generalizing, but I'm the person that is more practical with regards to getting things done. I feel like the people that are more on the kind of scientist aspect, they're also more careful with regards to adopting AI because they can probably achieve outcomes, but it's not going to be kind of what they have in mind with regards to quality and how they want things to look like. Yeah, I think that's a really good point.

When I speak to the I like the archetype, the the scientist archetype. When I speak to developers that are more leaning towards that, I notice something similar. However, I think if you're, if you give it, I, I would argue that for it to become a tool in your tool chain that you're satisfied with, if you're like on that side of being an engineer, you'll probably need to give it more time in terms of

instruction. So one thing that works really well and I've over time developed, it's, it's, it's like a kind of like a personal notebook in terms of guidelines that I now pace in every project. And then so when I prompt over time, I learned what kind of mistakes it make, but also, I don't know design principles that I've embedded into the code based on a domain driven design, commenting style, all these kind of things.

And then I just tag that into every prompt and I just tell it like, you have to follow these guidelines. And then I think you can, yeah, you can. There's always boilerplate code that you write, no matter if what kind of developer you are that you kind of like want to avoid. And the same thing with the three, three strikes and re factor. I'd like I, I'm also someone that prefers is if there's some

duplication. This is also my personal perspective on like seniority is that you're like, it's a trade off. You have to like really assess the trade-offs. Well in terms of what's the business priority, what's the value to the user? What's the risk of this code? You know, like technical depth wise and then just make a make a judgement call effectively. And that's kind of that's the taste. You're you're that's why you're good. You're good at those judgement calls.

And so I think you could yeah, it's really a tool. It's just a tool and it's really up to you to how to use it.

So yeah, someone like us probably uses these tools very differently than a scientist because I identify much more like you do as well, much more A scientist kind of developer would likely have a very different approach to it, but could still get value from it. Maybe just also vibe coding some potential implementation structures, you know, getting some feedback on it as I think a lot of engineers that work on like, I don't know really mission critical core

components, they tend to stay, stay in the design phase slightly longer. And you can do that with an LLM too instead of implementation phase, which maybe is what we are leaning towards most of the time. I do feel like so. I don't know necessarily if if vibe coding is going to be a tool set that I would advise for every certain scenario, but for me, AI is definitely something that needs to be in a tool. Well, somewhere I was talking to

a person. He now recently starting his own start up. He's with two Co founders and they're really working on speech to speech specifically. So not going back to text, but actually I don't even know how it works, but just keeping the speech as it is and then putting that into a model and then having speeches output. He's trying to solve a lot of customer conversations in businesses and that's kind of he's all in on that. He used to be head of AI with regards to AB and Amaro.

And there he said, I did a lot of metrics with regards to code maturity, right? There's a lot of methodologies where you can scan things. And he said it's not an exact science. But overall, when you look at size of code, quality of code, you can guesstimate kind of how long and how much effort went into that. And he would say, we had code bases where indeed we were working on on it with 10 people for two years and the numbers were kind of the same. And he said, we're now working

with three people. And I did the same kind of from a curiosity perspective on the current code base that we have. And he says we're hitting like the, the team of 12 people and we've already spanned a year and we've only been coding for like 4 months, which for me speaks volumes, right? Because this person has perspectives in a larger organization, metrics kind of makes sense. And you sure, I think when you're early, you generate more.

You can, you can I think go faster to a certain degree. But the number is actually, yeah, I thought that was fascinating, to be honest. He also said that so vibe coding they do, but he also talked about kind of a practice where they're using part of a library, open source, which is not necessarily like they're kind of also trailblazing. So when something is lacking, they have to fix it, but not necessarily within their own code base.

So then they would check out, they would have two code bases side by side, feed that into one model where they're saying, OK, this is how we're trying to use this, this is the use case and this is the open source part that we're using and this part is lacking and I want to add it. Can you help me with regards to that? And he said it's actually pretty good with regards to that. So for me, that was really cool.

Wow, I love the because that's something I haven't seen a lot of. I mean, next to these benchmarks, right. And like how good LLMS are at coding to actually have some kind of quantitative representation of LLMS in the wild used by teams. And like, how do they compare it to, to previous setups? That's a really interesting step from just subjective experience. I, I, I, I think I can second that.

On the other hand, I mean it sounds like he and likely his team, they have significant amounts of experience so they can evaluate this metrics, but they probably also have some intuition about what the quality of the code, like they can identify code smells and all this kind of stuff.

I feel like there's also this really interesting group of huge group of people now standing up start up people often times or people that are like in a job and wanted to build their own thing and are vibe coding the hell out of whatever they want to build. And I really do wonder like what the average code base quality is. I get a lot of these messages from people like, hey, vibe coded this thing, but now I can't get further and I'm stuck.

I think that's a huge, huge thing Also where I don't know, products can be built for that. People can be used for that to like help these people get over the that that small barrier. So I think if I'm not, I mean, yeah, it's not an exact sign. So I'm not entirely sure about this statement, but I do think the quality of the code, it's likely that the quality of the code that you'll produce on average in your code base will still be severely constrained by the seniority of the people that

are managing. So to say the, the LLMS or whatever the, the, the tool changes that they have. So, yeah, you and that's also an interesting like in terms of the job market, it's an interesting development, right? Like the, the, the more senior people are have a lot of leverage because they can with a three men team can code for 12. I think if you have, if you're really inexperienced, then you start using this kind of stuff. It's more of a more thing of luck. I don't know how you look at

that. And, and, and if there's like, have you seen situations in which teams or developers actually provide like guidelines on how to use these tools? Right? Because you I currently, I don't work in big teams, but if if I were in a CTO position again and I would have several teams, I would be very mindful of the fact that there are certain people even even like just their, their mindset might have, are they the the scientists kind

of developers or not? And just try to talk with them about how they would use these kind of tools, but also provide guidelines for how not to use them if you're a junior instead of like outright saying we're not using these tools, which I think you just mentioned some bigger companies don't. Yeah, yeah. I think that there there's, there's, there's something to do there. I haven't quite spoken to people that do or do not like. I don't know if you see this in big companies.

I haven't seen it yet, no. But when you were discussing kind of your way of working, I was thinking and I was wondering it'd be really fun to kind of pair program and if I were to distill kind of what works for you and what works for different environments and kind of get best practices with regards to vibe coding also for different situations. Maybe your early stage, maybe you already have an existing

project. I think that'd be very valuable because I don't think there's something like that out there now, which also makes sense, right? This is very new. The fact that you're saying, OK, if I don't like to shot it at Max, I kind of revert and I, I start with a fresh baseline and I kind of adjust the prompt rather than trying to brute forces brute force it, which is

kind of what I did intuitively. And I, I like it inspired me to go back to my Rubik's Cube problem and try that to actually see, OK, is that going to work? Is that a better approach than being like, OK, we go from here and I would do like commits as in I feel like I'm in a video game and this is like a safe point. This is a good state to save on. And then we just go again, basically, that's the feeling. Wow, that's so, yeah, that's so true.

I remember I think it was the other day where I needed to do a big refactoring and I did exactly this. Like I tried to get myself to a checkpoint then commit and then the same feeling of like who made it? Yeah, exactly. We're good. We're good on this. Check. Let's go again. Yeah, that's it. Like that's the feeling. Like from my perspective, I've done product management now I'm very, I'm, I'm very grateful for the experience, but things are moving so fast.

Like I think I've talked to you about this before. I feel like I'm missing out if I'm not hands on right now. Trying to figure out what good guidelines are going to be, what works for me, what works for others. Trying to figure out where to use AI and where it can be used effectively and where I need to step in with expertise or where I need to bring in community with regards to things I don't know. That's where I think a lot of difference making is going to be happening soon.

Yeah, probably. I mean for sure right now the big amount of the leverage is in in the in the coding bit. I do feel recently I was talking to a designer, a very, I would say like you as experience product manager designer and hadn't caught up in a while. And he ended ended up building I think in like the last three months an app and it works with cursor. And so I was really impressed because first of all, he's not a coder. I mean, he had worked with developers and pretty closely.

He knew some things, but and he also he spoke about this new role that is coming up both in the design and the product area, like a product engineer and a design engineer. And I was thinking about it. I think that's where for people that are now in products and depending on the company you're at, I'd like, I can imagine that if you're writing AI, don't know like a back end team and you are kind of in a product management role, but it's not really a user facing thing.

It might be more challenging because it's harder to prototype stuff. But if you're in any role, like as a designer, as a product person, and you can prototype things, I think there's a lot of cool stuff that you can do, especially if you have technical experience like you do. I would feel like a like a superhero. I, I'm going to play around with that.

I feel like, like that's the, I've heard a lot with regards and I've talked to a lot of product managers also in the past and they, for example, talked about the challenge of not having a person that can do visual design for me. That's an interesting problem at the time, but now it can be a soft problem, right? Because you as a product person can just generate some visuals and that can be a conversation

with your developers. Like is this something or can we move towards something like this? And sure, it's not going to be perfect, but yeah, like 85% of the way there and you're very close. Rather than you doing everything manually, teaching yourself visual design skills, going to Figma and trying to figure things out. Right now you have a lot of tools to do a lot of things on a more generic level. I'm just wondering where you want to go deep and where you kind of stay surface level. Yeah.

No, that's a really good point. I think so as a product, as a product person, I would also be mindful of if, if, if you're managing A-Team to, to try and understand what's happening there. Like you, it's hard. You can speak to a developer and be like, I don't know, this particular ticket, how did it go? What's the, is it finished? What's the quality of the code, etcetera. You can try to infer those things from just talking to people.

And I imagine if you're technically minded and a product person, you'll have some intuition about how things are going. It's easier to to get that perspective because you can technically there's these tools that like review PRS and then I give you an overview. Some of them even draw diagrams of like what's changed in the code is pretty cool. So that that I feel makes you a lot more productive isn't even as a product person because you

don't need to read all the code. So you can go pretty deep with these kind of because the translation can be done by these tools. On the other hand, I spoke to again, designers that they, I guess it doesn't count for all of them, but some of them I, I noticed are actually quite frustrated with the whole Figma flow. It's like I'm just moving pixels around. And they always felt quite constrained.

Like the, I mean, I think most of the designers that you speak to will have the desire to be able to write code. They're like, I wish because then I can. It's the frustrating pattern where you're trying to tell a developer to do this and they just constantly don't. It's not really the thing that you had in mind. And now they, they just pick up lovable or V0 or something like this and they actually prototype these things and they love it.

And sometimes they even go into the, the actual code base and implement stuff. And obviously it needs to be reviewed. So you need to have your work flows for this. I think as a, if you're, if you're in a position where you can orchestrate these kind of work flows, it'd be really interesting to see an experiment really like maybe week by week, like, OK, this week we're going to try this workflow. How did everyone feel? Next week we're going to try that.

How did everyone feel and like try to see and share our knowledge with other people in the company or something like what's the best way to do this together? Because I feel like as a designer, yeah, you just want to write code right now. And we also in my case, we, I'm building a native app right then. So Lovable, which is primarily web-based, does not work in those scenarios. But I can actually import Figma designs into Lovable and then just adjust.

Even though it's all web code that it spits out, I can still make modifications and I just like prototype things myself. And I don't need to be a designer because I imported the Figma file. So it kind of understands the, the structure of, of our design and it does pretty well. So I can say like, I don't know, layout change a margin changes and stuff like this. And then once I validated this actually looks better, then I can start implementing it.

So in a sense I'm I've like it doesn't work for like the broad strokes stuff like when it comes, it comes to translating like a vision or an idea you have with a designer. Like that process is is quite human to human, I feel. But even developers there could be more productive, like if you have a product minded front end engineer that I would love to see them do this, you know, lovable workflow.

So I wonder from the Rubik's Cube experiment, do you think there's stuff that you would want to try out with developers on your team? I would love to like the FOMO is also where I want to be in an environment that has that experimentation mindset, right? Where and I feel like kind of early stage companies more so start-ups have that by nature because they will use whatever means, right? Give me a cheat code and I'll happily use a cheat code to achieve whatever I'm trying to do.

And bigger companies like insurance companies or banks will be like, well, this cheat code comes with a risk and risk is not something we can afford. And we don't have to necessarily. We don't have to innovate. We can see what start-ups do. And then when there's something established, that's what we do. I feel like I want to be closer also because of the kind of Phase I am in my life.

Maybe again, my mid midlife crisis now where I can afford to experiment more, where I can afford that risk more, and also be in an environment where that is happening more. Yeah. Feel like I'm missing out. Yeah. Basically that's it. Yeah, I know. And I think, I think I know the feeling. It's funny because the, the kind of risk taking stuff that you and I I think are attracted to and to especially if you're like an implementation focus person like this is the time to like try that stuff.

It really is like the, the, the general, like the broader industry, I feel is like in a build or buy kind of crossroads in many cases. And I think the bigger like really risk minded organizations will likely end up buying other whatever companies and start-ups that have taken the risk. And then some are able to prove by virtue of their model and I'm assuming like reviews of everything and like due diligence that they solve this problem.

So I guess the real decision is like, if you're working somewhere like, do I want to be on the on the build side or on the buy side? And it's, it's an interesting phase to make. I guess it's, it's a lucky phase to be in a mid midlife crisis. You can be radical, and there's opportunities to be radical. Yeah, yeah, for sure.

You mentioned kind of using lovable and then also leveraging whatever you have in Figma. Now, what with the promise of MCP and even agent to agent, that's where things kind of cross interfaces, right? I was talking to a person previously on the show and he says AI for me is interesting, but it's more interesting if we kind of cross the boundaries of interfaces. If you think of a Figma, everything is there in isolation.

And I, as a user, I have to drag it out and put it somewhere else and then I have to drag that output and put it in my code and then that runs to production somewhere else. So I kind of have 4 interfaces. If I have, I'm in the middle and I basically have one tool that crosses those interfaces for me. And that's when we're talking with regards to productivity and

speed. And I feel like MCP having one protocol where I could just hook in a bunch of applications and I have a model reason on what tools are available to me and then figure things out with regards to, OK, I'm going to grab this and then we're going to go to this. And then this is going to be the outcome. Or even agent to agent. Have you seen Google's latest Like Agent Space as they call it? I haven't actually caught up on that, but I did read that

there's like a kind of MCP. Alternatives being developed there. Yeah, they have from what I've seen in a demo is you can go to Google Cloud, they have you can set up Google agent space and basically you can connect to a few out-of-the-box applications that they've partnered with.

I can give you the example of combining Slack, Confluence and SharePoint in the organization of, for example, Cibia where I only have one interface and I'm searching for something about Beyond Coding podcast and it's going to give me results of SharePoint, Confluence or Slack depending on whatever is out there basically. So I'm crossing boundaries of applications with one interface from an information looking

standpoint. If I'm looking for specific information on budget, we can have that kind of anywhere being discussed at any time if we're not thorough and application landscapes just are growing continuously and sometimes you just have a confluence, a slack and a sharp point then when where what is even Google Drive is sometimes there can be challenging. And this is kind of the solution to solving those boundaries when it comes to getting information.

It's really interesting you mentioned that because have you heard of what do we call it again Glean? So they, they do effectively this. So it's AB2B SAS company and they hook into I think it was Confluence, JIRA, these kind of tools like in Slack and SharePoint, whatnot. And it allows you to search through all of that. And that is, yeah, it's a huge, it's a huge issue, right? Like on the non develop

developer tooling side. And it's funny because my my girlfriend she onboarded into a new position recently and is very much struggling with a typical like onboarding stuff. Right where is what? Where is what? Who do I go to? Right? Like, oh, you, they I don't know. A company does a migration from one service to another. Things are not documented properly. You know that that lengthens your or like maybe triples your onboarding time sometimes, which is, is this also psychologically

is a bad experience for people. And this is like these kind of tools really help there. I wonder though, like because Glean obviously did not use or maybe they knew now, but they did not use MCP. So it's, it's fascinating to see that. And I, I love, I love how open source protocols do this, right? Like, Oh yeah, it's an open source protocol. Everyone can develop a server. Yeah, companies like Glean will have problems with that. Absolutely, But it's great because that's we, we need more

of that. Like I think these kind of picks and shovels like these, these base protocols are so obviously coming from crypto. That's a typical thing to say, but we need base protocols like as the base layer for all these other products to build on top of. So I would hope, I don't know how how the the Google, like I'm assuming Google Cloud obviously is proprietary stuff, vendor lock in that would personally keep me away from that.

If you're a bigger organization, it makes sense because you need guarantees and it's risk, right? But I love the fact that theoretically I can spin up a few MCP servers and create an interface on top of that and hook it up to GBT model and get things to work for my mini organization. Yeah, yeah, absolutely. So that yeah, there's huge value there. Yeah, I feel like we now have the ability to cross kind of interfaces and sure, it might not be perfect. This is very rough.

Like early stage people were talking about, well, am I really comfortable like having a model give a few available tool sets and then just go buck wild with the rest of what's available with one prompt. I think those are the same people that are maybe not potentially vibe coding yet because on the surface level, yes, potential is high and you can see a lot of problems with it.

But I feel like as we optimize, it can be a very cool and very effective tool in crossing interfaces and trying to do whatever it needs to do right. If you can get your design tokens in Figma or from Figma and for whatever reason you don't use lovable but you use cursor, then maybe those boundaries are already crossed with regards to MCP and then you can work that out through there. Yeah, yeah.

Those kind of things will be quite big and it's going to be interesting to see how certain companies, I imagine that Figma will either already have, they've already made this decision or they're about to. Are we going to build our own LLM thing inside of Figma or are we going to expose everything with MCP? And I personally, I feel that the exposing things to other tools like the kind of the marketplace mentality works better or people, people can

build apps on top of things. I would love to see stuff like that. I was speaking to a friend recently, very much the visionary type, and had this wild idea like what if we agents are going to be able to use MCP and imagine that they're going to be able to. I don't know who can see your banking app, Google Maps, WhatsApp, e-mail, you name it. Like everything that you do use on a daily basis embedded on your phone and then in your, I don't know, your meta glasses, for example.

Then you get to the point where we were imagining this, this situation where you're like on in a ski elevator and you're like, Hey, can you build this lightning page for me? And then I know you go down the piece and then you're ping, yeah, build a lightning page and you visualize it in your glasses. And like, it's, it's really wild. But it's it's funny because that

is not super crazy anymore. Like to to think about that, OK, it's obviously impossible now, but to think about if if you think about MCP and what might be possible with that, if Apple would choose to allow, you know, this to run openly on your phone, which given their history, unlikely to happen. But then maybe there's going to be a competitor. Maybe Google will decide to do it. Yeah, it's going to be really fun to to.

I can. It's hard to imagine what building anything will look like a year from now and there. And that's why I got the FOMO, because if you're in. Yeah. That's purely it Honestly. I, I was thinking though, like there are, as we were talking, there are solutions that kind of cross interface boundaries because Siri is one of them. Yet I don't use it very often because it's, it's not that great. I can say, can you reply to this text message or can you call,

can you text X? And it's going to say calling a person that I haven't spoken to in two years? And then it immediately rings and I'm like, whoa, whoa, whoa, whoa, whoa. Like if that's the risk, then I don't do that. Basically, I, it's coming close to because I have Apple earbuds, I'm fully within the Apple ecosystem. And when some when a text arrives, I also use Messenger, not necessarily WhatsApp that

much anymore. It reads out the text out loud and that's it. And I, I can actually just say, I tried this. It, it read out the text and I went reply and it went, what do? What do you want me to reply with? I was like, oh, that's cool. And then I said what I wanted to reply with and it read it out loud and it said, do you want me to send it? I was like, yeah. And I was like. Friendly things are already moving along quite well. Like maybe things are moving along and I'm not necessarily

aware of that. Whereas a year ago or two years ago I would say text this person, I would it would call a random person and maybe those bugs are already out there now. Perhaps, Yeah, it's funny. Do you do you use Apple intelligence? Is that like the latest? It should be in there, but I haven't used it yet.

OK, because I haven't tried it myself either, but I've been kind of like trying to follow what's happening and Apple seems to be in quite a lot of in, in trouble basically because they haven't been able to release this properly. I think they estimated it to to like an actual update with the features that everyone expects to be there in 2026. And and I still today actually while driving, I had Google Maps on and I had an earbud in and I said, Siri, what, what are my

directions? And I go, you have to unlock your iPhone for that. So it wasn't actually able to interact with Google Maps yet. So I I'm still very much on the Siri's skeptical like about here. But I do think you know, once if if there is the option to to run agents or communicate with agents that are running in the cloud and somehow can get access to this user interface.

Like I would personally, if there would be a service that runs all the stuff that you were just talking about headless in the cloud, I would I would hands down for sure. Yeah, great. Yeah, me too. Sign me up. Yeah, like even though Google is now kind of spearheading it with MCPI, do think it's possible to

create your own. And I, I am assuming that there's going to be an open version, open source version that's basically an interface on top of a lot of things that we use in organizations already, basically solving the same problem. And it might not be as good. Maybe Google has some search optimization because that's what Google's good at in the 1st place. But still like tooling will become available crossing kind of application boundaries. And that's what I'm really

excited about. Like I feel like now we're talking with regards to not just kind of solving my local problems with productivity, but also crossing boundaries in what do I actually have in my application in the 1st place or in my organization landscape in the first place. Yeah, absolutely. So you mentioned on the, on the FOMO topic, you mentioned that you'd love to do more on the, I don't know, building and the, the kind of the risk taking side. I suppose.

What are some of the areas that excite you the most because you see a lot of stuff happening specifically from your role, right? And interactions with so many people Also through the podcast, I'm always very curious because you're good at like providing an aggregate on all the experiences and conversations you have. What are certain things that you're specifically excited about if you were to move in in

any direction? I feel like that's difficult, like I feel like my ideas are never good enough for me to go

kind of all in on that. I do see that when it comes to developer tooling and developer experience, like having developers as a user, I think strategically can be very smart within an organization because already one of the benefits of being in an organization is you get educational budget or you could budget to play around with tooling and developers use that because it's good for developers to educate themselves and play around with things. They become better, better

engineers. So then having something of a tool that specifically solves a certain problem and having that as business purpose and vision feels like strategically a very good decision. But I haven't come across kind of a problem space where I'm like, OK, that's what I want to solve. I have like a friend that's very much in the start up phase, even before AI, he was a visionary and he said that he's going to create kind of a code automation

tool. And it's very much what is now out there with AI, except he built it kind of himself where you start from an architecture standpoint, you create kind of your blueprint from an from a landscape standpoint and then it generates a lot of the code kind of custom for you. So it's still high code and you can interject. You would have to specifically with kind of his version of development, you would say, here is what I interject manually and you cannot override this part specifically.

So you have automation and manual code, high code next to each other. And I never subscribed to that for one simple reason that it's so invasive in the developer workflow that I have to fully buy into this tool because it changes everything. Otherwise I'm out. So it's kind of an all in thing. I recently saw another presentation. It was about Hope AI and they are open core, so they build on top of this component system. I forget what it's called. I think it's bit specifically

front end component system. And then they have an AI component on top of that. So you can generate all your bit components. It's very much similar to V0 and lovable where you can do a lot of prototyping, except it uses the convention of bit to structure your components, document them sit step by step and it has this nice way of kind of looking at component dependencies and breaking down higher order components into smaller sub components.

Also with bit then I was like, that's really cool, like from a prototyping standpoint, but if I were to go all in then it completely changes my developer way of working because my components are going to be high code. I'm going to use this tool that's basically kind of comparable to prototyping and I'm not going to be, how am I going to be using that with cursor or like it changes a lot of way of working. And those are the higher over,

let's say more impactful. I think higher bets when we're talking about product bets, bigger bets. And I think a lower bet and maybe a more smart strategic bet is to look into developer tooling, solving smaller problems with or without AI. To be honest, I don't necessarily mind, but I do think using AI is going to give you an edge with regards to giving. Like getting that up and running. Definitely.

That's really cool. I, I love to, it's, it's, it's funny to me that you say, on the one hand, I don't think my ideas are that good enough or, or yeah, they're not, they're not that solid, But on the other hand have so many cool ideas. Like that's more the strategy, but I don't know what to do. Well, that's where it starts, right? I think, you know, I think I've never or barely seen success come from knowing exactly what to build initially.

And that's also, that's because there's so many assumptions there, right? Like you, I mean, you were kind of explaining it. And like if you're forced to to adopt this tool that originates from this big vision and someone started from it, building that from zero to 1, and then, OK, the vision is realized and then you still have to then actually use it, right? I have to still adopt it. What do I feel? What do I think?

And that's obviously the actually much more important than achieving this particular product vision that you have. Yeah, so I think and that's that's why I mean, you can, you can go about this in two ways. And that was always the case, right? Like you, you pitch and you raise seed funding or pre seed funding and you kind of like buy your way to, to users, right? Like ad budget fundamentally is, is kind of what everyone did running ads.

And, and and you have the extreme stories where like you're literally subsidizing users for years, like Uber has done, right, like super cheap Ubers because VC capital was just funding it. And now finally, they're profitable and you can feel it in the price, unfortunately. Yeah, sadly. Sadly, yeah. And this happens all over the place.

And I think this is such an interesting time because for anyone that is in the, in the, in the, in the developer ecosystem, if you have subjective, subjective experience of certain things that could go better, like the stuff that you, that you described, I'd actually never thought about it, but I think it's, it's really, there's a lot of cool stuff there in terms of tooling that you could build to help people gradually or teams gradually implement vibe code

tools. I don't know what the perfect name of that would be. And I think back in the day, if you would imagine, I don't know, like a couple of years ago to build something like that slowly, like an open source project like I would. And I had these ideas myself as well, where like, oh, this would be cool to have. It would cost me a couple of weekends to get something really

basic up and running. And I need other people to help because, you know, I don't know, I don't have experience in this particular thing or it's just too much work. Now you can get to a prototype that is much, much better in a few weekends or in a few days or maybe one weekend. So I think it's a really great time to to iterate like that, just like the the whole like open source, giving things away for free, seeing how people use it.

And then once you realize this is cool to like then scale it out. It's it's, it's an amazing time for that. So I feel like, I don't know, it depends on whether the organization is open for that, but I would urge anyone to, to really like play around and have fun. Like it's super fun to try and build these kind of things. And there's probably so many things that can be solved and can be done better.

Also to improve developer experience, by the way, like I don't know about you, but I think there's a lot of stuff in developer experience that is not that great. Pretty bad actually do. You have an example. Yeah. I mean, it's very subjective because developer experience is is fundamentally A subjective thing. But I think diving into someone else's code is right now like you can. You can nowadays, of course, like through cursor, it's already much easier. But I can open someone else's

code. Imagine a micro service situation that we're in, and I need to understand something about whatever update someone has done to a service, installing all the libraries, getting it to run locally. I don't know if there's any other dependencies. I don't understand any of the code. That person might be reachable, but they're super busy. That is something that is now much easier to do theoretically,

right? Like knowing exactly how to install everything, being able to do the, for example, if you do a GPTD research on all the libraries and you would like to try to figure out whether if there's any nuances you should know about when installing it and generating like basically a step by step on how to run the service if you're not the developer of this service. Those kind of things probably not done yet in a lot of bigger organizations or smaller

organizations. I would love to see something like that. And I think if there's a tool for that, probably, I mean, you can, you can build, build and distribute it for free. And then someone has to base in their their token, their token. Yeah, but that's like one example. I could build that, right? That's like, that's not bad and. We all know the frustration. It's like, you know, how does this?

I don't know. I remember doing that with a Scala Scala code base, which I know all the JVM ecosystem is complicated enough as it is. Yeah, interesting. I haven't looked at like that's what people tell me. Look in your own way of working and then see what you can improve, what frustrates you or what would inspire you to make make change there. And I only have like I've been out for a bit, but those things kind of are not really top of

mind anymore. Like I would love for a project that I build and eventually maybe run even to be in a solution space maybe which is not even tech. It could be like we talked about physical products. I've had thoughts of like opening a restaurant, but that's completely out of tech. I don't know how it can fit tech in there yet. But otherwise I have like nutrition. I have sports like health in general, anime, manga, yeah, food like in those spaces I

haven't even thought of yet. Oh, that's cool. Yeah, that's it's, it's actually such a good way to think about it because I, I personally feel that I mean, some founders like they have the big vision and they go fully like, I don't know, B to B. And that's like this is it's often times it's not a problem that you yourself individually relate to that much, but you can, I got to know you can, you can sell the vision and you can make yourself believe in it. It's just. Big opportunity.

Big opportunity, yeah. And it makes sense. I think there's there's so much to say for the scratch your own itch, fix your own frustration stuff. And that's also what I realized is aligns more with what I like. And obviously it's easier now than it was before. And especially these areas that are nice to you. Like I I love the this thinker Naval Raficon and he has this quote. Do what feels like play for you

and work for others, right. And if you're really into anime, like I know the same goes for other types of content like movies or podcasts. It's pretty sometimes. I actually asked you this question the other day. We were talking what anime should I check out? I don't know. And I kind of withhold because I I, you know, I value my time. So I would love to have an anime that it's very likely to be really fun. And I asked you that is actually something that I would love to

be able to ask some tool. And I think if I were to ask GPT, it probably wouldn't understand me well enough. So that kind of stuff, I don't know if there's something out there, but it's cool because you are uniquely equipped to do that, right? And I think everyone has some personal interests that make them uniquely equipped to solve

a particular problem. And I think for those, yeah, like the amount of play and fun that you can have there, I don't know, it feels I'm very optimistic in that sense. I think there's a lot of cool stuff that. Yeah, yeah. That's why I went to like the We Get Innovation Day. So we basically get time to play around with something and I see people picking up a new framework or picking up a new language. I just wanted to make a game in VR.

Like maybe that's like, it says a lot about me, right? And then I wanted to use the tooling that was more so out there and try and experiment with that. But that's more from a, how do I get this done? Like I still have that kind of outcome in my mind. And even with this conversation, I'm going to go back, I'm going to try again because now I'm going to try and figure out how I can maybe do it in one or two prompts and see if I can better do it from scratch or not like that.

From an outcome standpoint, it does fulfil me a lot to kind of, you know, work on things that also excite me. So maybe I should more or so now navigate towards that. Yeah, I wouldn't, I would obviously it's, it's a very personal journey, but I would always say it's so worth it also from a fulfilment perspective. And I think also like one of the limiting factors for a long time was, was also money, right.

And I think slowly Angel investors and, and the like are waking up to the concept of and, and people, people like Peter Levels, who is a, like a indie developer that's really big on Twitter and, and Danny Postman. Those are funny enough, they're both Dutch. Those are people that kind of have, they have inspired a lot of others to, to build in this way. I think investors are starting to realize that this is actually, it's obviously not the

10 XVC model, right? But they're starting to realize that this is actually a potentially a very good way to to create value and value can generate profits. So I feel like there's, there's a lot of opportunity there, Like if you're able to build something with a few users, it probably not that hard to attract some risk capital. Also, because it's not the amounts that you would need for

AVC backed company, right? Because you're on your own, Maybe you need one or two people to help you out and some growth and design stuff and that's it. And I was even playing around with this concept and I think someone like Peter levels

already kind of does this. Like he has an idea, they launch, he has distribution, right, But launches a a website or puts it on his Twitter, gets sign ups and then starts building the thing because he just realized, Oh, there's actually like someone that likes this.

You can do that with, with smoke tests like running ads and it doesn't have to be that expensive and then verify, Oh, you know, would people probably like this and then you can start trying trying to build it. Eventually we can even see models like, and I thought about doing this myself, but it's probably not the position that I'm in or most equipped to do. But if you have a good Twitter following or something, people can subscribe to your Twitter, right?

You could say I'm a I'm going to build full time, I'm going to build tools and it's all going to be in these directions or of interests. If you like this kind of stuff, subscribe to me and you'll get free access to all these tools. And then you have like a subscriber base that generates your revenue effectively that you can fund your lifestyle with and then have fun building all these things.

I think those, those models and it's, it's not too crazy anymore to think about that because influencers are kind of doing that, right? Like they just, they create something that people find cool and they pay them through in this case, like products advertisement, but you can also earn money on the advertising stuff within your app. And then if people subscribe to your Twitter, it's they don't see the advertisement. There's a lot of models you can

think about. And I think, yeah, like if you're if, if you're comfortable being a solar builder and you have fun stuff in the game direction or like interactive things that you love playing around with, man, yeah, go for go for it. Yeah, like the the skills that solar builders have and kind of the mindset of and also the ability to create I think are just going to be more valuable.

So it's both from an interest standpoint as well as maybe a bit towards the future because I feel like with AI we're going to cost reduce. I would love to be in a world where we don't cut headcount, but we do more with the headcount that we have. Yet it's not the pattern that

I've been seeing. So with people that are basically being laid off, either they're going to join other organizations, but then it's kind of this cascading effect that when they adopt AI and AI gets better, let's headcount potentially. So then you have to be really good at creating something from scratch yourself. And if more people start to do that, and I'm already good at that, I feel like my skill set is going to be valuable.

So it's both from a this is going to be a lot of fun standpoint as well as from what this is potentially very valuable for the future, right. If you use kind of what is latest out there like Peter Levels does or I, I don't know Danny postmod that that well, but I've definitely been inspired by that and also like the numbers he puts out. Not, not horrible with regards to the monthly recurring revenue. Yeah, like creating a playing game and then having advertisements on the buildings.

Like on a nutshell. I've only seen that on the surface level, but it it sounded genius to me. Yeah, yeah, Yeah. No, it's going really well. And I think I mean the whole, you know, a lot of founders end up with nothing sometimes, right? So in this case, this gradual indie hacking, it's also closer, I feel personally, to the creator's like the ideal psychological pattern for a creator, right? Like shorter feedback loops, less external pressure.

You have control over where you go with things. It's building a public, interacting with people. I think there's something about that that is really quite natural and organic to and I like thinking about these things because I think building is a very innate human desire, you know, to, to we're, we're, we're literally tool organisms. This is, this is, this is what we are in, in terms of how we

interact with the world. So I feel like this is a very, it's very much aligned with part of our, our, our nature in a sense. So I think there, there's something there I think worth worthwhile exploring.

I just want to double, double click on what you just mentioned with people being laid off because I obviously I'm not in, in amidst these feedback loops, but I, I, I have the idea that this is a, or restructuring, a reorganization of resources, but not as much people being being fired because they're, they're truly redundant like certain organizations. They just need less people to achieve something.

But I think if I think if I think about the total demand for software, especially considering the cost of production of software has gone down so much, I think we have a lot of demand for software and now that it's cheaper, I think there's so much stuff that can be built. So I'm, I'm personally, and maybe we're in a lucky position because we're product minded and all of that stuff, but I don't think there's a huge risk to be completely out of a job if you're, if you're a developer,

But maybe I'm seeing that wrong. I think, I think there's no risk if you stay on top of things like, and, and it's maybe also the developer adjacent roles that are being being laid off. Maybe not necessarily engineers, but I have, I mean, even in my close circle of friends, like people that have just been laid off, even if they're engineers or close to engineering within tech, like it's definitely happened.

And then it takes them a long time potentially also for the kind of stature of companies they're applying for, but it takes them a long time to find something comparable. Like if you come from a big organization and your department has been cut because it's not making impact the same way or they're restructuring be organising companies can do that. It's a thing. So then all of a sudden you're obsolete and you find yourself

without a job. If you want to get to kind of an equal level of company, either you have to compromise potentially for something less or it's going to take a long time, especially nowadays. That's kind of what I've seen from an observation standpoint. I see. And also, if, let's say generating code to get things up and running, or to execute things, or to get to a certain level of quality that is high or that is at least acceptable, becomes better and better. Then I feel like, yeah, lesser

people can do more. I just hope that with more people you're going to do more in general instead of trying to work with lesser people. Yeah, now I hope exactly the same. And I'm, I'm trying to like steel man that point, I guess, you know, out of out of maybe, maybe desperation. But it, it sounds to me like certain certain positions and jobs as as, as, as being functions in a company will be made redundant.

So it will force adaptation. But yeah, my hypothesis would be that there's still so much demand for software overall. Also because there's like in terms of frustration, like in most apps, there is stuff that really doesn't work about. We were talking about Siri. I'm still really disappointed in everything banking today. Like we can, we can do, we can do better. I can I can send you a bank request, a payment request. Finally, yeah yeah and a multi

currency. We got it, you know, but like there's just so much stuff that that can be improved there also in terms of fees, whether those are actually like really tangible impacts. So, and that's still all software. So it's not necessarily the deep tech, but also like the superficial levels.

I think I, I would hope that there's more than enough to be done for those that are, that are that are looking for for new things to do. But I can imagine that these transitionary periods can be tough if you're used to one particular way of working and you've done it for years and

then. Yeah, absolutely. Yeah, I was thinking one of the topics I want to get into, and I don't know what of this conversation kind of triggered it, but 3 1/2 years ago, for the people that don't know, Zoe also did an episode with me. I think you're one of the earliest people to actually come on the podcast. But you struck me as a guy that very much is aware of the time he spends on certain things. Like you're very much time aware. I I choose to spend time on this

versus this. And I'm wondering how nowadays you spend your time with regards to whatever you're trying to achieve. Right, You're saying I'm trying to build something from scratch. That's what you're working on nowadays, but you're also mindful of tooling that is out there and experimenting with the rest of what works and what doesn't work. How do you spend your time nowadays to achieve the things you want? Yeah, I love that question and also thank you for having me again. Really fun.

Happy to have you, yeah. Yeah, really cool. So I mean, as you said, I try to be conscious of how I spend my time and reflect on that. I think I was lucky because I gave myself around a year to quote UN quote figure things out. And so I started 5 experiments in parallel to try and decide what I wanted to build next. And that also very much it relates to the topic we were discussing before. You know, your own frustrations and and kind of the fulfillment you get from what you're

building. SO2 projects remained and I realized I love bringing builders and founders and operators together because I think you get really interesting conversations and, and you know, collaborations and new products that are being built. So I start organising retreats just to, yeah, to, to, to organise these kind of things where new ideas can, can, can be fostered and, and people have

fun. And also in a less, in a much more social kind of Co living situation like you can, you can organize a dinner, which is fun, but it still is somewhat stiff. And I think conversations can last weeks or days. And so creating an environment where one conversation can last very long. I think also it's proportional to the, to the outcome that along with the conversation is the deeper you usually can go. So that's, that's one thing.

And that still stands. So we're doing that like once or twice a year, getting some people together. We're going to do something on boats in a month from now, which is really fun. And then I think in terms of the FOMO that we were talking about before, it's, it's been good to be able to really explore all the tools that are out there as

they came out. And I think it's, it's helped sometimes I forget how much like how much progress you can make if you just immerse yourself in all these new tools and, and it's, you know, if you're a self critical, then it's like, Oh, I'm not doing enough. And that's definitely something that I, that I can struggle with sometimes. You're probably. Right. I guess that sounds familiar. Yeah.

Which is a blessing and a curse and I think being able to be be be able to to use these tools while scratching my own itch. Building an actual product has been really fun. So I try to, I try to use and, and play around with, with software still as much as I can. And I, I had AI had a real crossroads moment where we were talking about physical stuff. And I still, to some extent in the future, would love to build

something physical. And I'm, I'm definitely like either by supporting founders that are doing that or, you know, just have exploring it a little bit and talking to founders that, that are in, in this, in this domain. I still also realize that I've always found it so much fun to build digitally. It's like it's just truly a playground. And while we still have the freedom to do so, like while they're still demand, I think like I'm good, I'm just going to go all in on that.

So I'm still doing that. Like most of my time is spent coding, which I hadn't done in a few years. Like last time we spoke like CTO stuff. I still did a lot of dev OPS things and reviews and stuff, but I was actually kind of out of it of like real software engineering. And I, I have to say that it's, it's, I mean, it's, as I mentioned before, it's not as fun to do vibe coding all the time.

So in terms of time spent, I will likely reduce the, the amount of time that I spent vibe coding over time and, and learn more towards the, the product side, which is like a transition you've already made. I don't know exactly where that balance would be, but I think I think there's a lot of leverage

there. And I think if you spend say half a year to a year talking to people and thinking about things from a product level, you, you do get some the experience that you get through that is something that you can leverage quite well. And I think if you also have the technical expertise, then I think you can build quite, yeah, quite cool stuff with less effort than someone that hasn't

spent that amount of time. So I'm, I'm noticing that's kind of like where I'm organically trending towards gotcha. And yeah, lastly, lastly, the problem that I would that I'm really trying to solve is I think we're going to, as we already kind of touched upon, but we're going to end up in a, in a big, in a situation with a lot of demand for re re skilling or up skilling. And I love learning stuff. I think the tools that are out there to learn, and nowadays GPT

is one of them. And like Notebook, LM and all of those, they're great, but they're not personalized enough. I also struggle with finding content, not only anime, but books, podcasts, all of that stuff. Yeah. So I figured that's a problem I want to solve. I love doing it through software. I want to remember what I read. I want to find good content. I want to follow people that I find interesting. And I want to have AI help me learn abstract skills, like, I don't know, philosophy.

I'm really into like, you know, define happiness like that. That's the never ending question. And so I'm trying to build something that kind of pulls all those all those things together into one platform big task. And I'm glad that Vibe coding became as good as it is. Can I already download it? Is it at that stage? Yeah, it's we have test flight, so we're going to launch on like the production app in the App Store in a couple of weeks from

now. And we can probably put a link in the show notes or something to like the sign up. And I'd love to have beta testers like to try and like understand how people like learning and how people like finding new content. It's very much focused on the productive content consumption. So like reduce the noise. For example, you can send us newsletters and podcasts we ingest already and so we can extract the most relevant bits from it because there's a lot of generic content out there.

And the most average newsletter that I get in my inbox, I think 20% is truly interesting and it's still, I want to get that 20%. So we're trying to like extract that for you. And I just want to understand how people like doing those kind of things. It's very much to, to, to help you get more use from your time spent on a device. And, and not necessarily like, I don't know, I don't have Instagram or I don't really use it and Facebook and all that stuff.

And I think that's kind of the the audience that I'm going for is very much that that corner of the Internet. Yeah. I can't wait to try it out, not just because I know you, but also just from a, let's say product standpoint and a product vision. See how this thing is going to mesh because I know it's something you've you've built. I know it's something you've been building. It's also something that you're very passionate about for yourself, like scratching your

own H kind of thing. So I can't wait to try it out. I think it's gonna be fun. Also from your perspective, no, because you have been in this building phase. Have you done any user testing kind of during building or what have you done with regards to validation? Yeah, loads of. The only reason this product is still standing is because I well, I spoke to a lot of people, like a lot of interviews, and I realized that everyone there was like a a high moment for me.

Everyone I spoke to, doctors, PhD researchers, postdocs, software engineers, founders, they all to some extent had a personal library in their pocket. I don't know, they knew used Notion or Obsidian or Apple Notes and all of that. And but they didn't actually use the information in there. But their, their aim on average was like to remember stuff to keep learning. But they somehow struggled. Like they, they, they everyone checked the box of like, I save stuff.

I have a system for it, but I don't know how to use it. So that's kind of where the user testing led me to try and build this particular product. And the reason it's still standing now is because I literally just shoved the app app under people's noses. And some of them were like, oh, dude, I would love to put my all my, my whole system into this. Like, can I, can I already use it? And I was like, well, yeah. And I'm not really ready for that yet. Can I help?

And now, so the team has actually grown because people are like, I want to help. And, and, and so I've been really lucky with that. Good people. Yeah. So that was motivating. I think that's and and looping back just real really quickly to like, you know what you mentioned, like, I don't know if my ideas are good enough. I had no clue. I just felt like I'm just going to try.

And if people were like, I don't know, they just reacted the right way and maybe I'm still, maybe I'm delusional and this whole project will fail. I don't know. It could be that's always like that could be a reality. But like, just, yeah, just giving it to people, it's the only reason I'm still going, because it's also just a motivational thing. Otherwise it's quite tiring to build something on your own, I think. I think like psychologically speaking.

That's superhuman. Yeah. Like the fact that whatever you're excited about, other people are excited about. That's like, probably very fulfilling and amplifying, right? And that's the energy to keep going. Yeah. I never thought about that. Like I, I think I've mentioned to you before, for me, the starting is like the worst bit, like creating something from scratch and then maybe I can use that.

I've learned that doing stuff together, that really helps, not just from a starting standpoint, but also from the accountability that I feel like if we're starting with other people, I'm not pulling my own weight. Like that sucks. Like I would never want to be in that position. Therefore, I move and I try and move and do the best I can because that's also the level of accountability. It's like, yeah, we're doing this together, so we go for it.

And then having people that kind of validate early on, I think is going to amplify and be the fuel that you need to actually keep going. I think that's very valuable. Yeah, One thing that I'm recently, I don't know where I picked that up, but I love quotes like, I don't know, kind of the poetic way to summarize wisdoms. It's not it's not the destination that is important. It's also not the journey, but it's the company. And I think I'm starting to like live more by that ethos.

And you know, originally I was like, I guess I was at level 2, like, Oh yeah, the destination on import. But the journey is but. That's where I am at. Yeah, yeah, yeah. That's very cool, man. I'm going to, I'm going to leave it off on that. Food for thought to round off on. Thank you so much for coming on, man. This was a blast. Yeah, my pleasure. Thanks, man. We're. Going to round it off here. This is going to be episode 200.

Thank you so much for listening. The best way to support the show is to leave a comment. Let us know what you thought. Episode is a little bit longer as well, so I'm very curious to hear what you're thinking and otherwise we'll see you in the next one.