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.